| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | waiting for reload in tests |
| Date: | 2022-05-10 01:26:57 |
| Message-ID: | 20220510012657.63pkv4tfzsmhvy5i@alap3.anarazel.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
In a couple tests I (IIRC others as well) had the problem that a config reload
isn't actually synchronous. I.e. a sequence like
$node_primary->reload;
$node_primary->safe_psql('postgres',...)
isn't actually guaranteed to observe the config as reloaded in the the
safe_psql(). It *typically* will see the new config results, but if the system
busy and/or slow, the sighup might not yet have been propagated by postmaster
and/or not yet received by the relevant process.
I don't really see a way to guarantee this with reasonable effort in the
back-branches. In HEAD we could (with some difficulties around postmaster and
UI) use a global barrier to wait for the reload to complete. For the
backbranches I guess we could hack something using retries and setting a
pseudo-guc to check whether the reload has been processed - but that's not
bulletproof at all, some process(es) could take longer to receive the signal.
Anybody got a better idea?
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-05-10 01:29:32 | Re: waiting for reload in tests |
| Previous Message | KAWAMOTO Masaya | 2022-05-10 01:05:48 | Proposal: add a debug message about using geqo |