> 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