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: