Re: Some problems of recovery conflict wait events - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: Some problems of recovery conflict wait events
Date
Msg-id CA+fd4k4ReEfpj30eK1es69+SHEcRjb_wiQh5nrtkErUo0uO9jg@mail.gmail.com
Whole thread Raw
In response to Re: Some problems of recovery conflict wait events  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Responses Re: Some problems of recovery conflict wait events
Re: Some problems of recovery conflict wait events
List pgsql-hackers
On Wed, 4 Mar 2020 at 13:48, Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>
>
>
> On 2020/03/04 13:27, Michael Paquier wrote:
> > On Wed, Mar 04, 2020 at 01:13:19PM +0900, Masahiko Sawada wrote:
> >> Yeah, so 0001 patch sets existing wait events to recovery conflict
> >> resolution. For instance, it sets (PG_WAIT_LOCK | LOCKTAG_TRANSACTION)
> >> to the recovery conflict on a snapshot. 0003 patch improves these wait
> >> events by adding the new type of wait event such as
> >> WAIT_EVENT_RECOVERY_CONFLICT_SNAPSHOT. Therefore 0001 (and 0002) patch
> >> is the fix for existing versions and 0003 patch is an improvement for
> >> only PG13. Did you mean even 0001 patch doesn't fit for back-patching?
>
> Yes, it looks like a improvement rather than bug fix.
>

Okay, understand.

> > I got my eyes on this patch set.  The full patch set is in my opinion
> > just a set of improvements, and not bug fixes, so I would refrain from
> > back-backpatching.
>
> I think that the issue (i.e., "waiting" is reported twice needlessly
> in PS display) that 0002 patch tries to fix is a bug. So it should be
> fixed even in the back branches.

So we need only two patches: one fixes process title issue and another
improve wait event. I've attached updated patches.

Regards,

-- 
Masahiko Sawada            http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: PG14 target version?
Next
From: John Naylor
Date:
Subject: Re: Unicode escapes with any backend encoding