On Sun, Jun 16, 2019 at 07:14:05PM -0700, Peter Geoghegan wrote:
> The WAL record in question, XLOG_BTREE_META_CLEANUP, is certainly one
> of the less common record types used by nbtree. I agree that this
> should have been tested when it went in, but I'm not surprised that
> the bug remained undet
On Sun, Jun 16, 2019 at 7:05 PM Michael Paquier wrote:
> I would have supposed that more people scan WAL records using the
> description callbacks.
The WAL record in question, XLOG_BTREE_META_CLEANUP, is certainly one
of the less common record types used by nbtree. I agree that this
should have b
On Sun, Jun 16, 2019 at 06:54:57PM -0700, Peter Geoghegan wrote:
> On Sun, Jun 16, 2019 at 6:31 PM Michael Paquier wrote:
>> I think that we could just patch nbtpage.c so as we fetch the
>> metadata using XLogRecGetBlockData(), and log its data.
>
> Don't you mean nbtdesc.c?
Yeah I meant nbtdesc
On Sun, Jun 16, 2019 at 6:31 PM Michael Paquier wrote:
> I think that we could just patch nbtpage.c so as we fetch the
> metadata using XLogRecGetBlockData(), and log its data.
Don't you mean nbtdesc.c?
> The error
> comes from 3d92796, which is one year-old and has been visibly
> committed unte
Hi all,
(Adding in CC relevant committer and author, Teodor and Alexander)
I have been looking today at a crash of pg_waldump on one of the test
builds keeping running in some internal environment. Luckily, I have
been able to put my hands on a core file with 11.2 running. The
backtrace is not t
