> 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, 
> 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

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)


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to