Re: Off-Schedule Minor Release Consideration?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Off-Schedule Minor Release Consideration?
Date: 2020-12-02 19:50:11
Message-ID: 1671025.1606938611@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> Given that we have already heard about 3 separate minor release regressions
> in the most recent update I'm putting forth for discussion whether an
> off-schedule release should be done. I probably wouldn't care as much if
> it wasn't for the fact that the same release fixes two CVEs.

The release team had a discussion about this. We're leaning towards
not doing anything out of the ordinary, but are open to public input.
To recap a bit:

Actually there are four known regressions, because there are two
different CREATE TABLE LIKE bugs:
* CREATE TABLE LIKE gets confused if new table masks old one
(see f7f83a55b)
* CREATE TABLE LIKE fails to handle a self-referential foreign key
defined in the CREATE, if it depends on an index imported by LIKE
(see 97390fe8a)
* psql \c with a connstring containing a password ignores the password
(see 7e5e1bba0)
* LISTEN/NOTIFY can fail to empty its SLRU queue in v12 and earlier
(see 9c83b54a9)

We felt that the first three of these are at best minor annoyances.

The LISTEN/NOTIFY issue is potentially more serious, in that it
could cause a service outage for a site that makes heavy use of
NOTIFY. However, the race is between two listeners, so in the
common (I think) usage pattern of only one listener there's no
issue. Even if you hit the race condition, you don't have a problem
until 8GB more NOTIFY traffic has been sent, which seems like a lot.
The complainants in that bug report indicated they'd overrun that
amount in a week or two, but that seems like unusually heavy usage.

The other aspect that seems to mitigate the seriousness of the
LISTEN/NOTIFY issue is that a server restart is enough to clear
the queue. Given that you'd also need a server restart to install
a hypothetical off-cycle release, it's easy to see that there's
no benefit except to sites that anticipate logging more than 16GB
of NOTIFY traffic (and thus needing two or more restarts) before
February.

So we are leaning to the position that the severity of these issues
doesn't justify the work involved in putting out an off-cycle release.
But if there are people out there with high-NOTIFY-traffic servers
who would be impacted, please speak up!

(BTW, the calendar is also a bit unfriendly to doing an off-cycle
release. It's probably already too late to plan a Dec 10 release,
and by the week after that a lot of people will be in holiday mode.
If you start thinking about January, it's not clear why bother,
since we'll have minor releases in February anyway.)

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2020-12-02 19:57:33 Re: SELECT INTO deprecation
Previous Message Bruce Momjian 2020-12-02 19:47:40 Re: [PATCH] SET search_path += octopus