Re: pgsql: Avoid improbable PANIC during heap_update.
От | Peter Geoghegan |
---|---|
Тема | Re: pgsql: Avoid improbable PANIC during heap_update. |
Дата | |
Msg-id | CAH2-WzmpfcbFxb=CNC4JiCzLLCGrWyWSV2kxaXVew9owKk4nrA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pgsql: Avoid improbable PANIC during heap_update. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgsql: Avoid improbable PANIC during heap_update.
|
Список | pgsql-committers |
On Fri, Sep 30, 2022 at 4:52 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:> > I would be more confident here were it not for the recent > > heap_delete() issue reported by one of my AWS colleagues (and fixed by > > another, Jeff Davis). See commit 163b0993 if you missed it before now. > > Hmm, okay, though that's really a distinct bug of the same ilk. > You're right that I'd not paid close attention to that thread after > Jeff diagnosed the problem. I just meant that I don't feel particularly confident about what might be possible or likely in Postgres 14 with this new issue in heap_update() on point releases without today's bugfix. My theory about lazy_scan_noprune() might be correct, but take it with a grain of salt. > It does seem like Robins' report > shows that there's some way that v13 will set the AV bit without > a cleanup lock ... does that constitute a bug in itself? We never got to the bottom of that part, strangely enough. I can ask again. 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. -- Peter Geoghegan
В списке pgsql-committers по дате отправления: