From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Kevin Grittner <kgrittn(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: snapshot too old issues, first around wraparound and then more. |
Date: | 2020-04-02 00:26:04 |
Message-ID: | CAH2-Wznz_uBRoPvtTu47Z3mFTHXSbTagQ-15BC+hpCiFtKvi=w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Apr 1, 2020 at 4:59 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> Thanks, that's super helpful.
Glad I could help.
> I got a bit confused here - you seemed to have switched session 1 and 2
> around? Doesn't seem to matter much though, I was able to reproduce this.
Yeah, I switched the session numbers because I was in a hurry. Sorry about that.
As you have already worked out, one session does all the DDL and
initial loading of data, while the other session queries the data
repeatedly in a serializable (or RR) xact. The latter session exhibits
the bug.
> This indeed seems a separate bug.
> The primary issue here is that there is no TestForOldSnapshot() in
> heap_hot_search_buffer(). Therefore index fetches will never even try to
> detect that tuples it needs actually have already been pruned away.
I suspected that heap_hot_search_buffer() was missing something.
> The wrong queries I saw took longer to reproduce, so I've not been able
> to debug the precise reasons.
How hard would it be to write a debug patch that reduces the quantum
used in places like TransactionIdLimitedForOldSnapshots() to something
much less than the current 1 minute quantum? That made reproducing the
bug *very* tedious.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Alexey Bashtanov | 2020-04-02 00:29:04 | Re: control max length of parameter values logged |
Previous Message | David Zhang | 2020-04-02 00:20:12 | Re: Allow continuations in "pg_hba.conf" files |