Request MRE approval for PostgreSQL

[Sergio Durigan Junior]

On Tuesday, January 23 2024, Christopher James Halse Rogers wrote:

> On Thu, Jan 18 2024 at 11:21:18 -0500, Sergio Durigan Junior
> <sergiodj at ubuntu.com> wrote:
>> On Thursday, January 18 2024, Christopher James Halse Rogers wrote:
>> 
>>>  On Wed, Jan 17 2024 at 21:09:58 -0500, Sergio Durigan Junior
>>>  <sergiodj at ubuntu.com> wrote:
>>>>  On Wednesday, January 17 2024, Christopher James Halse Rogers
>>>> wrote:
>>>> 
>>>>>   Hi there!
>>>>  Hey, Chris,
>>>>  Thanks for the review.
>>>> 
>>>>>   On Sat, Jan 13 2024 at 00:08:35 -0500, Sergio Durigan Junior
>>>>>   <sergio.durigan at canonical.com> wrote:
>>>>>>   Hello,
>>>>>>   In the same spirit as Christian's formal request for an SRU
>>>>>>   exception
>>>>>>   for open-vm-tools, Athos and I would like to formally request
>>>>>> the
>>>>>>   approval of the PostgreSQL MRE wiki page.
>>>>>>   We (the Server team) have been doing such MREs for a number of
>>>>>>  years
>>>>>>   now, but it came to our attention recently that we don't
>>>>>> actually
>>>>>>  have
>>>>>>   the MRE policy for PostgreSQL formally defined in a wiki page,
>>>>>> as
>>>>>>  is
>>>>>>   usual for more recent packages.
>>>>>>   I don't know much about the history behind why such page doesn't
>>>>>>   exist,
>>>>>>   but we would like to fix it by proposing the following document:
>>>>>>     https://wiki.ubuntu.com/PostgreSQLUpdates
>>>>>   It looks like a good documentation of current practice, and
>>>>>  current
>>>>>   practice looks (mostly) good.
>>>>>   A couple of questions:
>>>>>   * Checking the PostgreSQL policy, they say that a pg_dump/restore
>>>>>     cycle between minor updates is *normally* not needed. Has it
>>>>>  *ever*
>>>>>     been needed in the past? Presumably we would not take such an
>>>>>  update
>>>>>     (at least, not under this MRE)?
>>>>  Athos and I have been doing this MRE for a bit more than a year
>>>> now,
>>>>  and
>>>>  so far we have never seen a situation where a pg_dump/restore cycle
>>>>  was
>>>>  needed.  I'm Cc'ing Christian, who used to handle the MREs before
>>>>  us, in
>>>>  case he knows something more.
>>>> 
>>>>>   * I notice a number of the updates are of the form “Fix FROB
>>>>>  index. If
>>>>>     you have any FROB indexes, you must run FROBINATE REINDEX to
>>>>> get
>>>>>  the
>>>>>     fixes”. How do we notify users of this? It's in the
>>>>> changelog,
>>>>>  which
>>>>>     is not nothing, and a debconf notice would be *way* too
>>>>>     disruptive. Is there anywhere else we should be pushing such
>>>>>  “you
>>>>>     really should check this” notifications?
>>>>  That's a good question.  My default answer for such scenarios tends
>>>>  to
>>>>  be "let's put it in a d/NEWS file", but I appreciate the fact
>>>> that not
>>>>  everybody will have apt-listchanges installed.  Nonetheless, maybe
>>>>  that's a good compromise between having the entries buried in the
>>>>  changelog vs. having a debconf notice.  WDYT?
>>>  Ooooh, yes. d/NEWS would definitely be an improvement!
>> Cool.
>> Just to clarify: does this mean that this request is approved
>> pending
>> the d/NEWS addition to the wiki page?
>
> I'd like an answer to the other question before approving - what
> happens if a pg_dump/pg_restore cycle *is* required across a minor
> update. Presumably the answer is “that update will not fall under this
> MRE”, but we should document both that decision and how we expect to
> pick up when this would apply.

OK, that is a good question.

I thought about it yesterday, and my answer here pretty much aligns with
what you expected.  But let me give a little bit of context first.

It's important to say that, to the best of my knowledge, there has *not*
been any PostgreSQL minor release that required a pg_dump/pg_restore
cycle ever since we started doing these MREs.  And that, I believe, is
for a good reason: upstream must know that they would be shooting
themselves in the foot in case they required such drastic measure from
their users.  And I must say that upstream seems pretty reasonable to
me, given my interactions with them for the past 3 years (give or take).
So, IMHO, the chances of us seeing such a requirement in a minor release
are very, very low.

On top of that, let me assure you that Athos and I (and the whole Server
team, if I'm being honest) would straight out refuse to proceed with the
MRE if we saw a breaking change/operation like this being required.
There is just no way to guarantee the data integrity of our users'
databases in such case, so having this being part of a LTS release is a
no-no from our standpoint.

Therefore, in a nutshell: if PostgreSQL upstream ever requires a
pg_dump/pg_restore cycle to be performed as part of a minor release
update, then that update will not fall under this MRE.

> Once that has a satisfactory answer, yes, it looks good to approve to
> me.

Hopefully my answer is enough, but please let me know if you'd like more
details.

BTW, I will take the liberty of updating the wiki page to reflect the
answer above, and also to include the d/NEWS requirement as previously
discussed.

Cheers,

-- 
Sergio
GPG key ID: E92F D0B3 6B14 F1F4 D8E0  EB2F 106D A1C8 C3CB BF14