Re: Jacob Champion
> On Tue, Aug 5, 2025 at 2:39 AM Jelte Fennema-Nio wrote:
> > On Tue, 5 Aug 2025 at 01:20, Jacob Champion
> > wrote:
> > > So, as we approach Beta 3: can anyone think of a way that this plan will
> > > fail?
> >
> > It's not entirely clear what plan exactly you talk about here
Re: Andrew Dunstan
> That file was deleted by the revert. Maybe you have a cache problem?
Oh right. This was caused by our snapshot builds using the latest
tarball (if available) and putting a patch on top that. I've now
bumped the upstream version to 18~beta3, this should avoid the
problem.
Sorr
The 18 branch is broken for apt.pg.o:
00:54:18 # Failed test 'dump_globals_only: pg_dumpall runs'
00:54:18 # at t/006_pg_dumpall.pl line 329.
00:54:18 # Tests were run but no plan was declared and done_testing() was not
seen.
00:54:18 # Looks like your test exited with 2 just after 1.
00:54:1
Re: Tomas Vondra
> >>> Submitted: https://marc.info/?l=linux-mm&m=175077821909222&w=2
> >>>
> >>
> >> Thanks! Now we wait ...
> >
> > It looks like that the bug is "confirmed" and that it will be fixed:
> > https://marc.info/?l=linux-kernel&m=175088392116841&w=2
If I'm reading the Linux git log c
Re: Nathan Bossart
> Here is what I have staged for commit, which I'm planning to do on Friday.
> diff --git a/doc/src/sgml/ref/pg_basebackup.sgml
> b/doc/src/sgml/ref/pg_basebackup.sgml
> index 9659f76042c..9be752fc12b 100644
> --- a/doc/src/sgml/ref/pg_basebackup.sgml
> +++ b/doc/src/sgml/ref/p
Re: Bertrand Drouvot
> +/*
> + * Work around Linux kernel bug in 32-bit compat mode: do_pages_stat() has
> + * incorrect pointer arithmetic for more than DO_PAGES_STAT_CHUNK_NR pages.
> + */
> +#if SIZEOF_SIZE_T == 4
I was also missing it in my suggested patch draft, but this should
probably inclu
Re: Bertrand Drouvot
> Yes, something like:
>
> diff --git a/src/backend/storage/ipc/shmem.c b/src/backend/storage/ipc/shmem.c
> index c9ae3b45b76..070ad2f13e7 100644
> --- a/src/backend/storage/ipc/shmem.c
> +++ b/src/backend/storage/ipc/shmem.c
> @@ -689,8 +689,17 @@ pg_get_shmem_allocations_num
Re: Bertrand Drouvot
> Yes, I think compat_uptr_t usage is missing in do_pages_stat() (while it's
> used
> in do_pages_move()).
I was also reading the kernel source around that place but you spotted
the problem before me. This patch resolves the issue here:
diff --git a/mm/migrate.c b/mm/migrate
Re: Tomas Vondra
> If it's a reliable fix, then I guess we can do it like this. But won't
> that be a performance penalty on everyone? Or does the system split the
> array into 16-element chunks anyway, so this makes no difference?
There's still the overhead of the syscall itself. But no idea how
Re: Tomas Vondra
> True. If it fails on first call, but succeeds on the other, then the
> problem is likely somewhere else. But also on the second call we won't
> do the memory touching. Can you try setting firstNumaTouch=false, so
> that we do this on every call?
firstNumaTouch=false, it still fa
Re: Tomas Vondra
> Huh. So it's only the first call that does this?
The first call after a restart. Reconnecting is not enough.
> Can you maybe print the addresses passed to pg_numa_query_pages? I
The addresses look good:
Breakpoint 1, pg_numa_query_pages (pid=0, count=32768, pages=0xeb44d02c,
Re: Tomas Vondra
> Didn't you say the first ~35 addresses succeed, right? What about the
> addresses after that?
That was pg_shmem_allocations_numa. The pg_numa_query_pages() in there
works (does not return -1), but then some of the status[] values are
-14.
When pg_buffercache_numa fails, pg_numa
Re: Andres Freund
> How confident are we that this isn't actually because we passed a bogus
> address to the kernel or such? With this patch, are *any* pages recognized as
> valid on the machines that triggered the error?
See upthread - the first 35 pages were ok, then a lot of -14.
> I wonder if
Re: To Andres Freund
> Ok, so we leave the touching in, but still defend against negative
> status values?
v2 attached.
Christoph
>From f05e0f4503b920cd9f136f57dc9707a47786a69c Mon Sep 17 00:00:00 2001
From: Christoph Berg
Date: Mon, 23 Jun 2025 17:50:41 +0200
Subject: [PATCH v
Re: Andres Freund
> > > Why do we try to force the pages to be allocated at all? This is just
> > > a monitoring function, it should not change the actual system state.
>
> The problem is that the kernel function just gives bogus results for pages
> that *are* present in memory but that have only
Re: To Tomas Vondra
> Why do we try to force the pages to be allocated at all? This is just
> a monitoring function, it should not change the actual system state.
One-time touching might also not be enough, what if the pages later
get swapped out and the monitoring functions are called again? They
gic. Regression tests pass, but we
probably have to think about whether to report these negative numbers
as-is or perhaps convert them to NULL.
Christoph
>From 189b70a625169687335606019f8d01aeb9a7e9fe Mon Sep 17 00:00:00 2001
From: Christoph Berg
Date: Mon, 23 Jun 2025 16:37:17
Re: Tom Lane
> I checked Debian and SUSE and noted that their "extended support"
> windows are a lot shorter than RHEL's, just two or three years.
> So maybe we shouldn't buy into RHEL's five-year window.
Fwiw, what we are doing for apt.postgresql.org and Debian is to
support LTS which extends Deb
Re: Tom Lane
> Yeah, seems quite bogus. It's harmless though, so I don't
> see a need to back-patch, do you?
Other than it being confusing, it doesn't hurt.
Christoph
t's probably safe
to just delete the rule.
Christoph
>From f8393e2308d7f91e15fc412848dd70157a68e29a Mon Sep 17 00:00:00 2001
From: Christoph Berg
Date: Fri, 20 Jun 2025 14:12:38 +0200
Subject: [PATCH] pgxs.mk: Remove bogus PORTNAME=win rule
PORTNAME should be win32, but the file we are cl
Re: Nathan Bossart
> I broke this up into several small patches. Notable changes are as
> follows:
>
> * Adjusted to the tab completion code to work more like the VACUUM utility
> options.
>
> * Introduced a new ExecCheckpoint() function in checkpointer.c and moved
> the privilege check and
ead checkpoint to run fast.
Christoph
>From 19062d3739b3217781631dd78ed6ad0ed0df3bc5 Mon Sep 17 00:00:00 2001
From: Christoph Berg
Date: Wed, 11 Jun 2025 16:32:23 +0200
Subject: [PATCH v6 1/2] Rename checkpoint options "immediate" and "flush-all"
There were two names in use for fast checkpoints
ation by someone
more knowledgeable in this area.
> I find this somewhat confusing; how about
> How about:
Taken unmodified, thanks!
Christoph
>From 19062d3739b3217781631dd78ed6ad0ed0df3bc5 Mon Sep 17 00:00:00 2001
From: Christoph Berg
Date: Wed, 11 Jun 2025 16:32:23 +0200
Subject: [PATCH v5
Re: Tomas Vondra
> Introduce pg_shmem_allocations_numa view
This is acting up on Debian's 32-bit architectures, namely i386, armel
and armhf:
---
/build/reproducible-path/postgresql-18-18~beta1+20250612/src/test/regress/expected/numa.out
2025-06-12 12:21:21.0 +
+++
/build/reproduci
t to decide
that without more votes in either direction.
Christoph
>From d3194009b9c27c5741695b8149d00ffc56ff7f8c Mon Sep 17 00:00:00 2001
From: Christoph Berg
Date: Wed, 11 Jun 2025 16:32:23 +0200
Subject: [PATCH v4 1/2] Rename checkpoint options "immediate" and "flush-
Re: Nathan Bossart
> That seems like a good idea to me. I'm tempted to say that "fast" more
> accurately describes what's happening than "immediate." "Immediate" sounds
> like it happens instantaneously, but it's actually just happening "fast,"
> i.e., as fast as possible.
Ack.
> > #define CHEC
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
1 - 100 of 478 matches
Mail list logo
