On 1/4/22 04:18, Himanshu Upadhyaya wrote:
> On Thu, Dec 16, 2021 at 3:06 AM Andrew Dunstan wrote:
>>
>>
>> SELECT JSON_OBJECTAGG(k: v ABSENT ON NULL) AS apt
>> FROM (VALUES ('no', 5), ('area', 50), ('rooms', 2), ('foo', NULL),
uot;2018-10-14 10:05:14",
"HR": 73
},
{
"location": [ 47.706, 13.2635 ],
"start time": "2018-10-14 101:39:21",
"HR": 135
}
]
}'::jsonb)->'track'->'segments';
?column?
[{"HR": 73, "location": [47.763, 13.4034], "start time": "2018-10-14
10:05:14"}, {"HR": 135, "location": [47.706, 13.2635], "start time":
"2018-10-14 101:39:21"}]
(1 row)
>> Few comments For 0002-SQL-JSON-constructors-v59.patch:
> Also, any thoughts on this?
I will look at that separately.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
ct rather more faithfully than many
implementations (e.g. we allow huge number strings). So as far as I'm
concerned, we are right and Oracle is wrong. It would hardly be the
first time such a thing has happened.
Oracle is not the definer of the JSON standard. ECMA is.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
currently reviewing:
andrew=# select 'foo' is json;
?column?
--
f
(1 row)
andrew=# select '"foo"' is json;
?column?
--
t
(1 row)
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
otting something amiss after an
> extra close read.
>
> Attached is an updated patch set that increases the test timeout (5min
> -> 10min). That should help, I assume.
ITYM 3 min -> 6 min. But in any case, is that really going to solve
this? The file should exist,
On 1/6/22 13:06, Andrew Dunstan wrote:
> On 1/5/22 02:32, Michael Paquier wrote:
>> On Sun, Jan 02, 2022 at 01:34:45PM -0800, Andres Freund wrote:
>>> The tests don't seem to pass on windows:
>>> https://cirrus-ci.com/task/5412456754315264?logs=test_bin#L47
rite it something
like this:
s/EXTENSION (.*?)plpython2?u/EXTENSION $1plpython3u/g ;
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 1/7/22 08:56, Juan José Santamaría Flecha wrote:
>
> On Fri, Jan 7, 2022 at 2:30 PM Andrew Dunstan wrote:
>
>
> Yeah, this code is not a model of clarity though. I had to think
> through
> it and I write quite a bit of perl. I would probably write it
>
On 1/4/22 08:37, Andrew Dunstan wrote:
> 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
On 1/10/22 06:53, Juan José Santamaría Flecha wrote:
>
> On Mon, Jan 10, 2022 at 12:51 PM Juan José Santamaría Flecha
> wrote:
>
> Please find attached a patch for so.
>
> The patch.
>
>
>
>
Pushed, and backpatched.
cheers
and
that can
> probably be improved. But cdb is so gnarly that I wanted to stop looking once
> I got this far...
>
>
> Andrew, I wonder if something like this could make sense for windows BF
> animals?
>
Very possibly. I wonder how well it will work on machines where I have
more than one animal .e.g. lorikeet (cygwin) jacana (msys) and bowerbird
(MSVC) are all on the same machine. Likewise drongo (MSVC) and fairywren
(msys2).
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
up in this mess?)
Your list contains at least some false positives. e.g.
<https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana&dt=2019-12-22%2014:19:02>
which has a different script failing.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
ly or indirectly own", here and
similarly in one or two other places.
...
I will probably do one or two more passes over the patches, but as I say
in general they look fairly good.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
opinion of an expert, if we have one.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 1/11/22 02:51, Andres Freund wrote:
> Hi,
>
> On 2022-01-10 10:57:00 -0500, Andrew Dunstan wrote:
>> On 10/5/21 15:30, Andres Freund wrote
>>> The above ends up dumping all crashes into a single file, but that can
>>> probably be improved. But cdb is so gna
On 1/11/22 16:13, Andres Freund wrote:
> Hi,
>
> On 2022-01-11 12:01:42 -0500, Andrew Dunstan wrote:
>> On 1/11/22 02:51, Andres Freund wrote:
>>> It'd be a bit of a fight with cdb's awfully documented and quirky
>>> scripting [1], but the bes
need to add -Wnoregister to the CXXFLAGS?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
t now we are seeing failures on the cfbot too (e.g.
https://cirrus-ci.com/task/5860692694663168 and
https://cirrus-ci.com/task/5316745152954368 ) so I think we need to
spend some effort on finding out what's going on here.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
a syntax error in the MERGE docs.
The problem with patches like this is that they seriously screw up the
cfbot, which doesn't know about the previous patches you want this based
on top of. See <http://cfbot.cputube.org/patch_36_3408.log>
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
fault case. But I agree it's confusing.
>
> 4)
> -test: json jsonb json_encoding jsonpath jsonpath_encoding jsonb_jsonpath
> +test: json jsonb json_encoding jsonpath jsonpath_encoding
> jsonb_jsonpath sqljson
>
> can we rename sqljson sql test file to json_constructor?
Not really - the later patches in the series add to it, so it ends up
being more than just constructor tests.
Thanks for reviewing,
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 1/12/22 16:15, Tom Lane wrote:
> Andrew Dunstan writes:
>> For some considerable time the recovery tests have been at best flaky on
>> Windows, and at worst disastrous (i.e. they can hang rather than just
>> fail).
> How long is "some considerable time"?
t of things to return to:
<https://www.postgresql.org/message-id/46c40cc7-db28-b684-379d-43b34daa5ffa%40dunslane.net>
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
ession altogether (comparable to, eg, --no-tablespaces).
> But I think that's optional. In any case, we don't want
> to put people in a position where they should have used such
> an option and now they have no good way to recover their
> dump to the system they want to recover to.
>
>
I'm fairly sure this prescription would satisfy the buildfarm. It sounds
pretty sane to me - I'd independently come to a very similar conclusion
before reading the above.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
tests are still ongoing ...
I thought Tom's suggestion upthread:
> Would it be sane to have the backend not bother to
> take any locks in binary-upgrade mode?
was interesting. Could we do that on the restore side? After all, what
are we locking against in binary upgrade mode?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
50)
{
return 1;
I'll try to come up with something better. Maybe just ignore lines like
SET default_toast_compression = 'pglz';
when taking the diff.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
e and that they cannot upgrade from their 9.5
> databases, which are now past EOL.
>
One possible (probable?) source is the JDBC driver, which currently
treats all Blobs (and Clobs, for that matter) as LOs. I'm working on
improving that some: <https://github.com/pgjdbc/pgjdbc/pull/2093>
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 3/21/21 12:56 PM, Jan Wieck wrote:
> On 3/21/21 7:47 AM, Andrew Dunstan wrote:
>> One possible (probable?) source is the JDBC driver, which currently
>> treats all Blobs (and Clobs, for that matter) as LOs. I'm working on
>> improving that some: <https://githu
nging
it now, but if anything that's the change that should have been made here.
Just wanted that on the record in case people got this wrong idea that
you can't use forward slashes when calling a program in cmd.exe.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 3/22/21 4:36 AM, Juan José Santamaría Flecha wrote:
>
> On Sun, Mar 21, 2021 at 10:28 PM Andrew Dunstan <mailto:and...@dunslane.net>> wrote:
>
>
> Note that the pg_ctl path is quoted, and those quotes are passed
> through
> to cmd.exe. That's wh
On 1/13/21 7:25 AM, Daniel Gustafsson wrote:
>> On 17 Dec 2020, at 22:37, Andrew Dunstan wrote:
>> I've been giving some thought to $subject. The initial impetus is the
>> promise I made to assist with testing of clients built with NSS against
>> servers built
On 3/23/21 6:36 PM, Michael Paquier wrote:
> On Thu, Jan 28, 2021 at 10:19:57AM -0500, Andrew Dunstan wrote:
>> +BEGIN
>> +{
>> +
>> +# putting this in a BEGIN block means it's run and checked by perl -c
>> +
>> +
>> +# everything other t
On 3/23/21 7:09 PM, Andrew Dunstan wrote:
> On 3/23/21 6:36 PM, Michael Paquier wrote:
>> On Thu, Jan 28, 2021 at 10:19:57AM -0500, Andrew Dunstan wrote:
>>> +BEGIN
>>> +{
>>> +
>>> +# putting this in a BEGIN block means it's run and checked
On 3/24/21 7:54 AM, Dagfinn Ilmari Mannsåker wrote:
> Andrew Dunstan writes:
>
>> And here it is. No subclass, no eval, no magic :-) Some of my colleagues
>> are a lot happier ;-)
>>
>> The downside is that we need to litter PostgresNode with a bunch of
>&
we probably shouldn't special case any
particular settings, but simply take any extra arguments as extra env
settings. And if any setting has undef (e.g. PGAPPNAME) we should unset it.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 3/24/21 9:23 AM, Andrew Dunstan wrote:
> On 3/24/21 8:29 AM, Alvaro Herrera wrote:
>> On 2021-Mar-24, Dagfinn Ilmari Mannsåker wrote:
>>
>>> I think it would be even neater having a method that returns the desired
>>> environment and then have the other met
On 3/24/21 11:41 AM, Alvaro Herrera wrote:
> On 2021-Mar-24, Andrew Dunstan wrote:
>
>> On 3/24/21 9:23 AM, Andrew Dunstan wrote:
>>> On 3/24/21 8:29 AM, Alvaro Herrera wrote:
>>> If we're going to do that we probably shouldn't special case any
>>&g
ange to you, I can help a bit.
Incidentally, I'm not sure why we need to break SSLServer into
SSL::Server - are we expecting to create other children of the SSL
namespace?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 3/24/21 12:54 AM, Michael Paquier wrote:
[numerous useful comments]
OK, here's a new patch. I hope to commit this within a few days.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
diff --git a/doc/src/sgml/client-auth.sgml b/doc/src/sgml/client-auth.sgml
>> (which would also break it, if you managed to find a non-ascii
>> compatible encoding). Maybe even something along the line of "the
>> contents have to be written in binary mode"?
>
> Perhaps something like the attached?
>
>
That seems a bit opaque. Let's tell them exactly what they need to avoid.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
be reviewed here. In fact
there are no changes at all in those patches from the previous set other
than a little patch fuzz. The only substantial changes are in patch 1,
which had bitrotted. However, I'm posting a new series to keep the
numbering in sync.
If the cfbot is happy I will set bac
On 3/26/21 4:22 PM, Andrew Dunstan wrote:
> On 3/8/21 1:55 PM, Ibrar Ahmed wrote:
>>
>> On Sat, Jan 23, 2021 at 3:37 PM Erik Rijkers > <mailto:e...@xs4all.nl>> wrote:
>>
>> On 2021-01-20 03:49, Nikita Glukhov wrote:
>>
>> > [0001-Ad
On 3/26/21 4:48 PM, Erik Rijkers wrote:
>> On 2021.03.26. 21:28 Andrew Dunstan wrote:
>> On 3/25/21 8:10 AM, David Steele wrote:
>>> On 1/20/21 8:42 PM, Nikita Glukhov wrote:
>>>> Thank you for review.
>>>>
>>>> Attached 45th version of
On 3/26/21 4:49 PM, Andrew Dunstan wrote:
> On 3/26/21 4:22 PM, Andrew Dunstan wrote:
>> On 3/8/21 1:55 PM, Ibrar Ahmed wrote:
>>> On Sat, Jan 23, 2021 at 3:37 PM Erik Rijkers >> <mailto:e...@xs4all.nl>> wrote:
>>>
>>> On 2021-01-20 03:49, N
if this patch has any impact on performance. I guess that
> adding 4 if statements will slow down `pg_dump` a little bit.
>
>
Not likely to be noticeable.
Please add this to the next commitfest.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
is not a good idea. You should have one regression test script ideally,
and it should be added as appropriate to both the parallel and serial
schedules (and not at the end). Any further tests should be added using
the other frameworks mentioned.
cheers
andrew
--
Andrew Dunstan
EDB
don't like using
joins, then either a) you should have the DBA create some views for them
that contain the joins, or b) you have the wrong application programmers -:)
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 3/26/21 2:45 PM, David Steele wrote:
> On 3/26/21 1:20 PM, Magnus Hagander wrote:
>> On Fri, Mar 26, 2021 at 5:52 PM Andrew Dunstan
>> wrote:
>>> On 3/26/21 10:19 AM, David Steele wrote:
>>>>
>>>>> No, the problem is you are using copy/
On 3/28/21 10:04 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 3/27/21 5:11 PM, Alvaro Herrera wrote:
>>> This seems pretty dangerous -- you just have to create one more FK, and
>>> suddenly a query that worked perfectly fine, now starts throwing errors
>
arget pg_dumpall against the original
source vs target pg_dumpall against the upgraded source.
If someone wants to come up with a better rule for detecting that
nothing has gone wrong, I'll be happy to implement it. I don't
particularly like the current rule either, it's there faute de mieux.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
e new routines of PostgresNode.pm,
> and I have done things this way to ease the patch lookup. Thoughts?
Looks reasonable.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
gt; version owing to the PATH confusion.
> Hmm, I think it should complain if you give it a path that doesn't
> actually contain a valid installation.
>
Yeah, it should be validated. All things considered I think just calling
'pg_config --version' is probably the simplest validation, and likely to
be sufficient.
I'll try to come up with something tomorrow.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
the interaction
>> with PostgresNode would be. I'll keep looking.
> Do you need to do "pg_ctl -w" perhaps?
Probably. The buildfarm does this unconditionally and has done for a
very long time, so maybe we don't need a version test for it.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 3/30/21 8:52 PM, Michael Paquier wrote:
> On Tue, Mar 30, 2021 at 08:44:26PM -0400, Andrew Dunstan wrote:
>> Yeah, it should be validated. All things considered I think just calling
>> 'pg_config --version' is probably the simplest validation, and likely to
>> b
without realising.
>
> It seems to me that sepgsql should also log the denial, but flag that
> permissive mode is on.
>
> Any reason not to do that?
+1 for doing what selinux does if possible.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
hat would it return? There is no sane description other than the
enum's label, which you can get far more simply.
Maybe this small break on orthogonality should be noted, if enough
people care, but I doubt we should do anything else.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 3/31/21 10:28 PM, Mark Dilger wrote:
>
>> On Mar 31, 2021, at 1:07 PM, Mark Dilger
>> wrote:
>>
>>
>>
>>> On Mar 31, 2021, at 1:05 PM, Andrew Dunstan wrote:
>>>
>>>
>>> On 3/31/21 3:48 PM, Alvaro Herrera wrote:
&
L value, so I'm
inclined to say your suggestion "it's not okay for AttrDefaultFetch to
leave such a state behind" is what we should go with.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
is up one way or
another as part of the cleanup on the other thread.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
I don't recall seeing this. Around that time I was busy returning from
Australia at the start of the pandemic, so my I might have missed it in
the hubbub.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 4/4/21 12:05 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 4/3/21 10:09 PM, Tom Lane wrote:
>>> Looking around at the other touches of AttrDefault.adbin in the backend
>>> (of which there are not that many), some of them are prepared for it to be
>>
On 4/4/21 11:21 AM, Andrew Dunstan wrote:
> On 4/4/21 9:19 AM, Justin Pryzby wrote:
>> It reminded me of this thread, but nothing ever came of it.
>> https://www.postgresql.org/message-id/20200328223052.GK20103%40telsasoft.com
>>
>>
>> https://www.postgresql.org
stigate.
Without that it's difficult to know what to look at.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 4/4/21 6:50 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 4/4/21 12:05 PM, Tom Lane wrote:
>>> I made CheckConstraintFetch likewise not install its array until
>>> it's done. I notice that it is throwing elog(ERROR) not WARNING
>>> for the
as Ubuntu, running PostgreSQL
> from an Ubuntu package with a freaky kernel. Hmm.
>
To test this the OP could just add
CPPFLAGS => '-DWAIT_USE_POLL',
to his animal's config's config_env stanza.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
t I could possibly be persuaded otherwise. Also, maybe
it belongs in src/test/perl.
. This line appears deundant, the variable is not referenced:
+ my $path = $ENV{PATH};
Also these lines at the bottom of CrossVersion.pm are redundant:
+use strict;
+use warnings;
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
l changes to PostgresNode itself. I think
that was a good decision. If you take out the versioning subroutines,
the actual version-aware changes Mark is proposing to PostgresNode are
quite small - less that 200 lines supporting versions all the way back
to 8.1. That's pretty awesome.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
its patch.
Aren't you likely to end up duplicating substantial amounts of code,
though? I'm certainly not at the stage where I think the version-aware
code is creating too much clutter. The "forest of conditionals" seems
more like a small thicket.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
ring the
> BF status with run-failed-because-of-$weird_problem issues, but it
> doesn't help from the standpoint of noticing when your animal is stuck.
> Maybe it'd be better to change that behavior.
>
Yeah, I'll have a look. It's not simple for a bunch of reasons.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 4/7/21 3:09 PM, Alvaro Herrera wrote:
> On 2021-Apr-07, Andrew Dunstan wrote:
>
>> Aren't you likely to end up duplicating substantial amounts of code,
>> though?
> No — did you look at his code? Each version is child of the one just
> above, so you only
On 4/7/21 4:02 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 4/7/21 1:07 PM, Tom Lane wrote:
>>> I do use it on some of my flakier dinosaurs, and I've noticed that
>>> when it does kick in, the buildfarm run just stops dead and no report
>>> is se
On 4/7/21 4:19 PM, Alvaro Herrera wrote:
> On 2021-Apr-07, Andrew Dunstan wrote:
>
>> b) as it stands pgaTester.pm can't be used for multiple versions in a
>> single program, which is a design goal here - it sets the single class
>> to invoke in its BEGIN block. At
e want it to do*?
>
>
Yeah, much more important. I think I would say that anything that's
simply not possible in an older version should cause an error and for
the rest the old version should probably behave by default as much like
its default as possible. I don't think we should try to make different
versions behave identically (or as close to as possible). In some
particular cases we should be able to override default behavior (e.g. by
setting the config explicitly).
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
ibraries=pg_stat_statements",
> # which typical installcheck users do not have (e.g. buildfarm clients).
> NO_INSTALLCHECK = 1
>
>
>
Yeah, Julien is right, we run "make check" for these in src/test/modules
but I missed contrib. I have fixed this on crake so we get some
immediate coverage and a fix will be pushed to github shortly.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
ments into the de-parsed body, but some
> folks might be satisfied with grabbing the prosrc text.
>
+many for storing query text.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
ern in plr.h looks quite breakable. Instead of hard
coding values like this they should save the value from the postgres
headers in another variable before undefining it and then restore that
value after inclusion of the R headers. That would work across versions
even if we renumber them.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 4/7/21 5:06 PM, Alvaro Herrera wrote:
> On 2021-Apr-07, Andrew Dunstan wrote:
>
>> Oh, you want to roll them all up into one file? That could work. It's a
>> bit frowned on by perl purists, but I've done similar (see PGBuild/SCM.pm).
> Ah! Yeah, pretty much e
;m going to take some of what you've done and
incorporate it in the patch I'm working on.
A PostgresVersion class is a good idea - I was already contemplating
something of the kind.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
have PTYs. Expect.pm is in fact a
pure perl module that sits on top of IO::Pty, which in turn sits on top
of IO::Tty. So if you have those Expect.pm probably isn't a huge
stretch. But let's not add a dependency if we can avoid it. And if we do
add one it will need to be a soft one like the case you mentioned.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
h are what Expect uses under the hood. So use
of any of that needs to be done just as it is done on
010_tab_completion.pl, i.e.
eval { require IO::Pty; };
if ($@)
{
plan skip_all => 'IO::Pty is needed to run this test';
}
cheers
andrew
--
Andrew Duns
On 8/4/20 5:42 PM, Daniel Gustafsson wrote:
>> On 3 Aug 2020, at 21:18, Andrew Dunstan
>> wrote:
>> On 8/3/20 12:46 PM, Andrew Dunstan wrote:
>>> On 7/31/20 4:44 PM, Andrew Dunstan wrote:
>>>> OK, here is an update of your patch that compiles and runs
;> SERIALIZABLE, for example. Generally the file seems more about
>> serializable than 2PC...
>>
>> So unless somebody disagrees I'm gonna add a new
>> prepared-transactions-2.spec.
>
> But I noticed that the already existing prepared transactions test
> wasn
gt; so it's worth testing.
>
What would the framework look like?
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
ly. I didn't address the linelengths being too long in this patch
> to
> make review easier instead.
>
I'll take a look.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Thu, Aug 6, 2020 at 4:12 PM Fabrízio de Royes Mello
wrote:
>
>
> On Mon, Jul 13, 2020 at 6:18 PM Fabrízio de Royes Mello
> wrote:
>>
>>
>> On Mon, Jul 13, 2020 at 5:05 PM Andrew Dunstan
>> wrote:
>> >
>> >
. (Also, how do we
>>> see this working in the back branches?)
>>
>> I would be fine with test.sh staying around for now.
>
> test.sh could be changed to invoke the TAP test.
Keeping test.sh is not necessary - I mis-remembered what the test module
does.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 10/10/21 7:18 AM, Michael Paquier wrote:
> On Fri, Oct 08, 2021 at 12:14:57PM -0400, Andrew Dunstan wrote:
>> I think we need to be more explicit about it, especially w.r.t. indirect
>> calls. Every subroutine in the call stack below where you want to error
>> reported
will choke if the supplied version is older.
We could even put lines like this in a small script that configure could
run.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
We don't need to keep the quoted string values anyway, and
# on some platforms the complex regex causes perl to barf and crash.
$src =~ s{/\*.*?\*/}{}gs;
After you've done that splitting it into lines is pretty simple.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 10/12/21 4:37 AM, Andres Freund wrote:
> git remote add andres g...@github.com:anarazel/postgres.git
ITYM:
git remote add andres git://github.com/anarazel/postgres.git
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 10/12/21 4:37 AM, Andres Freund wrote:
> # setup build directory
> meson setup build --buildtype debug
I took this for an outing on msys2 and it just seems to hang. If it's not
hanging it's unbelievably slow.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 10/12/21 11:28 AM, Andrew Dunstan wrote:
> On 10/12/21 4:37 AM, Andres Freund wrote:
>> # setup build directory
>> meson setup build --buildtype debug
> I took this for an outing on msys2 and it just seems to hang. If it's not
> hanging it's unbelievabl
:0: ERROR: Compiler ccache cc can not compile programs.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 10/12/21 2:09 PM, Andres Freund wrote:
> Hi,
>
> On 2021-10-12 09:59:26 -0700, Andres Freund wrote:
>> On 2021-10-12 11:50:03 -0400, Andrew Dunstan wrote:
>>> It hung because it expected the compiler to be 'ccache cc'. Hanging in
>>> such a cas
On 10/12/21 2:23 PM, Andres Freund wrote:
> Hi,
>
> On 2021-10-12 14:11:39 -0400, Andrew Dunstan wrote:
>> On 10/12/21 12:59 PM, Andres Freund wrote:
>>> If you repro the hanging, what's the last bit in meson-logs/meson-log.txt?
>> Here's the entire thi
On 10/12/21 2:37 PM, Andrew Dunstan wrote:
> On 10/12/21 2:09 PM, Andres Freund wrote:
>> Hi,
>>
>> On 2021-10-12 09:59:26 -0700, Andres Freund wrote:
>>> On 2021-10-12 11:50:03 -0400, Andrew Dunstan wrote:
>>>> It hung because it expected the compiler
virtual paths. So you do
something like this:
PATH="/c/perl/bin:$PATH" PROVE=/bin/core_perl/prove configure ...
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 10/12/21 9:03 PM, Andres Freund wrote:
> Hi,
>
> On 2021-10-12 13:42:56 -0700, Andres Freund wrote:
>> On 2021-10-12 16:02:14 -0400, Andrew Dunstan wrote:
>>> You do that by putting a path to it at the start of the PATH. The wrinkle in
>>> this is that yo
all.
It is in Strawberry's c/bin directory.
>
> Seems like we should consider using gendef instead of pexports, given it's
> available in msys?
Yeah. It's missing on my ancient msys animal (frogmouth), but it doesn't
build --with-perl.
jacana seems to have it.
If you
h this. There is no
requirement that we support VS2022 on day one of its release. Three
months really won't matter. Impatience doesn't serve us well here.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 10/13/21 5:46 PM, Andres Freund wrote:
> Hi,
>
> On 2021-10-13 16:06:32 -0400, Andrew Dunstan wrote:
>> If you prep a patch I'll test it.
> Well, right now I'm wondering if the better fix is to just remove the whole
> win32 block. I don't know how far bac
201 - 300 of 2812 matches
Mail list logo
