Re: potential stuck lock in SaveSlotToPath() - Mailing list pgsql-hackers

From Andres Freund
Subject Re: potential stuck lock in SaveSlotToPath()
Date
Msg-id 20200318202530.6ectap6floo7d27w@alap3.anarazel.de
Whole thread Raw
In response to Re: potential stuck lock in SaveSlotToPath()  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: potential stuck lock in SaveSlotToPath()  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Hi,

On 2020-03-18 16:54:19 -0300, Alvaro Herrera wrote:
> On 2020-Mar-18, Andres Freund wrote:
> > On 2020-03-18 16:46:23 +0100, Peter Eisentraut wrote:
> > > When SaveSlotToPath() is called with elevel=LOG, the early exits don't
> > > release the slot's io_in_progress_lock.  Fix attached.
> > 
> > I'm a bit confused as to why we we ever call it with elevel = LOG
> > (i.e. why we have the elevel parameter at all). That seems to have been
> > there from the start, so it's either me or Robert that's to blame. But I
> > can't immediately see a reason for it?
> 
> I guess you didn't want failure to save a slot be a reason to abort a
> checkpoint.

I don't see a valid reason for that though - if anything it's dangerous,
because we're not persistently saving the slot. It should fail the
checkpoint imo. Robert, do you have an idea?

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: potential stuck lock in SaveSlotToPath()
Next
From: Peter Eisentraut
Date:
Subject: Re: Collation versioning