Hi,
I'm reviewing patches in Commitfest 2024-07 from top to bottom:
https://commitfest.postgresql.org/48/
This is the 4th patch:
https://commitfest.postgresql.org/48/4710/
FYI: https://commitfest.postgresql.org/48/4681/ is my patch.
In <2726138.1712462...@sss.pgh.pa.us>
"Re: Fixing backslash
On Mon, Jul 15, 2024 at 10:29:32AM -0400, David E. Wheeler wrote:
> It’s here:
>
> https://commitfest.postgresql.org/48/5017/
Sorry for the delay. Finally came back to it, and applied the tests.
Thanks!
It was fun to see that HEAD was silenced with the first patch of this
thread that tweaked
On Fri, Jul 19, 2024 at 8:06 AM Peter Smith wrote:
>
> ==
> You wrote "tried to make the two_phase change before failover option
> wherever it makes sense to keep the code consistent". But, still
> failover is coded first in lots of places:
> - libpqrcv_alter_slot
> - ReplicationSlotAlter
> -
On Fri, Jul 5, 2024 at 9:56 PM Etsuro Fujita wrote:
> On Tue, Oct 24, 2023 at 8:48 PM Devrim Gündüz wrote:
> > I'm seeing an issue after upgrading from 12.13 to 15.4. This happens
> > when we run a query against a foreign table (fdw on the same instance to
> > a different database) -- but does no
On Thu, Jul 18, 2024 at 8:06 PM Tatsuo Ishii wrote:
> > I'm opposed to having a separate file for every function. I think
> > breaking up func.sgml into one piece per sect1 is about right. If that
> > proves cumbersome still we can look at breaking it up further, but
> > let's start with that.
>
Hello Richard,
18.07.2024 17:30, Richard Guo wrote:
The problemed plan is a non-parallel nestloop join. It's just chance
which join order the planner will pick, and slight variations in
underlying statistics could result in a different displayed plan.
From the two verbose plans, we can see sli
On 18/7/2024 19:49, Matthias van de Meent wrote:
On Wed, 17 Jul 2024 at 16:09, Andrei Lepikhov wrote:
On 17/7/2024 16:33, Matthias van de Meent wrote:
On Wed, 17 Jul 2024 at 05:29, Andrei Lepikhov wrote:
Because the @<@ and @>@ operators are not registered as commutative,
it couldn't apply
On Fri, Jul 12, 2024 at 11:07:49PM +0100, Ilya Gladyshev wrote:
> While working on CIC for partitioned tables [1], I noticed that REINDEX for
> partitioned tables is not tracking keeping progress of partitioned tables,
> so I'm creating a separate thread for this fix as suggested.
This limitation
> I'm opposed to having a separate file for every function. I think
> breaking up func.sgml into one piece per sect1 is about right. If that
> proves cumbersome still we can look at breaking it up further, but
> let's start with that.
That will create at least 30 func-xx.sgml files.
t-ishii$ grep
Hi,
In
"July Commitfest: Entries Needing Review" on Thu, 18 Jul 2024 14:17:38 -0400,
Corey Huinker wrote:
> If you know your patch isn't going to get reviewed in this commitfest,
> please consider moving it to the next commitfest or withdrawing it.
I hope my patch https://commitfest.postgr
On Thu, Jul 18, 2024 at 9:42 PM Amit Kapila wrote:
>
...
> I agree and have done that in the attached. I have made some
> additional changes: (a) removed the unrelated change of two_phase in
> protocol.sgml, (b) tried to make the two_phase change before failover
> option wherever it makes sense to
On Thu, Jul 18, 2024 at 09:37:06AM +0200, Daniel Gustafsson wrote:
> On 18 Jul 2024, at 09:29, Michael Paquier wrote:
>> How about using a new error code in class 58, say a
>> ERRCODE_FILE_NAME_TOO_LONG like in the attached?
>> ERRCODE_DUPLICATE_FILE is like that; it exists just for the mapping
>>
On Fri, Jul 19, 2024 at 12:17:44AM +0200, Tomas Vondra wrote:
> shall we do something about this patch? It seems to be in a pretty good
> shape (pretty much RFC, based on quick review), the cfbot is still
> happy, and there seems to be agreement this is a nice feature.
>
> Michael, I see you've re
On 2024-07-05 00:27, torikoshia wrote:
Hi,
With the current file_fdw, if even one line of data conversion fails,
the contents of the file cannot be referenced at all:
=# \! cat data/test.data
1,a
2,b
a,c
=# create foreign table f_fdw_test_1 (i int, t text) server f_fdw
options (filena
On Wed, Jul 17, 2024 at 9:31 PM jian he wrote:
>
> i think "INSERT INTO arroverflowtest(i[2147483647:2147483647]) VALUES
('{}');"
> means to insert one element (size) to a customized lower/upper bounds.
Ah, thank you, I mistakenly understood that as an array with size
2147483647, with the first 2
Hello,
Thank you for your response.
0. Here is an example of what I intended.
What I intended is to add pre-check tasks before executing pg_ctl start,
stop, and restart using the -A and -Z options.
=
[test@test]$ cat true.sh
#!/bin/bash
echo 'true'
exit
On Thu, Jul 18, 2024 at 01:37:40PM +0200, Anthonin Bonnefoy wrote:
> For utility statements defined within a function, the queryTree is
> copied to a plannedStmt as utility commands don't require planning.
> However, the queryId is not propagated to the plannedStmt. This leads
> to plugins relying
On Sat, Jul 13, 2024 at 1:22 AM Dean Rasheed wrote:
>
> On Wed, 26 Jun 2024 at 12:18, Dean Rasheed wrote:
> >
> > I've added a new elog() error check to
> > adjust_appendrel_attrs_mutator(), similar to the existing one for
> > varnullingrels, to report if we ever attempt to apply a non-default
>
On Thu, Jul 18, 2024 at 01:03:31PM -0400, Tom Lane wrote:
> This whole discussion seems quite bizarre to me. In the first
> place, it is certain that Unicode will continue to evolve, and
> I can't believe that we'd just freeze pg_c_utf8 on the current
> definition forever. Whether the first chang
Hi, here are some review comments for patch v19-0003
==
src/backend/catalog/pg_publication.c
1.
/*
* Translate a list of column names to an array of attribute numbers
* and a Bitmapset with them; verify that each attribute is appropriate
* to have in a publication column list (no system or
On Wed, Jul 17, 2024 at 2:27 AM Andrew Dunstan wrote:
> Here's the latest version of this patch. It removes all use of
> background_psql(). Instead it uses libpq's async interface, which seems
> to me far more robust. There is one remaining use of interactive_psql(),
> but that's reasonable as it'
Hi,
shall we do something about this patch? It seems to be in a pretty good
shape (pretty much RFC, based on quick review), the cfbot is still
happy, and there seems to be agreement this is a nice feature.
Michael, I see you've reviewed the patch in January. Do you agree / plan
to get it committe
"Anton A. Melnikov" writes:
> On 06.05.2024 13:19, Alexander Korotkov wrote:
>> Now there is a similar workaround in the 010_tab_completion.pl with regex:
>> qr/"mixedName\\?" /
> I think if there were or will be complaints from users about this behavior in
> Debian 10,
> then it makes sense to
Hi,
If I understand correctly, the problem is that it's not clear which of
the 'abc' substrings is matched/returned by the function, right?
I wonder if this is a problem only for understanding the test, or if it
makes the tests a bit weaker. I mean, what if the function returns the
wrong substrin
jian he writes:
> [ v5-0001-add-regex-functions-argument-names-to-pg_proc.patch ]
I'm not sure whether we've bikeshedded this to death yet, but
personally I'm content with the naming choices here (which basically
are those already shown in table 9.10). However, while looking
at the patch I notic
On 7/18/24 12:37, masahiro.ik...@nttdata.com wrote:
>> Let me share my opinion on those questions ...
> ...>
>> For ndistinct, I think we don't show this because it doesn't go through
>> clauselist_selectivity, which is the only thing I modified in the PoC.
>> But I guess we might improve estimate_
Hi Bertrand,
> 1 ===
> ...
> That's worth additional comments in the code.
There's this comment already about caching the value already, not sure
if you prefer something more?
/* Cache values to reduce contention on lock */
> 2 ===
> ...
> Looks like setting initialized to true is missing once
Hi Shveta,
Thanks for taking a look at the patch.
> > will leave user no option to unlink failover-enabled logical
> > subscribers from the wait on synchronous standbys.
That's a good point. I'm a bit biased in that I don't think there's a
great reason why someone would
want to replicate logical
On 11/3/23 10:06, Jelte Fennema-Nio wrote:
> I wanted to revive this thread, since it's by far one of the most
> common foot guns that people run into with PgBouncer. Almost all
> session level SET commands leak across transactions, but SET
> search_path is by far the one with the biggest impact wh
Andrew Dunstan writes:
> I'm opposed to having a separate file for every function.
I also think that would be a disaster. It would result in a huge
number of files which would make global editing (eg markup changes)
really painful, and it by no means flattens the document structure.
Somewhere th
On 2024-07-18 Th 4:16 PM, Corey Huinker wrote:
looking back.
The patch is big. no convenient way to review/validate it.
Perhaps we can break up the patches as follows:
1. create the filelist.sgml entries, and create new files as you
detailed, empty with func.sgml still managing the
I fixed a compiler warning on Windows in v6 of the patch set. Sorry for
the noise.
--
nathan
>From 139826d3b9290d547ae9b3446ad455ba713211e0 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Mon, 15 Jul 2024 13:13:05 -0500
Subject: [PATCH v6 1/4] parse sequence information
---
src/bin/pg_dum
James Coleman writes:
> On Thu, Jul 18, 2024 at 2:38 PM Tom Lane wrote:
>> Are you really sure nothing changed about what the ORM is emitting?
> Yes, aside from the fact that application code didn't change, we
> reproduced the problem by restoring a physical snapshot of the
> database and were a
>
>
> looking back.
> The patch is big. no convenient way to review/validate it.
>
Perhaps we can break up the patches as follows:
1. create the filelist.sgml entries, and create new files as you detailed,
empty with func.sgml still managing the sections, but each section now has
it's correspondi
Alena Rybakina writes:
> I fixed it. The code remains the same.
I see the cfbot is again complaining that this patch doesn't apply.
In hopes of pushing this over the finish line, I fixed up the (minor)
patch conflict and also addressed the cosmetic complaints I had
upthread [1]. I think the att
On Thu, Jul 18, 2024 at 2:38 PM Tom Lane wrote:
>
> James Coleman writes:
> > The plan generated by the planner changed suddenly one morning this
> > week, and in a very surprising way: the innermost scan (of "objects")
> > started choosing a seq scan, despite the cost from that node being
> > ve
> It seems that in your patch, WAL logging is skipped for all tables, not just
> temporary tables.
This code path is only used in two cases though:
* For the temporary tables ON COMMIT DROP
* For truncating tables that were created in the same transaction, or which
were already truncated in the
James Coleman writes:
> The plan generated by the planner changed suddenly one morning this
> week, and in a very surprising way: the innermost scan (of "objects")
> started choosing a seq scan, despite the cost from that node being
> very high and an index scan being possible
That looks weird to
On Wed, Jul 17, 2024 at 11:58:21PM -0400, Tom Lane wrote:
> ... okay, I lied, I looked at the patch. Why are you testing
>
> + if (pg_class_aclcheck(relid, GetUserId(), ACL_SELECT | ACL_USAGE) ==
> ACLCHECK_OK &&
>
> ? This is a substitute for a SELECT from the sequence and it seems
> like
Robert Haas writes:
> On Thu, Jul 18, 2024 at 7:08 AM David Rowley wrote:
>> I think the primary issue with the old way was index bloat wasn't
>> fixed. The release notes for 9.0 do claim the CLUSTER method "is
>> substantially faster in most cases", however, I imagine there are
>> plenty of case
There are currently 124 commitfest entries needing a reviewer.
Of those, 38 have activity this month, and the other 86 are a bit more
stale, some going back to last year.
We're already past the halfway point of this commitfest, so we need to get
reviewers on these.
If you know your patch isn't go
Hi all,
I've been optimizing queries for a long time, and I don't think I've
ever seen something more surprising to me than this -- sufficiently so
that I wanted to ask if others thought it implied a bug. It's possible
my mental model for the planner is broken in some significant way, or
that I'm
On Thu, Jul 18, 2024 at 7:08 AM David Rowley wrote:
> On Wed, 10 Jul 2024 at 22:58, Tomas Vondra
> wrote:
> > IIRC long time ago VACUUM FULL actually worked in a similar way, i.e. by
> > moving rows around. I'm not sure if it did the lock-free thing as
> > proposed here (probably not), but I gues
Fujii Masao writes:
> "because of recovery target settings" isn't always accurate.
> For example, if the DBA shuts down the server during recovery,
> POSTMASTER_SHUTDOWN_IN_RECOVERY can be returned regardless of
> the recovery target settings. Should we change the message to
> something like "serv
On 2024/07/19 1:27, Robert Haas wrote:
On Thu, Jul 18, 2024 at 9:47 AM Fujii Masao wrote:
"WAL not generated under wal_level=minimal" sounds a bit confusing??
How about "WAL generated while wal_level is replica or higher" instead?
Committed and back-patched to 17 with approximately that ch
On Wed, Jul 17, 2024 at 11:11 AM Tom Lane wrote:
> Ah. I have no particular objection to that, but I wonder whether
> we should make the autoconf/makefile infrastructure do it too.
I don't need it personally, having moved almost entirely to Meson. But
if the asymmetry is a sticking point, I can
Junwang Zhao writes:
> On Wed, Jul 10, 2024 at 3:59 AM Laurenz Albe wrote:
>> Attached is my suggestion.
> The patch LGTM.
>> I'll set the status to "waiting for author"; if you are fine with my version,
>> I think that the patch is "ready for committer".
> I've set it to "ready for committer"
On 2024/07/10 11:45, Junwang Zhao wrote:
Attached is my suggestion.
The patch LGTM.
+ case POSTMASTER_SHUTDOWN_IN_RECOVERY:
+ print_msg(_(" done\n"));
+ print_msg(_("server shut down because of recovery
targ
On Wed, Jul 17, 2024 at 3:42 PM David Zhang wrote:
> Totally agree. Either Implementing OCSP requests over HTTP, then parsing
> the response and then saving the results to a file, or using an OpenSSL
> client with a cron job to periodically update the file should work.
> Using a cron job would lik
On Thu, 2024-07-18 at 16:45 +0200, Laurenz Albe wrote:
> On Thu, 2024-07-18 at 07:00 -0700, Noah Misch wrote:
> > What I am against is routinely updating the built-in provider to
> > adopt any changes
> > > that Unicode makes.
That is a perfectly reasonable position; please add it to the version
Jeff Davis writes:
> On Thu, 2024-07-18 at 07:00 -0700, Noah Misch wrote:
>> Maybe someone will change
>> something in v18 so it's not like that, but don't count on it.
> That's backwards. If nothing happens in v18, then there will be no
> breaking Unicode change. It takes an active step by a com
On Thu, 2024-07-18 at 07:00 -0700, Noah Misch wrote:
> Given all the messages on this thread, if the feature remains in
> PostgreSQL, I
> advise you to be ready to tolerate PostgreSQL "routinely updating the
> built-in
> provider to adopt any changes that Unicode makes".
You mean messages from me,
On Wed, Jul 10, 2024 at 5:01 PM Robert Haas wrote:
> Here is a draft patch that attempts to fix this problem. I'm not
> certain that it's completely correct, but it does seem to fix the
> reported issue.
I tried to write a test case for this and discovered that there are
actually two separate pro
> Okay, that is very interesting. Yes, we will have no problem reproducing the
> exact license text in the source code. I think we can remove the license
> issue
> as a blocker for this patch.
Hi,
I was wondering if I can I get a review please. I am interested in the refactor
question for the
On 2024/07/18 19:49, Hayato Kuroda (Fujitsu) wrote:
Shouldn't this test also check if the returned user_name is valid?
You meant to say that we should print the user_name, right? Done.
Yes, I think it's better to test if the value in the user_name column is as
expected.
- I found an in
On Thu, Jul 18, 2024 at 9:47 AM Fujii Masao wrote:
> "WAL not generated under wal_level=minimal" sounds a bit confusing??
> How about "WAL generated while wal_level is replica or higher" instead?
Committed and back-patched to 17 with approximately that change, but
reworded slightly to make the te
Hi Floris,
> On Jul 18, 2024, at 21:36, Floris Van Nee wrote:
>
>
>> I also encountered the similar performance issue with temporary tables
>> andprovided a patch to optimize the truncate performance during commit
>> in [1].
>
> Interesting, that is definitely another good way to improve the p
On Thu, 2024-07-18 at 07:00 -0700, Noah Misch wrote:
> What I am against is routinely updating the built-in provider to adopt any
> changes
> > that Unicode makes.
>
> Given all the messages on this thread, if the feature remains in PostgreSQL, I
> advise you to be ready to tolerate PostgreSQL "
On 7/18/24 10:23, Nazir Bilal Yavuz wrote:
On Thu, 18 Jul 2024 at 17:01, Joe Conway wrote:
So perhaps I am back to needing more storage...
You might not need more storage. Thomas knows better, but AFAIU, CFBot
will pull only sonoma images after the patch in this thread gets
merged. And your s
On Thu, Jul 18, 2024 at 4:11 PM Richard Guo wrote:
> On Thu, Jul 18, 2024 at 4:00 PM Alexander Lakhin wrote:
> > Please look at a recent buildfarm failure [1], which shows some
> > instability of that test addition:
> > -- the joinrel is not parallel-safe due to the OFFSET clause in the
> > su
Hi,
On Thu, 18 Jul 2024 at 17:01, Joe Conway wrote:
>
> On 7/18/24 08:55, Nazir Bilal Yavuz wrote:
> > Hi,
> >
> > On Thu, 18 Jul 2024 at 15:00, Joe Conway wrote:
> >>
> >> On 7/18/24 07:55, Joe Conway wrote:
> >> > On 7/18/24 04:12, Nazir Bilal Yavuz wrote:
> >> >> Could it be pulling the ''mac
On 7/18/24 08:55, Nazir Bilal Yavuz wrote:
Hi,
On Thu, 18 Jul 2024 at 15:00, Joe Conway wrote:
On 7/18/24 07:55, Joe Conway wrote:
> On 7/18/24 04:12, Nazir Bilal Yavuz wrote:
>> Could it be pulling the ''macos-runner:sonoma' image on every run?
>
> Or perhaps since this was the first run it
On Thu, Jul 18, 2024 at 10:05:34AM +0200, Laurenz Albe wrote:
> On Wed, 2024-07-17 at 15:03 -0700, Noah Misch wrote:
> > If I'm counting the votes right, you and Tom have voted that the feature's
> > current state is okay, and I and Laurenz have voted that it's not okay.
>
> Maybe I should expand
On 2024/07/17 22:44, Robert Haas wrote:
On Tue, Jul 16, 2024 at 1:16 PM Fujii Masao wrote:
I don't have another solution that can be pushed into v17. I understand
the risks raised so far, so I'm okay with just pushing the "fast_forward" patch.
It might be helpful to add a note to the summari
> I also encountered the similar performance issue with temporary tables
> andprovided a patch to optimize the truncate performance during commit
> in [1].
Interesting, that is definitely another good way to improve the performance,
especially with a large number of temp tables. I think the two o
Hi,
On Thu, 18 Jul 2024 at 15:00, Joe Conway wrote:
>
> On 7/18/24 07:55, Joe Conway wrote:
> > On 7/18/24 04:12, Nazir Bilal Yavuz wrote:
> >> Could it be pulling the ''macos-runner:sonoma' image on every run?
> >
> > Or perhaps since this was the first run it simply needed to pull the
> > image
On Wed, 17 Jul 2024 at 16:09, Andrei Lepikhov wrote:
>
> On 17/7/2024 16:33, Matthias van de Meent wrote:
> > On Wed, 17 Jul 2024 at 05:29, Andrei Lepikhov wrote:
> >> Thanks for the job! I guess you could be more brave and push down also
> >> FILTER statement.
> >
> > While probably not impossib
On 7/18/24 07:55, Joe Conway wrote:
On 7/18/24 04:12, Nazir Bilal Yavuz wrote:
Could it be pulling the ''macos-runner:sonoma' image on every run?
Or perhaps since this was the first run it simply needed to pull the
image for the first time?
The scheduling timing (21:24) looks a lot like what
On 7/18/24 04:12, Nazir Bilal Yavuz wrote:
Hi,
On Thu, 18 Jul 2024 at 07:40, Thomas Munro wrote:
On Thu, Jul 18, 2024 at 9:58 AM Joe Conway wrote:
> On 7/17/24 16:41, Andres Freund wrote:
> > Does "tart pull ghcr.io/cirruslabs/macos-runner:sonoma" as the CI user
> > succeed?
>
> Yes, with ab
On Thu, 18 Jul 2024 at 19:56, Andy Fan wrote:
> I'm curious about why a 'unlikey' change can cause noticeable change,
> especially there is just one function call in the 'if-statement' (I am
> thinking more instrucments in the if-statement body, more changes it can
> cause).
>
> + if (unlike
On Thu, Jul 18, 2024 at 7:40 AM Hayato Kuroda (Fujitsu)
wrote:
>
> Regarding the CheckAlterSubOption(), the ordering is still preserved
> because I preferred to keep some specs. But I can agree that yours
> make codes simpler.
>
It is better to simplify the code in this case. I have taken care of
Hi,
For utility statements defined within a function, the queryTree is
copied to a plannedStmt as utility commands don't require planning.
However, the queryId is not propagated to the plannedStmt. This leads
to plugins relying on queryId like pg_stat_statements to not be able
to track utility sta
Noah Misch wrote:
> If I'm counting the votes right, you and Tom have voted that the feature's
> current state is okay, and I and Laurenz have voted that it's not okay. I
> still hope more people will vote, to avoid dealing with the tie. Daniel,
> Peter, and Jeremy, you're all listed as
Hi,
While answering one of the recent questions [1] I wanted to use
crc32(text) and discovered that it's missing out-of-the box. Of
course, one can use `substr(md5(x), 1, 8)` with almost the same effect
but it's less convenient and could be slower (I didn't do actual
benchmarks though). Also it's
Hi,
On Wed, 17 Jul 2024 at 23:41, Noah Misch wrote:
>
> On Wed, Jul 17, 2024 at 12:22:49PM +0300, Nazir Bilal Yavuz wrote:
> > On Tue, 16 Jul 2024 at 15:19, Noah Misch wrote:
> > > On Tue, Jul 16, 2024 at 02:11:20PM +0300, Nazir Bilal Yavuz wrote:
> > > > On Fri, 12 Jul 2024 at 02:52, Noah Misch
On Wed, 10 Jul 2024 at 22:58, Tomas Vondra
wrote:
> IIRC long time ago VACUUM FULL actually worked in a similar way, i.e. by
> moving rows around. I'm not sure if it did the lock-free thing as
> proposed here (probably not), but I guess at least some of the reasons
> why it was replaced by CLUSTER
On Thu, 18 Jul 2024 at 22:28, Ashutosh Bapat
wrote:
>
> On Thu, Jul 18, 2024 at 3:33 PM David Rowley wrote:
> > hmm? please tell me what word other than "can" best describes
> > something that is possible to happen but does not always happen under
> > all circumstances.
>
> May I suggest "may"? :
Dear Fujii-san,
Hi, long time no see :-).
Thanks for reviewing the patch! PSA new version.
> I've just started reviewing them.
>
> Here are the review comments for 0001 patch:
>
> Do we really need postgres_fdw_verify_connection_all()? The proposed feature
> aims to check if all postgres_fdw co
> Let me share my opinion on those questions ...
Thanks! I could understand the patch well thanks to your comments.
> On 7/12/24 12:09, masahiro.ik...@nttdata.com wrote:
> > Is it better to make the order of output consistent? For example, even
> > though there are three clauses shown in the be
On Thu, Jul 18, 2024 at 3:33 PM David Rowley wrote:
>
> On Thu, 18 Jul 2024 at 21:24, Ashutosh Bapat
> wrote:
> > If those GUCs are enabled, the planner consumes large amount of memory
> > and also takes longer irrespective of whether partitionwise plan is
> > used or not. That's why the default
On Tue, 16 Jul 2024 at 13:28, David G. Johnston
wrote:
> Add another note to caveats in the docs and call it a feature. We produce a
> valid answer for the data model encountered. The non-determinism isn’t
> wrong, it’s just a poorly written query/model with non-deterministic results.
> Since
Hi,
this patch is still on the table, though for v18 now.
Nathan mentioned up-thread that he was hesitant to commit this without
further discussion. Laurenz, Stephen and I are +1 on this, but when it
comes to committers having chimed in only Tom did so far and was -1.
Are there any others who h
On Thu, Jul 18, 2024 at 3:30 PM Nitin Motiani wrote:
>
> On Thu, Jul 18, 2024 at 3:25 PM Nitin Motiani wrote:
> >
> > On Thu, Jul 18, 2024 at 3:05 PM Nitin Motiani
> > wrote:
> > >
> > > On Wed, Jul 17, 2024 at 5:25 PM vignesh C wrote:
> > > >
> > > > I tested these scenarios, and as you expec
On Thu, 18 Jul 2024 at 21:24, Ashutosh Bapat
wrote:
> If those GUCs are enabled, the planner consumes large amount of memory
> and also takes longer irrespective of whether partitionwise plan is
> used or not. That's why the default is false. If majority of those
> joins use nested loop memory, or
On Thu, Jul 18, 2024 at 3:25 PM Nitin Motiani wrote:
>
> On Thu, Jul 18, 2024 at 3:05 PM Nitin Motiani wrote:
> >
> > On Wed, Jul 17, 2024 at 5:25 PM vignesh C wrote:
> > >
> > > I tested these scenarios, and as you expected, it throws an error for
> > > the create publication case:
> > > 2024-0
On Thu, Jul 18, 2024 at 3:05 PM Nitin Motiani wrote:
>
> On Wed, Jul 17, 2024 at 5:25 PM vignesh C wrote:
> >
> > I tested these scenarios, and as you expected, it throws an error for
> > the create publication case:
> > 2024-07-17 14:50:01.145 IST [481526] 481526 ERROR: could not receive
> > d
On 2024-Jul-18, David HJ wrote:
> As a long-time PostgreSQL user, I've increasingly run into issues with the
> 63-byte limit for identifiers, particularly table names. This limit, while
> historically sufficient, is becoming a significant pain point in modern
> database design and usage.
This has
On Wed, Jul 17, 2024 at 5:25 PM vignesh C wrote:
>
> On Wed, 17 Jul 2024 at 11:54, Amit Kapila wrote:
> >
> > On Tue, Jul 16, 2024 at 6:54 PM vignesh C wrote:
> > >
> > > On Tue, 16 Jul 2024 at 11:59, Amit Kapila wrote:
> > > >
> > > > On Tue, Jul 16, 2024 at 9:29 AM Amit Kapila
> > > > wrote
Hi David,
> As a long-time PostgreSQL user, I've increasingly run into issues with the
> 63-byte limit for identifiers, particularly table names. This limit, while
> historically sufficient, is becoming a significant pain point in modern
> database design and usage.
I can understand your pain.
On Thu, Jul 18, 2024 at 4:03 AM David Rowley wrote:
>
> Over on [1], there's a complaint about a query OOMing because the use
> of enable_partitionwise_aggregate caused a plan with 1000 Hash
> Aggregate nodes.
>
> The only mention in the docs is the additional memory requirements and
> CPU for que
On Wed, Jul 17, 2024 at 11:32:49AM +0200, Anthonin Bonnefoy wrote:
> Wouldn't it be enough to call pgstat_report_query_id in ExecutorRun
> and ProcessUtility? With those changes [1], both normal statements and
> utility statements called through extended protocol will correctly
> report the query_i
Hi, here are some review comments for v19-0002
==
src/backend/replication/logical/tablesync.c
make_copy_attnamelist:
nitpick - tweak function comment
nitpick - tweak other comments
~~~
fetch_remote_table_info:
nitpick - add space after "if"
nitpick - removed a comment because logic is self-
*The Current Situation*
As a long-time PostgreSQL user, I've increasingly run into issues with the
63-byte limit for identifiers, particularly table names. This limit, while
historically sufficient, is becoming a significant pain point in modern
database design and usage.
*Real-World Examples*
The
Hi,
On Thu, 18 Jul 2024 at 07:40, Thomas Munro wrote:
>
> On Thu, Jul 18, 2024 at 9:58 AM Joe Conway wrote:
> > On 7/17/24 16:41, Andres Freund wrote:
> > > Does "tart pull ghcr.io/cirruslabs/macos-runner:sonoma" as the CI user
> > > succeed?
> >
> > Yes, with about 25 GB to spare.
>
> Thanks.
On Thu, Jul 18, 2024 at 4:00 PM Alexander Lakhin wrote:
> Please look at a recent buildfarm failure [1], which shows some
> instability of that test addition:
> -- the joinrel is not parallel-safe due to the OFFSET clause in the subquery
> explain (costs off)
> select * from tenk1 t1, (s
On Wed, 2024-07-17 at 15:03 -0700, Noah Misch wrote:
> If I'm counting the votes right, you and Tom have voted that the feature's
> current state is okay, and I and Laurenz have voted that it's not okay.
Maybe I should expand my position.
I am very much for the built-in CTYPE provider. When I sa
Hello Richard,
12.07.2024 05:29, Richard Guo wrote:
On Sat, Jul 6, 2024 at 5:32 PM Richard Guo wrote:
Here is a new rebase.
I'm planning to push it next week, barring any objections.
Pushed.
Please look at a recent buildfarm failure [1], which shows some
instability of that test addition:
> On 17 Jul 2024, at 23:32, Nathan Bossart wrote:
> On Wed, Jul 17, 2024 at 11:16:59PM +0200, Daniel Gustafsson wrote:
>> +static void
>> +dispatch_query(const ClusterInfo *cluster, AsyncSlot *slot,
>>
>> + pg_free(query);
>> +}
>>
>> A minor point, perhaps fueled by me not having play
Ashutosh Bapat writes:
> On Fri, Jul 12, 2024 at 11:59 AM Ashutosh Bapat
> wrote:
>>
>>
> Out of curiosity, I measured the performance with just the "unlikely"
> change and with the full patch. Below are the results
> Testing with 100 partitions
...
> latency average = 333.538 ms
>
> with ju
> On 18 Jul 2024, at 09:29, Michael Paquier wrote:
> How about using a new error code in class 58, say a
> ERRCODE_FILE_NAME_TOO_LONG like in the attached?
> ERRCODE_DUPLICATE_FILE is like that; it exists just for the mapping
> with EEXIST.
Agreed, that's probably a better option.
--
Daniel Gus
1 - 100 of 102 matches
Mail list logo
