> On Wed, May 18, 2011 at 04:02:59PM +0100, Leonardo Francalanci wrote: > > > By the time the startup process > > > releases the AccessExclusiveLock acquired by the proposed > > > UNLOGGED -> normal conversion process, that relfilenode > > > needs to be either fully copied or unlinked all over again. > > > (Alternately, find some other way to make sure queries don't > > > read the half-copied file.) > > > > About this issue: how are AccessExclusiveLocks released on > > the standby when the master crashes? > > I assume those locks remain. It wouldn't be safe to release them; a master > crash is just one kind of WAL receipt latency.
But somehow when the master restarts the standby gets notified it has the unlock??? > When you promote the standby, though, ShutdownRecoveryTransactionEnvironment() > releases the locks. Ok; then the problem in the UNLOGGED -> normal conversion is that: 1) the master and the standby acquire a lock on the table 2) the master starts sending the pages to the standby 3) the master crashes before committing up until here no problems, as the standby still has the lock on the table. 4) when the master restarts, it removes all the fork for rels with INIT forks; are those "deletes" sent to the standby? And, if yes, would those be replayed by the standby *before* releasing the lock? If the answer is "yes", then I don't think we have a problem... but I think that at the moment those unlogged-table-forks deletes aren't sent at all. (When promoting the standby, we could have ShutdownRecoveryTransactionEnvironment() remove all the fork for rels with INIT forks before releasing the locks) Leonardo -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
