On 2/18/22 17:34, Andrew Dunstan wrote:
> On 2/17/22 12:12, Andres Freund wrote:
>> Hi,
>>
>> On 2022-02-17 09:20:56 -0500, Andrew Dunstan wrote:
>>> I don't think we have or have ever had a buildfarm animal targeting
>>> msys. In general I think of
On 2/16/22 15:46, Andrew Dunstan wrote:
> Largely following a recipe from Andres, I have migrated buildfarm
> animals fairywren and jacana to a setup that shouldn't need (and in fact
> won't be able to use) PostgreSQL::Test:Utils::perl2host(). AFAICT these
> two are the
On 2/19/22 13:04, Andrew Dunstan wrote:
> On 2/16/22 15:46, Andrew Dunstan wrote:
>> Largely following a recipe from Andres, I have migrated buildfarm
>> animals fairywren and jacana to a setup that shouldn't need (and in fact
>> won't be able to use) PostgreSQL::
On 2/19/22 16:34, Andres Freund wrote:
> Hi,
>
> On 2022-02-19 13:04:05 -0500, Andrew Dunstan wrote:
>> OK, nothing broke, so here are two more invasive patches.
> Great!
>
>
>> The first
>> removes perl2host completely and adjusts all the places that use
ion would be to add removing the reservation files in
an END handler. That would be pretty simple.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2022-11-06 Su 08:51, Álvaro Herrera wrote:
> On 2022-Jun-14, Andrew Dunstan wrote:
>
>> OK, here's a more principled couple of patches. For config_data, if you
>> give multiple options it gives you back the list of values. If you don't
>> specify any, in sca
On 2022-11-09 We 05:35, Andrew Dunstan wrote:
> On 2022-11-06 Su 08:51, Álvaro Herrera wrote:
>> On 2022-Jun-14, Andrew Dunstan wrote:
>>
>>> OK, here's a more principled couple of patches. For config_data, if you
>>> give multiple options it gives you
intending to add a new subdirectory to the default layout?
Why is that x84_64-linux-gnu there?
Also, why have the CPPFLAGS made their way into the LDFLAGS? That seems
wrong.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2022-11-14 Mo 18:24, Andres Freund wrote:
> Hi,
>
> On 2022-11-14 17:41:54 -0500, Andrew Dunstan wrote:
>> Here's a couple of things I've noticed.
>>
>>
>> andrew@ub22:HEAD $ inst.meson/bin/pg_config --libdir --ldflags
>> /home/andrew/pgl/
e functionality gets reviewed
> and committed.
>
>
Nikita,
just checking in, are you making progress on this? I think we really
need to get this reviewed and committed ASAP if we are to have a chance
to get the SQL/JSON stuff reworked to use it in time for rel
ings that ld itself will recognize?
> I don't think there's a clear cut line what is for ld and what
> isn't. Including stuff that influences both preprocessor and
> linker. -ffreestanding will e.g. change preprocessor, compiler (I think), and
> linke
On 2022-11-06 Su 11:30, Andrew Dunstan wrote:
>
> One possible addition would be to add removing the reservation files in
> an END handler. That would be pretty simple.
>
>
Here's a version with that. I suggest we try it out and see if anything
breaks.
cheers
andrew
-
rsion that uses pg_class_aclcheck() instead. I'm not sure how I
> missed this earlier.
>
OK, reading the history I think everyone is on board with expanding
AclMode from uint32 to uint64. Is that right? If so I'm intending to
commit at least the first two of these patches fairly soon
o recreate the image and add in
musl-locales, but maybe we should just leave it as it is to test the
case where the command isn't available.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2022-11-17 Th 01:18, Noah Misch wrote:
> On Mon, Aug 22, 2022 at 09:44:42AM -0400, Andrew Dunstan wrote:
>> On 2022-08-21 Su 20:40, Noah Misch wrote:
>>> This (commit 13d856e of 2015-07-29) added the following:
>>>
>>> --- a/src/test/perl/TestLib.p
coverage for cfbot?
>
Are we going to impose some sane minimum, or leave it up to developers
to discover that for themselves?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2022-11-04 Fr 10:06, Jehan-Guillaume de Rorthais wrote:
> On Thu, 3 Nov 2022 13:11:18 -0500
> Justin Pryzby wrote:
>
>> On Tue, Jun 28, 2022 at 06:17:40PM -0400, Andrew Dunstan wrote:
>>> Nice catch, but this looks like massive overkill. I think we can very
>>&
On 2022-11-17 Th 10:48, Tom Lane wrote:
> Andres Freund writes:
>> On 2022-11-17 09:58:48 -0500, Andrew Dunstan wrote:
>>> Are we going to impose some sane minimum, or leave it up to developers
>>> to discover that for themselves?
>> I don't think we shou
On 2022-11-17 Th 17:11, Andrew Dunstan wrote:
> On 2022-11-04 Fr 10:06, Jehan-Guillaume de Rorthais wrote:
>> On Thu, 3 Nov 2022 13:11:18 -0500
>> Justin Pryzby wrote:
>>
>>> On Tue, Jun 28, 2022 at 06:17:40PM -0400, Andrew Dunstan wrote:
>>>> Nice catc
It also runs a git daemon, and several of my animals
point at that.
If there's a better git API I'll be happy to try to use it.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
f the buildfarm for a very long time. See the alerts
section of the config file.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2022-11-19 Sa 09:33, Tom Lane wrote:
> Tomas Vondra writes:
>> On 11/19/22 14:51, Andrew Dunstan wrote:
>>> On 2022-11-19 Sa 05:34, Tomas Vondra wrote:
>>>> I wonder if it'd make sense to have some simple & optional alerting
>>>> based o
e sure the directory exists
>> +mkpath($portdir) unless -d $portdir;
>> }
> Perhaps we should just export a directory in configure instead of this
> guessing game?
>
>
>
I think the obvious candidate would be to export top_builddir from
src/Makefile.global. That would remove the need to infer it from
TESTDATADIR.
Any objections?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2022-11-19 Sa 15:16, Andres Freund wrote:
> Hi,
>
> On 2022-11-19 10:56:33 -0500, Andrew Dunstan wrote:
>>> Perhaps we should just export a directory in configure instead of this
>>> guessing game?
>> I think the obvious candidate would be to export top_bui
On 2022-11-20 Su 17:32, Thomas Munro wrote:
> On Sun, Nov 20, 2022 at 2:44 AM Andrew Dunstan wrote:
>> It might not suit your use case, but one of the things I do to reduce
>> fetch load is to run a local mirror which runs
>>
>>git fetch -q --prune
>>
>&
: "4cbcb7ed85",
> "REL_13_STABLE": "c13667b518",
> "REL_14_STABLE": "5cda142bb9",
> "REL_15_STABLE": "ff9d27ee2b",
> "HEAD": "51b5834cd5"
> }
>
No. It's the way it is because the client relies on their being in the
right order. JSON hashes are conceptually unordered.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2022-11-21 Mo 15:58, Tom Lane wrote:
> Andrew Dunstan writes:
>> The buildfarm server now creates a companion to branches_of_interest.txt
>> called branches_of_interest.json which looks like this:
> ... okay ...
>
>> It updates this every time it does a git fetch
On 2022-11-21 Mo 16:20, Magnus Hagander wrote:
> n Mon, Nov 21, 2022 at 9:58 PM Tom Lane wrote:
>
> Andrew Dunstan writes:
> > The buildfarm server now creates a companion to
> branches_of_interest.txt
> > called branches_of_interest.json which looks lik
On 2022-11-20 Su 14:05, Andres Freund wrote:
>> If it works ok I will backpatch in couple of days.
> +1
Done.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2022-11-22 Tu 13:04, Magnus Hagander wrote:
>
>
> On Tue, Nov 22, 2022 at 12:10 AM Magnus Hagander
> wrote:
>
>
>
> On Mon, Nov 21, 2022 at 11:42 PM Andrew Dunstan
> wrote:
>
>
> On 2022-11-21 Mo 16:20, Magnus Hagander wrote:
>
> On Nov 22, 2022, at 8:36 PM, Tom Lane wrote:
>
> Andres Freund writes:
>> While looking into a weird buildfarm failure ([1]), I noticed this:
>
>> # Checking port 62707
>> Use of uninitialized value $pid in scalar chomp at
>> /mnt/resource/bf/build/grassquit/REL_11_STABLE/pgsql.build/../p
OK we should adjust the head comment on the function.
In any case I think this comment would be better English with "might"
instead of "may":
/* user may have the ANALYZE privilege */
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
ight return undef if the file is empty?
>
>
Yeah, should be fixed now.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
further? In principle maybe,
> but I'm not sure we have enough animals to make it worthwhile.
>
>
Yeah, that's my feeling. We have managed to get a large improvement with
a fairly small effort, I'm much less excited about getting another small
improvement from a large effort.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
be some fallout with cross version upgrades,
which I will try to prevent.
cheers
andrew
[1]
https://git.postgresql.org/pg/commitdiff/171c7fffaa4a3f2b000f980ecb33c2f7441a9a03
[2] https://community.chocolatey.org/packages/ActivePerl#comment-5484577151
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2022-11-25 Fr 18:48, Andrew Dunstan wrote:
> For various reasons (see below) it's preferable to build on Windows with
> Strawberry Perl. This works OK if you're building with Msys2, I upgraded
> the instance on the machine that runs fairywren and drongo today, and
> fai
On 2022-11-25 Fr 18:52, Andrew Dunstan wrote:
> On 2022-11-25 Fr 18:48, Andrew Dunstan wrote:
>> For various reasons (see below) it's preferable to build on Windows with
>> Strawberry Perl. This works OK if you're building with Msys2, I upgraded
>> the instance on
tps://www.postgresql.org/message-id/flat/20220219234148.GC9008%40telsasoft.com
> - set TESTDIR from perl rather than Makefile
I looked at the latest set here, patch 1 still doesn't look right, I
think vc_regress.pl should be setting PG_SUBDIR like the Makefile.global
does.
cheers
andrew
--
On 2022-11-26 Sa 16:05, Andres Freund wrote:
> Hi,
>
> On 2022-11-26 09:43:19 -0500, Andrew Dunstan wrote:
>> OK, so this cures the problem for drongo:
>>
>>
>> diff --git a/src/tools/msvc/Mkvcbuild.pm b/src/tools/msvc/Mkvcbuild.pm
>> index 83a3e40425..dc
On 2022-11-26 Sa 16:25, Andrew Dunstan wrote:
> On 2022-11-26 Sa 16:05, Andres Freund wrote:
>> Hi,
>>
>> On 2022-11-26 09:43:19 -0500, Andrew Dunstan wrote:
>>> OK, so this cures the problem for drongo:
>>>
>>>
>>> diff --git a/src/tools/
On 2022-11-23 We 18:54, Nathan Bossart wrote:
> On Wed, Nov 23, 2022 at 02:56:28PM -0500, Andrew Dunstan wrote:
>> I have committed the first couple of these to get them out of the way.
> Thanks!
>
>> But I think we need a bit of cleanup in the next patch.
>> vacuu
On 2022-11-21 Mo 00:26, Tom Lane wrote:
> Corey Huinker writes:
>> On Tue, Nov 15, 2022 at 11:36 AM Andrew Dunstan wrote:
>>> Nikita,
>>> just checking in, are you making progress on this? I think we really
>>> need to get this reviewed and committed ASAP i
onment variable to force tap tests to use
> tcp.
>
Not sure if it's useful here, but a few months ago I prepared patches to
remove the config-auth option of pg_regress, which struck me as more
than odd, and replace it with a perl module. I didn't get around to
finishing them, b
itdb.c.)
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
hope we can get this settled early next week and then we
can get to work on the next tranche of functions, those that will let
the SQL/JSON work restart.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
eed to be
> a switch to make this optional.)
+1 for fixing this. Your scheme seems reasonable. This has been a pain
point for a long time. I'm not sure what we'd gain by making the fix
optional.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2022-12-02 Fr 12:40, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 2022-12-02 Fr 09:18, Tom Lane wrote:
>>> The scheme I've vaguely thought about, but not got round to writing,
>>> is to merge all blobs with the same owner and ACL into one TOC entry.
>
On 2022-12-03 Sa 16:46, Tom Lane wrote:
> Andrew Dunstan writes:
>> Great. Let's hope we can get this settled early next week and then we
>> can get to work on the next tranche of functions, those that will let
>> the SQL/JSON work restart.
> OK, here's a draf
On 2022-12-04 Su 10:25, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 2022-12-03 Sa 16:46, Tom Lane wrote:
>>> 1. Bikeshedding on my name choices is welcome. I know Robert is
>>> dissatisfied with "ereturn", but I'm content with that so I didn
name people are still going to be making mistakes based on
> that confusion 10 years from now.
>
OK, I take both this point and Tom's about trying to keep it the same
length. So we need something that's 7 letters, doesn't say 'return' and
preferably begins with &
t;> ... "errsave", maybe?
> IMO eseterr is quite awful while errsave is not, so here goes my vote
> for the latter.
Wait a minute! Oh, no, sorry, as you were, 'errsave' is fine.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2022-12-05 Mo 14:22, Corey Huinker wrote:
>
> On Mon, Dec 5, 2022 at 11:36 AM Andrew Dunstan
> wrote:
>
>
> On 2022-12-05 Mo 11:20, Robert Haas wrote:
> > On Mon, Dec 5, 2022 at 11:09 AM Tom Lane wrote:
> >> Robert Haas writes:
> >&
y. I don't mind
> that as regression-test infrastructure, but I'm a bit less excited
> about exposing it as a user feature.
>
I think a functional mechanism could be very useful. Who knows when the
standard might specify something in this area?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
e alternative.
>
>
Yeah, I don't think there's terribly much to choose between 'safe' and
'noerror' in terms of meaning.
I originally chose InputFunctionCallContext as a more neutral name in
case we wanted to be able to pass some other sort of node for the
context in future.
Maybe that was a little too forward looking.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
area, just abandoning the idea that that's our initial
> test mechanism.)
>
The new functions on their own are likely to make plenty of people quite
happy once we've adjusted all the input functions.
Perhaps we should add a type in the regress library that will never have
a safe inpu
On 2022-12-07 We 09:20, Tom Lane wrote:
> Andrew Dunstan writes:
>> Perhaps we should add a type in the regress library that will never have
>> a safe input function, so we can test that the mechanism works as
>> expected in that case even after we adjust all the core
uash them that's ok. I wouldn't break up
0003. I think we're going to end up committing the remaining work in
batches, although they would probably be a bit more thematically linked
than these.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
be made that CLUSTER should be governed by the
VACUUM privileges, given how VACUUM FULL is now implemented.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
ndered whether
> an input function that uses a Bison/Flex parser would have big
> problems getting converted. This one didn't, anyway.
Cool
>
> Given that this additional experimentation didn't find any holes
> in the API design, I think this is pretty m
it what you
currently have so people can start work on other input functions.
Thanks for your work on this.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2022-12-09 Fr 10:16, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 2022-12-08 Th 21:59, Tom Lane wrote:
>>> Yeah, I was planning to take a look at that before walking away from
>>> this stuff. (I'm sure not volunteering to convert ALL the input
>>>
On 2022-12-09 Fr 10:37, Andrew Dunstan wrote:
> I am currently looking at the json types. I think that will be enough to
> let us rework the sql/json patches as discussed a couple of months ago.
>
OK, json is a fairly easy case, see attached. But jsonb is a different
kettle of fish.
shouldn't try to do what I suggest above for
> v14; but without it, these changes are just moving the security
> issue to a different place rather than eradicating it completely.
>
>
Is there anything else we should be doing along the eat your own dogfood
line that don't have these security implications?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
ne in PostgresNode would do something like:
my $logpos = -s $logfile;
do_some_stuff();
my @lines = file_lines($logfile, $logpos);
This has the benefit of working the same on all platforms, and no
truncation, rotation, or restart is required.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 4/14/21 8:10 PM, Michael Paquier wrote:
> On Wed, Apr 14, 2021 at 05:10:41PM -0400, Andrew Dunstan wrote:
>> That seems rather heavy-handed. The buildfarm's approach is a bit
>> different. Essentially it seeks to the previous position of the log file
>> before rea
On 4/15/21 12:57 AM, Michael Paquier wrote:
> On Wed, Apr 14, 2021 at 09:26:19PM -0400, Andrew Dunstan wrote:
>> Well, let me try it on fairywren tomorrow. Since we manage this on the
>> buildfarm without any use at all of Win32API::File it might not be
>> necessa
On 4/15/21 8:36 PM, Michael Paquier wrote:
> On Thu, Apr 15, 2021 at 07:16:05AM -0400, Andrew Dunstan wrote:
>> Reviewing the history, I don't want to undo 114541d58e5.
> Maybe we could remove it, but that may be better as a separate
> discussion if it is proving to not i
users are likely to want.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
general rolling
your own is a bad idea.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 4/17/21 9:04 AM, Michael Paquier wrote:
> On Thu, Apr 15, 2021 at 09:12:52PM -0400, Andrew Dunstan wrote:
>> It's worked on fairywren, I will double check on drongo and if all is
>> well will commit.
> Thanks Andrew. For the archive's sake, this has been committe
On 4/12/21 10:57 AM, Jehan-Guillaume de Rorthais wrote:
> On Mon, 12 Apr 2021 09:52:24 -0400
> Andrew Dunstan wrote:
>
>> On 4/12/21 8:59 AM, Jehan-Guillaume de Rorthais wrote:
>>> Hi,
>>>
>>> On Wed, 7 Apr 2021 20:07:41 +0200
>>> Jehan-Guil
On 4/17/21 12:31 PM, Andrew Dunstan wrote:
> On 4/12/21 10:57 AM, Jehan-Guillaume de Rorthais wrote:
>> On Mon, 12 Apr 2021 09:52:24 -0400
>> Andrew Dunstan wrote:
>>
>>> On 4/12/21 8:59 AM, Jehan-Guillaume de Rorthais wrote:
>>>> Hi,
>>>
On 4/17/21 3:43 PM, Mark Dilger wrote:
>
>> On Apr 16, 2021, at 11:06 AM, Andrew Dunstan wrote:
>>
>>
>> Hi,
>>
>> Peter Geoghegan suggested that I have the cross version upgrade checker
>> run pg_amcheck on the upgraded module. This seemed to me lik
On Mon, Apr 19, 2021 at 4:53 AM Pavel Stehule
wrote:
>
>
> po 19. 4. 2021 v 7:43 odesílatel Thomas Munro
> napsal:
>
>> Hi,
>>
>> Moving this topic into its own thread from the one about collation
>> versions, because it concerns pre-existing problems, and that thread
>> is long.
>>
>> Currently
On 4/17/21 12:35 PM, Andrew Dunstan wrote:
>
>> OK, here is more WIP on this item. I have drawn substantially on Mark's
>> and Jehan-Guillaime's work, but it doesn't really resemble either, and I
>> take full responsibility for it.
>>
>> The g
On 4/19/21 8:32 AM, Michael Paquier wrote:
> On Mon, Apr 19, 2021 at 08:11:01AM -0400, Andrew Dunstan wrote:
>> As far as I know, without any compatibility changes the module is fully
>> compatible with releases 13 and 12, and with releases 11 and 10 so long
>> as you don&
On 4/19/21 10:26 AM, Dave Page wrote:
>
>
> On Mon, Apr 19, 2021 at 11:52 AM Andrew Dunstan <mailto:and...@dunslane.net>> wrote:
>
>
> My understanding from Microsoft staff at conferences is that
> Azure's PostgreSQL SAS runs on linux, not WIndows.
On 4/18/21 7:32 PM, Alvaro Herrera wrote:
> On 2021-Apr-18, Andrew Dunstan wrote:
>
>> On 4/17/21 3:43 PM, Mark Dilger wrote:
>>> I'd also like your impressions on whether we're likely to move
>>> contrib/amcheck into core anytime soon. If so, is it wo
On 4/19/21 10:43 AM, Mark Dilger wrote:
>
>> On Apr 19, 2021, at 5:11 AM, Andrew Dunstan wrote:
>>
>> I think therefore I'm inclined for now to do nothing for old version
>> compatibility.
> I agree with waiting until the v15 development cycle.
>
>
On 4/19/21 1:25 PM, Mark Dilger wrote:
>
>> On Apr 19, 2021, at 9:53 AM, Tom Lane wrote:
>>
>> Andrew Dunstan writes:
>>> OK, so let's fix it. If amcheck is going to stay in contrib then ISTM
>>> pg_amcheck should move there. I can organize that
d = 500,
si_sigval = {sival_int = 0, sival_ptr = 0x0}}, _sigchld = {si_pid =
333090, si_uid = 500, si_status = 0, si_utime = 0, si_stime = 0},
_sigfault = {si_addr = 0x1f400051522, _addr_lsb = 0, _addr_bnd = {_lower
= 0x0, _upper = 0x0}}, _sigpoll = {si_band = 2147483981090, si_fd = 0}}}
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
e easily as
>
> my $includes = join ';', @{$self->{includes}};
> $includes .= ';' unless $includes eq '';
>
or even more simply:
my $includes = join ';', @{$self->{includes}}, "";
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
I've just noticed that we have 41 perl files in our sources with
copyright notices of some sort and 161 without. Should we do something
about that?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Yeah
The comment is a bit strange anyway - Cygwin is actually going to use
Unix sockets, not TCP.
I think I would just change the test to this: $use_tcp &&
$TestLib::windows_os.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 4/20/21 8:47 AM, Robert Haas wrote:
> On Mon, Apr 19, 2021 at 2:55 PM Andrew Dunstan wrote:
>> There are at least two other client side programs in contrib. So this
>> argument doesn't quite hold water from a consistency POV.
> I thought that at first, too. But the
and things we don't for one reason
or another (e.g. pgcrypto, adminpack)
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
on't want to do that, do "make install" before "make check".
>
>
FYI the buildfarm client has a '--delay-check' option that does exactly
this. It's useful on Alpine Linux as well as MacOS
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 4/19/21 12:37 PM, Andrew Dunstan wrote:
> On 4/19/21 10:43 AM, Mark Dilger wrote:
>>> On Apr 19, 2021, at 5:11 AM, Andrew Dunstan wrote:
>>>
>>> I think therefore I'm inclined for now to do nothing for old version
>>> compatibility.
>> I
On 4/21/21 1:13 AM, Michael Paquier wrote:
> On Tue, Apr 20, 2021 at 01:11:59PM -0400, Andrew Dunstan wrote:
>> Here's the patch for that.
> Thanks.
>
>> +# Accept standard formats, in case caller has handed us the output of a
>> +# postgres com
On 4/20/21 6:49 PM, Alexey Kondratov wrote:
> On 2021-04-20 18:03, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> On 4/19/21 7:22 PM, Tom Lane wrote:
>>>> I wonder whether we could get away with just replacing the $use_tcp
>>>> test with $TestLib::w
On 4/22/21 2:52 AM, Michael Paquier wrote:
> On Wed, Apr 21, 2021 at 10:04:40AM -0400, Andrew Dunstan wrote:
>> Here's a patch with these things attended to.
> Thanks. Reading through it, that seems pretty much fine to me. I
> have not spent time checking _version_cmp in de
On 4/22/21 2:52 AM, Michael Paquier wrote:
> On Wed, Apr 21, 2021 at 10:04:40AM -0400, Andrew Dunstan wrote:
>> Here's a patch with these things attended to.
> Thanks. Reading through it, that seems pretty much fine to me. I
> have not spent time checking _version_c
he first regex should match things like "12", "12.1", "14devel", or those
> same things prefixed with "(PostgreSQL) ", and strip off the "(PostgreSQL)"
> part if it exists. But the code should also BAIL_OUT if the regex completely
> fails to match.
>
Not quite. PostgresVersion doesn't know about Test::More. It could die
(or croak) and we could catch it in an eval.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 4/22/21 11:09 AM, Alvaro Herrera wrote:
> On 2021-Apr-21, Andrew Dunstan wrote:
>
>> +=head1 DESCRIPTION
>> +
>> +PostgresVersion encapsulated Postgres version numbers, providing parsing
>> +of common version formats and comparison operations.
> Small t
= -3, beta = -2, rc = -1. Or maybe that's overkill.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 4/23/21 12:41 AM, Michael Paquier wrote:
> On Thu, Apr 22, 2021 at 08:43:10PM -0400, Andrew Dunstan wrote:
>> Interesting point. Maybe we need to do something like devel = -4, alpha
>> = -3, beta = -2, rc = -1. Or maybe that's overkill.
> And after that it would come to
print "standby 1: $result\n";
lines are there for debugging. Normally you would just process $result
using the Test::More functions
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 4/24/21 1:54 AM, Michael Paquier wrote:
> On Fri, Apr 23, 2021 at 08:10:01AM -0400, Andrew Dunstan wrote:
>> Yeah, I think it's ok for comparison purposes just to lump them all
>> together. Here's a patch that does that and some consequent cleanup.
>> Note we n
On 4/18/21 5:58 PM, Mark Dilger wrote:
>
>> On Apr 18, 2021, at 6:19 AM, Andrew Dunstan wrote:
>>
>> how about specifying pg_catalog as the schema instead of public?
> Done.
>
Pushed with slight changes.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
veCopy all use the Carp module, but
contain numerous calls to "die" where they should probably have calls to
"croak" or "confess".
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
1301 - 1400 of 2807 matches
Mail list logo
