st 21. 5. 2025 v 8:27 odesílatel Laurenz Albe
napsal:
> On Tue, 2025-05-20 at 17:06 -0400, Bruce Momjian wrote:
> > f no committer intends to pick it up and commit it, I think the proper
> > > action would be to step up and reject the patch set, not complain
> about the
> > > insistence of the au
hi.
Looking at AlterDomainValidateConstraint, it seems currently, ALTER
DOMAIN VALIDATE
CONSTRAINT will re-validate a VALID constraint, which
would just waste cycles.
Ideally, this operation should be a no-op.
The attached patch addresses this by making ALTER DOMAIN VALIDATE CONSTRAINT a
no-op in
Hi,
In the comments of add_partial_path, we have:
*We don't generate parameterized partial paths for several reasons.
Most
*importantly, they're not safe to execute, because there's nothing to
*make sure that a parallel scan within the parameterized portion of the
Hi,
On Tue, May 20, 2025 at 02:12:41PM -0700, Jeff Davis wrote:
> On Mon, 2025-05-19 at 14:07 -0400, Robert Haas wrote:
> > I agree with that, but I think that it may also be error-prone to
> > assume that it's OK to acquire heavyweight locks on other catalog
> > objects at any place in the code w
st 21. 5. 2025 v 2:21 odesílatel Michael Paquier
napsal:
> On Tue, May 20, 2025 at 10:28:31PM +0200, Pavel Stehule wrote:
> > This topic is difficult, because there is no common solution. SQL/PSM is
> > almost dead. T-SQL (and MySQL) design is weak and cannot be used for
> > security.
> > Oracle'
Hi,
On Wed, May 21, 2025 at 9:59 AM Fujii Masao wrote:
> I've pushed the patch. Thanks!
>
Glad to hear it, thank you!
--
Best regards,
Daniil Davydov
út 20. 5. 2025 v 23:07 odesílatel Bruce Momjian napsal:
> On Tue, May 20, 2025 at 10:36:54PM +0200, Laurenz Albe wrote:
> > On Tue, 2025-05-20 at 16:28 -0400, Bruce Momjian wrote:
> > > Well, we do have a right, e.g., we would not allow someone to
> repeatedly
> > > post patches for a Postgres ex
On Mon, May 19, 2025 at 7:45 PM Tom Lane wrote:
> Isaac Morland writes:
> > I assume this question has an obvious negative answer, but why can't we
> > attach const declarations to the various structures that make up the plan
> > tree (at all levels, all the way down)? I know const doesn't actua
On Tue, May 6, 2025 at 4:52 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Mon, May 5, 2025 at 6:59 PM Amit Kapila wrote:
> >
> > On Sun, May 4, 2025 at 2:33 PM Masahiko Sawada
> > wrote:
> > >
> > > While I cannot be entirely certain of my analysis, I believe the root
> > > cause might be related to the
On Wed, May 21, 2025 at 12:45 AM Masahiko Sawada wrote:
>
> On Mon, May 19, 2025 at 2:05 AM Amit Kapila wrote:
> >
> > On Sun, May 18, 2025 at 1:09 AM Masahiko Sawada
> > wrote:
> > >
> > > On Sat, May 10, 2025 at 7:08 AM Amit Kapila
> > > wrote:
> > > >
> > > >
> > > > Can we have a paramete
On Tue, May 20, 2025 at 10:35:39AM -0500, Sami Imseih wrote:
> 1/ this was missed in pg_stat_statements
> ./contrib/pg_stat_statements/pg_stat_statements.c:uint64
> saved_queryId = pstmt->queryId;
Right. Some greps based on "queryid" and "query_id" point that this
is the last reference to uin
On Mon, May 19, 2025 at 5:18 PM Masahiro Ikeda wrote:
>
> Thanks for your work and feedback!
>
> I've updated the patches and added regular regression tests for
> both pg_prewarm and amcheck.
Thanks for updating the patches!
Regarding the 0001 patch:
+CREATE TABLE test_part1 PARTITION OF test F
On Mon, Apr 28, 2025 at 10:45 AM jian he wrote:
>
> summary of attached patch:
> v1-0001
> we need to compute the generation expression for the domain with constraints,
> thus rename ExecComputeStoredGenerated to ExecComputeGenerated.
>
> v1-0002
> soft error variant of ExecPrepareExpr, ExecInitEx
On Thu, May 15, 2025 at 8:30 PM Fujii Masao wrote:
> > I suppose to add initialization of `nstats` and `nabortstats` to
> > ParsePrepareRecord (see attached patch).
>
> LGTM. Barring any objection, I will commit this patch.
I've pushed the patch. Thanks!
Regards,
--
Fujii Masao
On Wed, May 21, 2025 at 11:41:18AM +0900, Fujii Masao wrote:
> Since pg_regress uses log_line_prefix = '%m %b[%p] %q%a ',
> isn't it better to use the same setting in TAP tests as well?
Oh, right, good point. I've managed to miss this part in
pg_regress.c. Using the same value makes even more se
On Wed, May 21, 2025 at 11:14:11AM +0900, torikoshia wrote:
> Hi,
>
> I've noticed a minor inconsistency in the output of pg_aios.
>
> According to the documentation, the values for 'operation' are described as:
>
> readv, a vectored read
> ...
> writev, a vectored write
>
> However, in a
On Wed, May 21, 2025 at 8:51 AM Michael Paquier wrote:
>
> Hi all,
>
> While navigating through the logs in the CI, the buildfarm, or even my
> own machine, I've found myself spending a lot of time looking at
> very specific log entries to find out the PID of a specific process,
> sometimes mistak
Hi,
I've noticed a minor inconsistency in the output of pg_aios.
According to the documentation, the values for 'operation' are described
as:
readv, a vectored read
...
writev, a vectored write
However, in actual output, they appear as read and write -- without the
trailing v:
=#
On Tue, May 20, 2025 at 02:04:20PM +, David Steele wrote:
> I did a careful examination of the remaining diffs (there are quite a few)
> and in every case I consider them to be beneficial, i.e. they make the
> output more targeted and readable.
>
> I did not do a real code review, but I did no
On Tue, May 20, 2025 at 2:32 PM Robert Haas wrote:
> trying to create a role that already exists. At this point, my head is
> already kind of exploding, because I thought we were pretty careful to
> try to make it so that pg_dump output can be restored without error even
> in the face of pre-exis
Hi Hannu,
On Tue, May 20, 2025 at 08:49:28AM +0200, Hannu Krosing wrote:
> (I added two who I *think* I remember took notes)
>
> Please upload the notes to the Unconference section in
> https://wiki.postgresql.org/wiki/PGConf.dev_2025
>
> I have also some random notes on scraps of paper from the
Thanks a lot!
On Tue, May 20, 2025 at 9:42 AM Tomas Vondra wrote:
>
> On 5/20/25 08:49, Hannu Krosing wrote:
> > Hi to all note-takers
> >
> > (I added two who I *think* I remember took notes)
> >
> > Please upload the notes to the Unconference section in
> > https://wiki.postgresql.org/wiki/PGCo
On Mon, May 12, 2025 at 4:31 PM Dmitry Koval wrote:
>
> Hi!
>
> We (with colleagues) discussed further improvements to SPLIT/MERGE
> PARTITION(S). As a result of the discussion, the following answers to
> the questions remained:
>
> 1. Who should be the owner of new partitions (SPLIT PARTITION com
On Tue, May 20, 2025 at 11:28:17PM +1200, David Rowley wrote:
> Certainly, a bit late, yes. It basically requires implementing
> unsigned types on the SQL level. I believe there are a few sunken
> ships along that coastline, and plenty of history in the archives if
> you want to understand some of
On Tue, May 20, 2025 at 2:13 AM vignesh C wrote:
>
> On Tue, 20 May 2025 at 03:16, Michael Paquier wrote:
> >
> > On Mon, May 19, 2025 at 11:19:48AM -0400, Robert Haas wrote:
> > > The advantage of Fujii-san's proposal is that it is very simple to
> > > implement. A subscription option would inde
On Tue, May 20, 2025 at 10:28:31PM +0200, Pavel Stehule wrote:
> This topic is difficult, because there is no common solution. SQL/PSM is
> almost dead. T-SQL (and MySQL) design is weak and cannot be used for
> security.
> Oracle's design is joined with just one environment. And although almost
> a
Hi all,
While navigating through the logs in the CI, the buildfarm, or even my
own machine, I've found myself spending a lot of time looking at
very specific log entries to find out the PID of a specific process,
sometimes mistaking a normal backend vs a logical WAL sender while
looking for a PID,
On Tue, May 20, 2025 at 3:22 PM Melanie Plageman
wrote:
>
>
> On Tue, May 20, 2025 at 5:23 PM Masahiko Sawada wrote:
>>
>>
>> On Fri, May 2, 2025 at 11:59 AM Masahiko Sawada
>> wrote:
>> >
>> > However, there is a possibility that we have already eagerly scanned
>> > another page and returned i
On Thu, May 15, 2025 at 10:10 PM Daniil Davydov <3daniss...@gmail.com> wrote:
>
> Hi,
>
> On Fri, May 16, 2025 at 4:06 AM Matheus Alcantara
> wrote:
> > I've reviewed the v1-0001 patch, the build on MacOS using meson+ninja is
> > failing:
> > ❯❯❯ ninja -C build install
> > ninja: Entering director
On Tue, May 20, 2025 at 5:23 PM Masahiko Sawada
wrote:
>
> On Fri, May 2, 2025 at 11:59 AM Masahiko Sawada
> wrote:
> >
> > However, there is a possibility that we have already eagerly scanned
> > another page and returned it to the read stream before we freeze the
> > eagerly-scanned page and d
> At the same time AFAICT there isn't much more code paths
> to worry about in case of a LocationExpr as a node
I can imagine there are others like value expressions,
row expressions, json array expressions, etc. that we may
want to also normalize.
> I believe it's worth to not only to keep amoun
Ashutosh Bapat wrote 2023-03-28 15:58:
Bumping it to attract some attention.
On Tue, Mar 21, 2023 at 12:51 PM Ashutosh Bapat
wrote:
Hi,
Hash table scans (seq_scan_table/level) are cleaned up at the end of a
transaction in AtEOXact_HashTables(). If a hash seq scan continues
beyond transaction
On 20/5/25 22:43, Nico Williams wrote:
[snip]
What you want is for C to have a type attribute that denotes
immutability all the way down. `const` doesn't do that. One thing that
could be done is to write a utility that creates const-all-the-way-down
clones of given types, but such a tool can't
(CC'ed to Melanie)
On Fri, May 2, 2025 at 11:59 AM Masahiko Sawada wrote:
>
> Hi,
>
> I hit the assertion failure in the subject line with the following script:
>
> create table t (a int) with (autovacuum_enabled = off);
> insert into t select generate_series(1, 1_000_000);
> vacuum t;
> insert i
On Mon, 2025-05-19 at 14:07 -0400, Robert Haas wrote:
> I agree with that, but I think that it may also be error-prone to
> assume that it's OK to acquire heavyweight locks on other catalog
> objects at any place in the code where we record a dependency. I will
> not be surprised at all if that tur
Andres Freund writes:
> On 2025-05-20 16:18:57 -0400, Tom Lane wrote:
>> I'm curious though: what was the test case you were looking at?
> It's a modified query from our regression tests, I had added some debugging to
> find cases where the targetlists differed. I attached the extracted, somewha
On Tue, May 20, 2025 at 10:28:31PM +0200, Pavel Stehule wrote:
> út 20. 5. 2025 v 18:39 odesílatel Bruce Momjian napsal:
> I sent a reduced version a few months ago - from 21 patches to 8 (and it can
> be
> reduced to six if we postpone tools for detection ambiguity).
> The timing was not perfect
On Tue, May 20, 2025 at 10:36:54PM +0200, Laurenz Albe wrote:
> On Tue, 2025-05-20 at 16:28 -0400, Bruce Momjian wrote:
> > Well, we do have a right, e.g., we would not allow someone to repeatedly
> > post patches for a Postgres extension we don't manage, or the jdbc
> > driver. I also don't think
On Wed, May 14, 2025, at 4:06 AM, Laurenz Albe wrote:
> On Tue, 2025-05-13 at 17:53 -0400, Scott Mead wrote:
> > On Tue, May 13, 2025, at 5:07 PM, Greg Sabino Mullane wrote:
> > > On Tue, May 13, 2025 at 4:37 PM Scott Mead wrote:
> > > > I'll open by proposing that we prevent the planner from au
I wrote:
> [ confused... ] I get the same output from that script with or
> without the patch.
Oh, scratch that: I'd gotten confused about which branch I was
working in. It does change the output as you say.
I still think it's irrelevant to view display, including pg_dump,
though. Those operat
Given that some time has passed I'd like to raise this again. Any chance
of this making it back to 16 to fix the regression?
We'll be using 16 for the better part of a year still and we're having
to resort to some annoying workarounds for this.
Regards,
Bennie
On 2024/11/10 18:17, Tom Lane
Hi
út 20. 5. 2025 v 18:39 odesílatel Bruce Momjian napsal:
> On Tue, May 20, 2025 at 01:33:18PM -0300, Marcos Pegoraro wrote:
> > Em ter., 20 de mai. de 2025 às 11:56, Bruce Momjian
> > escreveu:
> >
> > I will again ask why this patch set is being reposted when there is
> no
> > plan t
On Mon, May 19, 2025 at 08:41:06AM -0400, Isaac Morland wrote:
> I assume this question has an obvious negative answer, but why can't we
> attach const declarations to the various structures that make up the plan
> tree (at all levels, all the way down)? I know const doesn't actually
> prevent a va
Hi,
On 2025-05-20 16:18:57 -0400, Tom Lane wrote:
> Andres Freund writes:
> >> I'm tempted to back-patch this: the plan tree damage seems harmless at
> >> present, but maybe it'd become less harmless with future fixes.
>
> > There are *some* cases where this changes the explain output, but but t
On Tue, 2025-05-20 at 16:28 -0400, Bruce Momjian wrote:
> On Tue, May 20, 2025 at 08:47:36PM +0200, Daniel Gustafsson wrote:
> > > On 20 May 2025, at 18:39, Bruce Momjian wrote:
> > > My only point is that we should only be using email lists for work that
> > > is being actively worked on to be ad
On Tue, May 20, 2025 at 08:47:36PM +0200, Daniel Gustafsson wrote:
> > On 20 May 2025, at 18:39, Bruce Momjian wrote:
> > My only point is that we should only be using email lists for work that
> > is being actively worked on to be added to community Postgres. There
> > has been talk of a trimmed
Andres Freund writes:
> Largely makes sense, the only thing I see is that the !returningLists branch
> does:
> /*
>* We still must construct a dummy result tuple type, because
> InitPlan
>* expects one (maybe should change that?).
>*/
On Mon, May 12, 2025 at 8:58 AM Peter Geoghegan wrote:
> I wonder if we can fix this problem by getting rid of the old support
> routine #5, "options". It currently doesn't do anything, and I always
> thought it was strange that it was added "for uniformity" with other
> index AMs.
Attached patch
On Mon, May 19, 2025 at 2:05 AM Amit Kapila wrote:
>
> On Sun, May 18, 2025 at 1:09 AM Masahiko Sawada wrote:
> >
> > On Sat, May 10, 2025 at 7:08 AM Amit Kapila wrote:
> > >
> > >
> > > Can we have a parameter like immediately_reserve in
> > > create_logical_slot API, similar to what we have fo
+1, this seems like it could be very useful. A somewhat related issue
is being able to tie plan nodes back to the query text: it can be hard
to understand the planner's decisions if it's not even clear what part
of the query it's making decisions about. I'm sure this is not an easy
problem in gener
> On 20 May 2025, at 18:39, Bruce Momjian wrote:
>
> On Tue, May 20, 2025 at 01:33:18PM -0300, Marcos Pegoraro wrote:
>> Em ter., 20 de mai. de 2025 às 11:56, Bruce Momjian
>> escreveu:
>>
>>I will again ask why this patch set is being reposted when there is no
>>plan to apply it to git
On Wed, Apr 30, 2025 at 4:29 PM Tom Lane wrote:
> However, I'd at least like to complain about the fact that
> it breaks pg_dumpall, which is surely not expecting anything
> but the default behavior. If for any reason the restore is
> run under a non-default setting of createrole_self_grant,
> th
Hi,
On 2025-05-20 13:04:46 -0400, Tom Lane wrote:
> I wrote:
> > I think we can just delete this assignment (and fix these comments).
>
> As attached.
Largely makes sense, the only thing I see is that the !returningLists branch
does:
/*
* We still must construct a
Ah ya, forgot that reltuples are not always accurate. This sounds
reasonable to me.
On Mon, May 19, 2025 at 2:32 PM Nathan Bossart
wrote:
> On Mon, May 19, 2025 at 02:13:45PM -0700, Hari Krishna Sunder wrote:
> > I think it would be better to revert 9879105 since there can be a
> > considerable
I wrote:
> I think we can just delete this assignment (and fix these comments).
As attached. I'm tempted to back-patch this: the plan tree damage
seems harmless at present, but maybe it'd become less harmless with
future fixes.
regards, tom lane
diff --git a/src/backend/
On Tue, May 20, 2025 at 01:33:18PM -0300, Marcos Pegoraro wrote:
> Em ter., 20 de mai. de 2025 às 11:56, Bruce Momjian
> escreveu:
>
> I will again ask why this patch set is being reposted when there is no
> plan to apply it to git master
>
> Too bad. I would love to have this functional
Andres Freund writes:
> Afaict the mtstate->ps.plan->targetlist assignment, and the ExecTypeFromTL(),
> ExecAssignResultTypeFromTL() before that, are completely superfluous. Am I
> missing something?
I think you are right. The two tlists are completely identical in
most cases, because of this b
Em ter., 20 de mai. de 2025 às 11:56, Bruce Momjian
escreveu:
> I will again ask why this patch set is being reposted when there is no
> plan to apply it to git master
Too bad. I would love to have this functionality, from the user's point of
view there are problems where it would solve them wo
Hi,
On 2025-05-20 10:59:22 -0400, Andres Freund wrote:
> On 2025-05-18 19:31:33 -0400, Tom Lane wrote:
> > While chasing down Valgrind leakage reports, I was disturbed
> > to realize that some of them arise from a case where the
> > executor scribbles on the plan tree it's given, which it is
> > a
> On Tue, May 20, 2025 at 06:30:25AM GMT, Michael Paquier wrote:
> On Mon, May 12, 2025 at 06:40:43PM -0400, Sami Imseih wrote:
> > Also, LocationExpr is not really an expression node, but a wrapper to
> > an expression node, so I think it's wrong to define it as a Node and be
> > required to add t
On Thu, Apr 10, 2025 at 12:00 PM Tom Lane wrote:
> Melanie recently committed a patch (9219093ca) that purports to
> generalize our log_connections logging ability:
>
> Convert the boolean log_connections GUC into a list GUC comprised of
> the
> connection aspects to log.
>
> This giv
On Sun, May 18, 2025 at 11:34:07PM -0400, Tom Lane wrote:
> Michael Paquier writes:
> > On Sun, May 18, 2025 at 12:09:23PM +0530, Shaik Mohammad Mujeeb wrote:
> >> Just wanted to check - should this be updated to reflect 1996-2025 instead?
>
> > This process is automated by src/tools/copyright.pl
Amit Langote writes:
> Thanks for pointing out the hole in the current handling of
> CachedPlan->stmt_list. You're right that the approach of preserving
> the list structure while replacing its contents in-place doesn’t hold
> up when the rewriter adds or removes statements dynamically. There
> mi
Hi Alexander,
Thank you very much for the review!
> The patchset doesn't seem to build after 371f2db8b0, which adjusted
> the signature of the INJECTION_POINT() macro. Could you, please,
> update the patchset accordingly.
I've updated the patch (see attached). Thanks.
> I see in 0004 patch we'
Supporting unsigned INTs will be valuable for more than just this
obviously, and if we do
ever have that capability, we would likely want to go that route. I
know I've been asked about
why queryIds could be negative more than a few times. Until then, I
think the patch being
suggested is reasonable
Hi!
On 31.03.25 13:22, Yugo Nagata wrote:
> On Mon, 31 Mar 2025 20:00:57 +0900
> Yugo Nagata wrote:
>
>> Hi,
>>
>> I found that multiple sessions concurrently execute CREATE OR REPLACE
>> FUNCTION
>> for a same function, the error "tuple concurrently updated" is raised. This
>> is
>> an interna
On Tue, May 20, 2025 at 4:52 AM Peter Eisentraut
wrote:
> log_connections has been changed from a Boolean parameter to a string
> one, but a number of places in the documentation and in various pieces
> of test code still use the old values. I think it would be better if
> they were adjusted to
Hi,
On 2025-05-18 19:31:33 -0400, Tom Lane wrote:
> While chasing down Valgrind leakage reports, I was disturbed
> to realize that some of them arise from a case where the
> executor scribbles on the plan tree it's given, which it is
> absolutely not supposed to do:
>
> /*
> * In
On Thu, May 15, 2025 at 08:48:37AM +0200, Pavel Stehule wrote:
> Hi
>
> fresh rebase
I will again ask why this patch set is being reposted when there is no
plan to apply it to git master?
--
Bruce Momjian https://momjian.us
EDB https://enterpris
Hi,
On Tue, 20 May 2025 at 02:54, Matthew Sterrett
wrote:
>
> Hello! Thanks for helping me with this.
> I'm still trying to figure out what is going on with the Bookworm test
> failures. I'm pretty sure this patchset should resolve all the issues
> with the macOS build, but I don't think it will
On Tue, May 20, 2025 at 05:15:54PM +0300, Nazir Bilal Yavuz wrote:
> > As of the date of the commit, "Co-authored-by:" is listed as:
> >
> > https://wiki.postgresql.org/wiki/Commit_Message_Guidance
> >
> > "Co-authored-by:" is used by committers when they want to give full
> > cred
> On Tue, May 20, 2025 at 11:03:52AM GMT, Dmitry Dolgov wrote:
> > By the way, the new test cases for ARRAY lists are sent in the last
> > patch of the series posted on this thread:
> > https://www.postgresql.org/message-id/7zbzwk4btnxoo4o3xbtzefoqvht54cszjj4bol22fmej5nmgkf@dbcn4wtakw4y
> >
> > The
On 20/5/2025 08:49, Hannu Krosing wrote:
Hi to all note-takers
(I added two who I *think* I remember took notes)
Please upload the notes to the Unconference section in
https://wiki.postgresql.org/wiki/PGConf.dev_2025
I have also some random notes on scraps of paper from the two sessions
I atte
Hi,
On Tue, 20 May 2025 at 16:52, Bruce Momjian wrote:
>
> On Tue, May 20, 2025 at 03:46:44PM +0300, Nazir Bilal Yavuz wrote:
> > Hi,
> >
> > Thanks for working on this!
> >
> > On Fri, 2 May 2025 at 05:44, Bruce Momjian wrote:
> > >
> > > I will continue improving it until beta 1, and until the
On 5/20/25 07:34, Sami Imseih wrote:
Tested the patch and it looks good to me.
Not that I thought it would fail, but I also confirmed the pgaudit case
works as expected.
I also tested and everything looks good with the patch.
I did a careful examination of the remaining diffs (there are quite
On Tue, May 20, 2025 at 03:46:44PM +0300, Nazir Bilal Yavuz wrote:
> Hi,
>
> Thanks for working on this!
>
> On Fri, 2 May 2025 at 05:44, Bruce Momjian wrote:
> >
> > I will continue improving it until beta 1, and until the final release.
> > I will probably add markup in 1-3 weeks. Let the fee
Hi Tom,
On Tue, May 20, 2025 at 12:06 PM Tom Lane wrote:
> My attention was drawn to commit 525392d57 after observing that
> Valgrind complained about a memory leak in some code that commit added
> to BuildCachedPlan(). I tried to make sense of said code so I could
> remove the leak, and eventua
On Sat, Apr 5, 2025 at 3:14 PM Atsushi Torikoshi
wrote:
On Thu, Apr 3, 2025 at 11:10 PM Robert Haas
wrote:
Do we really need ExecProcNodeOriginal? Can we find some way to reuse
ExecProcNodeReal instead of making the structure bigger?
I also wanted to implement this without adding elements to
Hi,
Thanks for working on this!
On Fri, 2 May 2025 at 05:44, Bruce Momjian wrote:
>
> I will continue improving it until beta 1, and until the final release.
> I will probably add markup in 1-3 weeks. Let the feedback begin. ;-)
+
+
+Add server variable file_copy_method to control the file co
On Tue, May 20, 2025 at 8:43 AM Peter Geoghegan wrote:
> I imagine bitmap index scans will be similar to plain index scans.
To be clear, I meant that the magnitude of the problem will be
similar. I do not mean that they aren't fixed by my v2. They should be
fully fixed by v2.
--
Peter Geoghegan
On Mon, May 19, 2025 at 8:21 PM Tomas Vondra wrote:
> With v2 the regression disappears, both for index-only scans and regular
> index scans. I haven't tried anything with bitmap scans - I hit the
> regression mostly by accident, on a workload that does IOS only. I may
> try constructing something
On Tue, May 13, 2025 at 08:05:24AM +0200, Laurenz Albe wrote:
> On Mon, 2025-05-12 at 20:27 -0700, David G. Johnston wrote:
> > Should all columns removed from system views and/or catalogs be listed in
> > “Migration” or is there some filtering criteria? There are at minimum quite
> > a few statist
Andrei,
> > ```
> > -- imagine replacing inefficient array_sample(array_agg(t), 10)
> > -- with more efficient array_sample_reservoir(t, 10)
> > SELECT (unnest(agg)).* AS k FROM
> > ( SELECT array_sample(array_agg(t), 10) AS agg FROM (
> > ... here goes the subquery ...
> > ) AS t
> > );
On Thu, May 15, 2025 at 02:02:02PM -0400, Álvaro Herrera wrote:
> As related anecdote, the rename of columns in pg_stat_activity a few
> years back caused some pg_upgrade pain, which IMO was understandable;
> it's reasonable to call that kind of thing out as a possible
> incompatibility, at least I
Tested the patch and it looks good to me.
Not that I thought it would fail, but I also confirmed the pgaudit case
works as expected.
```
LOG: AUDIT: SESSION,10,2,DDL,CREATE TABLE,,,"CREATE TABLE do_table
(""weird name""
INT)",
LOG: AUDIT: SESSION,10,3,DDL,DROP TABLE,,,DROP table do_table,
DO
``
On Fri, May 16, 2025 at 5:01 PM Amit Kapila wrote:
>
Please find some more comments on the 0001 patch:
1.
We need to know about such transactions
+ * for conflict detection and resolution in logical replication. See
+ * GetOldestTransactionIdInCommit and its use.
Do we need to mention resolution
On Tue, 20 May 2025 at 18:12, Julien Rouhaud wrote:
> I don't think it was discussed, but why not go the other way, keep everything
> as uint64 and expose an uint64 datatype at the SQL level instead? That's
> something I actually want pretty often so I would be happy to have that
> natively, whet
On Tue, May 20, 2025 at 8:38 AM shveta malik wrote:
>
> Please find few more comments:
>
> 1)
> ProcessStandbyPSRequestMessage:
> + /*
> + * This shouldn't happen because we don't support getting primary status
> + * message from standby.
> + */
> + if (RecoveryInProgress())
> + elog(ERROR, "the p
> On 20 May 2025, at 10:52, Peter Eisentraut wrote:
> src/test/ssl/t/SSL/Server.pm
While I don't have an immediate usecase or test in mind, having the SSL tests
use log_conections=all could be handy when hacking on the TLS support.
--
Daniel Gustafsson
On 5/19/25 20:01, Robert Haas wrote:
> Hi,
>
> A couple of people at pgconf.dev seemed to want to know more about my
> ongoing plan shape work, so here are the patches I have currently.
> This is a long way from something that actually looks like a usable
> feature, but these are bits of infrastru
On Tue, May 20, 2025 at 8:35 AM Nisha Moond wrote:
>
> >
> > Thanks for the comments, these are handled in the attached v20250516
> > version patch.
> >
>
> Thanks for the patches. Here are my review comments -
>
> Patch-0004: src/backend/replication/logical/sequencesync.c
>
Hi,
Currently, the b
> On 20 May 2025, at 04:29, Tom Lane wrote:
> I want to argue for reverting, at least for v18. I do not think that
> ProcessGetMemoryContextInterrupt is anywhere near release-quality.
> I found out while poking into Valgrind leak reports that it leaks
> memory --- and does so in TopMemoryContext
On Tue, May 20, 2025 at 10:24 AM Amit Kapila wrote:
>
> On Tue, May 20, 2025 at 8:38 AM shveta malik wrote:
> >
> > Please find few more comments:
> >
> > 1)
> > ProcessStandbyPSRequestMessage:
> > + /*
> > + * This shouldn't happen because we don't support getting primary status
> > + * message
On 5/20/25 08:49, Hannu Krosing wrote:
> Hi to all note-takers
>
> (I added two who I *think* I remember took notes)
>
> Please upload the notes to the Unconference section in
> https://wiki.postgresql.org/wiki/PGConf.dev_2025
>
> I have also some random notes on scraps of paper from the two ses
On Tue, 20 May 2025 at 03:16, Michael Paquier wrote:
>
> On Mon, May 19, 2025 at 11:19:48AM -0400, Robert Haas wrote:
> > The advantage of Fujii-san's proposal is that it is very simple to
> > implement. A subscription option would indeed be better, but it would
> > also be considerably more compl
On Tue, May 20, 2025 at 09:58:04AM +0200, Anthonin Bonnefoy wrote:
> Looking at the tests, there are 2 additionals empty DO blocks:
> +DO $$
> +DECLARE BEGIN
> +END $$;
>
> What's the point of those? They won't be visible in the output since
> we have 'toplevel IS FALSE' in the pg_stat_statements
On 12.03.25 16:43, Melanie Plageman wrote:
On Tue, Mar 11, 2025 at 6:27 PM Melanie Plageman
wrote:
I did more manual testing of my patches, and I think they are mostly
ready for commit except for the IsConnectionBackend() macro (if we
have something to change it to).
I've committed this and
Nico,
> > Can the detection of such queries be done by the yacc/bison parser
> > grammar?
>
> Maybe the `sortby` rule could check if the expression is `random()`,
> then `sort_clause` could check if `$3` is a one-item `sortby_list` of
> just `random()` and mark `$$` as special -- this should be ch
On 5/20/25 05:06, Tom Lane wrote:
> Amit Langote writes:
>> Pushed after some tweaks to comments and the test case.
>
> My attention was drawn to commit 525392d57 after observing that
> Valgrind complained about a memory leak in some code that commit added
> to BuildCachedPlan(). I tried to ma
> On Tue, May 20, 2025 at 11:57 AM Dilip Kumar wrote:
>
> On Mon, May 5, 2025 at 11:19 AM DIPESH DHAMELIYA
> wrote:
> >
> > Hello everyone,
> >
> > With the commit 556f7b7bc18d34ddec45392965c3b3038206bb62, Any plpgsql
> > function that returns scalar value would not be able to use parallelism to
1 - 100 of 104 matches
Mail list logo
