, and you shouldn't mess with them. I
don't think you're using SimpleTee correctly anyway, but it's really not
meant for general use, only for the use in Utils.pm.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
diff --git a/src/test/perl/PostgreSQL/Test/Cl
blem.
I'm happy to keep discussing what the best approach for the community
is. It's great that more light is being shed on this particular issue.
[0]
https://www.postgresql.org/message-id/CA%2BQeY%2BDTggHskCXOa39nag2sFds9BD-7k__zPbvL-_VVyJw7Sg%40mail.gmail.com
--
Respectfully,
Andrew Johnson
Software Engineer
Metronome, Inc.
z_6ugwfe6dke8b5-dtdv...@mail.gmail.com
[4]
https://www.postgresql.org/message-id/CAA5RZ0u43s4YbR%3D0mJ0_k3VGWjchJHhYnCoaZVzeLd3ccZtwhQ%40mail.gmail.com
--
Respectfully,
Andrew Johnson
Software Engineer
Metronome, Inc.
v1-0001-Adding-pg_stat_muiltixact-view-to-allow-membershi.patch
Description: Binary data
t can be implemented fairly cheaply.
I don't have terribly strong feelings about it, but matching a feature
implemented elsewhere has some attraction if it can be done easily.
OTOH I'm a bit curious to know what software produces multi-line CSV
headers.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
intenance effort is close to zero. As I pointed out elsewhere in this
thread, even if the server has limited use, the Cygwin psql client is
nicer to use on Windows than the native build, reason enough to keep it
going, at least until we improve the native build.
cheers
andrew
--
bytes for the same characters. This makes GB18030
significantly more storage-efficient compared to UTF-8 in terms of
space utilization.
Given this, removing it seems like a non-starter.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
The attached updated patch fixes the merge conflicts and updates the
numbering of the test files.
On Mon, Feb 24, 2025 at 12:06 PM Andrew Jackson
wrote:
> The previous patch had a mistake in a reference in the documentation. This
> should fix it.
>
> On Mon, Feb 24, 2025 at 10:
On 2025-04-21 Mo 12:29 PM, Andrew Dunstan wrote:
Last year the old Windows machine where I was running the buildfarm
member lorikeet died, and since then we've had no buildfarm coverage
for Cygwin. I now have a new (but slow) W11pro machine and I have been
testing out Cygwin builds
ok at retiring Cygwin when all
the live branches have psql with a working readline on native Windows
builds.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
On 2025-04-22 Tu 10:26 AM, Tom Lane wrote:
Andrew Dunstan writes:
I agree that I would not normally use Cygwin to run a Postgres instance.
But its psql is nicer than others on Windows because unlike the native
builds we build it with readline. That's why I've kept a buildfarm
an
On 2025-04-22 Tu 8:10 AM, Aleksander Alekseev wrote:
Hi Andrew,
Last year the old Windows machine where I was running the buildfarm
member lorikeet died, and since then we've had no buildfarm coverage for
Cygwin. I now have a new (but slow) W11pro machine and I have been
testing out C
ildfarm animal going with these
before I disappear.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
cygwin-fixes.tgz
Description: application/compressed-tar
//usr/local/pgsql/lib64:/usr/local/pgsql/lib:/usr/local/lib:/usr/lib64/...
What is that extra stuff doing on the end of your LD_LIBRARY_PATH? That
looks wrong. Do you have LD_LIBRARY_PATH set in your calling environment?
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
r we will
+see the expected backend log output.
That seems a little fragile. I can imagine test authors easily
forgetting this. Is it worth sanity checking to make sure
log_min_messages is appropriately set?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2025-04-17 Th 10:56 AM, Tom Lane wrote:
Andrew Dunstan writes:
Back in 2022 in commit 55828a6b6084 we disabled a bunch of tests due to
a timing issue. Nothing seems to have been done since ... do we still
want to keep these commented out lines around? This "temporary" fix
see
(noticed when looking into a different issue).
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2025-04-14 Mo 8:20 AM, Álvaro Herrera wrote:
On 2025-Apr-04, Andrew Dunstan wrote:
Non text modes for pg_dumpall, correspondingly change pg_restore
I think the new oid_string_list stuff in this commit is unnecessary, and
we can remove a bunch of lines by simplifying that to using
On 2025-04-15 Tu 2:30 PM, Mahendra Singh Thalor wrote:
Hi Andrew,
I did some refactoring to find out dump file extensions(.dmp/.tar etc)
in pg_restore. With the attached patch, we will not try to find out
file extension with each database, rather we will find out before the
loop.
Here, I am
ings that
should not be possible, and won't trigger anything in a non-assertion
build. This condition should cause a pg_fatal().
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
On 2025-04-14 Mo 12:28 PM, Andrew Dunstan wrote:
I'm also not sure about the double sscanf() business there ... There
must be a better way to do this.
Yes, probably. I'll look into that if you like.
something like this?
cheers
andrew
--
Andrew Dunstan
On 2025-04-14 Mo 8:20 AM, Álvaro Herrera wrote:
On 2025-Apr-04, Andrew Dunstan wrote:
Non text modes for pg_dumpall, correspondingly change pg_restore
I think the new oid_string_list stuff in this commit is unnecessary, and
we can remove a bunch of lines by simplifying that to using
On 2025-04-13 Su 1:51 PM, Andres Freund wrote:
Hi,
On April 13, 2025 7:27:33 PM GMT+02:00, Wolfgang Walther
wrote:
Andrew Dunstan:
On 2025-04-12 Sa 10:10 PM, Noah Misch wrote:
On Sat, Apr 12, 2025 at 07:51:06PM +0200, Wolfgang Walther wrote:
With injection points enabled, I get the
lly
tested PostgreSQL until one builds with injection points.
Here's a simple fix ... also removes some unnecessary escaping and
leaning toothpick syndrome.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
diff --git a/src/test/modules/test_aio/t/001_aio.pl b/s
On 2025-04-13 Su 8:12 AM, Álvaro Herrera wrote:
On 2025-Apr-12, Andrew Dunstan wrote:
Seems odd that this one is necessary at all. Doesn't a StringInfo always
have a trailing null byte?
AFAICT what this is doing that's significant, is increment StringInfo->len.
Before doing it,
am attaching a small patch to fix these 3 type conversions on head.
Seems odd that this one is necessary at all. Doesn't a StringInfo always
have a trailing null byte?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2025-04-10 Th 5:45 PM, Ranier Vilela wrote:
Em qui., 10 de abr. de 2025 às 15:58, Andrew Dunstan
escreveu:
On 2025-04-10 Th 2:38 PM, Ranier Vilela wrote:
Thanks. I have pushed these now with a few further small tweaks.
Sorry if it is not the right place
On 2025-04-10 Th 2:38 PM, Ranier Vilela wrote:
Thanks. I have pushed these now with a few further small tweaks.
Sorry if it is not the right place.
Coverity has another resource leak alert.
trivial patch attached.
Thanks for checking. Pushed.
cheers
andrew
--
Andrew Dunstan
On 2025-04-07 Mo 2:59 PM, Mahendra Singh Thalor wrote:
On Mon, 7 Apr 2025 at 18:52, Andrew Dunstan wrote:
On 2025-04-07 Mo 8:25 AM, Mahendra Singh Thalor wrote:
Hi,
In commit 643a1a61985bef2590496, we did some cleanup and we replaced
if-else with switch case.
Basically, we made a function
On 2025-04-08 Tu 11:45 AM, Peter Geoghegan wrote:
On Tue, Apr 8, 2025 at 11:20 AM Nathan Bossart wrote:
+1 for UTC.
+1, I think that AoE is needlessly obscure
+1
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
, then it's not working. And I bet there is a huge number of
people who have never even heard of it. Specify some time and data at
UTC and everyone will understand.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2025-04-08 Tu 10:17 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 2025-04-07 Mo 7:41 PM, Michael Paquier wrote:
delete_old_cluster.sh would be left around even if not using a VPATH
build with ./configure (your commit message does not mention that).
Even if .gitignore discards it, the
the source
directory to be scribbled on. All sorts of things might be left around.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
y reaction too.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2025-04-07 Mo 11:05 AM, Andrew Dunstan wrote:
On 2025-04-07 Mo 12:58 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 2025-04-01 Tu 11:15 AM, Andrew Dunstan wrote:
On 2025-04-01 Tu 8:47 AM, vignesh C wrote:
There is an existing CF entry for this at [1]. If no one picks this
till the end
On 2025-04-07 Mo 12:58 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 2025-04-01 Tu 11:15 AM, Andrew Dunstan wrote:
On 2025-04-01 Tu 8:47 AM, vignesh C wrote:
There is an existing CF entry for this at [1]. If no one picks this
till the end of this CF, we can move it to next CF.
[1] - https
-else.
Here, I am attaching a patch which makes both the files similar.
We can move this similar function into one common file also but as of
now, I made a static function same as pg_dumpall.c.
Yeah, let's put it in a common file. There's no point in duplicating it.
cheer
should do something like
pg_fatal("could not open "%s" file: %m", map_file_path);
Yeah. Here's a more thorough error message cleanup.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
diff --git a/src/bin/pg_dump/pg_dumpall.
nning and similar as well, on
the same usability grounds as banning tabs, except that putting an
encoding dependency into this rule will not end well.)
Sound like we have some work to do, and that's not going to happen in 24
hours.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Sent from my iPhone
> On Apr 6, 2025, at 11:23 AM, Álvaro Herrera wrote:
>
> On 2025-Apr-06, Andrew Dunstan wrote:
>
>> On 2025-03-28 Fr 10:43 AM, Nathan Bossart wrote:
>
>>> Taking a step back, are we sure that 1) this is the right place to do these
>&g
dd these checks to the grammar instead
of trying to patch up all the various places they are used in the tree.
Maybe. I don't think there is time for that for v18, so we'd have to
defer this for now. I can live with that - it's been like this for a
long time.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Apologies, forgot to attach the patch in the prior email.
On Sat, Mar 22, 2025 at 4:10 PM Andrew Jackson
wrote:
> Currently the LDAP usage in fe-connect.c does not explicitly set the
> protocol version to v3. This causes issues with many LDAP servers as they
> will often require clien
On 2025-03-31 Mo 12:16 PM, Mahendra Singh Thalor wrote:
On Mon, 31 Mar 2025 at 19:27, Andrew Dunstan wrote:
On 2025-03-31 Mo 5:34 AM, Mahendra Singh Thalor wrote:
There are a couple of rough edges, though.
First, I see this:
andrew@ub22arm:inst $ bin/pg_restore -C -d postgres
--exclude
see a reason not to do that?
In principle it seems quite reasonable, but I haven't looked at all the
current uses to see if they will be upset.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
committer
> attached to it soon. I'm not confident that I'll have time for it,
> unfortunately.
I think Andrew is planning this as a cleanup for "non-text pg_dumpall"
patch. Andrew, please if you have some bandwidth, then please let us
know your feedback for these patch
costs of that have been fully accounted for, especially
not the fact that almost all of those costs fall on people other than
us.
I am on board with not having it as part of stock libpq, but I don't see what
we gain by not building it as part of postgres (if the dependencies are
available, o
On 2025-04-04 Fr 5:12 AM, Mahendra Singh Thalor wrote:
On Fri, 4 Apr 2025 at 13:52, Mahendra Singh Thalor wrote:
On Fri, 4 Apr 2025 at 01:17, Andrew Dunstan wrote:
On 2025-04-01 Tu 1:59 AM, Mahendra Singh Thalor wrote:
On Mon, 31 Mar 2025 at 23:43, Álvaro Herrera wrote:
Hi
FWIW I don&#
Hi,
Added some tests for the LDAP connection parameters lookup functionality
with the attached patch. It is based off of the tests that were added
recently that cover the connection service file libpq functionality as well
as the existing ldap test framework.
Thanks,
Andrew Jackson
On Wed, Mar
upport pg_dump. It is not
marketed as a general purpose export facility.
*ahem*
What is your evidence for that proposition? If this were true we would
not support CSV mode, which pg_dump does not use. It might have
limitations, but its use goes far beyond just pg_dump, both in theory
and
17 00:00:00 2001
From: Peter Eisentraut
Date: Thu, 3 Apr 2025 15:06:13 +0200
Subject: [PATCH] libpq: Set LDAP protocol version 3
Some LDAP servers reject the default version 2 protocol. So set
version 3 before starting the connection. This matches how the
backend LDAP code
docco and comments.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
From aea4ab40f4d461141ba92b50986b68f036d044cb Mon Sep 17 00:00:00 2001
From: Mahendra Singh Thalor
Date: Wed, 19 Mar 2025 01:18:46 +0530
Subject: [PATCH v20250403 1/4] Move common pg_dump code related
On 2025-04-01 Tu 5:34 PM, Andres Freund wrote:
Hi,
On 2025-04-01 17:08:49 -0400, Andrew Dunstan wrote:
On 2025-04-01 Tu 4:17 PM, Andres Freund wrote:
For one using PG_TEST_INITDB_EXTRA_OPTS would probably require changing the
buildfarm code, because the buildfarm code filters out
committer
> attached to it soon. I'm not confident that I'll have time for it,
> unfortunately.
I think Andrew is planning this as a cleanup for "non-text pg_dumpall"
patch. Andrew, please if you have some bandwidth, then please let us
know your feedback for these
slike that).
Uh, not quite. Anything in the config's build_env is not filtered out.
That change was made a year ago.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
On 2025-04-01 Tu 11:15 AM, Andrew Dunstan wrote:
On 2025-04-01 Tu 8:47 AM, vignesh C wrote:
On Tue, 1 Apr 2025 at 16:02, Andrew Dunstan wrote:
On 2025-04-01 Tu 5:16 AM, vignesh C wrote:
On Sun, 2 Feb 2025 at 00:52, Lars Kanis
wrote:
This patch limits the workaround of using
On 2025-04-01 Tu 8:47 AM, vignesh C wrote:
On Tue, 1 Apr 2025 at 16:02, Andrew Dunstan wrote:
On 2025-04-01 Tu 5:16 AM, vignesh C wrote:
On Sun, 2 Feb 2025 at 00:52, Lars Kanis wrote:
This patch limits the workaround of using __buildin_setjmp on the
Windows MINGW platform. This
w.com/questions/53709069/setjmp-longjmp-in-x86-64-w64-mingw32
That report is from quite a few years ago, so I'm not sure it really helps.
If one of you would add this to the next CF we could see how the CFbot
reacts to it. In general it looks sane.
cheers
andrew
--
Andre
strict in that it creates a dummy database
that is not started and passes all queries though that and tests that the
connection service file correctly overrides the environment variables set
by the dummy databases' query functions
Thanks,
Andrew Jackson
On Mon, Mar 31, 2025, 4:01 PM Ryo Kanba
On 2025-03-31 Mo 5:34 AM, Mahendra Singh Thalor wrote:
>
> There are a couple of rough edges, though.
>
> First, I see this:
>
>
> andrew@ub22arm:inst $ bin/pg_restore -C -d postgres
> --exclude-database=regression_dummy_seclabel
> --exclude-database=regression_
On 2025-03-31 Mo 1:16 PM, Andrew Dunstan wrote:
Thanks. Here are patches that contain (my version of) all the
cleanups. With this I get a clean restore run in my test case with no
error messages.
This time with patches
cheers
andrew
--
Andrew Dunstan
EDB: https
On 2025-03-30 Su 12:50 PM, Andrew Dunstan wrote:
On 2025-03-29 Sa 1:17 AM, Mahendra Singh Thalor wrote:
On Sat, 29 Mar 2025 at 03:50, Andrew Dunstan
wrote:
On 2025-03-27 Th 5:15 PM, Andrew Dunstan wrote:
On 2025-03-19 We 2:41 AM, Mahendra Singh Thalor wrote:
On Wed, 12 Mar 2025 at 21:18
On 2025-03-29 Sa 1:17 AM, Mahendra Singh Thalor wrote:
On Sat, 29 Mar 2025 at 03:50, Andrew Dunstan wrote:
On 2025-03-27 Th 5:15 PM, Andrew Dunstan wrote:
On 2025-03-19 We 2:41 AM, Mahendra Singh Thalor wrote:
On Wed, 12 Mar 2025 at 21:18, Andrew Dunstan
wrote:
On 2025-03-12 We 3:03 AM
On 2025-03-29 Sa 2:58 PM, David G. Johnston wrote:
On Sat, Mar 29, 2025 at 11:56 AM Andrew Dunstan
wrote:
I don't believe that the premise supports the conclusion.
Regardless, I do support this patch and probably any similar ones
proposed in the future. Do you have an opinion on
On 2025-03-29 Sa 12:17 PM, David G. Johnston wrote:
On Sat, Mar 29, 2025 at 9:06 AM Andrew Dunstan
wrote:
On 2025-03-29 Sa 10:40 AM, David G. Johnston wrote:
On Saturday, March 29, 2025, Kirill Reshke
wrote:
On Sat, 29 Mar 2025 at 09:47, jian he
wrote
On 2025-03-19 We 2:41 AM, Mahendra Singh Thalor wrote:
On Wed, 12 Mar 2025 at 21:18, Andrew Dunstan wrote:
On 2025-03-12 We 3:03 AM, jian he wrote:
On Wed, Mar 12, 2025 at 1:06 AM Álvaro Herrera wrote:
Hello,
On 2025-Mar-11, Mahendra Singh Thalor wrote:
In map.dat file, I tried to fix
On 2025-03-27 Th 7:57 AM, Mahendra Singh Thalor wrote:
On Thu, 27 Mar 2025 at 16:16, Andrew Dunstan wrote:
On 2025-03-26 We 8:52 AM, Srinath Reddy wrote:
sorry for the noise ,previous response had my editor's formatting,just
resending without that formatting.
./psql postgres
Hi,
O
On 2025-03-27 Th 7:33 AM, Srinath Reddy wrote:
./psql postgres
On Thu, Mar 27, 2025 at 4:16 PM Andrew Dunstan
wrote:
Yes, sorry, I misread the thread. I think we should proceed with
options 1 and 3 i.e. prevent creation of new databases with a CR
or LF, and have pgdumpall exit
On 2025-03-26 We 8:52 AM, Srinath Reddy wrote:
sorry for the noise ,previous response had my editor's formatting,just
resending without that formatting.
./psql postgres
Hi,
On Wed, Mar 26, 2025 at 5:55 PM Andrew Dunstan
wrote:
You can still create a database with these using &q
test* for
Solution 1.
You can still create a database with these using "CREATE DATABASE"
though. Shouldn't we should really be preventing that?
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
ng to test it but I haven't been able to set up an environment
for testing. But I don't think that should hold it up.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
ection
Parameters" described in [3]
[0] https://github.com/lldap/lldap
[1] https://github.com/osixia/docker-openldap
[2] https://linux.die.net/man/3/ldap
[3] https://www.postgresql.org/docs/current/libpq-ldap.html
On Sat, Mar 22, 2025 at 6:10 PM Tom Lane wrote:
> Andrew Jackson
Currently the LDAP usage in fe-connect.c does not explicitly set the
protocol version to v3. This causes issues with many LDAP servers as they
will often require clients to use the v3 protocol and disallow any use of
the v2 protocol. Further the other usage of LDAP in postgres (in
`backend/libpq/au
On 2025-03-21 Fr 12:42 PM, Tom Lane wrote:
Matheus Alcantara writes:
On Thu, Mar 20, 2025 at 7:38 PM Andrew Dunstan wrote:
(wondering if this another of these cases where the "path includes postgres"
thing bites us, and we're looking in the wrong place)
Nope, testing shows it
On 2025-03-21 Fr 11:52 AM, Matheus Alcantara wrote:
On Thu, Mar 20, 2025 at 7:38 PM Andrew Dunstan wrote:
Buildfarm member snakefly doesn't like this too much. Since no other
animals have failed, I guess it must be about local conditions on
that machine, but the report is pretty o
On 2025-03-20 Th 10:53 AM, Andrew Dunstan wrote:
On 2025-03-19 We 2:55 PM, Tom Lane wrote:
Peter Eisentraut writes:
Committed that, thanks.
Buildfarm member snakefly doesn't like this too much. Since no other
animals have failed, I guess it must be about local conditions on
that ma
nough. Or otherwise, it can at least serve as
inspiration for what you can implement yourself in your extension's
makefile.
No support for TAP tests, AFAICT. I guess this is a first step, but TAP
support would be nice.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
1.1.sql ./amcheck--1.0.sql
'/opt/postgres/build-farm-18/HEAD/pgsql.build/tmp_install/opt/postgres/build-farm-18/HEAD/inst/share/extension/'
make[1]: Leaving directory
`/opt/postgres/build-farm-18/HEAD/pgsql.build/contrib/amcheck'
(wondering if this another of these cases where the "path includes postgres"
thing bites us, and we're looking in the wrong place)
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
On 2025-03-18 Tu 1:55 PM, Tom Lane wrote:
But at least I should get it set up here. I tried setting
PG_TEST_EXTRA=code-indent locally and running 'meson test' and I
didn't get a failure -- and 'git grep code-indent' returned nothing.
Any tips?
Andrew was suggesting a
est' or CI.
Maybe we could have a TAP test module that would run it but only if you
have "code-indent" in your PG_TEST_EXTRA.
cheers
andre
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
> On Mar 18, 2025, at 9:34 AM, Robert Haas wrote:
>
> On Tue, Mar 18, 2025 at 9:27 AM Andrew Dunstan wrote:
>> Maybe we could have a TAP test module that would run it but only if you
>> have "code-indent" in your PG_TEST_EXTRA.
>
> What is the
op. Which version do we need?
nls can be formed in two ways: by declare_dependency() or by
cc.find_library(). It is not clear to me where to get a version.
pam also can be produced by dependency() or cc.find_library().
Yeah. I'm planning to commit your patch shortly.
cheers
andr
at is the exact reason.
That's not supposed to happen. I am testing a fix to see if I can make
it collect the logs, but for now we'll have to wait till the next failure ..
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
est thing here would be to have the one line
format and escape NL/CRs in the database name.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2025-03-11 Tu 5:03 PM, Álvaro Herrera wrote:
On 2025-Mar-11, Andrew Dunstan wrote:
I'm not sure everyone thinks that was a good idea for backup manifests (in
fact I know some don't), and it seems somewhat like overkill for a simple
map of oids to database names.
If such a sim
not sure everyone thinks that was a good idea for backup manifests
(in fact I know some don't), and it seems somewhat like overkill for a
simple map of oids to database names.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
small formatting error in the docs
(extra comma in the parameter list); patch attached.
Thanks, pushed.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
y) should be turned off or updated?
I'll start with my nomination for 1: we need a Windows animal that
builds in the same way and with the same options as the installer
binaries. That's something we are actually working on at EDB.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
ntation and the documentation. The implementation is json_stripe_nulls
(target JSON, ...), but the current documentation says json_stripe_nulls(target
JSONB, ...).
Argh! My glasses must have been fogged up yesterday.
pushed, thanks
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
nteract more sensibly with the server list of branches.
So we could say something like "branches_to_build =>
'UP_TO_REL_15_STABLE'". That would be pretty simple to code for.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
eory behind all of this or is the
current situation somewhat accidental?
Fairly accidental, I think.
We do have a project at EDB at fill in certain gaps in buildfarm
coverage, so maybe we can reduce the incidence of such accidents.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
. I agree
that "all" is a bad name, but I think "default" would make sense.
I can live with it but I think this just looks a bit odd.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
ode/releases> or
<https://buildfarm.postgresql.org/downloads/latest-client.tgz>
(My apologies to buildfarm owners if they updated yesterday.)
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2025-03-04 Tu 6:04 PM, Tom Lane wrote:
Andrew Dunstan writes:
Will check your patch out too.
Comparing previous run against current, I now see that my patch
caused it to skip these steps:
module-ldap_password_func-check
module-pg_bsd_indent-check
contrib-sepgsql-check
Skipping the ldap
On 2025-03-04 Tu 5:28 PM, Tom Lane wrote:
Andrew Dunstan writes:
I think I found a logic bug. Testing.
Not sure what you are looking at, but I was trying to fix it
by making the loop over test modules skip unbuilt modules,
borrowing the test you added in v19 to skip unbuilt contrib
modules
On 2025-03-04 Tu 5:28 PM, Tom Lane wrote:
Andrew Dunstan writes:
I think I found a logic bug. Testing.
Not sure what you are looking at, but I was trying to fix it
by making the loop over test modules skip unbuilt modules,
borrowing the test you added in v19 to skip unbuilt contrib
modules
s => [qw(TestUpgrade)],
# settings used by run_branches.pl
global => {
which I changed to follow the lead of build-farm.conf.sample.
But surely that wouldn't affect this!?
I think I found a logic bug. Testing.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
CE: [{"": [[3]]}, [6], [2], "bCi"]
+NOTICE: [2]
works fine. I guess that is good enough. Should we add these to the
sql/jsonb.sql to document the expected behavior, both with the error
when using plain "a" and with the correct output when using "(a)"?
The reason I mention this is that the plpgsql parser might get changed
at some point, and without a test case, we might not notice if this
breaks.
Yes, I think so.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
kept error builds
* improve check for installation complete, to avoid redundant installs
where path includes "postgresql or "pgsql"
The release is available at
<https://github.com/PGBuildFarm/client-code/releases> or
<https://buildfarm.postgresql.org/downloads/latest
Yeah, I try to avoid making too many releases, but I agree it's time to
push one.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
them
around?
There are 4 marked "Ready For Committer" - all authored by committers :-)
Maybe the message isn't getting through, After I got the email message,
I moved one yesterday that I am listed on as an author although I'm not
really, but the real author had not
On 2025-02-24 Mo 11:04 AM, Peter Eisentraut wrote:
On 21.02.25 17:38, Andrew Dunstan wrote:
I don't think this is such a terrible kluge. I think it's different
from the server log case, which after all requires access to the
server file system to exploit.
To me, the mechanism by
1 - 100 of 1435 matches
Mail list logo
