Re: logical decoding bug: segfault in ReorderBufferToastReplace()

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: logical decoding bug: segfault in ReorderBufferToastReplace()
Дата
Msg-id 20191214002513.p5rw6vqenzvrud5y@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: logical decoding bug: segfault in ReorderBufferToastReplace()  (Jeremy Schneider <schnjere@amazon.com>)
Ответы Re: logical decoding bug: segfault in ReorderBufferToastReplace()  (Jeremy Schneider <schnjere@amazon.com>)
Re: logical decoding bug: segfault in ReorderBufferToastReplace()  (Jeremy Schneider <schnjere@amazon.com>)
Список pgsql-bugs
Hi,

On 2019-12-13 16:13:35 -0800, Jeremy Schneider wrote:
> On 12/11/19 08:35, Andres Freund wrote:
> > I think we need to see pg_waldump output for the preceding records. That
> > might allow us to see why there's a toast record that's being associated
> > with this table, despite there not being a toast table.
> Unfortunately the WAL logs are no longer available at this time.  :(
> 
> I did a little poking around in the core file and searching source code
> but didn't find anything yet.  Is there any memory structure that would
> have the preceding/following records cached in memory?  If so then I
> might be able to extract this from the core dumps.

Well, not the records directly, but the changes could be, depending on
the size of the changes. That'd already help. It depends a bit on
whether there are subtransactions or not (txn->nsubtxns will tell
you). Within one transaction, the currently loaded (i.e. not changes
that are spilled to disk, and haven't currently been restored - see
txn->serialized) changes are in ReorderBufferTXN->changes.


> > Seems like we clearly should add an elog(ERROR) here, so we error out,
> > rather than crash.

> done - in the commit that I replied to when I started this thread :)
> 
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=69f883fef14a3fc5849126799278abcc43f40f56

Ah, I was actually thinking this is the thread of a similar sounding
bug, where ReorderBufferToastReplace would crash because there isn't
actually a new tuple - there somehow toast changes exist for a delete.


> > Is this version of postgres effectively unmodified in any potentially
> > relevant region (snapshot computations, generation of WAL records, ...)?
> It's not changed from community code in any relevant regions.  (Also,
> FYI, this is not Aurora.)

Well, I've heard mutterings that plain RDS postgres had some efficiency
improvements around snapshots (in the GetSnapshotData() sense) - and
that's an area where slightly wrong changes could quite plausibly
cause a bug like this.

Greetings,

Andres Freund



В списке pgsql-bugs по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: BUG #16104: Invalid DSA Memory Alloc Request in Parallel Hash
Следующее
От: Jeff Janes
Дата:
Сообщение: Re: BUG #16162: create index using gist_trgm_ops leads to panic