Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Chapman Flack <chap(at)anastigmatix(dot)net>
Cc: David Steele <david(at)pgmasters(dot)net>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file
Date: 2022-03-01 20:05:23
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


* Chapman Flack (chap(at)anastigmatix(dot)net) wrote:
> On 03/01/22 14:14, Stephen Frost wrote:
> >> There can't really be many teams out there thinking "we'll just ignore
> >> these scripts forever, and nothing bad will happen." They all know they'll
> >> have to do stuff sometimes. But it matters how we allow them to schedule it.
> >
> > We only make these changes between major versions. That's as much as we
> > should be required to provide.
> It's an OSS project, so I guess we're not required to provide anything.
> But in the course of this multi-release exclusive to non-exclusive
> transition, we already demonstrated, in 7117685, that we can avoid
> inflicting immediate breakage when there's nothing in our objective
> that inherently requires it, and avoiding it is relatively easy.
> I can't bring myself to think that was a bad precedent.

It's actively bad because we are ridiculously inconsistent when it comes
to these things and we're terrible about ever removing anything once
it's gotten into the tree as 'deprecated'. Witness that it's 8 years
since 7117685 and we still have these old and clearly broken APIs
around. We absolutely need to move *away* from this approach, exactly
how 2dedf4d9, much more recently than 7117685, for all of its other
flaws, did.

> So if I'm outvoted here and the reason is "look, a lighter burden is
> involved this time than that time", then ok. I would rather bow to that
> argument on the specific facts of one case than abandon the precedent
> from 7117685 generally.

It's far from precedent- if anything, it's quite the opposite from how
most changes around here are made, and much more recent commits in the
same area clearly tossed out entirely the idea of trying to maintain
some kind of backwards compatibility with existing scripts.



In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Dmitry Dolgov 2022-03-01 20:26:11 Re: Commitfest 2022-03 Patch Triage Part 1a.i
Previous Message Robert Haas 2022-03-01 20:03:48 Re: CREATEROLE and role ownership hierarchies