Request MRE approval for PostgreSQL

[Christopher James Halse Rogers]

On Thu, Jan 25 2024 at 14:59:27 -0500, Sergio Durigan Junior 
<sergiodj at ubuntu.com> wrote:
> 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.

That looks good to me now; approved. I'll update the 
StableReleaseUpdates page.

Thanks!
Chris