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
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 |