From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Hot standby, conflict resolution |
Date: | 2009-01-23 20:13:31 |
Message-ID: | 1232741611.2327.1312.camel@ebony.2ndQuadrant |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 2009-01-23 at 21:30 +0200, Heikki Linnakangas wrote:
> >> Correct me if I'm wrong, but I thought the idea of this new conflict
> >> resolution was that the startup process doesn't need to wait for the
> >> target backend to die. Instead, the target backend knows to commit
> >> suicide if it stumbles into a buffer that's been modified in a
> >> conflicting way. Looking at ResolveRecoveryConflictWithVirtualXIDs, it
> >> looks like we still wait.
> >
> > err, no, that's just an oversight, not intentional.
>
> Ok, then I think we have a little race condition. The startup process
> doesn't get any reply indicating that the target backend has processed
> the SIGINT and set the cached conflict LSN. The target backend might
> move ahead using the old LSN for a little while, even though the startup
> process has already gone ahead and replayed a vacuum record.
Hah! You had me either way. Very neat :-)
I'll think some more and reply, but not tonight.
> Another tiny issue is that it looks like a new conflict LSN always
> overwrites the old one. But you should always use the oldest conflicted
> LSN in the checks, not the newest.
OK
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2009-01-23 20:13:43 | Re: Pluggable Indexes |
Previous Message | Greg Stark | 2009-01-23 20:13:22 | Re: Hot Standby (v9d) |