From: Tom Lane <tgl@sss.pgh.pa.us>
To: Matthias van de Meent <boekewurm+postgres@gmail.com>
cc: Justin Pryzby <pryzby@telsasoft.com>, pgsql-hackers@postgresql.org
Subject: Re: v16dev: TRAP: failed Assert("size > SizeOfXLogRecord"),
 File: "xlog.c", Line: 1055, PID: 13564
In-reply-to: 
 <CAEze2Wg+Pbec3jaaUSF8E6Piy=bq=gXkFCFyaYwFDYTDjCMSvg@mail.gmail.com>
References: <ZD1daibg4RF50IOj@telsasoft.com>
 <CAEze2Wg+Pbec3jaaUSF8E6Piy=bq=gXkFCFyaYwFDYTDjCMSvg@mail.gmail.com>
Comments: In-reply-to Matthias van de Meent <boekewurm+postgres@gmail.com>
	message dated "Mon, 17 Apr 2023 18:50:40 +0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2444560.1681748021.1@sss.pgh.pa.us>
Date: Mon, 17 Apr 2023 12:13:41 -0400
Message-ID: <2444561.1681748021@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2444561.1681748021%40sss.pgh.pa.us>
Precedence: bulk

Matthias van de Meent <boekewurm+postgres@gmail.com> writes:
> Looking at log_newpage_range, it seems like we're always trying to log
> a record if startblk < endblk; but don't register the PageIsNew()
> buffers in the range. That means that if the last buffers in the range
> are new, this can result in no buffers being registered in the last
> iteration of the main loop (if the number of non-new buffers in the
> range is 0 (mod 32)).

Yeah, I just came to the same conclusion.  One thing I don't understand
yet: log_newpage_range is old (it looks like this back to v12), and
that Assert is older, so why doesn't this reproduce further back?
Maybe the state where all the pages are new didn't happen before?
Is that telling us there's a bug somewhere else?  Seems like a job
for git bisect.

To be clear: log_newpage_range is certainly broken, and your fix looks
appropriate.  I'm just wondering what else we need to learn here.

			regards, tom lane