isn't visible at the SQL level.
Do we think that making this change is valuable enough to justify
taking such a risk?
yes +1
Agree to all the above
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2025-08-02 Sa 4:57 PM, Andrew Dunstan wrote:
The V18 Release notes contain this:
Allow inactive replication slots to be automatically invalided
using server variable idle_replication_slot_timeout
<https://www.postgresql.org/docs/18/runtime-config-replication.html#GUC-I
On 2025-07-29 Tu 11:40 AM, Tom Lane wrote:
Andrew Dunstan writes:
OK. I'm inclined to do this after the CF finishes, to avoid collisions
with other patches. I assume it's going to make the CFbot fairly unhappy.
+1 for proceeding that way. (I did not look at whether the proposed
c
in.
That makes sense ... naming the new encoding so as to avoid confusion
might be a challenge.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
harath Rupireddy)
Shouldn't this read "invalidated"?
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
On 2025-08-01 Fr 8:24 PM, Zhijie Hou (Fujitsu) wrote:
On Saturday, August 2, 2025 12:59 AM Andrew Dunstan
wrote:
On 2025-08-01 Fr 11:03 AM, Zhijie Hou (Fujitsu) wrote:
On Friday, August 1, 2025 8:56 PM Andrew Dunstan mailto:and...@dunslane.net
wrote:
We have another example to consider
On 2025-08-01 Fr 11:03 AM, Zhijie Hou (Fujitsu) wrote:
On Friday, August 1, 2025 8:56 PM Andrew Dunstan wrote:
On 2025-08-01 Fr 4:03 AM, Zhijie Hou (Fujitsu) wrote:
On Monday, July 28, 2025 1:07 PM Hayato Kuroda (Fujitsu)
mailto:kuroda.hay...@fujitsu.com wrote:
Dear Shubham,
The attached
to bear should pg_basebackup be made more complex in the
future. pg_basebackup becoming more complex means that
pg_createsubscriber would need to cope with the facilities added to
the former.
In short, I don't think that this patch is a good idea.
+1
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
it. pg_amcheck
might allow you to have multiple --database arguments, but I don't think
it depends on the order of arguments. You didn't answer his question
about what getopt_long() does. I don't recall if it is free to mangle
the argument order.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
On 2025-07-31 Th 2:22 PM, Nathan Bossart wrote:
On Wed, Jul 30, 2025 at 02:51:59PM -0400, Andrew Dunstan wrote:
OK, now that's reverted...
Can we close the open item for this one now? Or is there something else
remaining?
Thanks for the reminder. I have marked the item as
ious, test returned 2 (wstat 512, 0x200)
00:54:18 Failed 1/1 subtests
Devel is ok.
That file was deleted by the revert. Maybe you have a cache problem?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2025-07-29 Tu 4:09 PM, Andrew Dunstan wrote:
On 2025-07-28 Mo 8:04 AM, Andrew Dunstan wrote:
On 2025-07-27 Su 7:56 PM, Noah Misch wrote:
On Fri, Jul 25, 2025 at 04:59:29PM -0400, Tom Lane wrote:
Andrew Dunstan writes:
Before we throw the baby out with the bathwater, how about this
On 2025-07-29 Tu 4:34 PM, Noah Misch wrote:
On Tue, Jul 29, 2025 at 04:09:13PM -0400, Andrew Dunstan wrote:
here's a reversion patch for master.
This reverts parts or all of the following commits:
I briefly looked through this. The biggest non-reverted part is, I think,
c1da728
On 2025-07-28 Mo 8:04 AM, Andrew Dunstan wrote:
On 2025-07-27 Su 7:56 PM, Noah Misch wrote:
On Fri, Jul 25, 2025 at 04:59:29PM -0400, Tom Lane wrote:
Andrew Dunstan writes:
Before we throw the baby out with the bathwater, how about this
suggestion? pg_dumpall would continue to produce
produced output is the
same as the master branch.
[snip]
OK. I'm inclined to do this after the CF finishes, to avoid collisions
with other patches. I assume it's going to make the CFbot fairly unhappy.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
(which is a nitpick a commmitter
can deal with, no need for a new version IMO).
At the same time they should do:
s/need/needs/
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
On 2025-07-27 Su 7:56 PM, Noah Misch wrote:
On Fri, Jul 25, 2025 at 04:59:29PM -0400, Tom Lane wrote:
Andrew Dunstan writes:
Before we throw the baby out with the bathwater, how about this
suggestion? pg_dumpall would continue to produce globals.dat, but it
wouldn't be process
On 2025-07-25 Fr 12:21 PM, Noah Misch wrote:
On Thu, Jul 24, 2025 at 04:33:15PM -0400, Andrew Dunstan wrote:
On 2025-07-21 Mo 8:53 PM, Noah Misch wrote:
I suspect this is going to end with a structured dump like we use on the
pg_dump (per-database) side. It's not an accident tha
On 2025-07-25 Fr 4:34 AM, Álvaro Herrera wrote:
On 2025-Jul-24, Andrew Dunstan wrote:
Obviously we already have some functions for things like views and
triggers, but most notably we don't have one for tables, something users
have long complained about. I have been trying to think
reluctantly come to the conclusion that it would probably be better to
back the feature out and have another go for PG 19.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
That seems a bit fragile, though. The alternative is that we
have a separate function for each object type, e.g.
pg_get_{objecttype}_ddl. I'm kinda leaning that way, but I'd like some
sort of consensus before any work gets done.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
rd, I think we will have to live with what the standards
committee decides, regardless of our preference. We've almost certainly
been preempted here by other RDBMSs using QUALIFY, heedless of English
grammar.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
well. It seems that
connecting to Redis has been unstable recently.
That's unrelated to your commit, stable branches of crake are red as
well.
Yes, fallout from a system upgrade. Fixed, now, sorry for the noise.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2025-07-21 Mo 8:53 PM, Noah Misch wrote:
On Mon, Jul 21, 2025 at 04:41:03PM -0400, Andrew Dunstan wrote:
On 2025-07-17 Th 6:18 AM, Mahendra Singh Thalor wrote
--- a/src/bin/pg_dump/pg_restore.c
+++ b/src/bin/pg_dump/pg_restore.c
+/*
+ * read_one_statement
+ *
+ * This will start reading
at identifiers with CR or LF are turned into
Unicode quoted identifiers, so each SQL statement would always only
occupy one line. Or just reject role and tablespace names with CR or LF
altogether, just as we do for database names.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
I think, for this case, we can do some
more doc changes.
Example: pg_restore --globals-only : this will restore the global.dat
file(including all drop commands). It might drop databases if any drop
commands.
I don't think doc changes are useful.
Yeah, I don't think this is something that can
On 2025-07-09 We 4:51 PM, Andres Freund wrote:
Hi,
On 2025-07-09 16:10:25 -0400, Tom Lane wrote:
Andrew Dunstan writes:
/*
To turn off/hide the contents of this file:
#define
MICROSOFT_WINDOWS_WINBASE_H_DEFINE_INTERLOCKED_CPLUSPLUS_OVERLOADS 0
*/
I don't thi
On 2025-07-08 Tu 4:10 PM, Andrew Dunstan wrote:
On 2025-07-08 Tu 3:45 PM, Tom Lane wrote:
Andrew Dunstan writes:
It's done and running. Testing before I re-enabled the animal it shows
it was happy.
In the no-good-deed-goes-unpunished department ... drongo is now spewing
a boatload of
ttp://001_password.pl> (Wstat: 512 (exited 2)
Tests: 1 Failed: 0)
Non-zero exit status: 2
Parse errors: No plan found in TAP output
Files=1, Tests=1, 183 wallclock secs ( 0.02 usr 0.00 sys + 0.41 cusr
0.14 csys = 0.57 CPU)
Result: FAIL
gmake: *** [Makefile:17: check] Error 1
These
On 2025-07-08 Tu 3:45 PM, Tom Lane wrote:
Andrew Dunstan writes:
It's done and running. Testing before I re-enabled the animal it shows
it was happy.
In the no-good-deed-goes-unpunished department ... drongo is now spewing
a boatload of these warnings:
C:\\Program Files (x86)\\Wi
d the animal it shows
it was happy.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
e can say "get a newer compiler" depends in part on how
long it's been fixed.
Meanwhile I will update drongo anyway.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
hould avoid the timeouts.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
nd it looks rather ugly anyway.
Given we've got this far without it being a significant issue, I don't
think there's much need to backpatch it.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
, 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
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 - 100 of 1390 matches
Mail list logo
