Re: Hot standby, dropping a tablespace - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Hot standby, dropping a tablespace
Date
Msg-id 497C30CA.7090908@enterprisedb.com
Whole thread Raw
In response to Re: Hot standby, dropping a tablespace  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Hot standby, dropping a tablespace
List 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


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Hot standby, dropping a tablespace
Next
From: Bernd Helmle
Date:
Subject: Re: [COMMITTERS] pgsql: Automatic view update rules Bernd Helmle