On 3/2/21 7:48 AM, Andrew Dunstan wrote:
> On 3/1/21 3:07 PM, Andres Freund wrote:
>> Hi,
>>
>> As part of trying to make the aio branch tests on cirrus CI pass with
>> some tap tests I noticed that "src/tools/msvc/vcregress.pl recoverycheck"
>> hang
aving a support for PROVE_TESTS would be nice in src/tools/msvc/,
> wrapping any ENV{PROVE_TESTS} value within an extra glob() before
> passing that down to the prove command.
Yes, I saw similar this morning, which woud have been after that commit.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 3/3/21 12:47 AM, Andres Freund wrote:
> Hi,
>
> On 2021-03-02 21:20:52 -0500, Andrew Dunstan wrote:
>> On 3/2/21 8:27 PM, Michael Paquier wrote:
>>> On Tue, Mar 02, 2021 at 04:54:57PM -0800, Andres Freund wrote:
>>>> It sti
ation failed in require at c:\Program
Files\Git\usr\bin\core_perl\prove line 9.
BEGIN failed--compilation aborted at c:\Program
Files\Git\usr\bin\core_perl\prove line 9.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 3/3/21 7:57 AM, Andrew Dunstan wrote:
> On 3/3/21 12:47 AM, Andres Freund wrote:
>> Hi,
>>
>> On 2021-03-02 21:20:52 -0500, Andrew Dunstan wrote:
>>> On 3/2/21 8:27 PM, Michael Paquier wrote:
>>>> On Tue, Mar 02, 2021 at 04:54:57PM -0800, Andres Fre
On 3/3/21 4:42 PM, Andres Freund wrote:
> Hi,
>
> On 2021-03-03 16:07:13 -0500, Andrew Dunstan wrote:
>> Here's what I actually got working. Rip out the calls to kill_kill and
>> replace them with:
>>
>>
>> $psql_primary{stdin} .=
On 3/3/21 5:32 PM, Andrew Dunstan wrote:
> On 3/3/21 4:42 PM, Andres Freund wrote:
>> Hi,
>>
>> On 2021-03-03 16:07:13 -0500, Andrew Dunstan wrote:
>>> Here's what I actually got working. Rip out the calls to kill_kill and
>>> replace them with:
&g
On 3/3/21 7:21 PM, Andrew Dunstan wrote:
> On 3/3/21 5:32 PM, Andrew Dunstan wrote:
>> On 3/3/21 4:42 PM, Andres Freund wrote:
>>> Hi,
>>>
>>> On 2021-03-03 16:07:13 -0500, Andrew Dunstan wrote:
>>>> Here's what I actually got working. Rip
On 3/4/21 12:56 PM, Andres Freund wrote:
> Hi,
>
> On 2021-03-04 11:10:19 -0500, Andrew Dunstan wrote:
>> Here's the patch.
> Awesome. Will you commit it?
Done
>
>
>> I didn't see a convenient way of handling the pg_recvlogical case, so
>> t
a bad idea. This isn't the first time to be a problem,
> see e.g. [1].
>
> Why don't we instead have pgwin32_doRegister() include a parameter that
> indicates we're running as a service and remove all the heuristics?
I assume you mean a postmaster parameter, that wou
\pgsql.build\\postgres.vcxproj" (default
> targets) -- FAILED.
>
> Looks like it wasn't a clean build, those functions and all the
> callers were removed by the patch. That's a separate issue than on
> 'walleye' - unless that was also not a completely clean b
On 3/4/21 2:16 PM, Joel Jacobson wrote:
> On Sat, Jan 30, 2021, at 22:18, Andrew Dunstan wrote:
>> ssl-match-client-cert-dn-v3.patch
>
> Spelling error of "conjunction":
> + This option is probably best used in comjunction with a
> username map.
>
>
fbot.cputube.org/
>
It's bitrotted a bit more dues to commits bb437f995d and 25936fd46c
(A useful feature of the cfbot might be to notify the authors and
reviewers when it detects bitrot for a previously passing entry.)
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
arking the patch "Waiting on Author"
What is the point of doing that if we're going to reject the patch as
discussed upthread?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
the madness that can result from managing this.
I've lost weeks of my life to it ... If you add cygwin into the mix and
you're trying to coordinate builds among three buildfarm animals it's a
major pain.)
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 10/29/20 11:20 AM, Daniel Gustafsson wrote:
>> On 28 Oct 2020, at 07:39, Andres Freund wrote:
>> Have you done testing to ensure that NSS PG cooperates correctly with
>> openssl PG? Is there a way we can make that easier to do? E.g. allowing
>> to build frontend with NSS and backend with open
On 11/1/20 5:04 PM, Daniel Gustafsson wrote:
>> On 1 Nov 2020, at 14:13, Andrew Dunstan wrote:
>> I've been looking through the new patch set, in particular the testing
>> setup.
> Thanks!
>
>> The way it seems to proceed is to use the existing openssl generat
of them.
This feature is best used in conjunction with a map. e.g. in testing I
have this pg_hba.conf line:
hostssl all all 127.0.0.1/32 cert clientname=DN map=dn
and this pg_ident.conf line:
dn /^C=US,ST=North.Carolina,O=test,OU=eng,CN=andrew$ andrew
If people like this idea I'll
" in their query. And if we generate a
column name in some cases and not in others there will be complaints of
inconsistency.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
x: bar j: {"foo": 3, "bar": 4}
>> and you say:
>> select j->>x from mytable;
>> What should the column be named?
> Suppose it should be named 'as x'
So if we then say:
select x, j->>x from mytable;
you want both result columns named x? That seems like a recipe for
serious confusion. I really don't think this proposal has been properly
thought through.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 11/12/20 11:12 AM, David G. Johnston wrote:
> On Thu, Nov 12, 2020 at 8:59 AM Andrew Dunstan <mailto:and...@dunslane.net>> wrote:
>
>
>
> So if we then say:
>
>
> select x, j->>x from mytable;
>
>
> you want both resu
On 11/12/20 8:37 AM, Daniel Gustafsson wrote:
>> On 11 Nov 2020, at 21:44, Andrew Dunstan wrote:
>> If people like this idea I'll add tests and docco and add it to the next CF.
> Sounds like a good idea, please do.
>
> Can this case really happen in n
OK, although it feels a bit odd.
Might it be better to have the values as typename={binary,text} pairs
instead of oid={0,1} pairs, which are fairly opaque? That might make
things easier for things like UDTs where the oid might not be known or
constant.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
little more to see what's going on here.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
l.
https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=drongo&dt=2020-11-16%2012%3A59%3A17&stg=make
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 11/12/20 4:21 PM, Andrew Dunstan wrote:
> On 11/12/20 8:37 AM, Daniel Gustafsson wrote:
>>> On 11 Nov 2020, at 21:44, Andrew Dunstan wrote:
>>> If people like this idea I'll add tests and docco and add it to the next CF.
>> Sounds like a good idea, please do.
&
this
is a file with exactly three single-valued fields. Not sure if it's
worth doing anything about this, or we should just live with it the way
it is.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 11/20/20 2:19 AM, Fabien COELHO wrote:
>
> Hello Andrew,
>
>> I noticed somewhat to my surprise as I was prepping the tests for the
>> "match the whole DN" patch that pg_ident.conf is parsed using the same
>> routines used for pg_hba.conf, and as a result the DN almost always
>> needs to be qu
On 11/20/20 4:54 PM, Corbit, Dann wrote:
>
> I would like to have all my certificates and keys on the same machine
> (localhost for local connections and dcorbit for tcp/ip).
> I found a couple tutorials and tried them but it failed.
> I saw one document that said the common name should be the po
ta\Local\Temp\*.*
-Force -Recurse
ci/inst-tools.bat:
choco install -y --no-progress --version=1.0.0
visualstudio2019-workload-vctools --install-args="--add
Microsoft.VisualStudio.Component.VC.CLI.Support"
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
world.
>
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.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 1/11/21 9:34 AM, Peter Eisentraut wrote:
> On 2020-12-20 18:09, Andrew Dunstan wrote:
>> On 12/19/20 11:19 AM, Andrew Dunstan wrote:
>>> This turns out to be remarkably short, with the use of a little eval
>>> magic.
>>>
>>> Give th
ou add any other printable escaped characters
> (such as comma, in the CN example here) NSS will still double-quote the
> whole thing.
>
> --Jacob
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=355096
OK, that bug is a bit ugly.
I'm not sure where we want to go with the present patch. Do we want to
go with what we have and document the limitations more, or try to do
something more elaborate? If so, exactly what?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 1/13/21 7:56 AM, Andrew Dunstan wrote:
> On 1/11/21 9:34 AM, Peter Eisentraut wrote:
>> On 2020-12-20 18:09, Andrew Dunstan wrote:
>>> On 12/19/20 11:19 AM, Andrew Dunstan wrote:
>>>> This turns out to be remarkably short, with the use of a little eval
>>&
On 1/28/21 9:24 AM, Alvaro Herrera wrote:
> On 2021-Jan-28, Andrew Dunstan wrote:
>
> ... neat stuff, thanks.
>
>> +# Windows picks up DLLs from the PATH rather than
>> *LD_LIBRARY_PATH
>> +# choose the right path separator
>> +
On 1/28/21 11:39 AM, Jacob Champion wrote:
> On Wed, 2021-01-27 at 15:42 -0500, Andrew Dunstan wrote:
>> I'm not sure where we want to go with the present patch. Do we want to
>> go with what we have and document the limitations more, or try to do
>> something more elab
On 1/29/21 8:18 AM, Daniel Gustafsson wrote:
>> On 28 Jan 2021, at 23:10, Andrew Dunstan wrote:
>> On 1/28/21 11:39 AM, Jacob Champion wrote:
>>> Unfortunately I don't really know what that solution should look like.
>>> A DSL for filtering on RDNs w
On 1/28/21 5:10 PM, Andrew Dunstan wrote:
>
>> (I'd still recommend switching to use the RFC
>> flag to OpenSSL, to ease future improvements.) There should be a bunch
>> of warning documentation saying not to do anything more complex unless
>> you're
On 1/29/21 10:10 AM, Andrew Dunstan wrote:
> On 1/28/21 5:10 PM, Andrew Dunstan wrote:
>>> (I'd still recommend switching to use the RFC
>>> flag to OpenSSL, to ease future improvements.) There should be a bunch
>>> of warning documentation saying not to do anyt
ient-code/releases> and
<https://buildfarm.postgresql.org/downloads>
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
other things like the JSON code..
Not easily in the buildfarm as it is today. We can easily create modules
for extensions and other things that don't require modification of core
code, but things that require patching core code are a whole different
story.
That's not to say it couldn't be done, a SMOP. But using something like
Appveyor or Cirrus might be a lot simpler.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2/5/21 2:50 PM, Heikki Linnakangas wrote:
> On 05/02/2021 21:16, Andrew Dunstan wrote:
>>
>> On 2/5/21 10:54 AM, Stephen Frost wrote:
>>> * Heikki Linnakangas (hlinn...@iki.fi) wrote:
>>>> I ran it for about 2 h on my laptop with the patch I was working
that a few hook variables will be enough to do anything.
Yeah. I think we'd need a fairly fully worked implementation to see
where it goes. Is Amazon going to release (under TPL) its TDS
implementation of this? That might go a long way to convincing me this
is worth considering.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
t least see allowing '-' as
reasonable, and maybe ':'. Not sure about other punctuation characters.
OTOH I'd be surprised if the identifier restriction would burden a large
number of people.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
I expend too much more effort on this.
>
Should we really be getting rid of
PostgreSQL::Test::Cluster::backup_fs_hot() ?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
the work I have been doing on backwards
compatibility of the TAP framework. I need to get back to that now that
the great module namespace adjustment has settled down.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
so we could possibly
test transforms. Anything else? I don't think we need to worry about all
the authentication-supporting options. XML/XSLT maybe.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
to change the external representation only
for non-ASCII values? If so, that seems OK. Changing it for ASCII
values seems ugly. #1 is the simplest to implement and to understand,
and I suspect it would break very little in practice, but others might
disagree with that assessment.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 12/3/21 14:42, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 12/3/21 14:12, Tom Lane wrote:
>>> I can think of at least three ways we might address this:
>>>
>>> * Forbid all non-ASCII values for type "char". This results in
>>> simple
ng that. On non-MSVC, the path to a non-installed psql is
in this case "$TESTDIR/../../bin/psql" - this should work for VPATH
builds as well as non-VPATH. On MSVC it's a bit harder - it's
"$top_builddir/$releasetype/psql" but we don't expose that. Perhaps we
should. c.f. commit f4ce6c4d3a
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
ately.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
diff --git a/src/tools/msvc/vcregress.pl b/src/tools/msvc/vcregress.pl
index f3357b3292..608b0449a3 100644
--- a/src/tools/msvc/vcregress.pl
+++ b/src/tools/msvc/vcregress.pl
@@ -59,6 +59,12 @@ copy("$Config/autoinc/a
ans the server terminated abnormally
# before or while processing the request.'
# doesn't match '(?^:SSL error: sslv3 alert certificate revoked)'
There's nothing terribly suspicious in the server log, so I'm not quite
sure what's go
On 12/5/21 15:14, Daniel Gustafsson wrote:
>> On 5 Dec 2021, at 18:03, Andrew Dunstan wrote:
>> I am getting this test failure 001_ssltests.pl on my test MSVC system
>> when SSL tests are enabled:
>>
>>not ok 110 - certificate authorization fails with revok
On 12/5/21 14:47, Noah Misch wrote:
> On Sun, Dec 05, 2021 at 11:57:31AM -0500, Andrew Dunstan wrote:
>> Certain TAP tests rely on settings that the Make files provide for them.
>> However vcregress.pl doesn't provide those settings. This patch remedies
>> that, and I p
On 12/5/21 12:50, Tom Lane wrote:
> Andrew Dunstan writes:
>> I am getting this test failure 001_ssltests.pl on my test MSVC system
>> when SSL tests are enabled:
>> not ok 110 - certificate authorization fails with revoked client cert
>> with server-
On 12/6/21 01:02, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 12/5/21 12:50, Tom Lane wrote:
>>> This looks quite a bit like the sort of failure that commit
>>> 6051857fc was meant to forestall. I wonder whether reverting
>>> that commit changes the re
On 12/6/21 10:30, Alexander Lakhin wrote:
> Hello Andrew,
> 06.12.2021 17:56, Andrew Dunstan wrote:
>> Yeah, quite annoying, especially because only some combinations of MSVC
>> runtime / openssl version seem to trigger the problem.
>>
>>
>> Adding a shut
's going to be a whole lot of changes. You should just be
able to cherry-pick them in most cases I suspect.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
her than that.
> It does sound like we may be running into OpenSSL bugs/oddities,
> not only kernel issues, so it may be impossible to do better
> on our side.
Yeah. My suspicion is that SD_BOTH is what closesocket() does if
shutdown() hasn't been previously called.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 12/5/21 18:32, Noah Misch wrote:
> On Sun, Dec 05, 2021 at 06:00:08PM -0500, Andrew Dunstan wrote:
>> On 12/5/21 14:47, Noah Misch wrote:
>>> On Sun, Dec 05, 2021 at 11:57:31AM -0500, Andrew Dunstan wrote:
>>>> Certain TAP tests rely on settings that t
just wanted to get
> this out of the way since the code was already written and I've had
> this on my list for, uh, 7 years.
+many as long as we cover all the cases in Cluster.pm and Utils.pm. I
suspect they have acquired some new multi-test subs in the intervening 7
years :-)
cheers
On 12/8/21 03:14, Michael Paquier wrote:
> On Tue, Dec 07, 2021 at 03:40:29PM -0500, Andrew Dunstan wrote:
>> All done.
> bowerbird is complaining here with the tests of pg_basebackup:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2021-12-08%200
er many tests it actually runs, and as long as
they all pass we're good. It just seems slightly sloppy.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 12/8/21 18:10, Thomas Munro wrote:
> On Sun, Dec 5, 2021 at 4:16 AM Andrew Dunstan wrote:
>> TAP tests are passed a path to pg_regress as $ENV{PG_REGRESS}. You
>> should be using that. On non-MSVC, the path to a non-installed psql is
>> in this case "$TESTDIR/../
2017 in their title. Would
> those be in trouble?
Probably not if they have been updated. I have Windows machines
substantially older that 2018 but now running versions dated later.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
ything. On Unix/Msys the shell just removes the quotes.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
ransaction, an ALTER SUBSCRIPTION
> command might block for a long time until replication of that
> transaction completes. I have a hard time understanding why anyone
> would consider that an improvement.
>
+1
I think noticing changes at the transaction boundary is perfectly
acceptable.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 12/9/21 15:15, Thomas Munro wrote:
> On Fri, Dec 10, 2021 at 2:12 AM Andrew Dunstan wrote:
>> The new version appears to set an empty --bindir for pg_regress. Is that
>> right?
> It seems to be necessary to find eg psql, since --bindir='' means
> "e
s attached this appends "control connection" for the control connection, but
> perhaps we should just not append anything for that?
>
"control connection" seems reasonable.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
n in the wild, but I'm sure there are some out there
sitting in a cupboard humming along.
This might also be a good time to revive work on making the TAP test
framework backwards compatible via subclassing.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
st a link to fuzzystrmatch. Also, a couple examples would be
> helpful, I guess - similarly to fuzzystrmatch. The last line in the
> docs is annoyingly long.
It's not clear to me why we need a new module for this. Wouldn't it be
better just to add the new function to fuzzystrmatch?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
that doesn't seem like it could cause this.
>
> Any thoughts?
>
It's also failing on REL_14_STABLE, so I think it must be an
environmental change.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
;$tempbase/$subdir");
+my $tempdir = "$tempbase/$subdir";
+system("mkdir $tempdir");
What's going on here?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
do it shortly unless there's an objection.
* I need to undo the removal of client logic that supported 9.2's
unix_socket_directory setting as opposed to the later
unix_socket_directories.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
nteger: "no"
> LINE 2: FROM (VALUES ('no', 5), ('area', 50), ('rooms', 2), ('foo', ...
> ^
> LOCATION: pg_strtoint32, numutils.c:320
>
>
>
The literal above is simply not legal json, so the json parser is going
to reject it outright. However it is quite reasonable for JSON
constructors to convert non-string key values to strings. Otherwise we'd
be rejecting not just numbers but for example dates as key values. c.f.
json_build_object(), the documentation for which says "Key arguments are
coerced to text."
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
error at or near "*"
> LINE 1: select json_object(*) from test;
>
>
You can spell that a bit differently today, e.g.
select to_json(r) from test r;
I don't know either if it's in the spec, but building in support for *
in this context seems likely to
r. Having just a timestamped directory name would make
life annoying for a poor buildfarm maintainer. Also, please don't change
anything before I have a chance to adjust the buildfarm code to what is
going to be done.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
ior be?
I don't think we should fall back on the CN. It would seem quite odd to
do so for IP addresses but not for DNS names.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 12/15/21 21:36, Larry Rosenman wrote:
> On 12/15/2021 11:15 am, Andrew Dunstan wrote:
>> OK, old_branches_of_interest.txt now exists on the buildfarm server, and
>> the code has been modified to take notice of it (i.e. to accept builds
>> for branches listed there). The
ose options?
> and FreeBSD head / main would be useful?
> (Currently FreeBSD 14 and clang 13).
>
Sure. I think if we get coverage for modern Linux, FreeBSD and Windows
we should be in good shape.
I doubt we need a heck of a lot of animals - there's not going to be
much going on here.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 12/16/21 12:26, Larry Rosenman wrote:
> On 12/16/2021 11:17 am, Andrew Dunstan wrote:
>> On 12/16/21 11:11, Larry Rosenman wrote:
>>>
>>>>
>>>> A new animal, because we're not supporting every build option. On the
>>>> non-live
On 12/16/21 15:53, Larry Rosenman wrote:
>
>
> I get:
> ERROR for site owner:
> Invalid domain for site key
>
> on https://pgbuildfarm.org/cgi-bin/register-form.pl
try https://buildfarm.postgresql.org/cgi-bin/register-form.pl
cheers
andrew
ms a
bit pointless in an ephemeral instance.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 12/17/21 14:34, Andres Freund wrote:
> Hi,
>
> On 2021-12-17 09:36:05 -0500, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> Maye I have missed it, but why are we using ccache here? That seems a
>>> bit pointless in an ephemeral instance.
>> I believe Mu
so why did we never
> invent \getenv?
I don't recall anyone expressing a need for it at the time we added
\setenv.
+1 for adding it now.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 12/21/21 15:06, Larry Rosenman wrote:
> I filled out that form on the 16th, and haven't gotten a new animal
> assignment. Is there
> a problem with my data?
It's a manual process, done when your friendly admins have time. I have
approved it now.
cheers
andrew
--
an try -- I haven't been very good at that.
>
> I can give you access to the machine and the id the Buildfarm runs under.
>
> (or give me a good process starting from a buildfarm layout).
>
>
I will work on it on my FBSD setup.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 12/23/21 08:50, Andrew Dunstan wrote:
> On 12/22/21 23:20, Larry Rosenman wrote:
>> On 12/22/2021 10:15 pm, Tom Lane wrote:
>>> Larry Rosenman writes:
>>>> On 12/22/2021 9:59 pm, Tom Lane wrote:
>>>>> Does it work if you drop --enable-nls? (It&
rectory.
looks like it's picking up the wrong perl libraries. Please show us the
output of
grep -v secret
/home/pgbuildfarm/buildroot/REL9_2_STABLE/$animal.lastrun-logs/web-txn.data
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 12/23/21 12:23, Andrew Dunstan wrote:
> On 12/23/21 11:27, Larry Rosenman wrote:
>>> For the 9.2 error, try setting this in the config_env stanza:
>>>
>>>
>>> CFLAGS => '-O2 -fPIC',
>>>
>>>
>>>
>> That g
to the client-side and this seems like the next logical
> step.
>
> Thoughts?
>
>
Isn't that going to break every existing client? How is a client
supposed to know which protocol to follow?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
ver I think the present patch is a
good stake to put into the ground.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
diff --git a/src/test/perl/PostgreSQL/Test/Cluster.pm b/src/test/perl/PostgreSQL/Test/Cluster.pm
index c061e850fb..0e0bf0ecfc 100644
--- a/src/test/perl/Postg
On 12/28/21 09:30, Andrew Dunstan wrote:
> PFA a patch to extend the compatibility of PostgreSQL::Test::Cluster to
> all live branches. It does this by introducing a couple of subclasses
> which override a few things. The required class is automatically
> detected and used, so users d
ronment variables are less interesting there.)
>
>
I haven't tested, but I'm fairly sure
postgres=# \! echo %PATH%
would do the trick on Windows.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
n this little patch really helps me whenever I have to deal
> with Windows and MSVC from the command line. Besides, it could help
> old branches as well.
>
Seems reasonable. I don't see any reason not to do it for pgbison.bat
and pgflex.bat, just for the sake of consistency.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
, we wanted to make it do so. Would that
> be sane? Which name (referenced or referencing column) would
> the merged column have?
>
>
I agree this would cause confusion. I think your earlier suggestion of
JOIN ... FOREIGN KEY ...
seems reasonable.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
airywren | 5
> REL_12_STABLE | jacana| 1
> REL_12_STABLE | tern | 1
> REL_13_STABLE | fairywren | 3
> REL_14_STABLE | drongo| 2
> REL_14_STABLE | fairywren | 6
>
>
FYI, drongo and fairywren are run on the same AWS/EC2 Windows Server
2019 instance. Nothing else runs on it.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 12/31/21 11:20, Dagfinn Ilmari Mannsåker wrote:
> Andrew Dunstan writes:
>
>> +my $subclass = __PACKAGE__ . "::V_$maj";
>> +bless $node, $subclass;
>> +unless ($node->isa(__PACKAGE__))
>> +{
>>
nk you.
> I reviewed and tested these and they LGTM. FYI the rebased v3 patches
> upthread are raw diffs so git am won't apply them.
That's not at all unusual. I normally apply patches just using
patch -p 1 < $patchfile
> I can add myself to
> the CF as a rev
On 1/4/22 07:20, Michael Paquier wrote:
> On Wed, Dec 29, 2021 at 09:48:14AM -0500, Andrew Dunstan wrote:
>> Seems reasonable. I don't see any reason not to do it for pgbison.bat
>> and pgflex.bat, just for the sake of consistency.
> Yeah, that would close the loop. Andr
101 - 200 of 2809 matches
Mail list logo
