pg.ddx.io pgsql-committers@postgresql.org mailing list archive
help / color / mirror / Atom feedpgsql: Rewrite interval_hash() so that the hashcodes are equal for
17+ messages / 4 participants
[nested] [flat]
* pgsql: Rewrite interval_hash() so that the hashcodes are equal for
@ 2009-04-04 04:53 Tom Lane <tgl@postgresql.org>
0 siblings, 0 replies; 17+ messages in thread
From: tgl@postgresql.org @ 2009-04-04 04:53 UTC (permalink / raw)
To: pgsql-committers
Log Message:
-----------
Rewrite interval_hash() so that the hashcodes are equal for values that
interval_eq() considers equal. I'm not sure how that fundamental requirement
escaped us through multiple revisions of this hash function, but there it is;
it's been wrong since interval_hash was first written for PG 7.1.
Per bug #4748 from Roman Kononov.
Backpatch to all supported releases.
This patch changes the contents of hash indexes for interval columns. That's
no particular problem for PG 8.4, since we've broken on-disk compatibility
of hash indexes already; but it will require a migration warning note in
the next minor releases of all existing branches: "if you have any hash
indexes on columns of type interval, REINDEX them after updating".
Modified Files:
--------------
pgsql/src/backend/utils/adt:
timestamp.c (r1.197 -> r1.198)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/timestamp.c?r1=1.197&r2=1.1...)
pgsql/src/test/regress/expected:
interval.out (r1.26 -> r1.27)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/interval.out?r1=1.26&r2...)
pgsql/src/test/regress/sql:
interval.sql (r1.18 -> r1.19)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/interval.sql?r1=1.18&r2=1.19)
^ permalink raw reply [nested|flat] 17+ messages in thread
* pgsql: Rewrite interval_hash() so that the hashcodes are equal for
@ 2009-04-04 04:53 Tom Lane <tgl@postgresql.org>
0 siblings, 0 replies; 17+ messages in thread
From: tgl@postgresql.org @ 2009-04-04 04:53 UTC (permalink / raw)
To: pgsql-committers
Log Message:
-----------
Rewrite interval_hash() so that the hashcodes are equal for values that
interval_eq() considers equal. I'm not sure how that fundamental requirement
escaped us through multiple revisions of this hash function, but there it is;
it's been wrong since interval_hash was first written for PG 7.1.
Per bug #4748 from Roman Kononov.
Backpatch to all supported releases.
This patch changes the contents of hash indexes for interval columns. That's
no particular problem for PG 8.4, since we've broken on-disk compatibility
of hash indexes already; but it will require a migration warning note in
the next minor releases of all existing branches: "if you have any hash
indexes on columns of type interval, REINDEX them after updating".
Tags:
----
REL8_3_STABLE
Modified Files:
--------------
pgsql/src/backend/utils/adt:
timestamp.c (r1.184.2.1 -> r1.184.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/timestamp.c?r1=1.184.2.1&r2...)
pgsql/src/test/regress/expected:
interval.out (r1.19 -> r1.19.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/interval.out?r1=1.19&r2...)
pgsql/src/test/regress/sql:
interval.sql (r1.12 -> r1.12.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/interval.sql?r1=1.12&r2=1.12...)
^ permalink raw reply [nested|flat] 17+ messages in thread
* pgsql: Rewrite interval_hash() so that the hashcodes are equal for
@ 2009-04-04 04:53 Tom Lane <tgl@postgresql.org>
0 siblings, 0 replies; 17+ messages in thread
From: tgl@postgresql.org @ 2009-04-04 04:53 UTC (permalink / raw)
To: pgsql-committers
Log Message:
-----------
Rewrite interval_hash() so that the hashcodes are equal for values that
interval_eq() considers equal. I'm not sure how that fundamental requirement
escaped us through multiple revisions of this hash function, but there it is;
it's been wrong since interval_hash was first written for PG 7.1.
Per bug #4748 from Roman Kononov.
Backpatch to all supported releases.
This patch changes the contents of hash indexes for interval columns. That's
no particular problem for PG 8.4, since we've broken on-disk compatibility
of hash indexes already; but it will require a migration warning note in
the next minor releases of all existing branches: "if you have any hash
indexes on columns of type interval, REINDEX them after updating".
Tags:
----
REL8_2_STABLE
Modified Files:
--------------
pgsql/src/backend/utils/adt:
timestamp.c (r1.169.2.2 -> r1.169.2.3)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/timestamp.c?r1=1.169.2.2&r2...)
pgsql/src/test/regress/expected:
interval.out (r1.18.2.1 -> r1.18.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/interval.out?r1=1.18.2.1&am...)
pgsql/src/test/regress/sql:
interval.sql (r1.11.2.1 -> r1.11.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/interval.sql?r1=1.11.2.1&r2=...)
^ permalink raw reply [nested|flat] 17+ messages in thread
* pgsql: Rewrite interval_hash() so that the hashcodes are equal for
@ 2009-04-04 04:53 Tom Lane <tgl@postgresql.org>
0 siblings, 0 replies; 17+ messages in thread
From: tgl@postgresql.org @ 2009-04-04 04:53 UTC (permalink / raw)
To: pgsql-committers
Log Message:
-----------
Rewrite interval_hash() so that the hashcodes are equal for values that
interval_eq() considers equal. I'm not sure how that fundamental requirement
escaped us through multiple revisions of this hash function, but there it is;
it's been wrong since interval_hash was first written for PG 7.1.
Per bug #4748 from Roman Kononov.
Backpatch to all supported releases.
This patch changes the contents of hash indexes for interval columns. That's
no particular problem for PG 8.4, since we've broken on-disk compatibility
of hash indexes already; but it will require a migration warning note in
the next minor releases of all existing branches: "if you have any hash
indexes on columns of type interval, REINDEX them after updating".
Tags:
----
REL8_1_STABLE
Modified Files:
--------------
pgsql/src/backend/utils/adt:
timestamp.c (r1.157.2.3 -> r1.157.2.4)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/timestamp.c?r1=1.157.2.3&r2...)
pgsql/src/test/regress/expected:
interval.out (r1.14.2.1 -> r1.14.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/interval.out?r1=1.14.2.1&am...)
pgsql/src/test/regress/sql:
interval.sql (r1.8.2.1 -> r1.8.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/interval.sql?r1=1.8.2.1&r2=1...)
^ permalink raw reply [nested|flat] 17+ messages in thread
* pgsql: Rewrite interval_hash() so that the hashcodes are equal for
@ 2009-04-04 04:53 Tom Lane <tgl@postgresql.org>
0 siblings, 0 replies; 17+ messages in thread
From: tgl@postgresql.org @ 2009-04-04 04:53 UTC (permalink / raw)
To: pgsql-committers
Log Message:
-----------
Rewrite interval_hash() so that the hashcodes are equal for values that
interval_eq() considers equal. I'm not sure how that fundamental requirement
escaped us through multiple revisions of this hash function, but there it is;
it's been wrong since interval_hash was first written for PG 7.1.
Per bug #4748 from Roman Kononov.
Backpatch to all supported releases.
This patch changes the contents of hash indexes for interval columns. That's
no particular problem for PG 8.4, since we've broken on-disk compatibility
of hash indexes already; but it will require a migration warning note in
the next minor releases of all existing branches: "if you have any hash
indexes on columns of type interval, REINDEX them after updating".
Tags:
----
REL8_0_STABLE
Modified Files:
--------------
pgsql/src/backend/utils/adt:
timestamp.c (r1.117.4.3 -> r1.117.4.4)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/timestamp.c?r1=1.117.4.3&r2...)
pgsql/src/test/regress/expected:
interval.out (r1.9.6.1 -> r1.9.6.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/interval.out?r1=1.9.6.1&...)
pgsql/src/test/regress/sql:
interval.sql (r1.5.8.1 -> r1.5.8.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/interval.sql?r1=1.5.8.1&r2=1...)
^ permalink raw reply [nested|flat] 17+ messages in thread
* pgsql: Rewrite interval_hash() so that the hashcodes are equal for
@ 2009-04-04 04:54 Tom Lane <tgl@postgresql.org>
0 siblings, 0 replies; 17+ messages in thread
From: tgl@postgresql.org @ 2009-04-04 04:54 UTC (permalink / raw)
To: pgsql-committers
Log Message:
-----------
Rewrite interval_hash() so that the hashcodes are equal for values that
interval_eq() considers equal. I'm not sure how that fundamental requirement
escaped us through multiple revisions of this hash function, but there it is;
it's been wrong since interval_hash was first written for PG 7.1.
Per bug #4748 from Roman Kononov.
Backpatch to all supported releases.
This patch changes the contents of hash indexes for interval columns. That's
no particular problem for PG 8.4, since we've broken on-disk compatibility
of hash indexes already; but it will require a migration warning note in
the next minor releases of all existing branches: "if you have any hash
indexes on columns of type interval, REINDEX them after updating".
Tags:
----
REL7_4_STABLE
Modified Files:
--------------
pgsql/src/backend/utils/adt:
timestamp.c (r1.96.2.3 -> r1.96.2.4)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/timestamp.c?r1=1.96.2.3&r2=...)
pgsql/src/test/regress/expected:
interval.out (r1.9.2.1 -> r1.9.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/interval.out?r1=1.9.2.1&...)
pgsql/src/test/regress/sql:
interval.sql (r1.5.4.1 -> r1.5.4.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/interval.sql?r1=1.5.4.1&r2=1...)
^ permalink raw reply [nested|flat] 17+ messages in thread
* pgsql: make dist uses git archive
@ 2024-03-25 05:34 Peter Eisentraut <peter@eisentraut.org>
2024-03-25 09:04 ` Re: pgsql: make dist uses git archive Magnus Hagander <magnus@hagander.net>
0 siblings, 1 reply; 17+ messages in thread
From: Peter Eisentraut @ 2024-03-25 05:34 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
make dist uses git archive
This changes "make dist" to directly use "git archive", rather than
the custom shell script it currently runs.
This is to make the creation of the distribution tarball more directly
traceable to the git repository. That is why we removed the "make
distprep" step.
"make dist" continues to produce a .gz and a .bz2 tarball as before.
The archives produced this way are deterministic and reproducible,
meaning for a given commit the result file should always be
bit-for-bit identical. The exception is that if you use a git version
older than 2.38.0, gzip records the platform in the archive, so you'd
get a different output on Windows vs. macOS vs. "UNIX" (everything
else). In git 2.38.0, this was changed so that everything is recorded
as "UNIX" now. This is just something to keep in mind. This issue is
specific to the gzip format, it does not affect other compression
formats.
Meson has its own distribution building command (meson dist), but we
are not using that at this point. The main problem is that, the way
they have implemented it, it is not deterministic in the above sense.
Also, we want a "make" version for the time being. But the target
name "dist" in meson is reserved for that reason, so we call the
custom target "pgdist" (so call something like "meson compile -C build
pgdist").
Reviewed-by: Tristan Partin <tristan@neon.tech>
Discussion: https://www.postgresql.org/message-id/flat/40e80f77-a294-4f29-a16f-e21bc7bc75fc%40eisentraut.org
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/619bc23a1a2f3750ac3668fe5a7564bc51e01684
Modified Files
--------------
GNUmakefile.in | 32 +++++++++++++----------------
meson.build | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 79 insertions(+), 18 deletions(-)
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: pgsql: make dist uses git archive
2024-03-25 05:34 pgsql: make dist uses git archive Peter Eisentraut <peter@eisentraut.org>
@ 2024-03-25 09:04 ` Magnus Hagander <magnus@hagander.net>
2024-03-25 19:30 ` Re: pgsql: make dist uses git archive Peter Eisentraut <peter@eisentraut.org>
0 siblings, 1 reply; 17+ messages in thread
From: Magnus Hagander @ 2024-03-25 09:04 UTC (permalink / raw)
To: Peter Eisentraut <peter@eisentraut.org>; +Cc: pgsql-committers@lists.postgresql.org, Andrew Dunstan <andrew@dunslane.net>
This seems to have broken buildfarm member guaibasaurus, which I believe is
the only one that runs "make dist" as part of the buildfarm. And as a
result,t hat breaks the snapshot build uploads.
I don't know exactly how it does it, it appears to not run from within the
git repository. It might be this needs an update to the buildfarm code
itself to handle this path? I haven't dug into how that code does the make
dist part (thus cc:ing in Andrew as well).
//Magnus
On Mon, Mar 25, 2024 at 6:35 AM Peter Eisentraut <peter@eisentraut.org>
wrote:
> make dist uses git archive
>
> This changes "make dist" to directly use "git archive", rather than
> the custom shell script it currently runs.
>
> This is to make the creation of the distribution tarball more directly
> traceable to the git repository. That is why we removed the "make
> distprep" step.
>
> "make dist" continues to produce a .gz and a .bz2 tarball as before.
>
> The archives produced this way are deterministic and reproducible,
> meaning for a given commit the result file should always be
> bit-for-bit identical. The exception is that if you use a git version
> older than 2.38.0, gzip records the platform in the archive, so you'd
> get a different output on Windows vs. macOS vs. "UNIX" (everything
> else). In git 2.38.0, this was changed so that everything is recorded
> as "UNIX" now. This is just something to keep in mind. This issue is
> specific to the gzip format, it does not affect other compression
> formats.
>
> Meson has its own distribution building command (meson dist), but we
> are not using that at this point. The main problem is that, the way
> they have implemented it, it is not deterministic in the above sense.
> Also, we want a "make" version for the time being. But the target
> name "dist" in meson is reserved for that reason, so we call the
> custom target "pgdist" (so call something like "meson compile -C build
> pgdist").
>
> Reviewed-by: Tristan Partin <tristan@neon.tech>
> Discussion:
> https://www.postgresql.org/message-id/flat/40e80f77-a294-4f29-a16f-e21bc7bc75fc%40eisentraut.org
>
> Branch
> ------
> master
>
> Details
> -------
>
> https://git.postgresql.org/pg/commitdiff/619bc23a1a2f3750ac3668fe5a7564bc51e01684
>
> Modified Files
> --------------
> GNUmakefile.in | 32 +++++++++++++----------------
> meson.build | 65
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 79 insertions(+), 18 deletions(-)
>
>
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: pgsql: make dist uses git archive
2024-03-25 05:34 pgsql: make dist uses git archive Peter Eisentraut <peter@eisentraut.org>
2024-03-25 09:04 ` Re: pgsql: make dist uses git archive Magnus Hagander <magnus@hagander.net>
@ 2024-03-25 19:30 ` Peter Eisentraut <peter@eisentraut.org>
2024-03-25 21:22 ` Re: pgsql: make dist uses git archive Magnus Hagander <magnus@hagander.net>
0 siblings, 1 reply; 17+ messages in thread
From: Peter Eisentraut @ 2024-03-25 19:30 UTC (permalink / raw)
To: Magnus Hagander <magnus@hagander.net>; +Cc: pgsql-committers@lists.postgresql.org, Andrew Dunstan <andrew@dunslane.net>
On 25.03.24 10:04, Magnus Hagander wrote:
> This seems to have broken buildfarm member guaibasaurus, which I believe
> is the only one that runs "make dist" as part of the buildfarm. And as a
> result,t hat breaks the snapshot build uploads.
>
> I don't know exactly how it does it, it appears to not run from within
> the git repository. It might be this needs an update to the buildfarm
> code itself to handle this path? I haven't dug into how that code does
> the make dist part (thus cc:ing in Andrew as well).
I don't see any code for this in the client-code git repository. So
maybe it is a local custom module?
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: pgsql: make dist uses git archive
2024-03-25 05:34 pgsql: make dist uses git archive Peter Eisentraut <peter@eisentraut.org>
2024-03-25 09:04 ` Re: pgsql: make dist uses git archive Magnus Hagander <magnus@hagander.net>
2024-03-25 19:30 ` Re: pgsql: make dist uses git archive Peter Eisentraut <peter@eisentraut.org>
@ 2024-03-25 21:22 ` Magnus Hagander <magnus@hagander.net>
2024-03-25 22:20 ` Re: pgsql: make dist uses git archive Andrew Dunstan <andrew@dunslane.net>
0 siblings, 1 reply; 17+ messages in thread
From: Magnus Hagander @ 2024-03-25 21:22 UTC (permalink / raw)
To: Peter Eisentraut <peter@eisentraut.org>; +Cc: pgsql-committers@lists.postgresql.org, Andrew Dunstan <andrew@dunslane.net>
On Mon, Mar 25, 2024 at 8:30 PM Peter Eisentraut <peter@eisentraut.org>
wrote:
> On 25.03.24 10:04, Magnus Hagander wrote:
> > This seems to have broken buildfarm member guaibasaurus, which I believe
> > is the only one that runs "make dist" as part of the buildfarm. And as a
> > result,t hat breaks the snapshot build uploads.
> >
> > I don't know exactly how it does it, it appears to not run from within
> > the git repository. It might be this needs an update to the buildfarm
> > code itself to handle this path? I haven't dug into how that code does
> > the make dist part (thus cc:ing in Andrew as well).
>
> I don't see any code for this in the client-code git repository. So
> maybe it is a local custom module?
>
>
Huh, it seems you're right. I didn't realize that :) We received that
module from Andrew back in Nov 2011, but I guess it was never committed to
the repo (assuming that was the intention) :) But it has served us well so
far...
PFA the module. It's pretty simple, but I don't know enough (anything,
really) about the bf client code to say how to fix it...
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/;
Attachments:
Dist.pm (application/x-perl, 1.4K) download
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: pgsql: make dist uses git archive
2024-03-25 05:34 pgsql: make dist uses git archive Peter Eisentraut <peter@eisentraut.org>
2024-03-25 09:04 ` Re: pgsql: make dist uses git archive Magnus Hagander <magnus@hagander.net>
2024-03-25 19:30 ` Re: pgsql: make dist uses git archive Peter Eisentraut <peter@eisentraut.org>
2024-03-25 21:22 ` Re: pgsql: make dist uses git archive Magnus Hagander <magnus@hagander.net>
@ 2024-03-25 22:20 ` Andrew Dunstan <andrew@dunslane.net>
2024-03-26 07:20 ` Re: pgsql: make dist uses git archive Peter Eisentraut <peter@eisentraut.org>
0 siblings, 1 reply; 17+ messages in thread
From: Andrew Dunstan @ 2024-03-25 22:20 UTC (permalink / raw)
To: Magnus Hagander <magnus@hagander.net>; +Cc: Peter Eisentraut <peter@eisentraut.org>; pgsql-committers@lists.postgresql.org
On Mon, Mar 25, 2024 at 5:22 PM Magnus Hagander <magnus@hagander.net> wrote:
>
>
> On Mon, Mar 25, 2024 at 8:30 PM Peter Eisentraut <peter@eisentraut.org>
> wrote:
>
>> On 25.03.24 10:04, Magnus Hagander wrote:
>> > This seems to have broken buildfarm member guaibasaurus, which I
>> believe
>> > is the only one that runs "make dist" as part of the buildfarm. And as
>> a
>> > result,t hat breaks the snapshot build uploads.
>> >
>> > I don't know exactly how it does it, it appears to not run from within
>> > the git repository. It might be this needs an update to the buildfarm
>> > code itself to handle this path? I haven't dug into how that code does
>> > the make dist part (thus cc:ing in Andrew as well).
>>
>> I don't see any code for this in the client-code git repository. So
>> maybe it is a local custom module?
>>
>>
> Huh, it seems you're right. I didn't realize that :) We received that
> module from Andrew back in Nov 2011, but I guess it was never committed to
> the repo (assuming that was the intention) :) But it has served us well so
> far...
>
I can add it to the repo. I'll look at adding a sanity test.
>
> PFA the module. It's pretty simple, but I don't know enough (anything,
> really) about the bf client code to say how to fix it...
>
The problem occurs because except in vpath mode the buildfarm operates on a
copy of the code, and for efficiency reasons we don't copy the ,git
directory.
The simplest fix is probably to change the machine's config to use a vpath
build.
In the config file change the undef here to a 1:
'use_vpath' => undef,
That worked for me in a quick test.
cheers
andrew
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: pgsql: make dist uses git archive
2024-03-25 05:34 pgsql: make dist uses git archive Peter Eisentraut <peter@eisentraut.org>
2024-03-25 09:04 ` Re: pgsql: make dist uses git archive Magnus Hagander <magnus@hagander.net>
2024-03-25 19:30 ` Re: pgsql: make dist uses git archive Peter Eisentraut <peter@eisentraut.org>
2024-03-25 21:22 ` Re: pgsql: make dist uses git archive Magnus Hagander <magnus@hagander.net>
2024-03-25 22:20 ` Re: pgsql: make dist uses git archive Andrew Dunstan <andrew@dunslane.net>
@ 2024-03-26 07:20 ` Peter Eisentraut <peter@eisentraut.org>
2024-03-26 08:13 ` Re: pgsql: make dist uses git archive Andrew Dunstan <andrew@dunslane.net>
0 siblings, 1 reply; 17+ messages in thread
From: Peter Eisentraut @ 2024-03-26 07:20 UTC (permalink / raw)
To: Andrew Dunstan <andrew@dunslane.net>; Magnus Hagander <magnus@hagander.net>; +Cc: pgsql-committers@lists.postgresql.org
On 25.03.24 23:20, Andrew Dunstan wrote:
> The problem occurs because except in vpath mode the buildfarm operates
> on a copy of the code, and for efficiency reasons we don't copy the ,git
> directory.
>
> The simplest fix is probably to change the machine's config to use a
> vpath build.
>
> In the config file change the undef here to a 1:
>
> 'use_vpath' => undef,
>
> That worked for me in a quick test.
Note that "make dist" doesn't work with vpath in backbranches. :-/
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: pgsql: make dist uses git archive
2024-03-25 05:34 pgsql: make dist uses git archive Peter Eisentraut <peter@eisentraut.org>
2024-03-25 09:04 ` Re: pgsql: make dist uses git archive Magnus Hagander <magnus@hagander.net>
2024-03-25 19:30 ` Re: pgsql: make dist uses git archive Peter Eisentraut <peter@eisentraut.org>
2024-03-25 21:22 ` Re: pgsql: make dist uses git archive Magnus Hagander <magnus@hagander.net>
2024-03-25 22:20 ` Re: pgsql: make dist uses git archive Andrew Dunstan <andrew@dunslane.net>
2024-03-26 07:20 ` Re: pgsql: make dist uses git archive Peter Eisentraut <peter@eisentraut.org>
@ 2024-03-26 08:13 ` Andrew Dunstan <andrew@dunslane.net>
2024-03-26 09:15 ` Re: pgsql: make dist uses git archive Magnus Hagander <magnus@hagander.net>
0 siblings, 1 reply; 17+ messages in thread
From: Andrew Dunstan @ 2024-03-26 08:13 UTC (permalink / raw)
To: Peter Eisentraut <peter@eisentraut.org>; +Cc: Magnus Hagander <magnus@hagander.net>; pgsql-committers@lists.postgresql.org
On Tue, Mar 26, 2024 at 3:20 AM Peter Eisentraut <peter@eisentraut.org>
wrote:
> On 25.03.24 23:20, Andrew Dunstan wrote:
> > The problem occurs because except in vpath mode the buildfarm operates
> > on a copy of the code, and for efficiency reasons we don't copy the ,git
> > directory.
> >
> > The simplest fix is probably to change the machine's config to use a
> > vpath build.
> >
> > In the config file change the undef here to a 1:
> >
> > 'use_vpath' => undef,
> >
> > That worked for me in a quick test.
>
> Note that "make dist" doesn't work with vpath in backbranches. :-/
>
Ugh.
OK, plan B :
In the Module's setup code, right after the "die", put
symlink("$buildroot/$branch/pgsql/.git","$pgsql/.git");
cheers
andrew
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: pgsql: make dist uses git archive
2024-03-25 05:34 pgsql: make dist uses git archive Peter Eisentraut <peter@eisentraut.org>
2024-03-25 09:04 ` Re: pgsql: make dist uses git archive Magnus Hagander <magnus@hagander.net>
2024-03-25 19:30 ` Re: pgsql: make dist uses git archive Peter Eisentraut <peter@eisentraut.org>
2024-03-25 21:22 ` Re: pgsql: make dist uses git archive Magnus Hagander <magnus@hagander.net>
2024-03-25 22:20 ` Re: pgsql: make dist uses git archive Andrew Dunstan <andrew@dunslane.net>
2024-03-26 07:20 ` Re: pgsql: make dist uses git archive Peter Eisentraut <peter@eisentraut.org>
2024-03-26 08:13 ` Re: pgsql: make dist uses git archive Andrew Dunstan <andrew@dunslane.net>
@ 2024-03-26 09:15 ` Magnus Hagander <magnus@hagander.net>
2024-03-26 10:10 ` Re: pgsql: make dist uses git archive Andrew Dunstan <andrew@dunslane.net>
0 siblings, 1 reply; 17+ messages in thread
From: Magnus Hagander @ 2024-03-26 09:15 UTC (permalink / raw)
To: Andrew Dunstan <andrew@dunslane.net>; +Cc: Peter Eisentraut <peter@eisentraut.org>; pgsql-committers@lists.postgresql.org
On Tue, Mar 26, 2024 at 9:13 AM Andrew Dunstan <andrew@dunslane.net> wrote:
>
>
> On Tue, Mar 26, 2024 at 3:20 AM Peter Eisentraut <peter@eisentraut.org>
> wrote:
>
>> On 25.03.24 23:20, Andrew Dunstan wrote:
>> > The problem occurs because except in vpath mode the buildfarm operates
>> > on a copy of the code, and for efficiency reasons we don't copy the
>> ,git
>> > directory.
>> >
>> > The simplest fix is probably to change the machine's config to use a
>> > vpath build.
>> >
>> > In the config file change the undef here to a 1:
>> >
>> > 'use_vpath' => undef,
>> >
>> > That worked for me in a quick test.
>>
>> Note that "make dist" doesn't work with vpath in backbranches. :-/
>>
>
>
> Ugh.
>
> OK, plan B :
>
> In the Module's setup code, right after the "die", put
>
> symlink("$buildroot/$branch/pgsql/.git","$pgsql/.git");
>
>
If I understand you right, you meant:
die "can't run this module with vpath builds"
if $conf->{vpath};
+ symlink("$buildroot/$branch/pgsql/.git","$pgsql/.git");
my $self = {buildroot => $buildroot, pgbranch=> $branch, bfconf =>
$conf, pgsql => $pgsql};
bless ($self, $class);
If so, I tried that, but it didn't work. That's this run here:
https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=guaibasaurus&dt=2024-03-26%2009%3A...
//Magnus
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: pgsql: make dist uses git archive
2024-03-25 05:34 pgsql: make dist uses git archive Peter Eisentraut <peter@eisentraut.org>
2024-03-25 09:04 ` Re: pgsql: make dist uses git archive Magnus Hagander <magnus@hagander.net>
2024-03-25 19:30 ` Re: pgsql: make dist uses git archive Peter Eisentraut <peter@eisentraut.org>
2024-03-25 21:22 ` Re: pgsql: make dist uses git archive Magnus Hagander <magnus@hagander.net>
2024-03-25 22:20 ` Re: pgsql: make dist uses git archive Andrew Dunstan <andrew@dunslane.net>
2024-03-26 07:20 ` Re: pgsql: make dist uses git archive Peter Eisentraut <peter@eisentraut.org>
2024-03-26 08:13 ` Re: pgsql: make dist uses git archive Andrew Dunstan <andrew@dunslane.net>
2024-03-26 09:15 ` Re: pgsql: make dist uses git archive Magnus Hagander <magnus@hagander.net>
@ 2024-03-26 10:10 ` Andrew Dunstan <andrew@dunslane.net>
2024-03-26 11:09 ` Re: pgsql: make dist uses git archive Andrew Dunstan <andrew@dunslane.net>
0 siblings, 1 reply; 17+ messages in thread
From: Andrew Dunstan @ 2024-03-26 10:10 UTC (permalink / raw)
To: Magnus Hagander <magnus@hagander.net>; +Cc: Peter Eisentraut <peter@eisentraut.org>; pgsql-committers@lists.postgresql.org
On Tue, Mar 26, 2024 at 5:15 AM Magnus Hagander <magnus@hagander.net> wrote:
>
>
> On Tue, Mar 26, 2024 at 9:13 AM Andrew Dunstan <andrew@dunslane.net>
> wrote:
>
>>
>>
>> On Tue, Mar 26, 2024 at 3:20 AM Peter Eisentraut <peter@eisentraut.org>
>> wrote:
>>
>>> On 25.03.24 23:20, Andrew Dunstan wrote:
>>> > The problem occurs because except in vpath mode the buildfarm operates
>>> > on a copy of the code, and for efficiency reasons we don't copy the
>>> ,git
>>> > directory.
>>> >
>>> > The simplest fix is probably to change the machine's config to use a
>>> > vpath build.
>>> >
>>> > In the config file change the undef here to a 1:
>>> >
>>> > 'use_vpath' => undef,
>>> >
>>> > That worked for me in a quick test.
>>>
>>> Note that "make dist" doesn't work with vpath in backbranches. :-/
>>>
>>
>>
>> Ugh.
>>
>> OK, plan B :
>>
>> In the Module's setup code, right after the "die", put
>>
>> symlink("$buildroot/$branch/pgsql/.git","$pgsql/.git");
>>
>>
> If I understand you right, you meant:
>
> die "can't run this module with vpath builds"
> if $conf->{vpath};
> + symlink("$buildroot/$branch/pgsql/.git","$pgsql/.git");
>
> my $self = {buildroot => $buildroot, pgbranch=> $branch, bfconf
> => $conf, pgsql => $pgsql};
> bless ($self, $class);
>
> If so, I tried that, but it didn't work. That's this run here:
> https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=guaibasaurus&dt=2024-03-26%2009%3A...
>
>
>
*sigh*
OK, instead of speculating I'll experiment and come up with an answer.
cheers
andrew
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: pgsql: make dist uses git archive
2024-03-25 05:34 pgsql: make dist uses git archive Peter Eisentraut <peter@eisentraut.org>
2024-03-25 09:04 ` Re: pgsql: make dist uses git archive Magnus Hagander <magnus@hagander.net>
2024-03-25 19:30 ` Re: pgsql: make dist uses git archive Peter Eisentraut <peter@eisentraut.org>
2024-03-25 21:22 ` Re: pgsql: make dist uses git archive Magnus Hagander <magnus@hagander.net>
2024-03-25 22:20 ` Re: pgsql: make dist uses git archive Andrew Dunstan <andrew@dunslane.net>
2024-03-26 07:20 ` Re: pgsql: make dist uses git archive Peter Eisentraut <peter@eisentraut.org>
2024-03-26 08:13 ` Re: pgsql: make dist uses git archive Andrew Dunstan <andrew@dunslane.net>
2024-03-26 09:15 ` Re: pgsql: make dist uses git archive Magnus Hagander <magnus@hagander.net>
2024-03-26 10:10 ` Re: pgsql: make dist uses git archive Andrew Dunstan <andrew@dunslane.net>
@ 2024-03-26 11:09 ` Andrew Dunstan <andrew@dunslane.net>
2024-03-26 13:09 ` Re: pgsql: make dist uses git archive Magnus Hagander <magnus@hagander.net>
0 siblings, 1 reply; 17+ messages in thread
From: Andrew Dunstan @ 2024-03-26 11:09 UTC (permalink / raw)
To: Magnus Hagander <magnus@hagander.net>; +Cc: Peter Eisentraut <peter@eisentraut.org>; pgsql-committers@lists.postgresql.org
On Tue, Mar 26, 2024 at 6:10 AM Andrew Dunstan <andrew@dunslane.net> wrote:
>
>
> On Tue, Mar 26, 2024 at 5:15 AM Magnus Hagander <magnus@hagander.net>
> wrote:
>
>>
>>
>> On Tue, Mar 26, 2024 at 9:13 AM Andrew Dunstan <andrew@dunslane.net>
>> wrote:
>>
>>>
>>>
>>> On Tue, Mar 26, 2024 at 3:20 AM Peter Eisentraut <peter@eisentraut.org>
>>> wrote:
>>>
>>>> On 25.03.24 23:20, Andrew Dunstan wrote:
>>>> > The problem occurs because except in vpath mode the buildfarm
>>>> operates
>>>> > on a copy of the code, and for efficiency reasons we don't copy the
>>>> ,git
>>>> > directory.
>>>> >
>>>> > The simplest fix is probably to change the machine's config to use a
>>>> > vpath build.
>>>> >
>>>> > In the config file change the undef here to a 1:
>>>> >
>>>> > 'use_vpath' => undef,
>>>> >
>>>> > That worked for me in a quick test.
>>>>
>>>> Note that "make dist" doesn't work with vpath in backbranches. :-/
>>>>
>>>
>>>
>>> Ugh.
>>>
>>> OK, plan B :
>>>
>>> In the Module's setup code, right after the "die", put
>>>
>>> symlink("$buildroot/$branch/pgsql/.git","$pgsql/.git");
>>>
>>>
>> If I understand you right, you meant:
>>
>> die "can't run this module with vpath builds"
>> if $conf->{vpath};
>> + symlink("$buildroot/$branch/pgsql/.git","$pgsql/.git");
>>
>> my $self = {buildroot => $buildroot, pgbranch=> $branch, bfconf
>> => $conf, pgsql => $pgsql};
>> bless ($self, $class);
>>
>> If so, I tried that, but it didn't work. That's this run here:
>> https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=guaibasaurus&dt=2024-03-26%2009%3A...
>>
>>
>>
> *sigh*
>
> OK, instead of speculating I'll experiment and come up with an answer.
>
OK, this should work. Put these lines after the first print statement of
the module's build() routine - the setup() routine runs too early:
my $src = "$self->{buildroot}/$self->{pgbranch}/pgsql";
symlink("$src/.git", "$self->{pgsql}/.git");
cheers
andrew
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: pgsql: make dist uses git archive
2024-03-25 05:34 pgsql: make dist uses git archive Peter Eisentraut <peter@eisentraut.org>
2024-03-25 09:04 ` Re: pgsql: make dist uses git archive Magnus Hagander <magnus@hagander.net>
2024-03-25 19:30 ` Re: pgsql: make dist uses git archive Peter Eisentraut <peter@eisentraut.org>
2024-03-25 21:22 ` Re: pgsql: make dist uses git archive Magnus Hagander <magnus@hagander.net>
2024-03-25 22:20 ` Re: pgsql: make dist uses git archive Andrew Dunstan <andrew@dunslane.net>
2024-03-26 07:20 ` Re: pgsql: make dist uses git archive Peter Eisentraut <peter@eisentraut.org>
2024-03-26 08:13 ` Re: pgsql: make dist uses git archive Andrew Dunstan <andrew@dunslane.net>
2024-03-26 09:15 ` Re: pgsql: make dist uses git archive Magnus Hagander <magnus@hagander.net>
2024-03-26 10:10 ` Re: pgsql: make dist uses git archive Andrew Dunstan <andrew@dunslane.net>
2024-03-26 11:09 ` Re: pgsql: make dist uses git archive Andrew Dunstan <andrew@dunslane.net>
@ 2024-03-26 13:09 ` Magnus Hagander <magnus@hagander.net>
0 siblings, 0 replies; 17+ messages in thread
From: Magnus Hagander @ 2024-03-26 13:09 UTC (permalink / raw)
To: Andrew Dunstan <andrew@dunslane.net>; +Cc: Peter Eisentraut <peter@eisentraut.org>; pgsql-committers@lists.postgresql.org
On Tue, Mar 26, 2024 at 12:09 PM Andrew Dunstan <andrew@dunslane.net> wrote:
>
>
> On Tue, Mar 26, 2024 at 6:10 AM Andrew Dunstan <andrew@dunslane.net>
> wrote:
>
>>
>>
>> On Tue, Mar 26, 2024 at 5:15 AM Magnus Hagander <magnus@hagander.net>
>> wrote:
>>
>>>
>>>
>>> On Tue, Mar 26, 2024 at 9:13 AM Andrew Dunstan <andrew@dunslane.net>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Mar 26, 2024 at 3:20 AM Peter Eisentraut <peter@eisentraut.org>
>>>> wrote:
>>>>
>>>>> On 25.03.24 23:20, Andrew Dunstan wrote:
>>>>> > The problem occurs because except in vpath mode the buildfarm
>>>>> operates
>>>>> > on a copy of the code, and for efficiency reasons we don't copy the
>>>>> ,git
>>>>> > directory.
>>>>> >
>>>>> > The simplest fix is probably to change the machine's config to use a
>>>>> > vpath build.
>>>>> >
>>>>> > In the config file change the undef here to a 1:
>>>>> >
>>>>> > 'use_vpath' => undef,
>>>>> >
>>>>> > That worked for me in a quick test.
>>>>>
>>>>> Note that "make dist" doesn't work with vpath in backbranches. :-/
>>>>>
>>>>
>>>>
>>>> Ugh.
>>>>
>>>> OK, plan B :
>>>>
>>>> In the Module's setup code, right after the "die", put
>>>>
>>>> symlink("$buildroot/$branch/pgsql/.git","$pgsql/.git");
>>>>
>>>>
>>> If I understand you right, you meant:
>>>
>>> die "can't run this module with vpath builds"
>>> if $conf->{vpath};
>>> + symlink("$buildroot/$branch/pgsql/.git","$pgsql/.git");
>>>
>>> my $self = {buildroot => $buildroot, pgbranch=> $branch, bfconf
>>> => $conf, pgsql => $pgsql};
>>> bless ($self, $class);
>>>
>>> If so, I tried that, but it didn't work. That's this run here:
>>> https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=guaibasaurus&dt=2024-03-26%2009%3A...
>>>
>>>
>>>
>> *sigh*
>>
>> OK, instead of speculating I'll experiment and come up with an answer.
>>
>
>
> OK, this should work. Put these lines after the first print statement of
> the module's build() routine - the setup() routine runs too early:
>
> my $src = "$self->{buildroot}/$self->{pgbranch}/pgsql";
> symlink("$src/.git", "$self->{pgsql}/.git");
>
>
>
That seems to have sorted it.
I did a manual force run and that made it recovered. Let's see if it's also
happy after the first regular run, but it definitely look right.
Thanks!
//Magnus
^ permalink raw reply [nested|flat] 17+ messages in thread
end of thread, other threads:[~2024-03-26 13:09 UTC | newest]
Thread overview: 17+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2009-04-04 04:53 pgsql: Rewrite interval_hash() so that the hashcodes are equal for Tom Lane <tgl@postgresql.org>
2009-04-04 04:53 pgsql: Rewrite interval_hash() so that the hashcodes are equal for Tom Lane <tgl@postgresql.org>
2009-04-04 04:53 pgsql: Rewrite interval_hash() so that the hashcodes are equal for Tom Lane <tgl@postgresql.org>
2009-04-04 04:53 pgsql: Rewrite interval_hash() so that the hashcodes are equal for Tom Lane <tgl@postgresql.org>
2009-04-04 04:53 pgsql: Rewrite interval_hash() so that the hashcodes are equal for Tom Lane <tgl@postgresql.org>
2009-04-04 04:54 pgsql: Rewrite interval_hash() so that the hashcodes are equal for Tom Lane <tgl@postgresql.org>
2024-03-25 05:34 pgsql: make dist uses git archive Peter Eisentraut <peter@eisentraut.org>
2024-03-25 09:04 ` Re: pgsql: make dist uses git archive Magnus Hagander <magnus@hagander.net>
2024-03-25 19:30 ` Re: pgsql: make dist uses git archive Peter Eisentraut <peter@eisentraut.org>
2024-03-25 21:22 ` Re: pgsql: make dist uses git archive Magnus Hagander <magnus@hagander.net>
2024-03-25 22:20 ` Re: pgsql: make dist uses git archive Andrew Dunstan <andrew@dunslane.net>
2024-03-26 07:20 ` Re: pgsql: make dist uses git archive Peter Eisentraut <peter@eisentraut.org>
2024-03-26 08:13 ` Re: pgsql: make dist uses git archive Andrew Dunstan <andrew@dunslane.net>
2024-03-26 09:15 ` Re: pgsql: make dist uses git archive Magnus Hagander <magnus@hagander.net>
2024-03-26 10:10 ` Re: pgsql: make dist uses git archive Andrew Dunstan <andrew@dunslane.net>
2024-03-26 11:09 ` Re: pgsql: make dist uses git archive Andrew Dunstan <andrew@dunslane.net>
2024-03-26 13:09 ` Re: pgsql: make dist uses git archive Magnus Hagander <magnus@hagander.net>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox