Re: old_snapshot_threshold vs indexes
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>,
Kevin Grittner <kgrittn@gmail.com>
Date: 2019-08-26T22:59:38Z
Lists: pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes: > On Tue, Aug 27, 2019 at 9:28 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> It is hard to express what a bad idea it is to be asking for complex >> catalog searches while holding a buffer lock. We could easily get >> into undetectable deadlocks that way, for example. We need to refactor >> these call sites to arrange that the catalog lookup happens outside >> the low-level page access. > Hmm. Right. Perhaps the theory was that it was OK because it's > shared (rather than exclusive), or perhaps the catalog lookup was > sufficiently well hidden and was forgotten. I strongly suspect the latter. Also, it may well be that the unlogged-index check was not in the original design but was added later with insufficient thought about where it'd be called from. > At first glance it seems > like we need to capture PageGetLSN(page) while we have the lock, and > then later pass that into TestForOldSnapshot() instead of the page. > I'll look into that and write a patch, probably in a day or two. Hm, but surely we need to do other things to the page besides TestForOldSnapshot? I was imagining that we'd collect the RelationHasUnloggedIndex flag (or perhaps better, the RelationAllowsEarlyPruning result) before attempting to lock the page, and then pass it to TestForOldSnapshot. regards, tom lane
Commits
-
Avoid catalog lookups in RelationAllowsEarlyPruning().
- eeb68c1cddf3 10.11 landed
- b9c4ccfefca0 11.6 landed
- 8cc6016a8cd4 12.0 landed
- 720b59b55b84 13.0 landed
-
Fix deadlock in heap_compute_xid_horizon_for_tuples().
- 4fd05bb55b40 12.0 cited
-
Fix hash index vs "snapshot too old" problemms
- 2cc41acd8fa3 9.6.0 cited