| From: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com> |
| Subject: | Re: subscription/026_stats test is intermittently slow? |
| Date: | 2024-04-20 05:00:00 |
| Message-ID: | 8d9cb1c7-b85d-fc36-627d-ef8f3726e219@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello Michael and Robert,
20.04.2024 05:57, Michael Paquier wrote:
> On Fri, Apr 19, 2024 at 01:57:41PM -0400, Robert Haas wrote:
>> It looks to me like in the first run it took 3 minutes for the
>> replay_lsn to catch up to the desired value, and in the second run,
>> two seconds. I think I have seen previous instances where something
>> similar happened, although in those cases I did not stop to record any
>> details. Have others seen this? Is there something we can/should do
>> about it?
> FWIW, I've also seen delays as well with this test on a few occasions.
> Thanks for mentioning it.
It reminds me of
https://www.postgresql.org/message-id/858a7622-2c81-1687-d1df-1322dfcb2e72%40gmail.com
At least, I could reproduce such a delay with the attached patch applied.
Best regards,
Alexander
| Attachment | Content-Type | Size |
|---|---|---|
| 026_stats-180.patch | text/x-patch | 822 bytes |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2024-04-20 05:56:00 | Re: fix tablespace handling in pg_combinebackup |
| Previous Message | Andy Fan | 2024-04-20 04:19:02 | Re: UniqueKey v2 |