Re: pg_upgrade test for binary compatibility of core data types

2021-12-01 Thread Michael Paquier
On Wed, Dec 01, 2021 at 04:19:44PM +0900, Michael Paquier wrote: > I'll get that done down to 10 to maximize its influence, then I'll > move on with the buildfarm code and send a patch to plug this and > reduce the dependencies between core and the buildfarm code. Okay, I have checked this one

Re: pg_upgrade test for binary compatibility of core data types

2021-11-30 Thread Michael Paquier
On Thu, Nov 18, 2021 at 03:58:18PM +0900, Michael Paquier wrote: > + ver >= 905 AND ver <= 1300 AS oldpgversion_95_13, > + ver >= 906 AND ver <= 1300 AS oldpgversion_96_13, > + ver >= 906 AND ver <= 1000 AS oldpgversion_96_10, > So here, we have the choice between conditions that play with

Re: pg_upgrade test for binary compatibility of core data types

2021-11-17 Thread Michael Paquier
On Wed, Nov 17, 2021 at 10:47:28PM -0600, Justin Pryzby wrote: > I'm not sure if everything the buildfarm does is needed anymore, or if any of > it could be removed now, rather than being implemented in test.sh. +-- This file has a bunch of kludges needed for testing upgrades across major

Re: pg_upgrade test for binary compatibility of core data types

2021-11-17 Thread Michael Paquier
On Wed, Nov 17, 2021 at 11:57:51PM -0500, Tom Lane wrote: > Something funny about that on prion: > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prion=2021-11-18%2001%3A55%3A38 > Not sure what's going on there. Yes, that was just some missing quoting in the aclitem of this new table.

Re: pg_upgrade test for binary compatibility of core data types

2021-11-17 Thread Tom Lane
Michael Paquier writes: > Okay. I have worked on 0001 to add the table to check after the > binary compatibilities and applied it. Something funny about that on prion: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prion=2021-11-18%2001%3A55%3A38 @@ -747,6 +747,8 @@ '{(2020-01-02

Re: pg_upgrade test for binary compatibility of core data types

