| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Floris Van Nee <florisvannee(at)optiver(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, "exclusion(at)gmail(dot)com" <exclusion(at)gmail(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #17947: Combination of replslots pgstat issues causes error/assertion failure |
| Date: | 2024-06-05 23:51:10 |
| Message-ID: | ZmD57ld6KIhJ4Pmi@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Wed, Jun 05, 2024 at 10:24:43AM +0000, Floris Van Nee wrote:
> I noticed it but wasn't sure if it was necessary here due to the exceptional case here.
> It raises ereport error right after and can only reach this if the entry was created
> In the call to pgstat_prep_pending_entry before it, so it seems unlikely another
> backend holds a ref to it. I might be wrong though.
It does not prevent addressing the original issue, so pushed down to
15 after running concurrent tests for a few extra hours.
>> Attached is an updated patch with refined comments at the top of ?
>> pgstat_drop_entry(), to be applied to 15~.
>
> Thanks for testing the patch. Updated patch looks good to me.
I'll try to look at this one separately.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2024-06-06 03:29:33 | Re: BUG #18477: A specific SQL query with "ORDER BY ... NULLS FIRST" is performing poorly if an ordering column is n |
| Previous Message | Erik Wienhold | 2024-06-05 16:08:13 | Re: BUG #18495: invalid type mapping for timestamptz from call of: getMetaData and then geColumns on PgConnection. |