Re: switch UNLOGGED to LOGGED - Mailing list pgsql-hackers

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