From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | Re: pgsql: Avoid improbable PANIC during heap_update. |
Date: | 2022-10-01 01:29:28 |
Message-ID: | CAH2-WznFSJs7UcO1yhTWiQHjYh4PYJULc3UXz+uftLVSNcUh-Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Fri, Sep 30, 2022 at 5:09 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> In any case we cannot really treat the information that we have about
> that as a bug report -- not as things stand. Why should the question
> of whether or not we ever set a page PD_ALL_VISIBLE without a cleanup
> lock on v13 be a mystery at all? Why wouldn't a simple grep get to the
> bottom of it? I have to imagine that the true explanation is very
> simple and boring.
I talked to Robins about this privately. I was wrong; there isn't a
simple or boring explanation.
Robins set out to find bugs like this in Postgres via stress-testing.
He used a lab environment for this, and was quite methodical. So there
is no reason to doubt that a PANIC happened on v13 at least once.
There must be some relatively complicated explanation for that, but
right now I can only speculate.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2022-10-01 02:44:40 | pgsql: meson: mingw: Add -Wl,--disable-auto-import, enable when linking |
Previous Message | Peter Geoghegan | 2022-10-01 00:09:50 | Re: pgsql: Avoid improbable PANIC during heap_update. |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2022-10-01 01:44:52 | Re: problems with making relfilenodes 56-bits |
Previous Message | Bharath Rupireddy | 2022-10-01 01:29:26 | Re: An attempt to avoid locally-committed-but-not-replicated-to-standby-transactions in synchronous replication |