Re: [HACKERS] ProcessStandbyHSFeedbackMessage can make global xmin go backwards

2011-10-21 Thread Alvaro Herrera
Excerpts from Tom Lane's message of jue oct 20 19:20:19 -0300 2011: So I've concluded that there's just no point in the GetOldestXmin clamping, and we should just apply the xmin value we get from the standby if it passes basic sanity checks (the epoch test), and hope that we're not too late

Re: [HACKERS] ProcessStandbyHSFeedbackMessage can make global xmin go backwards

2011-10-21 Thread Merlin Moncure
On Wed, Oct 19, 2011 at 6:04 PM, Tom Lane t...@sss.pgh.pa.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.  But in fact, whoever has the oldest xmin could exit

Re: [HACKERS] ProcessStandbyHSFeedbackMessage can make global xmin go backwards

2011-10-21 Thread Tom Lane
Merlin Moncure mmonc...@gmail.com writes: On Wed, Oct 19, 2011 at 6:04 PM, Tom Lane t...@sss.pgh.pa.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:

Re: [HACKERS] ProcessStandbyHSFeedbackMessage can make global xmin go backwards

2011-10-20 Thread Tom Lane
I 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. But in fact, whoever has the oldest xmin could exit their transaction, allowing the global minimum to advance.

[HACKERS] ProcessStandbyHSFeedbackMessage can make global xmin go backwards

2011-10-19 Thread Tom Lane
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. But in fact, whoever has the oldest xmin could exit their transaction, allowing the global minimum to advance. If a VACUUM