From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Improve checking for pg_index.xmin |
Date: | 2020-01-08 13:37:28 |
Message-ID: | 19520.1578490648@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> On 01/11/2019 01:50, Alexander Korotkov wrote:
>> This happens so, because we're checking that there is no broken HOT
>> chains after index creation by comparison pg_index.xmin and
>> TransactionXmin. So, we check that pg_index.xmin is in the past for
>> current transaction in lossy way by comparison just xmins. Attached
>> patch changes this check to XidInMVCCSnapshot().
>> With patch the issue is gone. My doubt about this patch is that it
>> changes check with TransactionXmin to check with GetActiveSnapshot(),
>> which might be more recent. However, query shouldn't be executer with
>> older snapshot than one it was planned with.
> Hmm. Maybe you could construct a case like that with a creative mix of
> stable and volatile functions? Using GetOldestSnapshot() would be safer.
I really wonder if this is safe at all.
(1) Can we assume that the query will be executed with same-or-newer
snapshot as what was used by the planner? There's no such constraint
in the plancache, I'm pretty sure.
(2) Is committed-ness of the index-creating transaction actually
sufficient to ensure that none of the broken HOT chains it saw are
a problem for the onlooker transaction? This is, at best, really
un-obvious. Some of those HOT chains could involve xacts that were
still not committed when the index build finished, I believe.
(3) What if the index was made with CREATE INDEX CONCURRENTLY ---
which xid is actually on the pg_index row, and how does that factor
into (1) and (2)?
On the whole I don't find the risk/reward tradeoff of this looking
promising. Even if it works reliably, I think the situations where
it'll help a lot are a bit artificial.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2020-01-08 13:56:23 | Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index. |
Previous Message | Dagfinn Ilmari Mannsåker | 2020-01-08 13:33:13 | Fixing parallel make of libpq |