2021-11-17 Thread Justin Pryzby
On Wed, Nov 17, 2021 at 04:01:19PM +0900, Michael Paquier wrote: > On Sun, Nov 07, 2021 at 01:22:00PM -0600, Justin Pryzby wrote: > > That may be good enough for test.sh, but if the kludges were moved to a .sql > > script which was also run by the buildfarm (in stead of its hardcoded > >

Re: pg_upgrade test for binary compatibility of core data types

2021-11-17 Thread Michael Paquier
On Wed, Nov 17, 2021 at 10:07:17AM -0500, Andrew Dunstan wrote: > In general I'm in agreement with the direction here. If we can have a > script that applies to back branches to make them suitable for upgrade > testing instead of embedding this in the buildfarm client, so much the > better. Okay.

Re: pg_upgrade test for binary compatibility of core data types

2021-11-17 Thread Andrew Dunstan
On 11/17/21 02:01, Michael Paquier wrote: > > The oldest version tested by the buildfarm is 9.2, so we could ignore > this part I guess? > > Andrew, what do you think about this part? Based on my read of this > thread, there is an agreement that this approach makes the buildfarm > code more

Re: pg_upgrade test for binary compatibility of core data types

2021-11-16 Thread Michael Paquier
On Sun, Nov 07, 2021 at 01:22:00PM -0600, Justin Pryzby wrote: > That may be good enough for test.sh, but if the kludges were moved to a .sql > script which was also run by the buildfarm (in stead of its hardcoded > kludges), then > it might be necessary to handle the additional stuff my patch

Re: pg_upgrade test for binary compatibility of core data types

2021-11-07 Thread Michael Paquier
On Sun, Nov 07, 2021 at 01:22:00PM -0600, Justin Pryzby wrote: > That may be good enough for test.sh, but if the kludges were moved to a .sql > script which was also run by the buildfarm (in stead of its hardcoded > kludges), then > it might be necessary to handle the additional stuff my patch

Re: pg_upgrade test for binary compatibility of core data types

2021-11-07 Thread Justin Pryzby
On Mon, Oct 11, 2021 at 02:38:12PM +0900, Michael Paquier wrote: > On Fri, Oct 01, 2021 at 04:58:41PM +0900, Michael Paquier wrote: > > I was looking at this CF entry, and what you are doing in 0004 to move > > the tweaks from pg_upgrade's test.sh to a separate SQL script that > > uses psql's

Re: pg_upgrade test for binary compatibility of core data types

2021-10-12 Thread Michael Paquier
On Mon, Oct 11, 2021 at 02:38:12PM +0900, Michael Paquier wrote: > For now, attached is a patch to address the issues with test.sh that I > am planning to backpatch. This fixes the facility on HEAD, while > minimizing the diffs between the dumps. We could do more, like a > s/PROCEDURE/FUNCTION/

Re: pg_upgrade test for binary compatibility of core data types

2021-10-10 Thread Michael Paquier
On Fri, Oct 01, 2021 at 04:58:41PM +0900, Michael Paquier wrote: > I was looking at this CF entry, and what you are doing in 0004 to move > the tweaks from pg_upgrade's test.sh to a separate SQL script that > uses psql's meta-commands like \if to check which version we are on is > really

Re: pg_upgrade test for binary compatibility of core data types

2021-10-01 Thread Michael Paquier
On Sat, Sep 11, 2021 at 07:51:16PM -0500, Justin Pryzby wrote: > These are all "translated" from test.sh, so follow its logic. > Maybe it should be improved, but that's separate from this patch - which is > already doing a few unrelated things. I was looking at this CF entry, and what you are

Re: pg_upgrade test for binary compatibility of core data types

2021-09-24 Thread Andrew Dunstan
On 9/15/21 3:28 PM, Andrew Dunstan wrote: > On 9/13/21 9:20 AM, Andrew Dunstan wrote: >> On 9/12/21 2:41 PM, Andrew Dunstan wrote: >>> On 9/11/21 8:51 PM, Justin Pryzby wrote: @Andrew: did you have any comment on this part ? |Subject: buildfarm xversion diff |Forking

Re: pg_upgrade test for binary compatibility of core data types

2021-09-15 Thread Andrew Dunstan
On 9/13/21 9:20 AM, Andrew Dunstan wrote: > On 9/12/21 2:41 PM, Andrew Dunstan wrote: >> On 9/11/21 8:51 PM, Justin Pryzby wrote: >>> @Andrew: did you have any comment on this part ? >>> >>> |Subject: buildfarm xversion diff >>> |Forking >>>

Re: pg_upgrade test for binary compatibility of core data types

2021-09-13 Thread Andrew Dunstan
On 9/12/21 2:41 PM, Andrew Dunstan wrote: > On 9/11/21 8:51 PM, Justin Pryzby wrote: >> @Andrew: did you have any comment on this part ? >> >> |Subject: buildfarm xversion diff >> |Forking >> https://www.postgresql.org/message-id/20210328231433.gi15...@telsasoft.com >> | >> |I gave suggestion

Re: pg_upgrade test for binary compatibility of core data types

2021-09-12 Thread Andrew Dunstan
On 9/11/21 8:51 PM, Justin Pryzby wrote: > > @Andrew: did you have any comment on this part ? > > |Subject: buildfarm xversion diff > |Forking > https://www.postgresql.org/message-id/20210328231433.gi15...@telsasoft.com > | > |I gave suggestion how to reduce the "lines of diff" metric almost to

Re: pg_upgrade test for binary compatibility of core data types

2021-09-11 Thread Justin Pryzby
On Fri, Jul 16, 2021 at 06:02:18PM +, Jacob Champion wrote: > On Fri, 2021-04-30 at 13:33 -0500, Justin Pryzby wrote: > > On Sat, Mar 06, 2021 at 03:01:43PM -0500, Tom Lane wrote: > > > v4-0001 mostly teaches test.sh about specific changes that have to be > > > made to historic versions of the

Re: pg_upgrade test for binary compatibility of core data types

2021-09-11 Thread Tom Lane
Jacob Champion writes: > On Fri, 2021-04-30 at 13:33 -0500, Justin Pryzby wrote: >> I started this. I don't know if it's compatible with the buildfarm client, >> but >> I think any issues maybe can be avoided by using "IF EXISTS". > Here are the differences I see on a first pass (without

Re: pg_upgrade test for binary compatibility of core data types

2021-07-16 Thread Jacob Champion
On Fri, 2021-04-30 at 13:33 -0500, Justin Pryzby wrote: > On Sat, Mar 06, 2021 at 03:01:43PM -0500, Tom Lane wrote: > > v4-0001 mostly teaches test.sh about specific changes that have to be > > made to historic versions of the regression database to allow them > > to be reloaded into current

Re: pg_upgrade test for binary compatibility of core data types

2021-07-16 Thread Jacob Champion
On Fri, 2021-07-16 at 16:21 +, Jacob Champion wrote: > On Fri, 2021-04-30 at 13:33 -0500, Justin Pryzby wrote: > > On Sat, Mar 06, 2021 at 03:01:43PM -0500, Tom Lane wrote: > > > v4-0001 mostly teaches test.sh about specific changes that have to be > > > made to historic versions of the

Re: pg_upgrade test for binary compatibility of core data types

2021-07-16 Thread Jacob Champion
On Fri, 2021-04-30 at 13:33 -0500, Justin Pryzby wrote: > On Sat, Mar 06, 2021 at 03:01:43PM -0500, Tom Lane wrote: > > v4-0001 mostly teaches test.sh about specific changes that have to be > > made to historic versions of the regression database to allow them > > to be reloaded into current

Re: pg_upgrade test for binary compatibility of core data types

2021-04-30 Thread Justin Pryzby
On Sat, Mar 06, 2021 at 03:01:43PM -0500, Tom Lane wrote: > Peter Eisentraut writes: > > On 2021-01-12 22:44, Andrew Dunstan wrote: > >> Cross version pg_upgrade is tested regularly in the buildfarm, but not > >> using test.sh. Instead it uses the saved data repository from a previous > >> run of

Re: pg_upgrade test for binary compatibility of core data types

2021-03-06 Thread Tom Lane
Peter Eisentraut writes: > On 2021-01-12 22:44, Andrew Dunstan wrote: >> Cross version pg_upgrade is tested regularly in the buildfarm, but not >> using test.sh. Instead it uses the saved data repository from a previous >> run of the buildfarm client for the source branch, and tries to upgrade >>

Re: pg_upgrade test for binary compatibility of core data types

2021-01-15 Thread Peter Eisentraut
On 2021-01-12 22:44, Andrew Dunstan wrote: Cross version pg_upgrade is tested regularly in the buildfarm, but not using test.sh. Instead it uses the saved data repository from a previous run of the buildfarm client for the source branch, and tries to upgrade that to the target branch. Does it

Re: pg_upgrade test for binary compatibility of core data types

2021-01-12 Thread Andrew Dunstan
On 1/12/21 12:53 PM, Bruce Momjian wrote: > On Tue, Jan 12, 2021 at 11:27:53AM -0600, Justin Pryzby wrote: >> On Tue, Jan 12, 2021 at 12:15:59PM -0500, Bruce Momjian wrote: >>> Uh, what exactly is missing from the beta checklist? I read the patch >>> and commit message but don't understand it.

Re: pg_upgrade test for binary compatibility of core data types

2021-01-12 Thread Bruce Momjian
On Tue, Jan 12, 2021 at 11:27:53AM -0600, Justin Pryzby wrote: > On Tue, Jan 12, 2021 at 12:15:59PM -0500, Bruce Momjian wrote: > > Uh, what exactly is missing from the beta checklist? I read the patch > > and commit message but don't understand it. > > Did you try to use test.sh to upgrade from

Re: pg_upgrade test for binary compatibility of core data types

2021-01-12 Thread Justin Pryzby
On Tue, Jan 12, 2021 at 12:15:59PM -0500, Bruce Momjian wrote: > On Mon, Jan 11, 2021 at 10:13:52PM -0600, Justin Pryzby wrote: > > On Mon, Jan 11, 2021 at 03:28:08PM +0100, Peter Eisentraut wrote: > > > I think these patches could use some in-place documentation of what they > > > are > > >

Re: pg_upgrade test for binary compatibility of core data types

2021-01-12 Thread Bruce Momjian
On Mon, Jan 11, 2021 at 10:13:52PM -0600, Justin Pryzby wrote: > On Mon, Jan 11, 2021 at 03:28:08PM +0100, Peter Eisentraut wrote: > > I think these patches could use some in-place documentation of what they are > > trying to achieve and how they do it. The required information is spread > > over

Re: pg_upgrade test for binary compatibility of core data types

2021-01-11 Thread Justin Pryzby
On Mon, Jan 11, 2021 at 03:28:08PM +0100, Peter Eisentraut wrote: > On 2020-12-27 20:07, Justin Pryzby wrote: > > On Wed, Dec 16, 2020 at 11:22:23AM -0600, Justin Pryzby wrote: > > > On Sun, Dec 06, 2020 at 12:02:48PM -0600, Justin Pryzby wrote: > > > > I meant to notice if the binary format is

Re: pg_upgrade test for binary compatibility of core data types

2021-01-11 Thread Bruce Momjian
On Mon, Jan 11, 2021 at 03:28:08PM +0100, Peter Eisentraut wrote: > On 2020-12-27 20:07, Justin Pryzby wrote: > > rebased on 6df7a9698bb036610c1e8c6d375e1be38cb26d5f > > I think these patches could use some in-place documentation of what they are > trying to achieve and how they do it. The

Re: pg_upgrade test for binary compatibility of core data types

2021-01-11 Thread Peter Eisentraut
On 2020-12-27 20:07, Justin Pryzby wrote: On Wed, Dec 16, 2020 at 11:22:23AM -0600, Justin Pryzby wrote: On Sun, Dec 06, 2020 at 12:02:48PM -0600, Justin Pryzby wrote: I meant to notice if the binary format is accidentally changed again, which was what happened here: 7c15cef86 Base

Re: pg_upgrade test for binary compatibility of core data types

2020-12-27 Thread Justin Pryzby
On Wed, Dec 16, 2020 at 11:22:23AM -0600, Justin Pryzby wrote: > On Sun, Dec 06, 2020 at 12:02:48PM -0600, Justin Pryzby wrote: > > I meant to notice if the binary format is accidentally changed again, which > > was > > what happened here: > > 7c15cef86 Base information_schema.sql_identifier

Re: pg_upgrade test for binary compatibility of core data types

2020-12-16 Thread Justin Pryzby
On Sun, Dec 06, 2020 at 12:02:48PM -0600, Justin Pryzby wrote: > I meant to notice if the binary format is accidentally changed again, which > was > what happened here: > 7c15cef86 Base information_schema.sql_identifier domain on name, not varchar. > > I added a table to the regression tests so

pg_upgrade test for binary compatibility of core data types

2020-12-06 Thread Justin Pryzby
I'm finally returning to this 14 month old thread: (was: Re: BUG #16045: vacuum_db crash and illegal memory alloc after pg_upgrade from PG11 to PG12) On Tue, Oct 15, 2019 at 09:07:25AM +0200, Tomas Vondra wrote: > On Mon, Oct 14, 2019 at 11:41:18PM -0500, Justin Pryzby wrote: > > > > Perhaps