From: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
---|---|
To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Is a pg_stat_force_next_flush() call sufficient for regression tests? |
Date: | 2023-07-04 18:04:40 |
Message-ID: | 10a654e6-e9b1-30a2-84ae-7e4d4da44584@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 7/4/23 04:29, Kyotaro Horiguchi wrote:
> At Mon, 3 Jul 2023 15:45:52 +0200, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> wrote in
>> So I'm wondering if pg_stat_force_next_flush() is enough - AFAICS this
>> only sets some flag for the *next* pgstat_report_stat() call, but how do
>> we know that happens before the query execution?
>>
>> Shouldn't there be something like pg_stat_flush() that actually does the
>> flushing, instead of just setting the flag?
>
> The reason for the function is that pg_stat_flush() is supposed not to
> be called within a transaction. AFAICS pg_stat_force_next_flush()
> takes effect after a successfull transaction end and before the next
> command execution.
>
Sure, if we're supposed to report the stats only at the end of a
transaction, that makes sense. But then why didn't that happen here?
> To verify this, I put in an assertion to check that the flag gets
> consumed before reading of pg_stat_io (a.diff), then ran pgbench with
> the attached custom script. As expected, it didn't fire at all during
> several trials. When I wrapped all lines in t.sql within a
> begin-commit block, the assertion fired off immediately as a matter of
> course.
>
If I understand correctly, this just verifies that
1) if everything goes well, we report the stats at the end of the
transaction (otherwise the case without BEGIN/COMMIT would fail)
2) we don't report stats when in a transaction (with the BEGIN/COMMIT)
But the eelpout failure clearly suggests this may misbehave.
> Is there any chance concurrent backends or some other things can
> actually hinder the backend from reusing buffers?
>
No idea. I'm not very familiar with the reworked pgstat system, but
either the pgstat_report_stat() was not called for some reason, or it
decided there's nothing to report (i.e. have_iostats==false). Not sure
why would that happen.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2023-07-04 18:19:46 | Re: pg_basebackup check vs Windows file path limits |
Previous Message | Heikki Linnakangas | 2023-07-04 17:26:55 | Re: On /*----- comments |