From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
Cc: | Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Regression test postgres_fdw might fail due to autovacuum |
Date: | 2025-03-23 18:02:31 |
Message-ID: | p4ljt3fgytx5gglwu2uujkgypeszh3bcch2n4mwnx3y2qkqyod@fodaso67qwag |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2025-03-24 02:26:35 +0900, Fujii Masao wrote:
> > With autovacuum = off, all of these fluctuations go away.
>
> So you are suggesting disabling autovacuum during the postgres_fdw regression test?
I don't think that's a good fix in this case.
> Just my idea to stabilize the test with "RETURNING *" is to use WITH, like this:
>
> WITH tmp AS (UPDATE ... RETURNING *) SELECT * FROM tmp ORDER BY ...
+1
On 2025-03-23 16:00:00 +0200, Alexander Lakhin wrote:
> Interestingly enough, with "log_autovacuum_min_duration = 0" added to
> TEMP_CONFIG, I can't see "automatic vacuum/analyze" messages related
> to ft2/ "S 1"."T 1", so autovacuum somehow affects contents of this table
> indirectly.
>
> With autovacuum = off, all of these fluctuations go away.
Hm. Is it possible that autovacuum started but didn't finish?
FWIW, I observed some oddities around autovacuum=0 recently, but didn't have
time to track the source down yet. E.g. running pg_trgm's tests against a
server with autovacuum=0 results in test failures due to plan changes, despite
no AVs getting launched.
Greetings,
Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-03-23 19:10:02 | Re: Add Postgres module info |
Previous Message | Alexander Lakhin | 2025-03-23 18:00:01 | Re: Regression test postgres_fdw might fail due to autovacuum |