From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Hot standby, RestoreBkpBlocks and cleanup locks |
Date: | 2009-01-15 16:16:06 |
Message-ID: | 496F6146.5040008@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs wrote:
> The idea outlined before didn't deal with all call points for
> RecordIsCleanupRecord(), so doesn't actually work.
Hmm, grep finds two call points for that:
> ! case RECOVERY_TARGET_PAUSE_CLEANUP:
> ! /*
> ! * Advance until we see a cleanup record, then pause.
> ! */
> ! if (RecordIsCleanupRecord(record))
> ! pauseHere = true;
> ! break;
> !
and
> + /*
> + * Wait, kill or otherwise resolve any conflicts between
> + * incoming cleanup records and user queries. This is the
> + * main barrier that allows MVCC to work correctly when
> + * running standby servers. Only need to do this if there
> + * is a possibility that users may be active.
> + */
> + if (reachedSafeStartPoint && RecordIsCleanupRecord(record))
> + ResolveRedoVisibilityConflicts(EndRecPtr, record);
The second we can easily handle by getting rid of
ResolveRedoVisibilityConflicts functions and making the redo-functions
call XactResolveRecoveryConflicts when necessary.
Is the first really useful? I would understand "advance until next
cleanup record *that would block/kill queries*", but why would you want
to advance until the next cleanup record? Anyway, if it is useful, you
could do the pausing in XactResolveRecoveryConflicts, too.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-01-15 16:16:44 | Re: FWD: Re: Updated backslash consistency patch |
Previous Message | Tom Lane | 2009-01-15 16:15:41 | Re: BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION |