Re: Hot standby, dropping a tablespace

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Hot standby, dropping a tablespace
Дата
Msg-id 497C30CA.7090908@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Hot standby, dropping a tablespace  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Hot standby, dropping a tablespace  (Simon Riggs <simon@2ndQuadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Hot standby, dropping a tablespace
Следующее
От: Bernd Helmle
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Automatic view update rules Bernd Helmle