Re: [HACKERS] Weaker shmem interlock w/o postmaster.pid - Mailing list pgsql-hackers

From Dmitry Dolgov
Subject Re: [HACKERS] Weaker shmem interlock w/o postmaster.pid
Date
Msg-id CA+q6zcV4r+oS27G-nYqonG+q7442BOA350s3jeRtA-Oqx4vDWg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Weaker shmem interlock w/o postmaster.pid  (Noah Misch <noah@leadboat.com>)
Responses Re: [HACKERS] Weaker shmem interlock w/o postmaster.pid
List pgsql-hackers
> On Sun, Aug 12, 2018 at 8:48 AM Noah Misch <noah@leadboat.com> wrote:
>
> On Wed, Sep 11, 2013 at 10:28:00PM -0400, Noah Misch wrote:
> > On Wed, Sep 11, 2013 at 11:32:01AM -0400, Stephen Frost wrote:
> > > * Noah Misch (noah@leadboat.com) wrote:
> > > > Concretely, that means
> > > > not removing postmaster.pid on immediate shutdown in 9.3 and earlier.  That's
> > > > consistent with the rough nature of an immediate shutdown, anyway.
>
> With 9.3 having a few months left, that's less interesting, but ...

Thanks for the patch!

I'm a bit out of context, but taking into account that 9.3 is already beyond
EOL, is it still interesting? I'm just thinking about whether it's worth to
move it to the next CF, or mark as rejected, since no one reviewed the patch so
far?

As a side note, with this patch recovery tests are failing now on 016_shm.pl

#   Failed test 'detected live backend via shared memory'
#   at t/016_shm.pl line 87.
#                   '2018-11-28 13:08:08.504 UTC [21924] LOG:
listening on Unix socket "/tmp/yV2oDNcG8e/gnat/.s.PGSQL.512"
# 2018-11-28 13:08:08.512 UTC [21925] LOG:  database system was
interrupted; last known up at 2018-11-28 13:08:08 UTC
# 2018-11-28 13:08:08.512 UTC [21925] LOG:  database system was not
properly shut down; automatic recovery in progress
# 2018-11-28 13:08:08.512 UTC [21925] LOG:  invalid record length at
0/165FEF8: wanted 24, got 0
# 2018-11-28 13:08:08.512 UTC [21925] LOG:  redo is not required
# 2018-11-28 13:08:08.516 UTC [21924] LOG:  database system is ready
to accept connections
# '
#     doesn't match '(?^:pre-existing shared memory block)'


pgsql-hackers by date:

Previous
From: Alexander Kuzmenkov
Date:
Subject: Re: "SELECT ... FROM DUAL" is not quite as silly as it appears
Next
From: Dmitry Dolgov
Date:
Subject: Re: Conflict handling for COPY FROM