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
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
es are tiny.
What I might do with the new animal is run just enough TAP tests to
exercise psql. That would reduce the errors we get, so it would be less
bother to anyone.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
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
rdly measurable anyway - you would be in
effect saving one or two stat calls per database.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
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
s
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
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
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
pg_fatal("All the database, role/user names should have only
valid characters. A newline or \n"
+ "carriage return character is not allowed in these
object names. To fix this, please \n"
+ "rename these names with valid names. \n"
+ "To see all %d invalid object names, refer
db_role_user_invalid_names.txt file. \n"
+ " %s", count, output_path);
Also needs some cleanup.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
f course).
+1.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
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&#
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
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
patches.
Not sure if I will have time for this.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
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
ning as (Should use PQuser() for that rather than cparams.user).
BTW, if you're sending delta patches, make sure they don't have .patch
extensions. Otherwise, the CFBot gets upset. I usually just add .noci to
the file names.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
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
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
test we could write, not one we
already have.
Yeah, will try to have one next week.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
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
moved.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
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
h);
+ ecp = system_dir;
+
+ if (strlen(Extension_control_path) == 0)
+ {
+ paths = lappend(paths, ecp);
+ }
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
;
}
and various other things that insist on this. But I think all we should
need is for Python to be present, whether or not we are building plpython.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
On 2025-02-21 Fr 11:49 AM, Andres Freund wrote:
Hi,
On 2025-02-21 11:04:49 -0500, Andrew Dunstan wrote:
On 2025-02-21 Fr 10:50 AM, Andres Freund wrote:
Can we explicitly set the MESON_BUILD_ROOT environment variable when running
a test? With included patch for the src/tools/testwrap file
kluge. I think it's different from
the server log case, which after all requires access to the server file
system to exploit.
I agree that people should not send passwords in cleartext, but I don't
know that that means we should never try to ameliorate the risk of doing so.
cheers
" to set a MESON_*
variable, why not set the top_builddir or a dedicated variable?
And I don't think it should be done in testwrap, but to test_env in the
top-level meson.build.
Something like the attached?
LGTM
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
> On Feb 21, 2025, at 4:55 AM, Michael Paquier wrote:
>
> On Fri, Feb 21, 2025 at 04:36:07AM -0500, Andrew Dunstan wrote:
>> The fix has broken cross version upgrade test. Maybe we need to filter out
>> NO INDENT in releases prior to 16 in AdjustUpgrade.pm?s
>
>
_PORT_DIR.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
oss version upgrade test. Maybe we need to filter
out NO INDENT in releases prior to 16 in AdjustUpgrade.pm?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
with the
patch.
pushed, thanks.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
E-HEAD>
The conversion regexes are wrong for versions < 10, where the major
version is '9.x', but that just seems to be the tip of the iceberg.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
1 - 100 of 1355 matches
Mail list logo
