Hi,
Thank you for your patch. It is really useful for tracking the history
of generic and custom plan usage.
At first glance, I have the following suggestions for improvement:
1. Is there any reason for the double check of cplan != NULL? It seems
unnecessary, and we could simplify it to:
-
On Wed, Mar 5, 2025 at 3:10 PM Tom Lane wrote:
>
> Bertrand Drouvot writes:
> > yeah makes sense. Done in the attached, and bonus point I realized that the
> > test could be simplified (so, removing useless steps in passing).
>
> Just a side note: tayra showed two instances of this failure today
On Wed, 2025-03-05 at 15:22 +0530, Ashutosh Bapat wrote:
> Hmm. Updating the statistics without consuming more CPU is more
> valuable when autovacuum is off it improves query plans with no extra
> efforts. But if adding a new mode is some significant work, riding it
> on top of autovacuum=off might
> On 6 Mar 2025, at 2:10 AM, Ian Lawrence Barwick wrote:
>
> Hi
>
> 2025年3月1日(土) 2:58 Florents Tselai :
>> Please add this to the next Commitfest at
>> https://commitfest.postgresql.org/52/
>>
>>
>> Added ; thanks
>> https://commitfest.postgresql.org/patch/5260/
>
> I see this was committ
On 5/3/2025 19:50, Aleksander Alekseev wrote:
Andrei, Matthias,
Could you explain why you think the Pluggable TOASTer proposal was similar?
[...]
I merely pointed out that adding hooks without any particular value
for the Postgres users was criticized before, see for instance:
Thank you for y
On Tue, Mar 04, 2025 at 05:50:34PM -0500, Andres Freund wrote:
> On 2024-12-09 00:12:32 +0100, Tomas Vondra wrote:
> > [23:48:44.444](1.129s) ok 3 - reserved_connections limit
> > [23:48:44.445](0.001s) ok 4 - reserved_connections limit: matches
> > process ended prematurely at
> > /home/user/work/
Hi Robert,
Thanks for the review comments.
On Thu, Mar 6, 2025 at 2:10 AM Robert Haas wrote:
>
> On Wed, Mar 5, 2025 at 3:13 PM Nathan Bossart
> wrote:
> > * The patch alleges to only block DROP ROLE commands when there exists
> > _both_ admins of the target role and roles for which the targ
Thanks, Nathan, for reviewing the patch. Below are my comments inline:
On Thu, Mar 6, 2025 at 1:43 AM Nathan Bossart wrote:
>
>
> * The patch alleges to only block DROP ROLE commands when there exists
> _both_ admins of the target role and roles for which the target role is
> an admin. Howev
On Wed, Mar 05, 2025 at 03:25:12PM +0100, Daniel Verite wrote:
> Anthonin Bonnefoy wrote:
>> I do see the idea to make it easier to convert existing scripts into
>> using pipelining. The main focus of the initial implementation was
>> more on protocol regression tests with psql, so that's not
On Wed, Mar 05, 2025 at 08:55:55PM -0500, Andres Freund wrote:
> Once we've slept for 10+ seconds without reaching the target, sleeping for
> 100us is way too short a sleep and just wastes CPU cycles. A decent portion
> of the CPU time when running under valgrind is wasted just due to way too
> tig
Hi,
I prepared a patch that will allow us to set arbitrary values in -m and -x
options for pg_resetwal. For now, it is not possible to specify a value
that does not fit into existing SLRU segments, and
main idea of this patch (for REL_17_STABLE) is to create such segments
inside pg_resetwal's main(
Hi Shubham.
Some review comments for patch v13-0001.
==
GENERAL
1.
--cleanup-existing-publications
I've never liked this proposed switch name much.
e.g. why say "cleanup" instead of "drop"? What is the difference?
Saying drop is very explicit about what the switch will do.
e.g. why say "ex
On Fri, Feb 28, 2025 at 11:34 PM Shubham Khanna
wrote:
>
>
> The attached Patch contains the suggested changes.
>
> Thanks and regards,
> Shubham Khanna.
Some comments:
1.
+
+ -a
+ --all
+
+
+ For all source server non-template databases create subscriptions for
+
Hi,
On 2025-03-05 22:00:42 -0500, Corey Huinker wrote:
> On Wed, Mar 5, 2025 at 9:18 PM Andres Freund wrote:
> > On 2025-03-05 20:54:35 -0500, Corey Huinker wrote:
> > > It's been considered and not ruled out, with a "let's see how the simple
> > > thing works, first" approach. Considerations are
On Wed, Mar 5, 2025 at 9:18 PM Andres Freund wrote:
> Hi,
>
> On 2025-03-05 20:54:35 -0500, Corey Huinker wrote:
> > It's been considered and not ruled out, with a "let's see how the simple
> > thing works, first" approach. Considerations are:
> >
> > * pg_stats is keyed on schemaname + tablename
On Tue, Mar 04, 2025 at 10:18:49AM -0500, Tom Lane wrote:
>
> But yeah, I thought we were overdue for a buildfarm release.
> I'm pleased to see that Andrew just pushed one.
FWIW I installed the client version 19.1 this morning and forced a run on HEAD
and lapwing is back to green.
hi.
rearrange the patch.
v3-0001 and v3-0002 is preparare patches.
v3-0001 add function: ExecPrepareExprSafe and ExecInitExprSafe.
v3-0002 add function: DomainHaveVolatileConstraints
v3-0003 tests and apply fast default for domain with constraints.
v3-0003 table with empty rows aligned with mast
On Wed, Mar 05, 2025 at 08:54:35PM -0500, Corey Huinker wrote:
> * The stats data is kinda heavy (most common value lists, most common
> elements lists, esp for high stattargets), which would be a considerable
> memory impact and some of those stats might not even be needed (example,
> index stats
On 2025/03/05 9:33, Euler Taveira wrote:
> + Valid BACKENDTYPE values are
ARCHIVER,
> + AUTOVACUUM, BACKEND,
> + BGWORKER, BGWRITER,
> + CHECKPOINTER, LOGGER,
> + SLOTSYNCWORKER, WALRECEIVER,
> + WALSENDER, WALSUMMARIZER, and
> + WALWRITER.
W
On Wed, Mar 05, 2025 at 03:34:06PM -0800, Jeff Davis wrote:
> On Wed, 2025-03-05 at 14:33 -0600, Nathan Bossart wrote:
>> + report_status(PG_WARNING, "warning");
>> + pg_log(PG_WARNING, "Your installation contains
>> relations that may be affected by a new version of Uni
On Wed, Mar 05, 2025 at 03:40:52PM -0500, Greg Sabino Mullane wrote:
> I've seen various failures, but they always get caught quite early.
> Certainly early enough to easily abort, fix perms/mounts/etc., then retry.
> I think your instinct is correct that this reversion is more trouble than
> its w
Hi,
On 2025-03-05 20:54:35 -0500, Corey Huinker wrote:
> It's been considered and not ruled out, with a "let's see how the simple
> thing works, first" approach. Considerations are:
>
> * pg_stats is keyed on schemaname + tablename (which can also be indexes)
> and we need to use that because of t
Hi,
On 2025-03-05 16:19:04 -0800, Jacob Champion wrote:
> On Wed, Mar 5, 2025 at 9:28 AM Andres Freund wrote:
> > Unrelated to the change in this patch, but tests really shouldn't use
> > while(1)
> > loops without a termination condition. If something is wrong, the test will
> > hang indefinite
>
> Apologies if this has already been considered upthread, but would it be
> possible to use one query to gather all the required information into a
> sorted table? At a glance, it looks to me like it might be feasible. I
> had a lot of luck with reducing the number per-object queries with that
On Wed, Mar 05, 2025 at 08:17:53PM -0500, Andres Freund wrote:
> Right now --statistics more than doubles the number of queries that pg_dump
> issues. That's oviously noticeable locally, but it's going to be really
> noticeable when dumping across the network.
>
> I think we need to do more to les
>
> One fairly easy win would be to stop issuing getAttributeStats() for
> non-expression indexes. In most cases that'll already drastically cut down
> on
> the extra queries.
That does seem like an easy win, especially since we're already using
indexprs for some filters. I am concerned that, dow
On Wednesday, March 5, 2025, Shay Rojansky wrote:
>
>>> SELECT JSON_VALUE(jsonb '"AQID"', '$' RETURNING bytea); -- Expected
>>> 0x010203, got AQID
>>>
>>
>> I get \x41514944 which is precisely what I would expect since it what
>> this query results in as well:
>>
>> select 'AQID'::bytea;
>>
>
> I
Hi,
On 2025-02-25 21:29:56 -0500, Corey Huinker wrote:
> On Tue, Feb 25, 2025 at 9:00 PM Jeff Davis wrote:
>
> > On Mon, 2025-02-24 at 09:54 -0500, Andres Freund wrote:
> > > Have you compared performance of with/without stats after these
> > > optimizations?
> >
> > On unoptimized build with ass
>
> Please see v2
>
oops, had to fix a typo in meson.build. Please see v3.
--
Sami
v3-0001-add-plan_cache-counters-to-pg_stat_statements.patch
Description: Binary data
On Wed, Mar 05, 2025 at 08:04:44AM +, Bertrand Drouvot wrote:
> On Wed, Mar 05, 2025 at 12:35:26PM +0900, Michael Paquier wrote:
>> Perhaps there's a point in backpatching a portion of what's in the
>> attached patch (the wait event?), but I am not planning to bother much
>> with the stable bra
>
>
>> SELECT JSON_VALUE(jsonb '"AQID"', '$' RETURNING bytea); -- Expected
>> 0x010203, got AQID
>>
>
> I get \x41514944 which is precisely what I would expect since it what this
> query results in as well:
>
> select 'AQID'::bytea;
>
If the behavior of RETURNING is meant to be identical to that o
It looks like your bytea_output is set to 'escape', which would explain
what you are seeing. Try adding this in first:
SET bytea_output = hex;
SELECT JSON_VALUE(jsonb '"AQID"', '$' RETURNING bytea);
That (hex) is the default value, so you must be setting it to escape
somewhere. You can see where
Thanks for the review!
> I could see EXPLAIN being somewhat useful (especially for non-interactive
> things like auto_explain), so a weak +1 on that.
I'll make this a follow-up to this patch.
> Definitely not useful for pg_stat_database IMHO.
agree as well. I did not have strong feelings about
On Wednesday, March 5, 2025, Shay Rojansky wrote:
>
> SELECT JSON_VALUE(jsonb '"AQID"', '$' RETURNING bytea); -- Expected
> 0x010203, got AQID
>
I get \x41514944 which is precisely what I would expect since it what this
query results in as well:
select 'AQID'::bytea;
David J.
Greetings hackers,
The de-facto standard for storing binary data in JSON documents seems to be
base64-encoded strings, so I was expecting JSON_VALUE's RETURNING bytea to
do base64 decoding. However, that does not seem to be the case:
SELECT decode('AQID', 'base64'); -- 0x010203
SELECT JSON_VALUE(
On Wed, Mar 5, 2025 at 9:28 AM Andres Freund wrote:
> Unrelated to the change in this patch, but tests really shouldn't use while(1)
> loops without a termination condition. If something is wrong, the test will
> hang indefinitely, instead of timing out. On the buildfarm that can take out
> an an
Hi
2025年3月1日(土) 2:58 Florents Tselai :
> Please add this to the next Commitfest at
> https://commitfest.postgresql.org/52/
>
>
> Added ; thanks
> https://commitfest.postgresql.org/patch/5260/
I see this was committed, but there's a small formatting error in the docs
(extra comma in the paramete
On 2025/03/01 3:21, Nathan Bossart wrote:
On Thu, Feb 27, 2025 at 08:29:16PM -0800, Gurjeet Singh wrote:
On Mon, Jan 27, 2025 at 1:55 AM Laurenz Albe wrote:
I hope it is possible to override the global setting with the "vacuum_truncate"
option on an individual table.
Current patch behavio
On Wed, Mar 5, 2025 at 10:46 AM Melanie Plageman
wrote:
>
> As such, I wonder if my PGC_SET idea is not worth the effort and I
> should revise the earlier patch version which specified the stages but
> allow for on, off, true, yes, 1 for backwards compatibility and not
> include disconnections (so
On Wed, 5 Mar 2025 at 18:21, Burd, Greg wrote:
>
> Hello,
>
> I've rebased and updated the patch a bit. The biggest change is that the
> performance penalty measured with v1 of this patch is essentially gone in
> v10. The overhead was due to re-creating IndexInfo information
> unnecessarily,
On Wed, 2025-03-05 at 14:33 -0600, Nathan Bossart wrote:
> + report_status(PG_WARNING, "warning");
> + pg_log(PG_WARNING, "Your installation contains
> relations that may be affected by a new version of Unicode.\n"
> + "A list of potentially-affe
On 05/03/2025 21:25, Andres Freund wrote:
On 2025-02-28 22:24:56 +0200, Heikki Linnakangas wrote:
The second patch makes it possible to use ModifyWaitEvent() to switch
between WL_POSTMASTER_DEATH and WL_EXIT_ON_PM_DEATH. WaitLatch() used to
modify WaitEventSet->exit_on_postmaster_death directly,
On 2025/03/05 9:32, Fujii Masao wrote:
On 2025/03/05 7:26, Jacob Champion wrote:
On Mon, Mar 3, 2025 at 10:02 PM Fujii Masao wrote:
I've pushed the patch. Thanks!
Hi all,
+tests += {
+ 'name': 'ecpg',
+ 'sd': meson.current_source_dir(),
+ 'bd': meson.current_build_dir(),
+ 'tap':
On Wed, 2025-03-05 at 14:12 -0500, Tom Lane wrote:
> I'm afraid not. That pretty fundamentally breaks the wire protocol,
> I think.
The extended protocol docs say: "The possible responses to Execute are
the same as those described above for queries issued via simple query
protocol, except that Ex
Bertrand Drouvot writes:
> yeah makes sense. Done in the attached, and bonus point I realized that the
> test could be simplified (so, removing useless steps in passing).
Just a side note: tayra showed two instances of this failure today
[1][2]. That's not using valgrind. I wonder if we changed
Hi,
Sorry for the delay. This is a reply for the mail thread up to 17 Feb,
so it might be very out-of-date by now, in which case sorry for the
noise.
On Mon, 17 Feb 2025 at 20:54, Burd, Greg wrote:
> On Feb 15, 2025, at 5:49 AM, Matthias van de Meent
> wrote:
> >
> > In HEAD, we have a clear i
On 2025/3/4 23:57, Trey Boudreau wrote:
On Mar 3, 2025, at 10:39 PM, Quan Zongliang
wrote:
I implemented a LISTEN command that supports matching names in the
LIKE format.
Just like
LISTEN 'c%';
NOTIFY c1;NOTIFY c2;
Notifications are received for c1 and c2.
The parser down-cases Col
On 2025/3/6 00:42, Tom Lane wrote:
Aleksander Alekseev writes:
For instance, if I do:
```
LISTEN aaafoo;
LISTEN aaabar;
UNLISTEN aaa%;
```
Should I:
A. be unsubscribed from aaafoo and aaabar since both match aaa% or
B. UNLISTEN should have no effect since I never subscribed to aaa%
Robert Haas writes:
> On Wed, Mar 5, 2025 at 4:00 PM Tom Lane wrote:
>> Got it. So does that mean we can remove any #include's from explain.h
>> after moving the struct definition?
> Good question. It looks like "lib/stringinfo.h" can come out but the
> other two are still needed, so there is n
Hi,
Some time recently valgrind suppressions in the older backbranches stopped
fully working. E.g.
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2025-03-04%2022%3A31%3A25
failed on 14, with:
2025-03-04 22:33:13.359 UTC [3534679][postmaster][:0] LOG: database system is
ready
Hi,
On 2025-03-05 13:03:07 +, Bertrand Drouvot wrote:
> But yeah, if 0002 in [1] does not go in, then your concern is valid, so adding
> the extra check in the attached.
This crashes in cfbot:
https://cirrus-ci.com/task/5111872610893824
[13:42:37.315] src/tools/ci/cores_backtrace.sh freebsd
> On 5 Mar 2025, at 21:33, Andres Freund wrote:
>
> Hi,
>
> On 2025-03-05 21:27:45 +0100, Daniel Gustafsson wrote:
>> Following a119426 in the pg-vm-images repo [0] which installed libcurl in the
>> CI images we can now remove the installation commands from our Cirrus tasks.
>>
>> The attached
Hi,
On 2025-03-05 12:15:57 -0800, Jeff Davis wrote:
> On Wed, 2025-03-05 at 11:33 -0800, James Hunter wrote:
> > For a bitfield, however, the CPU has to read from or write to the
> > byte
> > that contains the bit, but then it also has to mask out the *other*
> > bits in that bitfield. This is a d
On Wed, Mar 5, 2025 at 4:00 PM Tom Lane wrote:
> Ah. I was mistakenly assuming that 0001 would compile on its own ;-)
Oopsie.
> Got it. So does that mean we can remove any #include's from explain.h
> after moving the struct definition?
Good question. It looks like "lib/stringinfo.h" can come
On Wed, Mar 5, 2025 at 12:16 PM Jeff Davis wrote:
>
> On Wed, 2025-03-05 at 11:33 -0800, James Hunter wrote:
> > For a bitfield, however, the CPU has to read from or write to the
> > byte
> > that contains the bit, but then it also has to mask out the *other*
> > bits in that bitfield. This is a d
Robert Haas writes:
> On Wed, Mar 5, 2025 at 1:53 PM Tom Lane wrote:
>> I'm quite confused by the #include additions in auto_explain.c and
>> file_fdw.c, and I strongly object to the ones in explain_state.h.
>> Surely those are unnecessary?
> They are necessary but they should have been part of
On Wed, Mar 5, 2025 at 2:43 PM Nathan Bossart
wrote:
> One other design point I wanted to bring up is whether we should bother
> generating a rollback script for the new "swap" mode. In short, I'm
> wondering if it would be unreasonable to say that, just for this mode, once
> pg_upgrade enters t
On Wed, Mar 5, 2025 at 3:13 PM Nathan Bossart wrote:
> * The patch alleges to only block DROP ROLE commands when there exists
> _both_ admins of the target role and roles for which the target role is
> an admin. However, it's not clear to me why both need to be true. I
> might be able to g
On Mon, Feb 17, 2025 at 11:46:43AM -0800, Jeff Davis wrote:
> Attached a version that rebases both patches. In my patch, I added a
> report_status().
I briefly looked at v2-0002, and the UpgradeTask usage looks correct to me.
Did you find it easy enough to use?
+ /*
+* The builtin p
Hi,
On 2025-03-05 21:27:45 +0100, Daniel Gustafsson wrote:
> Following a119426 in the pg-vm-images repo [0] which installed libcurl in the
> CI images we can now remove the installation commands from our Cirrus tasks.
>
> The attached is a trivial diff which restores the Cirrus task file to the
Overall I like the idea; adds some nice visibility to something that has
been very ephemeral in the past.
Not included in this patch and maybe for follow-up work, is this
> information a good idea also?
can be added to EXPLAIN output and perhaps pg_stat_database.
>
I could see EXPLAIN being some
Following a119426 in the pg-vm-images repo [0] which installed libcurl in the
CI images we can now remove the installation commands from our Cirrus tasks.
The attached is a trivial diff which restores the Cirrus task file to the state
it was in before OAuth was committed.
--
Daniel Gustafsson
[0
On Wed, 2025-03-05 at 11:33 -0800, James Hunter wrote:
> For a bitfield, however, the CPU has to read from or write to the
> byte
> that contains the bit, but then it also has to mask out the *other*
> bits in that bitfield. This is a data dependency, so it stalls the
> CPU
> pipeline.
Here the bi
On Tue, Feb 18, 2025 at 02:54:46PM +0530, Ashutosh Sharma wrote:
> Attached is a patch that checks for role dependencies when the DROP
> ROLE command is executed. If dependencies are found, the command is
> prevented from succeeding. Please review the attached patch and share
> your feedback. thank
On Wed, Mar 5, 2025 at 2:42 PM Nathan Bossart wrote:
> Of course, rollback would still be possible, but you'd really need to
> understand what "swap" mode does behind the scenes to do so safely. In any
> case, I'm growing skeptical that a probably-not-super-well-tested script
> that extremely few
On Wed, Mar 5, 2025 at 1:53 PM Tom Lane wrote:
> Here's some comments on 0001 and 0002; I didn't have time for
> 0003 today. But in any case, I think you should move forward
> with committing 0001/0002 soon so other people can play around
> in this space. 0003 can be left for later.
Cool. Thank
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
On Fri, Feb 28, 2025 at 02:51:27PM -0600, Nathan Bossart wrote:
> Cool. I appreciate the design feedback.
One other design point I wanted to bring up is whether we should bother
generating a rollback script for the new "swap" mode. In short, I'm
wondering if it would be unreasonable to say that,
On Wed, Mar 5, 2025 at 9:47 AM Israel Barth Rubio wrote:
> The v6 version of the patch contains the simple INSERT version, which
> adds only one tuple to the test_2 table, and is safer as your pointed
> out.
Cool. Here is v7, with minor changes. I rewrote the commit message,
renamed the test case
On Wed, Mar 5, 2025 at 10:40 AM Jeff Davis wrote:
>
> On Thu, 2025-03-06 at 01:07 +1300, David Rowley wrote:
> > I've attached the results. The 3990x with clang looks good, but the
> > rest are mostly slower.
>
> I am still curious why.
>
> If it's due to compiler misoptimization, is that kind of
On Thu, Sep 26, 2024 at 1:55 PM Alexander Korotkov
wrote:
> On Thu, Sep 26, 2024 at 12:04 AM Tom Lane wrote:
> > Florents Tselai writes:
> > > This patch is a follow-up and generalization to [0].
> > > It adds the following jsonpath methods: lower, upper, initcap,
> l/r/btrim,
> > > replace, s
>> What if we do something like a new EXPLAIN option which returns all
>> the rows
>> back to the client, and then writes out the plan to some local
>> memory.
> That's another idea, but I am starting to think returning two result
> sets from EXPLAIN ANALYZE would be generally useful.
I did not t
Hi,
On 2025-02-28 22:24:56 +0200, Heikki Linnakangas wrote:
> I noticed that the ShutdownLatchSupport() function is unused. The first
> patch removes it.
Looks like that's the case since
commit 80a8f95b3bca6a80672d1766c928cda34e979112
Author: Andres Freund
Date: 2021-08-13 05:49:26 -0700
Jeff Davis writes:
> Ideally, we'd have EXPLAIN ANALYZE return two result sets, kind of like
> how a query with a semicolon returns two result sets. That changes the
> expected message flow for EXPLAIN ANALYZE, though, so we'd need a new
> option so we are sure the client is expecting it (is this
On Wed, 2025-02-26 at 13:13 -0600, Sami Imseih wrote:
> 1/ The use of NOTICE to propagate the explain plan.
> I see the message content is checked, but this does not look robust
> and could lead to
> some strange results if another ExecutorRun hook emits a similar
> notice message.
Fundamentally,
Robert Haas writes:
> OK. It sounds to me like there is a good amount of support for going
> forward with something like what I have, even though some people might
> also like other things. What I feel is currently lacking is some
> review of the actual code. Would anyone like to do that?
Here's
On Fri, Feb 28, 2025 at 2:34 PM Tom Lane wrote:
>
> Sami Imseih writes:
> > However, I think any GUC that can influence the planner
> > should be considered for consistency in behavior.
> > It was mentioned above with the enable_* GUCs, but another
> > one I can think of is the max_parallel_worke
Andrei, Matthias,
> Could you explain why you think the Pluggable TOASTer proposal was similar?
> [...]
I merely pointed out that adding hooks without any particular value
for the Postgres users was criticized before, see for instance:
https://www.postgresql.org/message-id/20230206104917.sipa7nz
Hi,
Currently, there is little visibility for queries that are being executed
using generic or custom plans. There is pg_prepared_statements which
show generic_plans and custom_plans as of d05b172a760, but this
information is backend local and not very useful to a DBA that wishes
to track this inf
On Wed, Mar 5, 2025 at 1:34 PM Andres Freund wrote:
> Pushed both patches.
Thanks!
--
Peter Geoghegan
On Thu, 2025-03-06 at 01:07 +1300, David Rowley wrote:
> I've attached the results. The 3990x with clang looks good, but the
> rest are mostly slower.
I am still curious why.
If it's due to compiler misoptimization, is that kind of thing often
misoptimized, or is there something we're doing in pa
Hi,
On 2025-03-05 13:10:00 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2025-03-05 12:29:15 -0500, Tom Lane wrote:
> >> I think this does need to be documented somewhere/somehow, just so
> >> that people don't waste time focusing on "it's failing on FreeBSD"
> >> when the actual cause is
On 2025-Mar-05, Daniel Gustafsson wrote:
> I would avoid using Google for finding content on the wiki, the search
> function
> on the wiki itself is generally more reliable. Searching for FOSDEM 2025
> returns the following as the top result:
>
> https://wiki.postgresql.org/wiki/FOSDEM/PGDa
On Wed, 5 Mar 2025 at 10:04, Heikki Linnakangas wrote:
>
> On 28/02/2025 03:53, Peter Geoghegan wrote:
> > On Sat, Feb 8, 2025 at 8:47 AM Michail Nikolaev
> > wrote:
> >> Just some commit messages + few cleanups.
> >
> > I'm worried about this:
> >
> > +These longer pin lifetimes can cause buffer
On Wed, Mar 5, 2025 at 12:52 PM Jeff Davis wrote:
> It would be good to clarify whether this is for (a) experimenting with
> explain options that might be useful in core some day; or (b) special
> developer-only options that would never be useful in core; or (c)
> production-grade explain options
Andres Freund writes:
> On 2025-03-05 12:29:15 -0500, Tom Lane wrote:
>> I think this does need to be documented somewhere/somehow, just so
>> that people don't waste time focusing on "it's failing on FreeBSD"
>> when the actual cause is some other thing we happened to load
>> onto that task.
> 0
Hi,
On 2025-03-05 12:29:15 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I guess we could be add a "standardized" section at the top of each task
> > describing their oddities? Not sure it's worth it.
>
> I think this does need to be documented somewhere/somehow, just so
> that people don't
On Wed, Mar 5, 2025 at 12:20 PM Jeff Davis wrote:
> I didn't look into the technical details to see what might be required
> to allow that kind of collaboration, and I am not suggesting you
> redesign the entire feature around that idea.
OK. It sounds to me like there is a good amount of support
It would be good to clarify whether this is for (a) experimenting with
explain options that might be useful in core some day; or (b) special
developer-only options that would never be useful in core; or (c)
production-grade explain options specific to an extension.
On Tue, 2025-03-04 at 16:23 -050
Trey Boudreau writes:
> I didn’t see any past references to the pg_notify() ‘anomaly’:
> LISTEN FOO;
> NOTIFY FOO, ‘BAR’; -- notification delivered
> PERFORM pg_notify(‘FOO’, ‘BAR’); -- notification NOT delivered
> PERFORM pg_notify(‘foo’, ‘BAR’); -- notification delivered
> Can we come to some
Andres Freund writes:
> On 2025-03-05 11:19:46 -0500, Tom Lane wrote:
>> However, we seem to be moving towards a situation where each type of CI run
>> is a special snowflake that differs in multiple dimensions from other types.
>> That might make it difficult to figure out which dimension is resp
Hi,
On 2025-03-05 08:16:45 -0800, Jacob Champion wrote:
> From efc9fc3b3993601e9611131f229fbcaf4daa46f1 Mon Sep 17 00:00:00 2001
> From: Michael Paquier
> Date: Wed, 5 Mar 2025 13:30:43 +0900
> Subject: [PATCH 1/2] Fix race condition in pre-auth test
>
> ---
> src/test/authentication/t/007_pre_
Hi,
On Wed, Mar 05, 2025 at 09:18:16AM -0500, Andres Freund wrote:
> Hi,
>
> On 2025-03-05 13:03:07 +, Bertrand Drouvot wrote:
> > But yeah, if 0002 in [1] does not go in, then your concern is valid, so
> > adding
> > the extra check in the attached.
>
> This crashes in cfbot:
>
> https://
Does not seem like a bug to me. Just the normal auto-lowercase encountered
in every other SQL command. See:
greg=# select * from pg_listening_channels();
pg_listening_channels
---
(0 rows)
greg=# listen foo;
LISTEN
greg=# select * from pg_listening_channels();
pg_listening_c
> On 3 Mar 2025, at 16:23, Daniel Gustafsson wrote:
> The attached 0002 also contains documentation touchups and comments etc. 0001
> is your patch from v6.
I managed to misunderstand skip blocks in TAP tests in the 0002, so the
attached version fixes that. It has been failing on Debian in CI
Hello,
I've rebased and updated the patch a bit. The biggest change is that the
performance penalty measured with v1 of this patch is essentially gone in v10.
The overhead was due to re-creating IndexInfo information unnecessarily, which
I found existed in the estate. I've added a few fields
On Tue, 2025-03-04 at 16:23 -0500, Robert Haas wrote:
> But, I'm doubtful that
> letting unrelated extensions try to share the same option name is
> that
> thing.
This sub-discussion started because we were wondering whether to prefix
the options. I'm just pointing out that, even if there is a co
Hi,
While examining plan caches, I noticed that when a generic plan is invalidated,
the next execution of the prepared statement still results in a
generic plan. This
is of course with the default plan_cache_mode.
This behavior might go unnoticed since plan cache invalidations are
relatively unco
Hi,
On 2025-03-05 11:19:46 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Post-commit issues due to debug_parallel_query=regress seem rather common,
> > surely not helped by CI/cfbot not flagging them. I wonder if we ought to
> > make
> > one of the CI tasks use debug_parallel_query=regress,
> On Mar 5, 2025, at 10:42 AM, Tom Lane wrote:
>
> Anyway, I encourage reading some of the past threads on this
> topic.
>
I didn’t see any past references to the pg_notify() ‘anomaly’:
LISTEN FOO;
NOTIFY FOO, ‘BAR’; -- notification delivered
PERFORM pg_notify(‘FOO’, ‘BAR’); -- notification N
1 - 100 of 170 matches
Mail list logo
