Re: Why is subscription/t/031_column_list.pl failing so much? - Mailing list pgsql-hackers

From Alexander Lakhin
Subject Re: Why is subscription/t/031_column_list.pl failing so much?
Date
Msg-id e6ce3cf7-4025-f129-e3ac-0f778469f720@gmail.com
Whole thread Raw
In response to Re: Why is subscription/t/031_column_list.pl failing so much?  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Why is subscription/t/031_column_list.pl failing so much?
Re: Why is subscription/t/031_column_list.pl failing so much?
List pgsql-hackers
Hello Amit,

05.02.2024 15:20, Amit Kapila wrote:
> If this can be reproduced frequently then we can even try to test the
> patch in that thread by Osumi-San [1] (I haven't tested that it
> applies cleanly but shouldn't be difficult to make it work) based on
> the theory that walsender is starting up at an LSN somewhere before
> where the publication is created.
>
> [1] -
https://www.postgresql.org/message-id/TYCPR01MB83737A68CD5D554EA82BD7B9EDD39%40TYCPR01MB8373.jpnprd01.prod.outlook.com
>

Yes, with the aforementioned modification of bgwriter.c and when running
20 tests in parallel, I got failures on iterations 20. 3, 21 ..., but with the
updated Osumi-San's patch (which adds wait_for_catchup('sub1') before every
ALTER SUBSCRIPTION sub1 SET PUBLICATION ...) applied, 300 iterations ran
with no failures.

Best regards,
Alexander
Attachment

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: [PoC] Improve dead tuple storage for lazy vacuum
Next
From: jian he
Date:
Subject: recently added jsonpath method change jsonb_path_query, jsonb_path_query_first immutability