Hi,
On 5/30/23 5:24 PM, Andres Freund wrote:
Hi,
On 2023-05-29 14:31:24 +0200, Drouvot, Bertrand wrote:
On 5/29/23 1:03 PM, Tom Lane wrote:
but I wouldn't be surprised if something in the logical replication
mechanism itself could be running a transaction at the wrong instant.
Some of the ot
Hi,
On 2023-05-29 14:31:24 +0200, Drouvot, Bertrand wrote:
> On 5/29/23 1:03 PM, Tom Lane wrote:
> > but I wouldn't be surprised if something in the logical replication
> > mechanism itself could be running a transaction at the wrong instant.
> >
> > Some of the other recovery tests set
> > autov
Hi,
On 5/29/23 1:03 PM, Tom Lane wrote:
"Drouvot, Bertrand" writes:
On 5/26/23 9:27 AM, Yu Shi (Fujitsu) wrote:
Is it possible that the vacuum command didn't remove tuples and then the
conflict was not triggered?
The flush_wal table added by Andres should guarantee that the WAL is flushed,
"Drouvot, Bertrand" writes:
> On 5/26/23 9:27 AM, Yu Shi (Fujitsu) wrote:
>> Is it possible that the vacuum command didn't remove tuples and then the
>> conflict was not triggered?
> The flush_wal table added by Andres should guarantee that the WAL is flushed,
> so
> the only reason I can think
On Monday, May 29, 2023 5:22 PM Drouvot, Bertrand
wrote:
>
> Hi,
>
> On 5/26/23 9:27 AM, Yu Shi (Fujitsu) wrote:
> > Hi hackers,
> >
> > I saw a buildfarm failure on "dikkop"[1]. It failed in
> > 035_standby_logical_decoding.pl, because the slots row_removal_inactiveslot
> and
> > row_removal_a
Hi,
On 5/26/23 9:27 AM, Yu Shi (Fujitsu) wrote:
Hi hackers,
I saw a buildfarm failure on "dikkop"[1]. It failed in
035_standby_logical_decoding.pl, because the slots row_removal_inactiveslot and
row_removal_activeslot are not invalidated after vacuum.
Thanks for sharing!
regress_log_035_st
