Re: switch UNLOGGED to LOGGED

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