pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Laurenz Albe <laurenz.albe@cybertec.at>
To: Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: David G. Johnston <david.g.johnston@gmail.com>
Cc: Nisha Moond <nisha.moond412@gmail.com>
Cc: Gunnar Morling <gunnar.morling@googlemail.com>
Cc: pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
Subject: Re: Unexpected behavior when setting "idle_replication_slot_timeout"
Date: Wed, 9 Jul 2025 19:19:44 +0900
Message-ID: <49b70ae1-acbe-41ec-9d2d-8284b3462fc1@oss.nttdata.com> (raw)
In-Reply-To: <2dcea297694d9ab8eafd1db70d385ec0b49e3d27.camel@cybertec.at>
References: <CADGJaX_0+FTguWpNSpgVWYQP_7MhoO0D8=cp4XozSQgaZ40Odw@mail.gmail.com>
	<CABdArM76e8-XChodqKxEiRK3tR_Yv3cymn_AWfP4bOsLDscZAg@mail.gmail.com>
	<30e91649-06dd-453e-8658-5f4acd03a3bd@oss.nttdata.com>
	<b26f13d7-769a-4b64-8bed-cb3a833c0604@oss.nttdata.com>
	<686577f2379e4b978803e72746dcf0dd7baf3937.camel@cybertec.at>
	<e0789f10-5b48-4d6b-a32c-0f4426d254df@oss.nttdata.com>
	<CAA4eK1LOyUeCHk3hMtjT-bpqXLAnjODwcO+o7+bTnB2es-fSqw@mail.gmail.com>
	<70b183fb-f66e-40d8-b0de-be8c1052fa93@oss.nttdata.com>
	<CAKFQuwYVEgy+fiHMvSoykiEef-VF-ZV9Gxv4rynk9NNK9UMPYQ@mail.gmail.com>
	<472687.1751731008@sss.pgh.pa.us>
	<474268.1751731988@sss.pgh.pa.us>
	<f12271e6aea3b87eaa430d0c9008ca1f3154c31e.camel@cybertec.at>
	<CAA4eK1JaYNQtTj5u-YP3G2UJbJoevD4PnUiM+sQy8DerjNPJFA@mail.gmail.com>
	<1cea80b2ed4f355ae6a68e36f56a1410b59ea4a8.camel@cybertec.at>
	<OSCPR01MB14966D811DB105E49289B8298F549A@OSCPR01MB14966.jpnprd01.prod.outlook.com>
	<2dcea297694d9ab8eafd1db70d385ec0b49e3d27.camel@cybertec.at>



On 2025/07/09 18:21, Laurenz Albe wrote:
> On Wed, 2025-07-09 at 07:24 +0000, Hayato Kuroda (Fujitsu) wrote:
>>>> +# Wait a bit for the replication slots to become invalid
>>>> +$node->safe_psql('postgres', "SELECT pg_sleep(2)");
>>>>
>>>> Is it a good idea to add 2s to 'make check-world' for one particular test?
>>>
>>> That is debatable.  I thought that adding two seconds would be worth the
>>> advantage of removing the injection point that only fakes the timeout.
>>> We'd get better test coverage.
>>>
>>> But if the people who run the regression tests dozens of times every day
>>> object to the two seconds, I won't insist on this part of the patch.
>>
>> I can understand both concerns. One benefit not to use the injection point is
>> that any machines can run the test. Currently some BF machines do not enable
>> the injection point, thus the feature has not been verified on these env.
>> However, unconditional sleep makes the test longer.
>>
>> Based on that, I want to propose the hybrid approach; use injection_point_attach()
>> if possible, otherwise wait few seconds. One concern is that the test code may be
>> bit complex, but below codes was enough on my environment.
>>
>> ```
>> # Check if the 'injection_points' extension is available, as it may be
>> # possible that this script is run with installcheck, where the module
>> # would not be installed by default.
>> if ($node->check_extension('injection_points'))
>> {
>> 	# Register an injection point on the node to forcibly cause a slot
>> 	# invalidation due to idle_timeout
>> 	$node->safe_psql('postgres', 'CREATE EXTENSION injection_points;');
>>
>> 	$node->safe_psql('postgres',
>> 		"SELECT injection_points_attach('slot-timeout-inval', 'error');");
>> }
>> else
>> {
>> 	# Otherwise wait a bit for the replication slots to become invalid
>> 	$node->safe_psql('postgres', "SELECT pg_sleep(2)");
>> }
>> ```
>>
>> Attached patch implements the idea, which can be applied atop v2. How do you think?
> 
> I have no objections.

So the purpose of this "hybrid approach" is to test idle_replication_slot_timeout
even in environments where the injection point isn't available? Do we really need
this additional test? It seems to me that the test using the injection point is
sufficient.

Regards,

-- 
Fujii Masao
NTT DATA Japan Corporation






view thread (38+ messages)  latest in thread

Message-ID: <49b70ae1-acbe-41ec-9d2d-8284b3462fc1@oss.nttdata.com>
Permalink:  ../49b70ae1-acbe-41ec-9d2d-8284b3462fc1@oss.nttdata.com/
Also on:    postgresql.org/message-id/49b70ae1-acbe-41ec-9d2d-8284b3462fc1@oss.nttdata.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: masao.fujii@oss.nttdata.com, laurenz.albe@cybertec.at, kuroda.hayato@fujitsu.com, amit.kapila16@gmail.com, tgl@sss.pgh.pa.us, david.g.johnston@gmail.com, nisha.moond412@gmail.com, gunnar.morling@googlemail.com, pgsql-bugs@lists.postgresql.org
  Subject: Re: Unexpected behavior when setting "idle_replication_slot_timeout"
  In-Reply-To: <49b70ae1-acbe-41ec-9d2d-8284b3462fc1@oss.nttdata.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox