On Fri, 22 Oct 2021 at 19:27, Robert Haas wrote:
>
> Another thing to think about in that regard: how likely is that
> PostgreSQL 7.4 and PostgreSQL 15 both compile and run on the same
> operating system? I suspect the answer is "not very." I seem to recall
> Greg Stark trying to compile really ol
Justin Pryzby writes:
> I think you missed a few parts though ?
Um. I think those are leftover from when I was intending the
cutoff to be 9.0 not 9.2. I'll take a fresh look tomorrow.
regards, tom lane
On Wed, Dec 15, 2021 at 10:08:07PM -0600, Justin Pryzby wrote:
> Is it possible to clean up pg_upgrade, too ?
Nevermind - I found yesterday's e469f0aaf3 after git-fetch.
I think you missed a few parts though ?
src/bin/pg_upgrade/function.c
if (GET_MAJOR_VERSION(old_cluster.major_
Justin Pryzby writes:
> On Tue, Dec 14, 2021 at 05:18:44PM -0500, Tom Lane wrote:
>> I've completed the pg_dump/pg_dumpall part of that, but while
> Is it possible to clean up pg_upgrade, too ?
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=e469f0aaf3c586c8390bd65923f97d4b168
On Tue, Dec 14, 2021 at 05:18:44PM -0500, Tom Lane wrote:
> I wrote:
> > Anyway, it seems like there's some consensus that 9.2 is a good
> > stopping place for today. I'll push forward with
> > (1) back-patching as necessary to make 9.2 and up build cleanly
> > on the platforms I have handy;
> > (
I wrote:
> Anyway, it seems like there's some consensus that 9.2 is a good
> stopping place for today. I'll push forward with
> (1) back-patching as necessary to make 9.2 and up build cleanly
> on the platforms I have handy;
> (2) ripping out pg_dump's support for pre-9.2 servers;
> (3) ripping ou
On Mon, Dec 13, 2021 at 12:23 PM Tom Lane wrote:
> I've done as much as I plan to do in that direction. As of the
> respective branch tips, I see clean builds and check-world
> results with minimal configure options in all branches back to 9.2
> on Fedora 35 (gcc 11.2.1) and macOS Monterey (Apple
I wrote:
> Anyway, it seems like there's some consensus that 9.2 is a good
> stopping place for today. I'll push forward with
> (1) back-patching as necessary to make 9.2 and up build cleanly
> on the platforms I have handy;
I've done as much as I plan to do in that direction. As of the
respecti
Andrew Dunstan writes:
> 9.2 is how far back crake goes in testing pg_ugrade from old versions,
> so that could well be a convenient stopping point. For older versions
> there is still the possibility of building on older toolchains and
> running on modern ones. Yes it's more cumbersome, but it do
On 12/9/21 12:50, Tom Lane wrote:
>
> In short then, there is a really large gap between 9.1 and 9.2 in terms
> of how hard they are to build on current toolchains. It's kind of
> fortunate that Peter proposed 9.2 rather than some earlier cutoff.
> In any case, I've completely lost interest in t
[ mostly for the archives' sake ]
I wrote:
> I ran a new set of experiments concerning building back branches
> on modern platforms, this time trying Fedora 35 (gcc 11.2.1)
> on x86_64. I widened the scope of the testing a bit by adding
> "--enable-nls --with-perl" and running check-world not jus
On 06.12.21 22:19, Tom Lane wrote:
A minimal amount of maintenance would be "only back-patch fixes
for issues that cause failure-to-build". The next step up is "fix
issues that cause failure-to-pass-regression-tests", and then above
that is "fix developer-facing annoyances, such as compiler warn
On 12/7/21 13:59, Mark Dilger wrote:
>> On Dec 7, 2021, at 10:52 AM, Tom Lane wrote:
>>
>> I'm not entirely following ... are you suggesting that each released minor
>> version needs to be kept buildable separately?
> No. I'm just wondering if we want to share the product of such efforts if
>
> On Dec 7, 2021, at 10:52 AM, Tom Lane wrote:
>
> I'm not entirely following ... are you suggesting that each released minor
> version needs to be kept buildable separately?
No. I'm just wondering if we want to share the product of such efforts if
anybody (me, for instance) volunteers to d
Mark Dilger writes:
> Wouldn't you be able to see what changed by comparing the last released tag
> for version X.Y against the RELX_Y_STABLE branch? Something like `git diff
> REL8_4_22 origin/REL8_4_STABLE > buildability.patch`?
> Having such a patch should make reproducing old corruption bu
> On Dec 7, 2021, at 8:33 AM, Robert Haas wrote:
>
> However, it wouldn't be a great idea to back-patch a
> completely arbitrary subset of our fixes into those branches, because
> then it sort of gets confusing to understand what the status of that
> branch is. I don't know that I'm terribly b
Robert Haas writes:
> I guess the point about user-visible bug fixes is that, as soon as we
> start doing that, we don't really want it to be hit-or-miss. We could
> make a decision to back-patch all bug fixes or those of a certain
> severity or whatever we like back to older branches, and then th
On Mon, Dec 6, 2021 at 4:19 PM Tom Lane wrote:
> Right. The question that's on the table is how much is the right
> amount of maintenance. I think that back-patching user-visible bug
> fixes, for example, is taking things too far. What we want is to
> be able to replicate the behavior of the br
Robert Haas writes:
> On Sun, Dec 5, 2021 at 7:41 PM Tom Lane wrote:
>> Based on these results, I think maybe we should raise our ambitions
>> a bit compared to Peter's original proposal. Specifically,
>> I wonder if it wouldn't be wise to try to silence compile warnings
>> in these branches.
>
On Sun, Dec 5, 2021 at 7:41 PM Tom Lane wrote:
> Based on these results, I think maybe we should raise our ambitions
> a bit compared to Peter's original proposal. Specifically,
> I wonder if it wouldn't be wise to try to silence compile warnings
> in these branches. The argument for this is bas
I ran a new set of experiments concerning building back branches
on modern platforms, this time trying Fedora 35 (gcc 11.2.1)
on x86_64. I widened the scope of the testing a bit by adding
"--enable-nls --with-perl" and running check-world not just the
core tests. Salient results:
* Everything ba
On Fri, Dec 3, 2021 at 1:30 PM Tom Lane wrote:
> What's most likely to happen IMO is that committers will just start
> back-patching essential portability fixes into out-of-support-but-
> still-in-the-buildability-window branches, contemporaneously with
> the original fix. Yeah, that does mean mo
Peter Eisentraut writes:
> On 02.12.21 23:16, Andres Freund wrote:
>> I realize it's more complicated for users, but a policy based on supporting a
>> certain number of out-of-support branches calculated from the newest major
>> version is more realistic. I'd personally go for something like newes
Andrew Dunstan writes:
> On 12/3/21 12:10, Tom Lane wrote:
>> I experimented to see what this would entail exactly. Using
>> current macOS (Apple clang version 13.0.0) on M1 hardware,
>> I built with minimal configure options (--enable-debug --enable-cassert)
>> and ran the core regression tests.
On 12/3/21 12:10, Tom Lane wrote:
> Peter Eisentraut writes:
>> [ policy requiring that 9.2 and up be kept buildable, as of today ]
> I experimented to see what this would entail exactly. Using
> current macOS (Apple clang version 13.0.0) on M1 hardware,
> I built with minimal configure options
Peter Eisentraut writes:
> [ policy requiring that 9.2 and up be kept buildable, as of today ]
I experimented to see what this would entail exactly. Using
current macOS (Apple clang version 13.0.0) on M1 hardware,
I built with minimal configure options (--enable-debug --enable-cassert)
and ran t
On 02.12.21 23:16, Andres Freund wrote:
I think we should at least include pg_upgrade in this as well, it's pretty
closely tied to at least pg_dump.
right
* pg_dump and psql will maintain compatibility with servers at least
ten major releases back.
Personally I think that's too long... I
On 02.12.21 18:30, Tom Lane wrote:
This assumes a yearly major release cadence.
If the point is to not have to count dates carefully, why does the cadence
matter?
If we were to change the release cadence, then it would be appropriate
to review this policy.
I can get behind something rough
Hi,
On 2021-12-02 11:01:47 +0100, Peter Eisentraut wrote:
> - The policy for other client-side tools (list at [0]) is less clear
> and arguably less important. I suggest we focus on pg_dump and psql
> first, and then we can decide for the rest whether they want to
> match a longer window, a
On 12/2/21 12:30, Tom Lane wrote:
>
>> In practice, the effort can focus on keeping the most recent cutoff
>> release buildable. So in the above example, we really only need to
>> keep PG >=9.2 buildable to support ongoing development. The chances
>> that some needs to touch code pertaining to
Peter Eisentraut writes:
> Proposal:
> * pg_dump and psql will maintain compatibility with servers at least
>ten major releases back.
> * We keep old major release branches buildable as long as a new major
>release that has support for that old release is under support.
> This assumes a
On Thu, Dec 2, 2021 at 5:01 AM Peter Eisentraut
wrote:
> * pg_dump and psql will maintain compatibility with servers at least
>ten major releases back.
>
> * We keep old major release branches buildable as long as a new major
>release that has support for that old release is under support.
I was thinking a bit about formulating a policy for pg_dump backward
compatibility, based on the discussions in this thread.
Premises and preparatory thoughts:
- Users (and developers) want pg_dump to support server versions that
are much older than non-EOL versions.
- Less critically, much-l
On 10/25/21 13:09, Tom Lane wrote:
> Andres Freund writes:
>> On 2021-10-22 19:30:25 -0400, Tom Lane wrote:
>>> Yeah. I checked into when it was that we dropped pre-8.0 support
>>> from pg_dump, and the answer is just about five years ago (64f3524e2).
>>> So moving the bar forward by five relea
On 10/25/21 19:12, Justin Pryzby wrote:
> On Mon, Oct 25, 2021 at 11:38:51AM -0400, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> On 10/25/21 10:23, Tom Lane wrote:
(Hmmm ... but disk space could
become a problem, particularly on older machines with not so much
disk. Do we really
On Mon, Oct 25, 2021 at 11:38:51AM -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > On 10/25/21 10:23, Tom Lane wrote:
> >> (Hmmm ... but disk space could
> >> become a problem, particularly on older machines with not so much
> >> disk. Do we really need to maintain a separate checkout for eac
Anyway, to get back to the original point ...
No one has spoken against moving up the cutoff for pg_dump support,
so I did a very quick pass to see how much code could be removed.
The answer is right about 1000 lines, counting both pg_dump and
pg_upgrade, so it seems like it's worth doing independ
On 10/25/21 13:06, Andres Freund wrote:
> Hi,
>
> On 2021-10-25 10:23:40 -0400, Tom Lane wrote:
>> Also, I concur with Andrew's point that we'd really have to have
>> buildfarm support. However, this might not be as bad as it seems.
>> In principle we might just need to add resurrected branches
Hi,
On 2021-10-25 13:09:43 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I'd really like us to adopt a "default" policy on this. I think it's a waste
> > to spend time every few years arguing what exact versions to drop. I'd much
> > rather say that, unless there are concrete reasons to devi
Hi,
On 2021-10-25 12:43:15 -0400, Tom Lane wrote:
> Agreed, that might be too much work compared to the value. But if we're
> to be selective about support for this, I'm unclear on how we decide
> which platforms are supported --- and, more importantly, how we keep
> that list up to date over tim
Andres Freund writes:
> On 2021-10-25 10:23:40 -0400, Tom Lane wrote:
>> It seems like a fresh checkout from the repo would be little more expensive
>> than the current copy-a-checkout process.)
> I haven't looked in detail, but from what I've seen in the logs the
> is-there-anything-new check is
Andres Freund writes:
> On 2021-10-22 19:30:25 -0400, Tom Lane wrote:
>> Yeah. I checked into when it was that we dropped pre-8.0 support
>> from pg_dump, and the answer is just about five years ago (64f3524e2).
>> So moving the bar forward by five releases isn't at all out of line.
>> 8.4 would
Hi,
On 2021-10-25 10:23:40 -0400, Tom Lane wrote:
> Also, I concur with Andrew's point that we'd really have to have
> buildfarm support. However, this might not be as bad as it seems.
> In principle we might just need to add resurrected branches back to
> the branches_to_build list. Given my vi
Hi,
On 2021-10-22 19:30:25 -0400, Tom Lane wrote:
> Yeah. I checked into when it was that we dropped pre-8.0 support
> from pg_dump, and the answer is just about five years ago (64f3524e2).
> So moving the bar forward by five releases isn't at all out of line.
> 8.4 would be eight years past EOL
Alvaro Herrera writes:
> I do think you have moved the goalposts: to reiterate what I said above,
> I thought what we wanted was to have *some* server in order to test
> client-side changes with; not to be able to get a server running on
> every possible platform. I'm not really on board with the
On 2021-Oct-25, Tom Lane wrote:
> It's also unclear to me why we'd leave Windows out of this discussion.
> We keep saying we want to encourage Windows-based hackers to contribute,
> so doesn't that require testing it on the same basis as other platforms?
Testing of in-support branches, sure -- I
Andrew Dunstan writes:
> On 10/25/21 10:23, Tom Lane wrote:
>> (Hmmm ... but disk space could
>> become a problem, particularly on older machines with not so much
>> disk. Do we really need to maintain a separate checkout for each
>> branch? It seems like a fresh checkout from the repo would be
Alvaro Herrera writes:
> On 2021-Oct-25, Tom Lane wrote:
>> Also, I concur with Andrew's point that we'd really have to have
>> buildfarm support. However, this might not be as bad as it seems.
>> In principle we might just need to add resurrected branches back to
>> the branches_to_build list.
On 10/25/21 11:05, Alvaro Herrera wrote:
>
>> Also, I concur with Andrew's point that we'd really have to have
>> buildfarm support. However, this might not be as bad as it seems.
>> In principle we might just need to add resurrected branches back to
>> the branches_to_build list.
> Well, we wou
On 10/25/21 10:23, Tom Lane wrote:
>
> Also, I concur with Andrew's point that we'd really have to have
> buildfarm support. However, this might not be as bad as it seems.
> In principle we might just need to add resurrected branches back to
> the branches_to_build list. Given my view of what t
Robert Haas writes:
> On Mon, Oct 25, 2021 at 11:00 AM Tom Lane wrote:
>> Actually, I think we do. If I want to test against 7.4, ISTM I want
>> to test against the last released 7.4 version, not something with
>> arbitrary later changes. Otherwise, what exactly is the point?
> 1. You're free
On 10/25/21 11:09, Robert Haas wrote:
> On Mon, Oct 25, 2021 at 11:00 AM Tom Lane wrote:
>> Actually, I think we do. If I want to test against 7.4, ISTM I want
>> to test against the last released 7.4 version, not something with
>> arbitrary later changes. Otherwise, what exactly is the point?
On Mon, Oct 25, 2021 at 11:00 AM Tom Lane wrote:
> Actually, I think we do. If I want to test against 7.4, ISTM I want
> to test against the last released 7.4 version, not something with
> arbitrary later changes. Otherwise, what exactly is the point?
1. You're free to check out any commit you
On 2021-Oct-25, Tom Lane wrote:
> Roughly speaking, I think the policy should be "no feature bug fixes,
> not even security fixes, for EOL'd branches; only fixes that are
> minimally necessary to make it build on newer platforms". And
> I want to have a sunset provision even for that. Fixing eve
Robert Haas writes:
> On Mon, Oct 25, 2021 at 10:23 AM Tom Lane wrote:
>> Roughly speaking, I think the policy should be "no feature bug fixes,
>> not even security fixes, for EOL'd branches; only fixes that are
>> minimally necessary to make it build on newer platforms". And
>> I want to have a
On Mon, Oct 25, 2021 at 10:23 AM Tom Lane wrote:
> What concerns me here is that we not get into a position where we're
> effectively still maintaining EOL'd versions. Looking at the git
> history yesterday reminded me that we had such a situation back in
> the early 7.x days. I can see that I s
Robert Haas writes:
> Right. Well, we could leave it up to people who care to decide how
> much work they want to do, perhaps. But I do find it annoying that
> pg_dump is supposed to maintain compatibility with server releases
> that I can't easily build. Fortunately I don't patch pg_dump very
> o
On Mon, Oct 25, 2021 at 8:29 AM Andrew Dunstan wrote:
> But we don't need to build them on modern platforms, just run them on
> modern platforms, ISTM.
I don't really agree with this.
> Some months ago I built binaries all the way back to 7.2 that with a
> little help run on modern Fedora and Ub
On Sun, Oct 24, 2021 at 5:46 PM Tom Lane wrote:
> Hmm ... I guess the question is how much work we feel like putting
> into that, and how we'd track whether old branches still work,
> and on what platforms. It could easily turn into a time sink
> that's not justified by the value. I do see your
On 10/22/21 19:30, Tom Lane wrote:
> "David G. Johnston" writes:
>> On Fri, Oct 22, 2021 at 3:42 PM Tom Lane wrote:
>>> Anyway, I think the default answer is "revert 92316a458 and keep the
>>> compatibility goalposts where they are". But I wanted to open up a
>>> discussion to see if anyone li
On Fri, 2021-10-22 at 19:26 -0400, Robert Haas wrote:
> On Fri, Oct 22, 2021 at 6:42 PM Tom Lane wrote:
> > So my first thought was just to revert 92316a458 and give up on it as
> > a bad idea. However ... does anyone actually still care about being
> > able to dump from such ancient servers?
>
On 2021-Oct-24, Robert Haas wrote:
> You know, one thing we could think about doing is patching some of the
> older branches to make them compile on modern machines. That would not
> only be potentially useful for people who are upgrading from ancient
> versions, but also for hackers trying to do
Robert Haas writes:
> You know, one thing we could think about doing is patching some of the
> older branches to make them compile on modern machines. That would not
> only be potentially useful for people who are upgrading from ancient
> versions, but also for hackers trying to do research on the
On Fri, Oct 22, 2021 at 7:51 PM Alvaro Herrera wrote:
> I just tried to build 9.1. My config line there doesn't have ssl, but I
> do get this in the compile stage:
Hmm.
You know, one thing we could think about doing is patching some of the
older branches to make them compile on modern machines.
On 2021-Oct-22, Robert Haas wrote:
> In fact, I get that same failure on every branch older than 9.2. I
> expect I could work around that by disabling SSL or finding an older
> version of OpenSSL that works the way those branches expect, but that
> might not be the only problem, either.
I just tr
Robert Haas writes:
> Another thing to think about in that regard: how likely is that
> PostgreSQL 7.4 and PostgreSQL 15 both compile and run on the same
> operating system? I suspect the answer is "not very." I seem to recall
> Greg Stark trying to compile really old versions of PostgreSQL for a
"David G. Johnston" writes:
> On Fri, Oct 22, 2021 at 3:42 PM Tom Lane wrote:
>> Anyway, I think the default answer is "revert 92316a458 and keep the
>> compatibility goalposts where they are". But I wanted to open up a
>> discussion to see if anyone likes the other approach better.
> ... IMO,
On Fri, Oct 22, 2021 at 6:42 PM Tom Lane wrote:
> So my first thought was just to revert 92316a458 and give up on it as
> a bad idea. However ... does anyone actually still care about being
> able to dump from such ancient servers?
I think I recently heard about an 8.4 server still out there in
On Fri, Oct 22, 2021 at 3:42 PM Tom Lane wrote:
> Anyway, I think the default answer is "revert 92316a458 and keep the
> compatibility goalposts where they are". But I wanted to open up a
> discussion to see if anyone likes the other approach better.
>
> [1]
> https://www.postgresql.org/message-
While doing some desultory testing, I realized that the commit
I just pushed (92316a458) broke pg_dump against 8.0 servers:
$ pg_dump -p5480 -s regression
pg_dump: error: schema with OID 11 does not exist
The reason turns out to be something I'd long forgotten about: except
for the few "bootstrap
70 matches
Mail list logo
