Horton
Menu

Re: logical decoding - GetOldestXmin

Andres Freund <andres@2ndquadrant.com>

View thread
From: Andres Freund <andres@2ndquadrant.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Simon Riggs <simon@2ndquadrant.com>, Peter Geoghegan <peter@2ndquadrant.com>, pgsql-hackers@postgresql.org
Date: 2012-12-19T00:59:10Z
Lists: pgsql-hackers 
On 2012-12-18 19:56:18 -0500, Robert Haas wrote:
> On Tue, Dec 18, 2012 at 5:25 PM, anarazel@anarazel.de
> <andres@anarazel.de> wrote:
> > The problem is that at the time GetSnapshotData returns the xmin horizon might have gone upwards and tuples required for decoding might get removed by other backends. That needs to be prevented while holding the  procarray lock exclusively.
>
> Well, for the ordinary use of GetSnapshotData(), that doesn't matter,
> because GetSnapshotData() also updates proc->xmin.  If you're trying
> to store a different value in that field then of course it matters.

Absolutely right. I don't want to say there's anything wrong with it
right now. The "problem" for me is that it sets proc->xmin to the newest
value it can while I want/need the oldest valid value...

I will go with adding a already_locked parameter to GetOldestXmin then.

Thanks for the input,

Andres
--
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Background worker processes

  2. Rearrange storage of data in xl_running_xacts.

  3. Basic binary heap implementation.

  4. Embedded list interface

  5. Refactor xlog.c to create src/backend/postmaster/startup.c