On Thu, May 19, 2011 at 09:23:53AM +0100, Leonardo Francalanci wrote: > > 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???
I'd guess some WAL record arising from the post-crash master restart makes the standby do so. When a crash isn't involved, the commit or abort record is that signal. You could test and find out how it happens after a master crash with a procedure like this: 1. Start a master and standby on the same machine. 2. Connect to master; CREATE TABLE t(); BEGIN; ALTER TABLE t ADD c int; 3. kill -9 -`head -n1 $master_PGDATA/postmaster.pid` 4. Connect to standby and confirm that t is still locked. 5. Attach debugger to standby startup process and set breakpoints on StandbyReleaseLocks and StandbyReleaseLocksMany. 6. Restart master. > > 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. Correct. > 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. I think you are correct that they are not currently WAL-logged. > (When promoting the standby, we could have > ShutdownRecoveryTransactionEnvironment() remove all the fork for rels > with INIT forks before releasing the locks) Makes sense. nm -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
