pg.ddx.io pgsql-committers@postgresql.org mailing list archive
help / color / mirror / Atom feedpgsql: Initialise perl library as documented in perl API.
16+ messages / 6 participants
[nested] [flat]
* pgsql: Initialise perl library as documented in perl API.
@ 2009-06-04 15:59 Andrew Dunstan <adunstan@postgresql.org>
0 siblings, 1 reply; 16+ messages in thread
From: adunstan@postgresql.org @ 2009-06-04 15:59 UTC (permalink / raw)
To: pgsql-committers
Log Message:
-----------
Initialise perl library as documented in perl API. Backpatch to release 7.4.
Modified Files:
--------------
pgsql/src/pl/plperl:
plperl.c (r1.146 -> r1.147)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/pl/plperl/plperl.c?r1=1.146&r2=1.147)
^ permalink raw reply [nested|flat] 16+ messages in thread
* pgsql: Initialise perl library as documented in perl API.
@ 2009-06-04 16:00 Andrew Dunstan <adunstan@postgresql.org>
0 siblings, 0 replies; 16+ messages in thread
From: adunstan@postgresql.org @ 2009-06-04 16:00 UTC (permalink / raw)
To: pgsql-committers
Log Message:
-----------
Initialise perl library as documented in perl API. Backpatch to release 7.4.
Tags:
----
REL8_3_STABLE
Modified Files:
--------------
pgsql/src/pl/plperl:
plperl.c (r1.136 -> r1.136.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/pl/plperl/plperl.c?r1=1.136&r2=1.136.2.1)
^ permalink raw reply [nested|flat] 16+ messages in thread
* pgsql: Initialise perl library as documented in perl API.
@ 2009-06-04 16:00 Andrew Dunstan <adunstan@postgresql.org>
0 siblings, 0 replies; 16+ messages in thread
From: adunstan@postgresql.org @ 2009-06-04 16:00 UTC (permalink / raw)
To: pgsql-committers
Log Message:
-----------
Initialise perl library as documented in perl API. Backpatch to release 7.4.
Tags:
----
REL8_2_STABLE
Modified Files:
--------------
pgsql/src/pl/plperl:
plperl.c (r1.123.2.4 -> r1.123.2.5)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/pl/plperl/plperl.c?r1=1.123.2.4&r2=1.123.2.5)
^ permalink raw reply [nested|flat] 16+ messages in thread
* pgsql: Initialise perl library as documented in perl API.
@ 2009-06-04 16:00 Andrew Dunstan <adunstan@postgresql.org>
0 siblings, 0 replies; 16+ messages in thread
From: adunstan@postgresql.org @ 2009-06-04 16:00 UTC (permalink / raw)
To: pgsql-committers
Log Message:
-----------
Initialise perl library as documented in perl API. Backpatch to release 7.4.
Tags:
----
REL8_1_STABLE
Modified Files:
--------------
pgsql/src/pl/plperl:
plperl.c (r1.94.2.10 -> r1.94.2.11)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/pl/plperl/plperl.c?r1=1.94.2.10&r2=1.94.2.11)
^ permalink raw reply [nested|flat] 16+ messages in thread
* pgsql: Initialise perl library as documented in perl API.
@ 2009-06-04 16:01 Andrew Dunstan <adunstan@postgresql.org>
0 siblings, 0 replies; 16+ messages in thread
From: adunstan@postgresql.org @ 2009-06-04 16:01 UTC (permalink / raw)
To: pgsql-committers
Log Message:
-----------
Initialise perl library as documented in perl API. Backpatch to release 7.4.
Tags:
----
REL8_0_STABLE
Modified Files:
--------------
pgsql/src/pl/plperl:
plperl.c (r1.67.4.8 -> r1.67.4.9)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/pl/plperl/plperl.c?r1=1.67.4.8&r2=1.67.4.9)
^ permalink raw reply [nested|flat] 16+ messages in thread
* pgsql: Initialise perl library as documented in perl API.
@ 2009-06-04 16:01 Andrew Dunstan <adunstan@postgresql.org>
0 siblings, 0 replies; 16+ messages in thread
From: adunstan@postgresql.org @ 2009-06-04 16:01 UTC (permalink / raw)
To: pgsql-committers
Log Message:
-----------
Initialise perl library as documented in perl API. Backpatch to release 7.4.
Tags:
----
REL7_4_STABLE
Modified Files:
--------------
pgsql/src/pl/plperl:
plperl.c (r1.40.2.1 -> r1.40.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/pl/plperl/plperl.c?r1=1.40.2.1&r2=1.40.2.2)
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: [COMMITTERS] pgsql: Initialise perl library as documented in perl API.
@ 2009-06-04 16:38 Tom Lane <tgl@sss.pgh.pa.us>
parent: Andrew Dunstan <adunstan@postgresql.org>
0 siblings, 1 reply; 16+ messages in thread
From: Tom Lane @ 2009-06-04 16:38 UTC (permalink / raw)
To: Andrew Dunstan <andrew@dunslane.net>; +Cc: pgsql-hackers@postgresql.org
adunstan@postgresql.org (Andrew Dunstan) writes:
> Log Message:
> -----------
> Initialise perl library as documented in perl API. Backpatch to release 7.4.
Hmm, buildfarm says this doesn't work too well on Unixware :-(
regards, tom lane
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: [COMMITTERS] pgsql: Initialise perl library as documented in perl API.
@ 2009-06-04 17:08 Andrew Dunstan <andrew@dunslane.net>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 16+ messages in thread
From: Andrew Dunstan @ 2009-06-04 17:08 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers@postgresql.org
Tom Lane wrote:
> adunstan@postgresql.org (Andrew Dunstan) writes:
>
>> Log Message:
>> -----------
>> Initialise perl library as documented in perl API. Backpatch to release 7.4.
>>
>
> Hmm, buildfarm says this doesn't work too well on Unixware :-(
>
>
>
That's what we have a buildfarm for ;-) There's a failure on FBSD too
by the look of it. I'll dig some more to see what I can find.
I did test on Windows and Linux.
cheers
andrew
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: [COMMITTERS] pgsql: Initialise perl library as documented in perl API.
@ 2009-06-04 17:33 Tom Lane <tgl@sss.pgh.pa.us>
parent: Andrew Dunstan <andrew@dunslane.net>
0 siblings, 1 reply; 16+ messages in thread
From: Tom Lane @ 2009-06-04 17:33 UTC (permalink / raw)
To: Andrew Dunstan <andrew@dunslane.net>; +Cc: pgsql-hackers@postgresql.org
Andrew Dunstan <andrew@dunslane.net> writes:
> That's what we have a buildfarm for ;-) There's a failure on FBSD too
> by the look of it. I'll dig some more to see what I can find.
I see this when building HEAD on Fedora 10:
plperl.c: In function 'plperl_init_interp':
plperl.c:450: warning: null argument where non-null required (argument 3)
Seems like a good hint ...
regards, tom lane
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: [COMMITTERS] pgsql: Initialise perl library as documented in perl API.
@ 2009-06-04 17:57 Andrew Dunstan <andrew@dunslane.net>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 16+ messages in thread
From: Andrew Dunstan @ 2009-06-04 17:57 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers@postgresql.org
Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>
>> That's what we have a buildfarm for ;-) There's a failure on FBSD too
>> by the look of it. I'll dig some more to see what I can find.
>>
>
> I see this when building HEAD on Fedora 10:
>
> plperl.c: In function 'plperl_init_interp':
> plperl.c:450: warning: null argument where non-null required (argument 3)
>
> Seems like a good hint ...
>
>
>
Yeah. I didn't get that. But the odd thing is that on 5.8 especially it
shouldn't matter.
perl 5.8.8's perl.h has:
#ifndef PERL_SYS_INIT3
# define PERL_SYS_INIT3(argvp,argcp,envp) PERL_SYS_INIT(argvp,argcp)
#endif
and the only place it's defined elsewhere that I can see is for OS2 (for
anyone still running it!). These two Unixware machines have 5.8.8. and
the FBSD machine has 5.8.7. So surely it can't be that, unless I'm
missing something badly.
The unixish.h file has this on 5.8:
# define PERL_SYS_INIT(c,v) MALLOC_CHECK_TAINT2(*c,*v)
PERL_FPU_INIT MALLOC_INIT
I'm guessing the problem is actually somewhere in there.
I could construct a dummy environment to pass to perl to quiet that
warning, or I could even clone the environment - I'm mildly reluctant to
pass the real environment to this, as the perlembed man page blandly
tells us that this macro might mangle what is passed to it (even though
we know on 5.8 it doesn't).
cheers
andrew
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Re: [COMMITTERS] pgsql: Initialise perl library as documented in perl API.
@ 2009-06-05 13:46 Andrew Dunstan <andrew@dunslane.net>
parent: Andrew Dunstan <andrew@dunslane.net>
0 siblings, 3 replies; 16+ messages in thread
From: Andrew Dunstan @ 2009-06-05 13:46 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers@postgresql.org
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>> Andrew Dunstan <andrew@dunslane.net> writes:
>>
>>> That's what we have a buildfarm for ;-) There's a failure on FBSD
>>> too by the look of it. I'll dig some more to see what I can find.
>>>
>>
>> I see this when building HEAD on Fedora 10:
>>
>> plperl.c: In function 'plperl_init_interp':
>> plperl.c:450: warning: null argument where non-null required
>> (argument 3)
>>
>> Seems like a good hint ...
>>
>>
>>
> Yeah. I didn't get that. But the odd thing is that on 5.8 especially
> it shouldn't matter.
>
> perl 5.8.8's perl.h has:
>
> #ifndef PERL_SYS_INIT3
> # define PERL_SYS_INIT3(argvp,argcp,envp) PERL_SYS_INIT(argvp,argcp)
> #endif
>
>
> and the only place it's defined elsewhere that I can see is for OS2
> (for anyone still running it!). These two Unixware machines have
> 5.8.8. and the FBSD machine has 5.8.7. So surely it can't be that,
> unless I'm missing something badly.
>
> The unixish.h file has this on 5.8:
>
> # define PERL_SYS_INIT(c,v) MALLOC_CHECK_TAINT2(*c,*v)
> PERL_FPU_INIT MALLOC_INIT
>
> I'm guessing the problem is actually somewhere in there.
>
>
[hours of digging later]
On FBSD at least, this is failing in the function Perl_do_taint(). I
can't see anything too terrible in the source for this, but to dig
further I'd have to build another perl with debugging turned on. Anyway,
it turns out that this actually isn't called at all if Perl is
configured to use its own malloc() routines instead of those supplied by
the system, as is the case on Fedora, for example, but not FBSD.
So we have a bit of a dilemma. We know that this initialization is
required by the Perl API, and we know that some platforms fail without
it, and we also know that this fails on some platforms which use the
system's malloc() for perl.
I think we need to float a bug upstream to the perl guys on this, but as
a holding position I suggest that we alter the #ifdef test to avoid
calling PERL_SYS_INIT3() where MYMALLOC is defined. It's ugly, but I
can't think of another simple way around it (and we've done worse things
to accommodate platform weirdness ;-) )
BTW, it's not caused by passing NULL as the third argument of
PERL_SYS_INIT3() - changing that was the first thing I tried.
cheers
andrew
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Re: [COMMITTERS] pgsql: Initialise perl library as documented in perl API.
@ 2009-06-05 13:53 Bruce Momjian <bruce@momjian.us>
parent: Andrew Dunstan <andrew@dunslane.net>
2 siblings, 0 replies; 16+ messages in thread
From: Bruce Momjian @ 2009-06-05 13:53 UTC (permalink / raw)
To: Andrew Dunstan <andrew@dunslane.net>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-hackers@postgresql.org
Andrew Dunstan wrote:
> [hours of digging later]
>
> On FBSD at least, this is failing in the function Perl_do_taint(). I
> can't see anything too terrible in the source for this, but to dig
> further I'd have to build another perl with debugging turned on. Anyway,
> it turns out that this actually isn't called at all if Perl is
> configured to use its own malloc() routines instead of those supplied by
> the system, as is the case on Fedora, for example, but not FBSD.
>
> So we have a bit of a dilemma. We know that this initialization is
> required by the Perl API, and we know that some platforms fail without
> it, and we also know that this fails on some platforms which use the
> system's malloc() for perl.
>
> I think we need to float a bug upstream to the perl guys on this, but as
> a holding position I suggest that we alter the #ifdef test to avoid
> calling PERL_SYS_INIT3() where MYMALLOC is defined. It's ugly, but I
> can't think of another simple way around it (and we've done worse things
> to accommodate platform weirdness ;-) )
>
> BTW, it's not caused by passing NULL as the third argument of
> PERL_SYS_INIT3() - changing that was the first thing I tried.
I think with an extensive C comment that is acceptable at this point, at
least until we hear from the perl guys. I would think projects would
have hit this issue too.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Re: [COMMITTERS] pgsql: Initialise perl library as documented in perl API.
@ 2009-06-05 14:03 Tom Lane <tgl@sss.pgh.pa.us>
parent: Andrew Dunstan <andrew@dunslane.net>
2 siblings, 0 replies; 16+ messages in thread
From: Tom Lane @ 2009-06-05 14:03 UTC (permalink / raw)
To: Andrew Dunstan <andrew@dunslane.net>; +Cc: pgsql-hackers@postgresql.org
Andrew Dunstan <andrew@dunslane.net> writes:
> I think we need to float a bug upstream to the perl guys on this, but as
> a holding position I suggest that we alter the #ifdef test to avoid
> calling PERL_SYS_INIT3() where MYMALLOC is defined.
+1 on both.
> BTW, it's not caused by passing NULL as the third argument of
> PERL_SYS_INIT3() - changing that was the first thing I tried.
Nonetheless, that compiler warning is pretty ugly; please do something
about it. I concur with your feeling that setting up a dummy empty
environment array is probably the safest thing to do.
regards, tom lane
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Re: [COMMITTERS] pgsql: Initialise perl library as documented in perl API.
@ 2009-07-07 15:57 Andrew Dunstan <andrew@dunslane.net>
parent: Andrew Dunstan <andrew@dunslane.net>
2 siblings, 0 replies; 16+ messages in thread
From: Andrew Dunstan @ 2009-07-07 15:57 UTC (permalink / raw)
To: pgsql-hackers@postgresql.org; +Cc: Tom Lane <tgl@sss.pgh.pa.us>
Andrew Dunstan wrote:
>
> I think we need to float a bug upstream to the perl guys on this, but
> as a holding position I suggest that we alter the #ifdef test to avoid
> calling PERL_SYS_INIT3() where MYMALLOC is defined. It's ugly, but I
> can't think of another simple way around it (and we've done worse
> things to accommodate platform weirdness ;-) )
>
>
It turns out that this doesn't work on Cygwin with its latest Perl
(which has MYMALLOC defined). If we call PERL_SYS_INIT3() it fails in
that call, and if we don't call it it fails later. We haven't noticed it
earlier because my Cygwin buildfarm member's Perl is a couple of years
old. I guess we're lucky that it's not a more critical platform, but
there is no guarantee that this is the only place it will fail, now or
in the future. I will see about following up more energetically with the
Perl people.
The workaround on Cygwin is to downgrade the perl installation to 5.8.8.
cheers
andrew
^ permalink raw reply [nested|flat] 16+ messages in thread
* PG_TEST_EXTRAs by theme rather than test name (Re: pgsql: Add tests for libpq gssencmode and sslmode options)
@ 2024-04-12 17:03 Heikki Linnakangas <hlinnaka@iki.fi>
0 siblings, 1 reply; 16+ messages in thread
From: Heikki Linnakangas @ 2024-04-12 17:03 UTC (permalink / raw)
To: Peter Eisentraut <peter@eisentraut.org>; pgsql-hackers <pgsql-hackers@postgresql.org>
(moved to pgsql-hackers, change subject)
On 10/04/2024 18:54, Heikki Linnakangas wrote:
> On 10/04/2024 17:48, Peter Eisentraut wrote:
>> On 08.04.24 01:50, Heikki Linnakangas wrote:
>>> Add tests for libpq gssencmode and sslmode options
>>
>> Why aren't these tests at
>> src/interfaces/libpq/t/nnn_negotiate_encryption.pl ?
>
> To be honest, it never occurred to me. It started out as extra tests
> under src/test/ssl/, and when I decided to move them out to its own
> module, I didn't think of moving them to src/interfaces/libpq/t/.
>
> I will move it, barring any objections or better ideas.
Moved.
I also added an extra check for PG_TEST_EXTRA=kerberos, so that the
tests that require a MIT Kerberos installation are only run if
PG_TEST_EXTRA=kerberos is specified. That seems prudent; it seems
unlikely that you would want to run libpq_encryption tests with Kerberos
tests included, but not the main kerberos tests. If you specify
PG_TEST_EXTRA=libpq_encryption, but not 'kerberos', it's probably
because you don't have an MIT Kerberos installation on your system.
I added documentation for the new PG_TEST_EXTRA=libpq_encryption option,
I missed that earlier, with a note on the above interaction with 'kerberos'.
As we accumulate more PG_TEST_EXTRA options, I think we should
categorize the tests by the capabilities they need or the risk
associated, rather than by test names. Currently we have:
- kerberos: Requires MIT Kerberos installation and opens TCP/IP listen
sockets
- ldap: Requires OpenLDAP installation and opens TCP/IP listen sockets
- ssl: Opens TCP/IP listen sockets.
- load_balance: Requires editing the system 'hosts' file and opens
TCP/IP listen sockets.
- libpq_encryption: Opens TCP/IP listen sockets. For the GSSAPI tests,
requires MIT Kerberos installation
- wal_consistency_checking: is resource intensive
- xid_wraparound: is resource intensive
There are a few clear themes here:
- tests that open TCP/IP listen sockets
- tests that require OpenLDAP installation
- tests that require MIT Kerberos installation
- tests that require editing 'hosts' file
- tests that are resource intensive
We could have PG_TEST_EXTRA options that match those themes, and
enable/disable the individual tests based on those requirements. For
example, if you're on a single-user system and have no issue with
opening TCP/IP listen sockets, you would specify
"PG_TEST_EXTRA=tcp-listen", and all the tests that need to open TCP/IP
listen sockets would run. Also it would be nice to have autoconf/meson
tests for the presence of OpenLDAP / MIT Kerberos installations, instead
of having to enable/disable them with PG_TEST_EXTRA.
--
Heikki Linnakangas
Neon (https://neon.tech)
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: PG_TEST_EXTRAs by theme rather than test name (Re: pgsql: Add tests for libpq gssencmode and sslmode options)
@ 2024-04-14 08:16 Peter Eisentraut <peter@eisentraut.org>
parent: Heikki Linnakangas <hlinnaka@iki.fi>
0 siblings, 0 replies; 16+ messages in thread
From: Peter Eisentraut @ 2024-04-14 08:16 UTC (permalink / raw)
To: Heikki Linnakangas <hlinnaka@iki.fi>; pgsql-hackers <pgsql-hackers@postgresql.org>
On 12.04.24 19:03, Heikki Linnakangas wrote:
> As we accumulate more PG_TEST_EXTRA options, I think we should
> categorize the tests by the capabilities they need or the risk
> associated, rather than by test names.
This was recently discussed at [0], without success.
[0]:
https://www.postgresql.org/message-id/flat/CAN55FZ1zPuyoj0KtTOZ_oTsqdVd-SCRAb2RP7c-z0jWPneu76g%40mai...
^ permalink raw reply [nested|flat] 16+ messages in thread
end of thread, other threads:[~2024-04-14 08:16 UTC | newest]
Thread overview: 16+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2009-06-04 15:59 pgsql: Initialise perl library as documented in perl API. Andrew Dunstan <adunstan@postgresql.org>
2009-06-04 16:38 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-04 17:08 ` Andrew Dunstan <andrew@dunslane.net>
2009-06-04 17:33 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-04 17:57 ` Andrew Dunstan <andrew@dunslane.net>
2009-06-05 13:46 ` Andrew Dunstan <andrew@dunslane.net>
2009-06-05 13:53 ` Bruce Momjian <bruce@momjian.us>
2009-06-05 14:03 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-07-07 15:57 ` Andrew Dunstan <andrew@dunslane.net>
2009-06-04 16:00 pgsql: Initialise perl library as documented in perl API. Andrew Dunstan <adunstan@postgresql.org>
2009-06-04 16:00 pgsql: Initialise perl library as documented in perl API. Andrew Dunstan <adunstan@postgresql.org>
2009-06-04 16:00 pgsql: Initialise perl library as documented in perl API. Andrew Dunstan <adunstan@postgresql.org>
2009-06-04 16:01 pgsql: Initialise perl library as documented in perl API. Andrew Dunstan <adunstan@postgresql.org>
2009-06-04 16:01 pgsql: Initialise perl library as documented in perl API. Andrew Dunstan <adunstan@postgresql.org>
2024-04-12 17:03 PG_TEST_EXTRAs by theme rather than test name (Re: pgsql: Add tests for libpq gssencmode and sslmode options) Heikki Linnakangas <hlinnaka@iki.fi>
2024-04-14 08:16 ` Re: PG_TEST_EXTRAs by theme rather than test name (Re: pgsql: Add tests for libpq gssencmode and sslmode options) Peter Eisentraut <peter@eisentraut.org>
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