On 2024-03-11 Mo 22:50, Thomas Munro wrote:
On Tue, Mar 12, 2024 at 2:56 PM Andrew Dunstan wrote:
On 2024-03-11 Mo 04:21, Oleg Tselebrovskiy wrote:
Greetings, everyone!
While running "installchecks" on databases with UTF-8 encoding the test
citext_utf8 fails because of Turkis
aths, where in many cases the program will just exit anyway.
2. the fix is simple where it's needed.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
obody else does it I'll have a go, but it might take a while.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
n the docs.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2024-03-13 We 02:22, Peter Eisentraut wrote:
On 13.03.24 07:11, Andrew Dunstan wrote:
I and several colleagues have just been trying to build from a
tarball with meson.
That seems pretty awful and unfriendly and I didn't see anything
about it in the docs.
At https://www.postgresq
On 2024-03-13 We 02:31, Andrew Dunstan wrote:
On 2024-03-13 We 02:22, Peter Eisentraut wrote:
On 13.03.24 07:11, Andrew Dunstan wrote:
I and several colleagues have just been trying to build from a
tarball with meson.
That seems pretty awful and unfriendly and I didn't see anything
On 2024-02-27 Tu 19:19, Kori Lane wrote:
Here’s a patch for this.
Reposting as the archive mail processor doesn't seem to like the Apple
mail attachment.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgm
On 2022-12-10 Sa 14:38, Tom Lane wrote:
> Andrew Dunstan writes:
>> OK, json is a fairly easy case, see attached. But jsonb is a different
>> kettle of fish. Both the semantic routines called by the parser and the
>> subsequent call to JsonbValueToJsonb() can raise errors
e ability to
> identify exactly which character couldn't be translated --- and in
> this use-case there's always just one.
>
>
Yeah, probably overkill for now.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2022-12-11 Su 12:24, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 2022-12-10 Sa 14:38, Tom Lane wrote:
>>> I have not done anything here about errors within JsonbValueToJsonb.
>>> There would need to be another round of API-extension in that area
>>&g
t seems I am outnumbered. I will work on updating the patch to add
>> an ACL_MAINTAIN bit and a pg_maintain_all_tables predefined role.
> Any thoughts on $SUBJECT?
Yeah, the discussion got way off into the weeds here. I think the
original proposal seems reasonable. Please add it to the next CF if you
haven't already.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
ese shortly, unless Andrew is already on it.
>
>
Thanks, I have been looking at jsonpath, but I'm not quite sure how to
get the escontext argument to the yyerror calls in jsonath_scan.l. Maybe
I need to specify a lex-param setting?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
this is going to pay dividends
> in many ways for many years to come. It's something that we've needed
> for a really long time, and I'm very happy that we're moving forward
> with it.
>
> Thanks so much.
>
Robert beat me to it, but I will heartily second this. Ma
On 2022-12-14 We 17:37, Tom Lane wrote:
> Andrew Dunstan writes:
>> Thanks, I have been looking at jsonpath, but I'm not quite sure how to
>> get the escontext argument to the yyerror calls in jsonath_scan.l. Maybe
>> I need to specify a lex-param setting?
> You
I notice that none of the meson files contain copyright notices. Shall I
add them?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
uch but it should save a handful of cycles at run time.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
From 5a58ef37a20cd229a74ffa4b9b5d52a47a38f020 Mon Sep 17 00:00:00 2001
From: Andrew Dunstan
Date: Mon, 19 Dec 2022 05:58:08 -0500
Subject: [PATCH] Use existing SSL certs in
On 2022-12-19 Mo 10:25, Tom Lane wrote:
> Andrew Dunstan writes:
>> We don't generate SSL certificates for running the SSL tests, but
>> instead use pregenerated certificates that are part of our source code.
>> This patch applies the same policy to the LDAP tests, an
There is currently no test for the use of ldapbindpasswd in the
pg_hba.conf file. This patch, mostly the work of John Naylor, remedies that.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
From 78ca6b405601ce0d884406b94fa356e38e19d2e0 Mon Sep 17 00:00:00 2001
From: Andrew
file. A trivial test is added which provides an
example of such a module.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
From 65af40c5b3c05dcfcb55675dec066fe779382105 Mon Sep 17 00:00:00 2001
From: Andrew Dunstan
Date: Mon, 19 Dec 2022 11:19:24 -0500
Subject: [PATCH] Add a
to do it any more.
>
> I agree it's not very useful and a bit annoying.
Not sure I agree the cost is high, but yes it's not quite zero either. I
can see a bit more value when it's used with files we have a lot of like
meson.build.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
you have a tmp_install without
having to request to explicitly. It would be nice if we could make meson
do the same thing, and also honor NO_TEMP_INSTALL if set.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
thing ever, but I wouldn't mind a bit if I
>>> didn't have to do it any more.
>> I agree it's not very useful and a bit annoying.
> Agreed. To me, it's just one more thing to get wrong.
OK, I think there are enough objections that we can put that aside for
now, I will just go and add the copyright notices.
cheers
andew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2022-12-19 Mo 11:04, Andrew Dunstan wrote:
> On 2022-12-19 Mo 10:25, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> We don't generate SSL certificates for running the SSL tests, but
>>> instead use pregenerated certificates that are part of our source code.
e is
arguably nicer because it tells you without counting how many spaces
there are.
Changing the type of the second argument to appendBinaryStringInfo to
void* seems reasonable.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
error-safe casts.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
From be571575e54c1b24617c54dbcd3daa3826d7e15a Mon Sep 17 00:00:00 2001
From: Andrew Dunstan
Date: Wed, 21 Dec 2022 08:37:17 -0500
Subject: [PATCH] Introduce float4in_internal
This is the guts of float4in, cal
On 2022-12-21 We 10:33, Tom Lane wrote:
> Andrew Dunstan writes:
>> The attached patch factors out the guts of float4in so that the new
>> float4in_internal function is callable without going through the fmgr
>> call sequence. This will make adjusting the seg module&#
On 2022-12-18 Su 09:42, Andrew Dunstan wrote:
> On 2022-12-14 We 17:37, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> Thanks, I have been looking at jsonpath, but I'm not quite sure how to
>>> get the escontext argument to the yyerror calls in jsonath_scan.l. M
On 2022-12-22 Th 01:10, Tom Lane wrote:
> Andrew Dunstan writes:
>> And here's another for contrib/seg
>> I'm planning to commit these two in the next day or so.
> I didn't look at the jsonpath one yet. The seg patch passes
> an eyeball check, with one minor
On 2022-12-22 Th 11:44, Tom Lane wrote:
> Andrew Dunstan writes:
>> Yeah, I started there, but it's substantially more complex - unlike cube
>> the jsonpath scanner calls the error routines as well as the parser.
>> Anyway, here's a patch.
> I looked through
o argue that the logic in
RE_compile_and_cache is wrong I don't see what we're arguing about. If
instead I had altered the API of RE_compile_and_cache to include an
escontext parameter we wouldn't be having this argument at all. The only
reason I didn't do that was the point Tom quite properly raised about
why we're doing any caching here anyway.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2022-12-23 Fr 13:53, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 2022-12-22 Th 11:44, Tom Lane wrote:
>>> (I wonder why this is using RE_compile_and_cache at all, really,
>>> rather than some other API. There doesn't seem to be value in
>>> forci
On 2022-12-24 Sa 10:42, Tom Lane wrote:
> Andrew Dunstan writes:
>> As I was giving this a final polish I noticed this in jspConvertRegexFlags:
>> /*
>> * We'll never need sub-match details at execution. While
>> * RE_compile_and_execute would s
v16,
> because the next steps would be pretty invasive.
It's a judgement call, but I'm not too fussed about stopping here for
v16. I see the reg* items as probably the lowest priority to fix.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
've posted recently, this covers all
> of the core datatype input functions. There are still half
> a dozen to tackle in contrib.
>
>
Yeah, I'm currently looking at those in ltree.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2022-12-26 Mo 14:12, Andrew Dunstan wrote:
> On 2022-12-26 Mo 12:47, Tom Lane wrote:
>> Here's a proposed patch for making tsvectorin and tsqueryin
>> report errors softly. We have to take the changes down a
>> couple of levels of subroutines, but it's
+1 for doing this. The code simplification is nice too.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
> On Dec 27, 2022, at 12:47 PM, Tom Lane wrote:
>
> Andrew Dunstan writes:
>> Here's a patch that covers the ltree and intarray contrib modules.
>
> I would probably have done this a little differently --- I think
> the added "res" parameters aren
at's almost the same, but not quite, ISTM. Those are things you can't
say without quotes, but here unless I'm mistaken you'd be disallowing
this style if you use quotes. I get the difficulties with input
functions, but it seems like we'll be building lots of grounds for
c
On 2022-12-28 We 01:00, Amul Sul wrote:
> On Tue, Dec 27, 2022 at 11:17 PM Tom Lane wrote:
>> Andrew Dunstan writes:
>>> Here's a patch that covers the ltree and intarray contrib modules.
>> I would probably have done this a little differently --- I think
>>
't thought of yet.
> Hmm. Perhaps, but I think I'm content with this version of the patch.
Looked good to me too.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
is highly recommended.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2022-12-31 Sa 20:55, Noah Misch wrote:
> On Sat, Dec 31, 2022 at 10:02:32AM -0500, Andrew Dunstan wrote:
>> * check if a branch is up to date before trying to run it
>> This only applies if the |branches_to_build| setting is a keyword
>> rather than a list of
On 2022-12-19 Mo 11:16, Andrew Dunstan wrote:
> There is currently no test for the use of ldapbindpasswd in the
> pg_hba.conf file. This patch, mostly the work of John Naylor, remedies that.
>
>
This currently has failures on the cfbot for meson builds on FBSD13 and
Debian Bullse
> On Jan 1, 2023, at 2:03 PM, Thomas Munro wrote:
>
> On Mon, Jan 2, 2023 at 3:04 AM Andrew Dunstan wrote:
>>> On 2022-12-19 Mo 11:16, Andrew Dunstan wrote:
>>> There is currently no test for the use of ldapbindpasswd in the
>>> pg_hba.conf file. This p
On 2023-01-01 Su 14:02, Thomas Munro wrote:
> On Mon, Jan 2, 2023 at 3:04 AM Andrew Dunstan wrote:
>> On 2022-12-19 Mo 11:16, Andrew Dunstan wrote:
>>> There is currently no test for the use of ldapbindpasswd in the
>>> pg_hba.conf file. This patch, mostly the work of
On 2022-12-31 Sa 21:11, Andrew Dunstan wrote:
> On 2022-12-31 Sa 20:55, Noah Misch wrote:
>> On Sat, Dec 31, 2022 at 10:02:32AM -0500, Andrew Dunstan wrote:
>>> * check if a branch is up to date before trying to run it
>>> This only applies if the |branches_to_
On 2023-01-01 Su 18:31, Andrew Dunstan wrote:
> On 2023-01-01 Su 14:02, Thomas Munro wrote:
>> On Mon, Jan 2, 2023 at 3:04 AM Andrew Dunstan wrote:
>>> On 2022-12-19 Mo 11:16, Andrew Dunstan wrote:
>>>> There is currently no test for the use of ldapbindpasswd in t
ndrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
are about to standardize exactly this syntax,
> where is that information available? If we don't know that,
> I'd prefer to invent some kind of function or other instead of
> extending the grammar.
+1
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2023-01-02 Mo 10:44, Tom Lane wrote:
> Andrew Dunstan writes:
>> I've been wondering if it might be a good idea to have a third parameter
>> for pg_input_error_message() which would default to false, but which if
>> true would cause it to emit the detail and hint fie
On 2023-01-02 Mo 09:45, Andrew Dunstan wrote:
> On 2023-01-01 Su 18:31, Andrew Dunstan wrote:
>> On 2023-01-01 Su 14:02, Thomas Munro wrote:
>>> On Mon, Jan 2, 2023 at 3:04 AM Andrew Dunstan wrote:
>>>> On 2022-12-19 Mo 11:16, Andrew Dunstan wrote:
>>>>&
On 2023-01-04 We 16:26, Andrew Dunstan wrote:
> On 2023-01-02 Mo 09:45, Andrew Dunstan wrote:
>> On 2023-01-01 Su 18:31, Andrew Dunstan wrote:
>>> On 2023-01-01 Su 14:02, Thomas Munro wrote:
>>>> On Mon, Jan 2, 2023 at 3:04 AM Andrew Dunstan wrote:
>>>&g
On 2023-01-04 We 07:13, vignesh C wrote:
> On Fri, 2 Dec 2022 at 18:08, Andrew Dunstan wrote:
>>
>> On 2022-12-01 Th 21:10, Andres Freund wrote:
>>> Hi,
>>>
>>> On 2022-12-01 20:56:18 -0500, Tom Lane wrote:
>>>> Andres Freund writ
server
> side, for client cert validation?
+1 for doing this, although I think client certs are less likely to have
been issued by a public CA.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
d guess
> that's because (1) it's only running a tiny subset of the tests, (2)
> it crashes for the other reason with higher likelihood, and/or (3)
> it's not using much concurrency yet because the build farm doesn't use
> meson yet.
OK, should I now try re-enabling TAP tests on lorikeet?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
ser to each of the other nodes in
> the cluster by authenticating with that same certificate.
Yeah, I have done that sort of thing with pgbouncer auth using an ident
map. (There's probably a good case for making ident maps for useful by
adopting the +role mechanism from pg_hba.conf processing, but that's a
separate issue).
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
l's
> relationship to the DB locale is
>
Regardless of the punycode issue, allowing hyphens in ltree labels seems
quite reasonable. I haven't reviewed the patch yet, but if it's OK I
intend to commit it.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2023-01-06 Fr 11:29, Tom Lane wrote:
> Andrew Dunstan writes:
>> Regardless of the punycode issue, allowing hyphens in ltree labels seems
>> quite reasonable. I haven't reviewed the patch yet, but if it's OK I
>> intend to commit it.
> No objection to al
-eeca8ace1...@dunslane.net
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
diff --git a/doc/src/sgml/client-auth.sgml b/doc/src/sgml/client-auth.sgml
index cc8c59206c..f48bfce64a 100644
--- a/doc/src/sgml/client-auth.sgml
+++ b/doc/src/sgml/client-auth.sgml
@@ -961,6 +961,12 @@ mymap /^(.*)@otherd
uess there's no harm in that, and the performance impact should
be minimal, but I thought it worth mentioning, as it's probably not
strictly necessary.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
not have a hostname at all, and isn't
used to verify the connecting address, but to verify the username. It
needs to have a CN/DN equal to the user name of the connection, or that
maps to that name via pg_ident.conf.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2023-01-09 Mo 13:24, Nathan Bossart wrote:
> On Mon, Jan 09, 2023 at 08:00:26AM -0500, Andrew Dunstan wrote:
>> + If the database-username begins with a
>> + + character, then the operating system user can login
>> as
>> + any user belonging to that role,
adds.
Ok, that sounds reasonable, but the cfbot doesn't like patches that
depend on other patches in a different email. Maybe you can roll this up
as an extra patch in your next version? It's pretty small.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
arameters and is
only used for things that are not parameters. (I'm not sure where that's
documented other than the comment on commit 47046763c3, but it's what I
attempted to do with the earlier doc tidy up.)
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2022-12-31 Sa 10:02, Andrew Dunstan wrote:
> Changes
>
>
> * check if a branch is up to date before trying to run it
> This only applies if the |branches_to_build| setting is a keyword
> rather than a list of branches. It reduces the number of useless
> c
ght be simply to increase the latitude allowed for
old versions <= 15 with new versions >= 16. Currently we allow 90 for
cases where the versions differ, but we could increase it to, say, 200
in such cases (we'd need to experiment a bit to find the right limit).
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
lace to
start. More ambitiously we might also provide a function do do most of
the pre_upgrade adjustments made in TestUpgradeXversion.pm at lines
405-604. But let's walk before we try to run. This is probably a good
time to be doing this as I want to push out a new release pretty soon to
e for now) is a bottleneck in fixing issues that arise
from development. This is by far the biggest area where we have seen
buildfarm breakage for cross version upgrade testing.
cheers
andrew
[1] https://postgr.es/m/951602.1673535...@sss.pgh.pa.us
--
Andrew Dunstan
EDB: https://www.e
On 2023-01-13 Fr 19:49, Tom Lane wrote:
> Andrew Dunstan writes:
>> Here's a piece of WIP for that, in the form of a perl module that
>> provides a function that takes an old version number / tag and provides
>> the set of sql statements that need to be run to make t
On 2023-01-13 Fr 19:33, Justin Pryzby wrote:
> On Fri, Jan 13, 2023 at 05:20:41PM -0500, Andrew Dunstan wrote:
>> Over at [1] there was some discussion of moving knowledge of what's
>> required to be fixed from old branch repos to be able to upgrade them
>> into the co
-code/releases/tag/REL_16> or
<https://buildfarm.postgresql.org/downloads>
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
adjustments the
client's responsibility. That would make for much less disturbance in
the buildfarm code.
I also tried to remove a lot of the ugly release tag processing,
leveraging our PostgreSQL::Version gadget. I think that's worthwhile too.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
different. Is there
any case where a repo shouldn't be upgradeable to its own version
without adjustment?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
ided, so this looks
reasonable to me.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
out them, but I will have a closer
look. Those replacement lines are very difficult to read. I think use of
extended regexes and some multi-part replacements would help. I'll have
a go at that tomorrow.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2023-01-15 Su 18:37, Tom Lane wrote:
> Andrew Dunstan writes:
>> Those replacement lines are very difficult to read. I think use of
>> extended regexes and some multi-part replacements would help. I'll have
>> a go at that tomorrow.
> Yeah, after I wrote that code
On 2023-01-16 Mo 14:34, Tom Lane wrote:
> Andrew Dunstan writes:
>> OK, here's my version. It tests clean against all of crake's dump files
>> back to 9.2.
>> To some extent it's a matter of taste, but I hate very long regex lines
>> - it makes it very
SQL/Version.pm isn't there before v15.
>
> I don't see a good reason why we couldn't back-patch it, though.
> Any objections?
>
>
No, that seems perfectly reasonable.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
now. Then you should be able to try your unrevert.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2023-01-17 Tu 10:18, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 2023-01-16 Mo 21:58, Tom Lane wrote:
>>> I dunno if we want to stretch buildfarm owners' patience with yet
>>> another BF client release right now. On the other hand, I'm antsy
>>&
On 2023-01-17 Tu 11:30, Tom Lane wrote:
> Andrew Dunstan writes:
>> FYI crake has just passed the test with flying colours.
> Cool. I await the Windows machines' results with interest.
fairwren and drongo are clean except for fairywren upgrading 9.6 to 11.
This appears to
bitBarewordDirHandles] Severity: 5)
>
> This issue gets fixed here as of the attached.
> Comments?
Looks fine. Interesting it's not caught by perlcritic on my Fedora 35
instance, nor my Ubuntu 22.04 instance.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Also, I didn't reindent the unchanged code in
> sub installcheck, and I didn't add anything about skipping
> same-version tests.
No that won't work if we're using vpath builds (which was why I changed
it from what you had). $self->{pgsql} is always the bui
On 2023-01-18 We 16:14, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 2023-01-18 We 14:32, Tom Lane wrote:
>>> I suppose that the reason for not running under $from_source is to
>>> avoid corrupting the saved installations with unofficial versions.
>>> Howev
On 2023-03-25 Sa 12:38, Andres Freund wrote:
Hi,
On 2023-03-25 08:46:42 -0400, Andrew Dunstan wrote:
config/perl.m4 contains this:
AC_MSG_CHECKING(for flags to link embedded Perl)
if test "$PORTNAME" = "win32" ; then
perl_lib=`basename $perl_archlibexp/C
> On Mar 26, 2023, at 5:28 PM, Andres Freund wrote:
>
> Hi,
>
>> On 2023-03-26 12:39:08 -0700, Andres Freund wrote:
>> First: I am *not* arguing we shouldn't repair building against strawberry
>> perl
>> with mingw.
>
> Hm - can you describe the failure more - I just tried, and it worked t
On 2023-03-27 Mo 13:18, Andres Freund wrote:
Hi,
On 2023-03-26 21:13:41 -0400, Andrew Dunstan wrote:
On Mar 26, 2023, at 5:28 PM, Andres Freund wrote:
On 2023-03-26 12:39:08 -0700, Andres Freund wrote:
First: I am *not* arguing we shouldn't repair building against strawberry perl
with
. Asking people to install an old
and possibly buggy version of a perl module is not something we should do.
I think the barrier for this is pretty high. I try to keep module
requirements for the buildfarm client pretty minimal, and this could
affect a much larger group of people.
cheers
an
fied the possible
values for MSYS :-( )
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
re feature freeze. Thanks to Alvaro for advancing us a way down the
field. I hope we can get the remainder committed in the July CF.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
to pick this at setup time, but I guess
the upside is that we don't spend time looking for stuff we're not
actually going to use.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
n a test-private directory, so that port
conflicts are a non-issue.
For TAP tests we have pretty much resolved the port collisions issue for
TCP ports too. See commit 9b4eafcaf4
Perhaps the OP could adapt that logic to his use case.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
happens, and meson
install will install it, which does not happen.
"meson compile" doesn't seem to build the docs by default ( see
<https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=crake&dt=2023-04-06%2018%3A17%3A04&stg=build>),
and I
will be to add there. It would
certainly add an installation burden for test instances at the very least.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
Pty is missing
or too old? Somewhere to start looking at the very least.
Those aren't CPAN version numbers. See <https://metacpan.org/pod/IO::Pty>
prion was running 1.10 (dated to 2010). I have just updated it to 1.17
(the CPAN latest). We'll see if that makes a difference.
che
ave separated it out for reasons that
aren't entirely obvious:
andrew@emma:~ $ rpm -q -l -f /usr/share/perl5/open.pm
/usr/share/man/man3/open.3pm.gz
/usr/share/perl5/open.pm
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
ata at all. So I just nuked the
"use" lines.
Yeah.
I just spent a little while staring at the perl code. I have to say it
seems rather opaque, the data structure seems a bit baroque. I'll try to
simplify it.
cheers
andrew
--
to re-init the machine to use something else.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
endent issue exposed by the new test.
I wonder if we should make the test use data checksum - if we continue to see
the wrong query results, the corruption is more likely to be in memory.
I can run the test in isolation, and it's get an error reliably.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
On 2023-04-08 Sa 18:50, Thomas Munro wrote:
On Sun, Apr 9, 2023 at 10:17 AM Andrew Dunstan wrote:
I can run the test in isolation, and it's get an error reliably.
Random idea: it looks like you have compression enabled. What if you
turn it off in the directory where the test
901 - 1000 of 2779 matches
Mail list logo
