From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Leonardo Francalanci <m_lists(at)yahoo(dot)it> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: switch UNLOGGED to LOGGED |
Date: | 2011-05-19 09:20:20 |
Message-ID: | 20110519092020.GA2611@tornado.gateway.2wire.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Marko Kreen | 2011-05-19 11:41:41 | Re: Why not install pgstattuple by default? |
Previous Message | Leonardo Francalanci | 2011-05-19 08:23:53 | Re: switch UNLOGGED to LOGGED |