Re: Interesting glitch in autovacuum

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Interesting glitch in autovacuum
Date: 2008-09-10 20:11:04
Message-ID: 20361.1221077464@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndQuadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Raney 2008-09-10 20:16:33 Re: Planner question
Previous Message Simon Riggs 2008-09-10 19:54:23 Re: Interesting glitch in autovacuum