Horton
Menu

Re: logical decoding - GetOldestXmin

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Andres Freund <andres@2ndquadrant.com>
Cc: Simon Riggs <simon@2ndquadrant.com>, Peter Geoghegan <peter@2ndquadrant.com>, pgsql-hackers@postgresql.org
Date: 2012-12-14T19:01:30Z
Lists: pgsql-hackers 
On Fri, Dec 14, 2012 at 6:46 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> Just moving that tidbit inside the lock seems to be the pragmatic
> choice. GetOldestXmin is called
>
> * once per checkpoint
> * one per index build
> * once in analyze
> * twice per vacuum
> * once for HS feedback messages
>
> Nothing of that occurs frequently enough that 5 instructions will make a
> difference. I would be happy to go an alternative path, but right now I
> don't see any nice one. A "already_locked" parameter to GetOldestXmin
> seems to be a cure worse than the disease.

I'm not sure that would be so bad, but I guess I question the need to
do it this way at all.  Most of the time, if you need to advertise
your global xmin, you use GetSnapshotData(), not GetOldestXmin(), and
I guess I'm not seeing why that wouldn't also work here.  Am I dumb?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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