On Fri, Apr 15, 2022 at 04:49:28PM +0200, Christoph Berg wrote:
> Since build-time testing broke again about two weeks ago due to
> Debian's pg_config patch, I revisited the situation and found that the
> patch is in fact no longer necessary to support pg_config in /usr/bin:
>
> To support cross-c
Re: Michael Paquier
> > I was confusing that with this: The problem that led to the pg_config
> > patch years ago was that we have a /usr/bin/pg_config in
> > (non-major-version-dependant) libpq-dev, and
> > /usr/lib/postgresql/NN/bin/pg_config in the individual
> > postgresql-server-dev-NN package
On Wed, Feb 16, 2022 at 07:39:26PM -0500, Robert Haas wrote:
> Sorry, I saw that and then forgot about it ... but isn't it 3 days,
> not 4 weeks? In any case, I'm happy to have you take care of it, but I
> can also look at it tomorrow if you prefer.
Ugh. I looked at the top of the thread and saw
On Wed, Feb 16, 2022 at 7:24 PM Michael Paquier wrote:
> On Wed, Feb 16, 2022 at 01:38:51PM +0100, Christoph Berg wrote:
> > The build works with the "Add TAP test to automate the equivalent of
> > check_guc, take two" commit. Thanks!
>
> Thanks for double-checking, Christoph!
>
> > (Tests are sti
On Wed, Feb 16, 2022 at 01:38:51PM +0100, Christoph Berg wrote:
> The build works with the "Add TAP test to automate the equivalent of
> check_guc, take two" commit. Thanks!
Thanks for double-checking, Christoph!
> (Tests are still failing for
> https://www.postgresql.org/message-id/YgjwrkEvNEqoz
Re: Michael Paquier
> Hearing nothing, I have looked once again at this stuff and tested it
> with what Debian was doing. And that looks to work fine for
> everything we care about, so applied with the use of a relative path
> to find postgresql.conf.sample in the source tree.
The build works wit
On Mon, Feb 14, 2022 at 02:11:37PM +0900, Michael Paquier wrote:
> A run through the CI shows that this is working, and it also works
> with Debian's patch for the config data. I still tend to prefer the
> readability of a TAP test over the main regression test suite for this
> facility.
Hearing
On Sat, Feb 12, 2022 at 12:10:46PM -0800, Andres Freund wrote:
> Tap tests currently are always executed in the source directory above t/, as
> far as I can tell. So I don't think VPATH/non-VPATH or windows / non-windows
> would break using a relative reference from the test dir.
That would mean t
On Sat, Feb 12, 2022 at 05:31:55PM +0100, Christoph Berg wrote:
> To support multiple major versions in parallel, we need
> /usr/lib/postgresql/NN/lib and /usr/share/postgresql/NN, so it's not a
> single $PREFIX. But you are correct, and ./configure supports that.
Yep, I don't quite see the proble
Hi,
On 2022-02-12 13:29:54 +0900, Michael Paquier wrote:
> On Sat, Feb 12, 2022 at 09:49:47AM +0900, Michael Paquier wrote:
> > I guess that it would be better to revert the TAP test and rework all
> > that for the time being, then.
>
> And this part is done.
You wrote in the commit message that
Re: Tom Lane
> Ah. That seems a bit problematic anyway ... if the version-dependent
> pg_configs don't all return identical results, what's the
> non-version-dependent one supposed to do?
It still returns a correct --includedir for client apps that need it.
(Unfortunately many need --includedir-
Christoph Berg writes:
> I was confusing that with this: The problem that led to the pg_config
> patch years ago was that we have a /usr/bin/pg_config in
> (non-major-version-dependant) libpq-dev, and
> /usr/lib/postgresql/NN/bin/pg_config in the individual
> postgresql-server-dev-NN packages, and
Re: Tom Lane
> Christoph Berg writes:
> > I think the "bug" here is that vanilla PG doesn't support installing
> > in FHS locations with /usr/lib and /usr/share split, hence the Debian
> > patch.
>
> I'm confused by this statement. An out-of-the-box installation
> produces trees under $PREFIX/li
Christoph Berg writes:
> I think the "bug" here is that vanilla PG doesn't support installing
> in FHS locations with /usr/lib and /usr/share split, hence the Debian
> patch.
I'm confused by this statement. An out-of-the-box installation
produces trees under $PREFIX/lib and $PREFIX/share. What
Re: Michael Paquier
> On Fri, Feb 11, 2022 at 10:48:11AM +0100, Christoph Berg wrote:
> > It never caused any problem in the 12+ years we have been doing this,
> > but Debian is patching pg_config not to be relocatable since we are
> > installing into /usr/lib/postgresql/NN /usr/share/postgresql/NN
On Sat, Feb 12, 2022 at 09:49:47AM +0900, Michael Paquier wrote:
> I guess that it would be better to revert the TAP test and rework all
> that for the time being, then.
And this part is done.
--
Michael
signature.asc
Description: PGP signature
On Fri, Feb 11, 2022 at 12:34:31PM -0500, Tom Lane wrote:
> Justin Pryzby writes:
>> Or, is it okay to use ABS_SRCDIR?
>
> Don't see why not --- other tests certainly do.
Another solution would be to rely on TESTDIR, which is always set as
of the Makefile invocations and vcregress.pl, but that's
On Fri, Feb 11, 2022 at 10:48:11AM +0100, Christoph Berg wrote:
> It never caused any problem in the 12+ years we have been doing this,
> but Debian is patching pg_config not to be relocatable since we are
> installing into /usr/lib/postgresql/NN /usr/share/postgresql/NN, so
> not a single prefix.
Justin Pryzby writes:
> Or, is it okay to use ABS_SRCDIR?
Don't see why not --- other tests certainly do.
regards, tom lane
On Fri, Feb 11, 2022 at 10:41:27AM -0500, Tom Lane wrote:
> Justin Pryzby writes:
> > On Fri, Feb 11, 2022 at 09:59:55AM -0500, Tom Lane wrote:
> >> This seems like a pretty bad idea even if it weren't failing outright.
> >> We should be examining the version of the file that's in the source
> >>
Justin Pryzby writes:
> On Fri, Feb 11, 2022 at 09:59:55AM -0500, Tom Lane wrote:
>> This seems like a pretty bad idea even if it weren't failing outright.
>> We should be examining the version of the file that's in the source
>> tree; the one in the installation tree might have version-skew
>> pr
On Fri, Feb 11, 2022 at 09:59:55AM -0500, Tom Lane wrote:
> Christoph Berg writes:
> > this test is failing at Debian package compile time:
> > Could not open /usr/share/postgresql/15/postgresql.conf.sample: No such
> > file or directory at t/003_check_guc.pl line 47.
>
> > So it's trying to rea
Christoph Berg writes:
> this test is failing at Debian package compile time:
> Could not open /usr/share/postgresql/15/postgresql.conf.sample: No such file
> or directory at t/003_check_guc.pl line 47.
> So it's trying to read from /usr/share/postgresql which doesn't exist
> yet at build time.
Re: Michael Paquier
> Add TAP test to automate the equivalent of check_guc
>
> src/backend/utils/misc/check_guc is a script that cross-checks the
> consistency of the GUCs with postgresql.conf.sample, making sure that
Hi,
this test is failing at Debian package compile time:
00:55:07 ok 18 - dro
24 matches
Mail list logo