Re: ProcessStandbyHSFeedbackMessage can make global xmin go backwards

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

In response to

Browse pgsql-hackers by date

  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)