Re: Re: Minimal logical decoding on standbys - Mailing list pgsql-hackers

From Drouvot, Bertrand
Subject Re: Re: Minimal logical decoding on standbys
Date
Msg-id 46ec17a8-3c5d-7152-f6b0-ac122a5d0789@amazon.com
Whole thread Raw
In response to Re: Minimal logical decoding on standbys  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
List pgsql-hackers
Hi Peter,

On 8/26/21 1:35 PM, Peter Eisentraut wrote:
> CAUTION: This email originated from outside of the organization. Do 
> not click links or open attachments unless you can confirm the sender 
> and know the content is safe.
>
>
>
> I noticed the tests added in this patch set are very slow.  Here are
> some of the timings:
>
> ...
> [13:26:59] t/018_wal_optimize.pl ................ ok    13976 ms
> [13:27:13] t/019_replslot_limit.pl .............. ok    10976 ms
> [13:27:24] t/020_archive_status.pl .............. ok     6190 ms
> [13:27:30] t/021_row_visibility.pl .............. ok     3227 ms
> [13:27:33] t/022_crash_temp_files.pl ............ ok     2296 ms
> [13:27:36] t/023_pitr_prepared_xact.pl .......... ok     3601 ms
> [13:27:39] t/024_archive_recovery.pl ............ ok     3937 ms
> [13:27:43] t/025_stuck_on_old_timeline.pl ....... ok     4348 ms
> [13:27:47] t/026_standby_logical_decoding.pl .... ok   117730 ms <<<
>
> Is it possible to improve this?

Thanks for looking at it.

Once the walsender race conditions mentioned by Andres in [1] are 
addressed then i think that the tests should be much more faster.

I'll try to have a look soon and come with a proposal to address those 
race conditions.

Thanks

Bertrand

[1]: 
https://www.postgresql.org/message-id/20210802160133.uugcce5ql4m5mv5m%40alap3.anarazel.de





pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: list of acknowledgments for PG14
Next
From: Amit Kapila
Date:
Subject: Re: Skipping logical replication transactions on subscriber side