Hi,> > MaxAllocSize is pretty easy:
> > SELECT pg_logical_emit_message(false, long, long) FROM repeat(repeat(' ', 1024), 1024*1023) as l(long);
> >
> > on a standby:
> >
> > 2022-03-11 16:41:59.336 PST [3639744][startup][1/0:0] LOG: record length 2145386550 at 0/3000060 too long
>
> Thanks for the reference. I was already playing around with 2PC log
> records (which can theoretically contain >4GB of data); but your
> example is much easier and takes significantly less time.
A little confused here, does this patch V3 intend to solve this problem "record length 2145386550 at 0/3000060 too long"?
I set up a simple Primary and Standby stream replication environment, and use the above query to run the test for before and after patch v3. The error message still exist, but with different message.
Before patch v3, the error is showing below,
2022-06-10 15:32:25.307 PDT [4253] LOG: record length 2145386550 at 0/3000060 too long
2022-06-10 15:32:47.763 PDT [4257] FATAL: terminating walreceiver process due to administrator command
2022-06-10 15:32:47.763 PDT [4253] LOG: record length 2145386550 at 0/3000060 too long
After patch v3, the error displays differently
2022-06-10 15:53:53.397 PDT [12848] LOG: record length 2145386550 at 0/3000060 too long
2022-06-10 15:54:07.249 PDT [12852] FATAL: could not receive data from WAL stream: ERROR: requested WAL segment 000000010000000000000045 has already been removed
2022-06-10 15:54:07.275 PDT [12848] LOG: record length 2145386550 at 0/3000060 too long
And once the error happens, then the Standby can't continue the replication.
Is a particular reason to say "more datas" at line 52 in patch v3?
+ * more datas than are being accounted for by the XLog infrastructure.
On 2022-04-18 10:19 p.m., Michael Paquier wrote:
On Mon, Apr 18, 2022 at 05:48:50PM +0200, Matthias van de Meent wrote:
Seeing that the busiest time for PG15 - the last commitfest before the
feature freeze - has passed, could someone take another look at this?
The next minor release is three weeks away, so now would be a good
time to get that addressed. Heikki, Andres, are you planning to look
more at what has been proposed here?
--
Michael
--
David
Software Engineer
Highgo Software Inc. (Canada)
www.highgo.ca