Re: Interesting glitch in autovacuum - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Interesting glitch in autovacuum
Date
Msg-id 20361.1221077464@sss.pgh.pa.us
Whole thread Raw
In response to Re: Interesting glitch in autovacuum  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Interesting glitch in autovacuum  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> writes:
> On Wed, 2008-09-10 at 11:52 -0400, Tom Lane wrote:
>> I'm thinking that maybe an appropriate fix is to insert a
>> GetTransactionSnapshot call at the beginning of InitPostgres'
>> transaction, thus ensuring that every backend has some vaguely sane
>> value for RecentGlobalXmin before it tries to do any database access.

> Can't we just set RecentGlobalXmin without getting a Snapshot?

Well, certainly building an MVCC snapshot is more than we (appear to)
need, but I'm of the opinion that what we have got here is an unexpected
way in which these specialized transactions are unlike all others.
I think the safest fix is to make them more like normal transactions,
rather than invent still other ways to do things.  If there were a
serious performance argument against that, then yeah, but I don't see
one.  Backend startup isn't cheap in any case, and neither is a VACUUM,
so the incremental cost involved here seems negligible.

> There's
> no need for a snapshot at that point is there? Just lock ProcArrayLock,
> read GlobalXmin, drop lock.

There's no "GlobalXmin" variable.  We'd have to use GetOldestXmin();
which is cheaper than GetSnapshotData, but not hugely so.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Interesting glitch in autovacuum
Next
From: Tom Raney
Date:
Subject: Re: Planner question