From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: ProcessStandbyHSFeedbackMessage can make global xmin go backwards |
Date: | 2011-10-21 15:59:39 |
Message-ID: | 11236.1319212779@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
> On Wed, Oct 19, 2011 at 6:04 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> ProcessStandbyHSFeedbackMessage has a race condition: it thinks it can
>> call GetOldestXmin and then the result will politely hold still while
>> it considers what to do next.
> curious: are these bugs in production, and what would be the user
> visible symptoms of seeing them in the wild?
There's no bug so far as data integrity on the master goes. The risk
is that you'd see queries failing with replication conflicts on a
hot-standby slave even though you thought you'd protected them by
setting hot_standby_feedback = on. That would happen if any rows
actually got vacuumed despite the standby's attempt to set an xmin
that would protect them. This is possible anyway at walsender
startup, but I think the logic errors made it more probable.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Florian Pflug | 2011-10-21 16:05:03 | Re: Synchronized snapshots versus multiple databases |
Previous Message | Marti Raudsepp | 2011-10-21 15:57:47 | Re: pg_comments (was: Allow \dd to show constraint comments) |