Re: Hot standby, dropping a tablespace

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hot standby, dropping a tablespace
Date: 2009-01-25 09:28:42
Message-ID: 497C30CA.7090908@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs wrote:
> On Sat, 2009-01-24 at 21:58 +0200, Heikki Linnakangas wrote:
>> When replaying a DROP TABLE SPACE, you first try to remove the
>> directory, and if that fails, you assume that it's because it's in use
>> as a temp tablespace in a read-only transaction.
>
> That sounds like you think there another conclusion?

No, I think that assumption is correct.

>> You then call
>> ResolveRecoveryConflictWithVirtualXIDs to kill such transactions, and
>> try removing the directory again. But
>> ResolveRecoveryConflictWithVirtualXIDs doesn't wait for the target
>> transaction to die anymore (or at least it shouldn't, as we discussed
>> earlier), so that doesn't work AFAICS.
>
> The FATAL errors inflicted should be fairly quick to take effect, so
> waiting should not be a problem. We can make waiting for FATAL errors
> the standard response.

The call in tablespace replay uses ERROR, not FATAL. You don't need to
kill the whole session, just the current transaction.

It seems more and more to me that the FATAL and ERROR cases are really
quite different. Looking at the callers, there's four different needs
for GetConflictingVirtualXIDs+ResolveRecoveryConflictWithVirtualXIDs:

1. Kill all connections to a given database. Used when replaying DROP
DATABASE.

2. Kill all connections by given user. Hmm, not used for anything,
actually. Should remove the roleId argument from GetConflictingVirtualXIDs.

3. Kill all transactions using given tablespace as temp tablespace, FROP
TABLESPACE.

4. Mark all transactions that still see a given XID as running for
termination if they try to access a buffer with conflicting LSN (VACUUM,
btree-deletes).

All callers call GetConflictingVirtualXIDs first, and then
ResolveRecoveryConflictWithVirtualXIDs. That's a bit cumbersome; none of
the callers do anything else with the virtualxid array they get from
GetConflictingVirtualXIDs than pass it on to
ResolveRecoveryConflictWithVirtualXIDs. I'm thinking of an interface
consisting of three functions, replacing the current
GetConflictingVirtualXIDs and ResolveRecoveryConflictWithVirtualXIDs
functions:

/* Kill all connections to given database, wait for them to die */
void KillConnectionsToDatabase(Oid dbOid)

/* Kill all transactions that use given tablespace, wait for them to die */
void KillTransactionsUsingTablespace(Oid tablespaceOid)

/* Signal all backends that with xmin < limitXid that they need to abort
if they access a page with LSN >= conflict_lsn. (Or wait for them to
end, if max_standby_delay > 0). */
void ResolveRecoveryConflicts(Oid dbOid, TransactionId limitXid,
XLogRecPtr conflict_lsn, char *reason)

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bernd Helmle 2009-01-25 12:07:09 Re: [COMMITTERS] pgsql: Automatic view update rules Bernd Helmle
Previous Message Simon Riggs 2009-01-25 09:04:01 Re: Hot standby, dropping a tablespace