Re: Calling pgstat_report_wait_end() before ereport(ERROR)

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Calling pgstat_report_wait_end() before ereport(ERROR)
Date: 2019-04-16 05:44:43
Message-ID: 20190416054443.GF2673@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Apr 12, 2019 at 10:06:41PM +0900, Masahiko Sawada wrote:
> But I think that's not right, I've checked the code. If the startup
> process failed in that function it raises a FATAL and recovery fails,
> and if checkpointer process does then it calls
> pgstat_report_wait_end() in CheckpointerMain().

Well, the point is that the code raises an ERROR, then a FATAL because
it gets upgraded by recovery. The take, at least it seems to me, is
that if any new caller of the function misses to clean up the event
then the routine gets cleared. So it seems to me that the current
coding is aimed to be more defensive than anything. I agree that
there is perhaps little point in doing so. In my experience a backend
switches very quickly back to ClientRead, cleaning up the previous
event. Looking around, we have also some code paths in slot.c and
origin.c which close a transient file, clear the event flag... And
then PANIC, which makes even less sense.

In short, I tend to think that the attached is an acceptable cleanup.
Thoughts?
--
Michael

Attachment Content-Type Size
clean-error-paths.patch text/x-diff 4.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashwin Agrawal 2019-04-16 05:45:51 Re: Zedstore - compressed in-core columnar storage
Previous Message Noah Misch 2019-04-16 05:22:31 Re: [Patch] Mingw: Fix import library extension, build actual static libraries