Re: Re: Minimal logical decoding on standbys
От | Drouvot, Bertrand |
---|---|
Тема | Re: Re: Minimal logical decoding on standbys |
Дата | |
Msg-id | 46ec17a8-3c5d-7152-f6b0-ac122a5d0789@amazon.com обсуждение исходный текст |
Ответ на | Re: Minimal logical decoding on standbys (Peter Eisentraut <peter.eisentraut@enterprisedb.com>) |
Список | 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 по дате отправления: