Re: Nathan Bossart
> I imagine the documentation will pretty clearly indicate that setting WAIT
> to "false" will cause CHECKPOINT to not wait for it to finish.
I can add it, it's easy enough...
> I don't understand why we need to add both FAST and IMMEDIATE.
We have both:
=# checkpoint ;
2025-
Re: Jacob Champion
> I guess I'd be concerned that a hardware crypto provider might need
> good-faith cleanup to work well.
Hopefully not in every single backend.
Christoph
make people
shoot themselves into the foot.
Christoph
>From 2f94017b467b930038a5e67cf5a59743c8bc8275 Mon Sep 17 00:00:00 2001
From: Christoph Berg
Date: Fri, 30 May 2025 17:58:35 +0200
Subject: [PATCH v3] Add mode and flush_all options to checkpoint
Field reports indicate that some users are r
Re: Andres Freund
> I'd add a 'mode' that can be set to an arbitrary string, which then can be
> validated in C code. That seems more future proof.
Changed in the attached v2, thanks.
Christoph
>From c8975cbd1dbe5e5cae18414ea27bc3f2c0e8 Mon Sep 17 00:00:00 2001
Fr
Re: Tom Lane
> > Extending the idea, perhaps the check could be moved to run-time and
> > recursively check that only immutable functions are called, including
> > user-defined immutable functions?
>
> I don't think I'd trust that. UDFs can claim to be immutable but
> be lying about it.
That's w
Re: Robert Haas
> I don't think this is sufficient to fix the problem. We have built-in
> functions that are unsafe. These include LO functions like loread(),
> lowrite(), lo_unlink(); functions that change session state like
> set_config() and setseed(); functions that allow arbitrary query
> exec
Re: Michael Paquier
> On Mon, May 26, 2025 at 06:54:49PM +0200, Daniel Gustafsson wrote:
> > Agreed, it seems very unappealing to remove something so important to such a
> > large userbase.
>
> Agreed that the so-said "state" level requirement would be a
> non-starter.
Or maybe support for using
Re: Heikki Linnakangas
> 1. Have pg_upgrade run initdb for you. It's always felt silly that you need
> to run initdb with the new version yourself, when there's really only one
> correct way to do it.
Fwiw, Debian's pg_upgradecluster script would be happy if that problem
would be solved. Currently
Re: Andres Freund
> Hi,
>
> On 2025-05-30 18:17:45 +0200, Christoph Berg wrote:
> > A customer reported to use CHECKPOINT before shutdowns to make the
> > shutdowns themselves faster and asked if it was possible to make
> > CHECKPOINT optionally also write out u
Re: Nathan Bossart
> This patch also adds an IMMEDIATE option, which I proposed some time ago
> [0]. I ended up withdrawing it due to general skepticism about its
Thanks for the pointer, I did not go that far back when looking for
older threads.
When writing the patch, I was also thinking about
>From 1d7d7b7fab78312f5423dff578dd2689eac57591 Mon Sep 17 00:00:00 2001
From: Christoph Berg
Date: Fri, 30 May 2025 17:58:35 +0200
Subject: [PATCH v1] Add immediate and flush_all options to checkpoint
Field reports indicate that some users are running CHECKPOINT just
before shutting down to reduce the amount of data
Re: Jacob Champion
> Wolfgang reported over in [1] that I've missed a comma when appending
> to the PKG_CONFIG_REQUIRES_PRIVATE list, making libpq.pc look ugly:
>
> Requires.private: libssl, libcrypto libcurl
Is adding libcurl there even the right move? This will make all
programs using pkgco
Re: Jacob Champion
> So, committed. Thanks everyone for all the excellent feedback!
The package split between libpq5 and libpq-oauth in Debian has already
been accepted into the experimental branch.
Thanks,
Christoph
Re: Matheus Alcantara
> > Thanks, I have committed this. I did a bit of code reformatting and
> > adjusted the documentation a bit. It's good to get this in before beta1
> > so that we don't have to change the valid values of
> > extension_control_path past beta1.
>
> Thanks Peter!
And thanks e
Re: David E. Wheeler
> +
> +make install prefix=/etc/postgresql
I'd use /usr/local/postgresql there. "/etc" is just wrong.
> +
> +This will install the control SQL files into
> +/etc/postgresql/share and shared modules into
> +/etc/postgresql/lib. If the prefix does not
> +include
While reading the CREATE OPERATOR docs around prefix operators, I noticed
a few places that could be improved.
Christoph
>From 478aeea4fe44c9c3462aaf18dbf04a6ed6f74ebc Mon Sep 17 00:00:00 2001
From: Christoph Berg
Date: Fri, 25 Apr 2025 12:46:36 +0200
Subject: [PATCH v1] doc: Some copy-edit
Re: Jacob Champion
> I think the system is overconstrained at that point. If you want to
> support clients that delay-load the ABI they're compiled against,
> _and_ have them continue to work seamlessly after the system has
> upgraded the ABI underneath them, without restarting the client... is
> t
Re: Nathan Bossart
> Here is what I have staged for commit. I'll aim to commit these patches
> sometime next week to give time for additional feedback.
I confirm my PG13 test table gets analyzed now with the patch.
Christoph
Re: George MacKerron
> > Before we can make this change, I think we would have to improve the
> > UX. psql does not even have any --switch for it. PostgreSQL serving
> > non-SSL and SSL on the same port doesn't make the UX better... :-/
>
> How do you think the UX could be improved? Maybe by using
Re: Matheus Alcantara
> I've tested with the semver extension and it seems to work fine with
> this patch. Can you please check on your side to see if it's also
> working?
Hi Matheus,
thanks for the patch, it does indeed work.
diff --git a/src/backend/commands/extension.c b/src/backend/commands/
Re: Jacob Champion
> Also: since the libpq-oauth-18 and libpq-oauth-19 packages can be
> installed side-by-side safely, isn't the upgrade hazard significantly
> diminished? (If a user uninstalls the previous libpq-oauth version
> while they're still running that version of libpq in memory, _and_
>
Re: Jacob Champion
> But the consequences are much worse for a silent ABI mismatch. Imagine
> if libpq-oauth examines the wrong pointer inside PGconn for a
> security-critical check.
True.
> > Alternatively, there could be a dedicated SONAME for the plugin that
> > only changes when necessary, bu
Re: George MacKerron
> SMALLER IDEA
>
> I’d suggest two new special sslrootcert values:
>
> (1) sslrootcert=openssl
>
> This does exactly what sslrootcert=system does now, but is less confusingly
> named for Windows users. sslrootcert=system becomes a deprecated synonym for
> this option.
>
>
Re: Jacob Champion
> - Per ABI comment upthread, we are back to major-minor versioning for
> the shared library (e.g. libpq-oauth-18-0.so). 0001 adds the macros
> and makefile variables to make this easy, and 0002 is the bulk of the
> change now.
This will cause problems when programs are running
Re: Tomas Vondra
> We went through the open items on the RMT team meeting today, and my
> impression was the questions are mostly about performance of having
> checksums by default, but now I realize the thread talks about "upgrade
> experience" which seems fairly wide.
Fwiw, Debian's pg_upgradecl
Re: Nathan Bossart
> My first reaction is that we should just remove the reltuples != 0 check.
> That means vacuumdb might analyze some empty tables, but that doesn't seem
> too terrible.
Or some tables that aren't empty but were never analyzed when they
should have been. Sounds like a good thing.
Re: Matheus Alcantara
> I've tried to implement some kind of "SHAREDIR search path" as we've
> discussed on another thread [1] but it shows out that we need some
> considerable refactoring to make it work.
Remembering which path the .control file was found in and from there
open the extension "dir
Re: Nathan Bossart
> pg_log(PG_REPORT,
> +"Some statistics are not transferred by pg_upgrade.\n"
> "Once you start the new server, consider running:\n"
> +"%s/vacuumdb %s--all --analyze-in-stages
> --missing-stats-only\n"
> +
Re: To Nathan Bossart
> > Update guidance for running vacuumdb after pg_upgrade.
> >
> > Now that pg_upgrade can carry over most optimizer statistics, we
> > should recommend using vacuumdb's new --missing-stats-only option
> > to only analyze relations that are missing statistics.
>
> I've been
Re: Peter Eisentraut
> The new GUC extension_control_path specifies a path to look for
> extension control files. The default value is $system, which looks in
> the compiled-in location, as before.
Is the expectation that this also works for the extension "directory"?
semver is still failing bec
Re: Jelte Fennema-Nio
> - Ubuntu 20.04 can easily install Python3.9 from the official package
> repos. Currently this is still supported by Cristoph his pgdg repos,
> but looks like that support might be removed before PG18 given it's
> transition to "Expanded Security Maintenance" next month.
20.
Re: Nathan Bossart
> In any case, IMO it's unfortunate
> that we might end up recommending roughly the same post-upgrade steps as
> before even though the optimizer statistics are carried over.
Maybe the docs (and the pg_upgrade scripts) should recommend the old
procedure by default until this gap
Re: Nathan Bossart
> Update guidance for running vacuumdb after pg_upgrade.
>
> Now that pg_upgrade can carry over most optimizer statistics, we
> should recommend using vacuumdb's new --missing-stats-only option
> to only analyze relations that are missing statistics.
I've been looking at vacuum
Re: Jacob Champion
> > libpq_append_conn_error(conn, "no custom OAuth flows are available,
> > and libpq-oauth could not be loaded library could not be loaded. Try
> > installing the libpq-oauth package from the same source that you
> > installed libpq from");
>
> Thanks! I think that's a little t
Re: Jacob Champion
> But there's no connection between "libcurl" and "OAuth Device
> Authorization flow" in anyone's mind except the people who have worked
> on that feature.
Fwiw that was exactly the reason I originally voiced the idea to
rename.
> But let me turn this around, because we current
Re: Peter Eisentraut
> But worse, what you are hiding is the information what dependencies
> you are pulling in, which is the actual reason for the options. (If there
> was no external dependency, there would be no option at all.)
>
> This seems unnecessarily complicated and inconsistent. Once y
Re: Jacob Champion
> > Putting the minor version into the filename would make looking at
> > package diffs harder when upgrading. Do we really need this as opposed
> > to some hardcoded number like libpq.so.5.18 ?
> >
> > Perhaps reusing the number from libpq.so.5.18 also for this lib would
> > be
Re: Jacob Champion
> > How about ifdef-ing away the dlopen call if --with-libcurl is not specified.
>
> This sounds like a pretty decent, simple way to go. Christoph, does
> that ring any alarm bells from your perspective?
Ok for me. The opposite that I said in the other mail was just a
suggestio
Re: Jacob Champion
> Is it acceptable/desirable for a build, which has not been configured
> --with-libcurl, to still pick up a compatible OAuth implementation
> installed by the distro? If so, we can go with a "bare" dlopen(). If
> that's not okay, I think we will probably need to use pkglibdir or
Re: Jacob Champion
> > > +This module ABI is an internal implementation detail, so it's subject to
> > > change
> > > +without warning, even during minor releases (however unlikely). The
> > > compiled
> > > +version of libpq-oauth should always match the compiled version of libpq.
> >
> > Should
> On Thu, Apr 3, 2025 at 12:50 PM Daniel Gustafsson wrote:
> > Thanks, both LGTM so pushed.
Ack, the build there worked now. (Albeit without running any tests,
but let's not care too much about this snowflake architecture.)
> On Tue, Apr 1, 2025 at 3:40 PM Jacob Champion
> While I was looking in
Re: Sadeq Dousti
> > I think this is the wrong way round.
> > It should be \dtN instead of \dNt.
>
> Hi Christoph,
> The order does not matter, the user can use \dNt or \dtN, as they do
> exactly the same thing. Letters coming after \d can be freely permuted. If
> you mean a change to the document
> Add support for OAUTHBEARER SASL mechanism
Debian still has this experimental port with a GNU userland and a
FreeBSD kernel called kfreebsd. I don't expect anyone to particularly
care about it, but it found an actual bug:
/build/reproducible-path/postgresql-18-18~~devel.20250331/build/../src/in
Re: George MacKerron
> (3) Any other ideas?
I'm not a fan of "security by adding more connection parameters".
What are the chances of making "use the system/os default CA store"
the default? "sslmode=require" would then already actually "require" a
certificate if I'm reading the docs right. This
Re: Tatsuo Ishii
> Add memory/disk usage for Window aggregate nodes in EXPLAIN.
This is failing for PG18 on Debian unstable on 32-bit i386:
build/src/test/regress/regression.diffs
diff -U3
/build/reproducible-path/postgresql-18-18~~devel.20250331/src/test/regress/expected/expla
Re: Robert Haas
> > Another question is should we back-patch this? I believe we should (?)
>
> I don't think this qualifies as a bug. The current wording isn't
> factually wrong, just unhelpful. Even if it were wrong, we need a
> pretty good reason to change message strings in a stable branch,
> b
Re: Jacob Champion
> (That means that Windows builds --with-libcurl are similarly broken, I
> think. Not that Windows packagers will want to use --with-libcurl --
> it doesn't do anything -- but it should build.)
Does --with-libcurl still do anything useful if this feature test
fails? From what yo
Re: Fabien Coelho
> (1) it seems that is the only command which is really full SQL hidden in a
> backslash command
Perhaps this form could be improved by changing `\copy (select) to file`
to something like `select \gcopy (to file)`. That might make :expansion
in the "select" part easier to handle.
Re: To Daniel Gustafsson
> > Add support for OAUTHBEARER SASL mechanism
>
> Debian still has this experimental port with a GNU userland and a
> FreeBSD kernel called kfreebsd.
Sorry this part was nonsense, kfreebsd was actually terminated and
obviously I didn't even read the port's name. The fail
Re: David Rowley
> Any chance you could share the output of:
>
> explain (analyze,buffers off,costs off) select sum(n) over() from
> generate_series(1,2000) a(n);
PostgreSQL 18devel on x86-linux, compiled by gcc-14.2.0, 32-bit
=# explain (analyze,buffers off,costs off) select sum(n) over() from
Re: Andres Freund
> > Yes. Also, none of this has addressed my complaint about the extent
> > of the build and install dependencies. Yes, simply not selecting
> > --with-libcurl removes the problem ... but most packagers are under
> > very heavy pressure to enable all features of a package.
And
Re: Robert Haas
> I wonder if, in addition to removing the hint, we could also consider
> rewording the message. For example, a slight rewording to "server
> connection closed unexpectedly" would avoid implying that it was the
There is a lot of software doing string-parsing of this part of the
mes
Re: Sadeq Dousti
> Thanks Greg and others for the feedback!
>
> Please find attached the patch for implementing \dN (including \dNt, \dNi,
> \dNit).
I don't care particularly about the choice of letter, but I think this
is the wrong way round. It should be \dtN instead of \dNt.
Is the form \dN a
Re: Robert Haas
> I think that would be better than what we have now, but I still wonder
> if we should give some kind of a hint that an external process may be
> doing something to that file. Jakub and I may be biased by having just
> seen a case of exactly that in the field, but I wonder now how
Re: Peter Eisentraut
> Moreover, if there are zero-based months, why not zero-based days,
> or any of the other fields?
I would suspect this is coming from C's struct tm where tm_mon is
0..11 and all other fields being "normal". Used by asctime(), gmtime()
and friends.
Christoph
Re: Álvaro Herrera
> Introduce squashing of constant lists in query jumbling
>
> pg_stat_statements produces multiple entries for queries like
> SELECT something FROM table WHERE col IN (1, 2, 3, ...)
>
> depending on the number of parameters, because every element of
> ArrayExpr is individua
Re: Michael Paquier
> Attached is the second one, with more tests coverage with attribute
> aliases (these being ignored exists in stable branches, but why not
> while on it) and table aliases, and the fixes for the issues pointed
> out by Christoph. I'll double-check all that again tomorrow. Plea
Re: Michael Paquier
> So your idea to use the relation name in eref while skipping the
> column list looks kind of promising. Per se the attached. Thoughts?
Makes sense to me, thanks for digging into it.
> +++ b/src/backend/nodes/queryjumblefuncs.c
> @@ -33,6 +33,7 @@
> #include "postgres.h"
>
Re: To Michael Paquier
> > >> +#define JUMBLE_CUSTOM(nodetype, item) \
> > >> +_jumble##nodetype##_##item(jstate, expr, expr->item)
> >
> > In this one, I want to mean that we require a custom per-field
> > function to look like that:
> > _jumbleNodefoo_field(JumbleState *jstate, NodeFoo *
Re: Michael Paquier
> >> + * Note that the argument types are enforced for the per-field custom
> >> + * functions.
> >> + */
> >> +#define JUMBLE_CUSTOM(nodetype, item) \
> >> + _jumble##nodetype##_##item(jstate, expr, expr->item)
>
> In this one, I want to mean that we require a custom per-fiel
Re: Michael Paquier
> I have been thinking about this patch for a couple of days. What
> makes me unhappy in this proposal is that RangeTblEntry is a large and
> complicated Node, and we only want to force a custom computation for
> the "relid" portion of the node, while being able to also take so
just snakeoil :D.
Now there are proper ones, thanks.
Christoph
>From 725b6c65160a44678b2c43b4af0a3dc9c281830d Mon Sep 17 00:00:00 2001
From: Christoph Berg
Date: Mon, 17 Mar 2025 17:17:17 +0100
Subject: [PATCH v3] Jumble temp tables by name
Query jumbling considers everything by OID, which is
Re: Peter Eisentraut
> Committed that, thanks.
Awesome, thanks!
It works perfectly for the Debian "test extension packages at build
time" use case, replacing our old extension_destdir patch.
PKGARGS="--pgoption
extension_control_path=$PWD/debian/$PACKAGE/usr/share/postgresql/$v/extension:\$syst
ry why we are using a
> custom function.
I added a short comment just above custom_query_jumble.
Christoph
>From 70a80f9abd781f8114563ae8fc69e64123f12eeb Mon Sep 17 00:00:00 2001
From: Christoph Berg
Date: Mon, 17 Mar 2025 17:17:17 +0100
Subject: [PATCH v2] Jumble temp tables by name
Query jum
bench -S on temp tables where each table has just one record:
without patch: tps = 184430.801954 (without initial connection time)
with patch: tps = 185692.602764 (without initial connection time)
Christoph
>From c50dbb614f5e7696cb687aa156eb4149dcdb231d Mon Sep 17 00:00:00 2001
From:
Re: Thomas Munro
> > Hmm. Is looping on EINTR worth the trouble?
>
> I was just wondering if it might be one of those oddballs that ignores
> SA_RESTART, but I guess that doesn't seem too likely (I mean, first
> you'd probably have to have a reason to sleep or some other special
> reason, and who
Re: Aleksander Alekseev
> 1) Provide a tool written in C that allows changing pg_control, e.g.
> `pg_writecontoldata` or maybe a flat like `pg_controldata -w`.
I thought we already had pg_resetwal for that.
Christoph
showing -1, doesn't that mean
(-1 is translated to NULL for the SQL level.)
> we'll have to ask them to trace the system calls to figure out why, or
> if it's Windows, likely abandon all hope of ever knowing why? Should
> statvfs() retry on EINTR?
Hmm. Is looping on EINTR
nd on
this.
Christoph
>From df4ce715ff91bf095de94ee374fff0ebe9c1d4de Mon Sep 17 00:00:00 2001
From: Christoph Berg
Date: Fri, 14 Mar 2025 16:29:19 +0100
Subject: [PATCH] Add pg_tablespace_avail() functions
This exposes the f_avail value from statvfs() on tablespace directories
on the SQL level, allowing mo
Re: Aleksander Alekseev
> Do you think pg_resetwall should be able to do more than it currently
> does, or merely pointing out that we already have a tool for editing
> pg_control file?
I don't know if being able to mess with these fields makes sense, but
if so, pg_resetwal seems like the correct
systems need statfs() vs statvfs()
Christoph
>From 455640e375e7142d4bef2e4f47f678e3712a5a27 Mon Sep 17 00:00:00 2001
From: Christoph Berg
Date: Fri, 8 Nov 2019 14:12:35 +0100
Subject: [PATCH] Add pg_tablespace_avail() functions
This exposes the f_avail value from statvfs() on tablespace
Re: To PostgreSQL Hackers
> ... and the file is just fine. The blame is now on the kernel side for
> any machine-level problems. (The kernel on the porter box where I
> tried to reproduce the problem is much older than on the actual
> buildds. A new version that hopefully fixes the problem is being
Re: To PostgreSQL Hackers
> I cannot reproduce the problem on the Debian mipsel porter box, and
> the (working) test does not leave the base.tar.zst mentioned about
> behind.
Since I don't have access to the machine where it is failing, I
uploaded a new version that base64-encodes the "bad" base.t
I uploaded 15.12 to Debian bookworm (stable), but the mipsel (only
that) build is consistently failing, while 15.11 was working there
just two weeks earlier. No commit between 15.11 and 15.12 looks
remotely related, and zstd in bookworm did not change.
https://buildd.debian.org/status/logs.php?pkg
Re: Andres Freund
> I think that'd be *really* helpful. Of course that does require somebody
> watching and raising an alarm...
>
> Do you have ongoing package builds for sid or such?
What I am doing anyway is to trigger the regression test of each
package once a month (randomly distributed over
Re: Andres Freund
> > What's missing in the PG regression tests to see that problem?
>
> Well, the expanded tests added as part of the fix would catch it, but I agree,
> it's a problem this wasn't caught beforehand.
Oh sorry, I was actually skimming the git log to see if there is a
test, but then
Re: Andres Freund
> > > The fprintf suggests that since 5dc1e42b4 PQescapeIdentifier ignores its
> > > len.
> >
> > Ugh, yes. Need something like the attached.
>
> I just pushed this fix, together with an expansion of test_escape.c. With the
> expanded test both uses of strlen() are detected.
It happened again:
News for the tz database
Release 2025a - 2025-01-15 10:47:24 -0800
Briefly:
...
Improve pre-1991 data for the Philippines.
SELECT make_timestamptz(1846, 12, 10, 0, 0, 0, 'Asia/Manila') AT TIME ZONE
'UTC';
timezone
--
- Wed Dec 09
Bernd and I have been chasing a bug that happens when all of the
following conditions are fulfilled:
* PG 15..18 (older PGs are ok)
* gcc 14.2 on Debian unstable/testing (older Debians and Ubuntus are ok)
* arm64 running on graviton (AWS EC2 c8g.2xlarge, ok on different arm64 host)
* -O2 (ok with
Re: Michael Paquier
> > Is our five-year insufficient?
>
> FWIW, I'm already on the side that five-year support is quite good and
> I'd side with not extending that, even argue about reducing it
> (anti-tomato armor is now on). Backporting patches across up to 7
> branches can be really tedious d
Re: To Thomas Munro
> It is (was?) weird. The PG13 build for bullseye on apt.pg.o worked
> normally, but when I built for bullseye-security (Debian LTS), I had
> to remove the patch that removed the 039_end_of_wal.pl file because
> you had changed the file. The build then failed and I put the
> rem
Re: Thomas Munro
> Also why only this branch, when they all have it? Reproducible or
> one-off? Do you have any more clues?
It is (was?) weird. The PG13 build for bullseye on apt.pg.o worked
normally, but when I built for bullseye-security (Debian LTS), I had
to remove the patch that removed the
Re: Noah Misch
> I'm no longer arguing against the undo, but I'm trying to explain the
> consequences rigorously.
I'll just have to explain what happened here to the Debian security
team who just released the 16.5 update. We can do 16.6 on top of that.
Christoph
Re: Noah Misch
> I'm hearing the only confirmed impact on non-assert builds is the need to
> recompile timescaledb. (It's unknown whether recompiling will suffice for
> timescaledb. For assert builds, six PGXN extensions need recompilation.)
Which 6 extensions are these?
I re-ran the tests on a
Re: Noah Misch
> The non-asserts build passed. The asserts build failed with "+WARNING:
> problem in alloc set ExecutorState: detected write past chunk" throughout the
> diffs, but there were no crashes. (Note that AGE "make installcheck" creates
> a temporary installation, unlike PostgreSQL "mak
Re: Noah Misch
> Based on a grep of PGXN code, here are some or all of the modules that react
> to sizeof(ResultRelInfo):
>
> $ grepx -r 'lloc.*ResultRelInfo' | tee /tmp/1 | sed 's/-[^:]*/:/'|sort -u
> apacheage::resultRelInfo = palloc(sizeof(ResultRelInfo));
Confirmed, crashing: AGE for 14..
Re: Thomas Munro
> Pushed. Thanks!
Well...
postgresql 13.17, Debian bullseye, amd64:
t/039_end_of_wal.pl .. Dubious, test returned 2 (wstat 512,
0x200)
No subtests run
Test Summary Report
---
t/039_end_of_wal.pl(Wstat: 512 Tests: 0 Failed: 0)
Re: Tristan Partin
> This would need some massaging, and has various caveats like require using a
> well-known build system like PGXS or meson. There are probably security
> implications that need to be worked through. The packaging team could maybe
> have some burden lifted off their shoulders.
S
Re: Paul Ramsey
> Thanks for this, David,
>
> > On Oct 28, 2024, at 3:19 PM, David E. Wheeler wrote:
> >
> > ## Challenge: Third Party Dependencies
>
> This of course is the area that worries the heck out of me, as someone with
> extensions that includes not just single system dependencies but
All,
The PostgreSQL Contributor Page
(https://www.postgresql.org/community/contributors/) includes people who have
made substantial, long-term contributions of time and effort to the PostgreSQL
project. The PostgreSQL Contributors Team recognizes the following people for
their contributions.
New
Christoph
>From f4315196cd651e092e21ba283034e54d6fde Mon Sep 17 00:00:00 2001
From: Christoph Berg
Date: Tue, 1 Oct 2024 23:36:22 +0200
Subject: [PATCH] pg_waldump.sgml: Put underscore in front of FORK
Instead of including the leading underscore in the FORK name, put the
underscore into the file name format definitio
Re: Tom Lane
> Perhaps. I spent a little more effort on this and added code to
> report errors that don't come with an error location. On those,
> we don't have any constraints about what to report in the QUERY
> field, so I made it trim the string to just the current query
> within the script, w
Re: Tom Lane
> So the first part of that is great, but if your script file is
> large you probably won't be happy about having the whole thing
> repeated in the "QUERY" field. So this needs some work on
> user-friendliness.
Does this really have to be addressed? It would be way better than it
is
Re: Michael Banck
> I guess there's no way to make that error a bit more helpful, like
> printing out the offenbding SQL command, presumably because we are
> loding an extension?
I wish there was. The error reporting from failing extension scripts
is really bad with no context at all, it has hit m
Re: Tom Lane
> Improve default and empty privilege outputs in psql.
I'm sorry to report this when 17.0 has already been wrapped, but this
change is breaking `psql -l` against 9.3-or-earlier servers:
$ /usr/lib/postgresql/17/bin/psql
psql (17rc1 (Debian 17~rc1-1.pgdg+2), Server 9.3.25)
Geben Sie »
Re: To Tom Lane
> Let's keep it like it is now in PG17.
Late followup news: This feature has actually found a bug in
postgresql-debversion:
CREATE OPERATOR > (
LEFTARG = debversion,
RIGHTARG = debversion,
COMMUTATOR = <,
- NEGATOR = >=,
+ NEGATOR = <=,
RESTRICT = scalargtsel,
JO
Re: Jakub Wartak
> 1. dev/testing DBs: where frankly speaking nobody cares about such DBs
> until they stop/crash; this also includes DBs from new users on dev
> laptops too
> 2. production systems: where it matters to have log_lock_waits=on (and
> people may start getting nervous if they don't hav
Re: Tom Lane
> I fear that #2 is actually a pretty serious concern. I think there
> are a lot of places where we've assumed semi-implicitly that
> compilation file boundaries are optimization barriers, particularly
> around stuff like LWLocks and semaphores. I don't really want to
> spend time ch
Re: Robert Haas
> I've definitely seen systems where this setting would have generated
> regular output, because I see a lot of systems that are chronically
> overloaded.
I'd argue this is exactly what I mean by "this system has a problem".
Telling the user about that makes sense.
> cautious abou
Re: Laurenz Albe
> The major criticism is Tom's that it might unduly increase the log volume.
>
> I'm not trying to rush things, but I see little point in kicking a trivial
> patch like this through many commitfests. If no committer wants to step
> up and commit this, it should be rejected.
That
1 - 100 of 452 matches
Mail list logo
