On Friday, February 7, 2025 9:06 PM Nisha Moond
wrote:
>
> Attached v72 patches, addressed the above comments as well as Vignesh's
> comments in [2].
> - There are no new changes in patch-002.
Thanks for updating the patch, I have few review comments:
1.
> InvalidateObsoleteReplicationSlots(R
Hi
when I worked on strict expr check patch I found so syntax for named
arguments of cursors supports only our legacy proprietary syntax `argname
:= value`
https://www.postgresql.org/docs/current/plpgsql-cursors.html
I propose to enhancing to ANSI/SQL standard syntax for named arguments
`argnam
hi.
```
drop table if exists idxpart;
create table idxpart (a int, b int, c text) partition by range (a);
create table idxpart1 (like idxpart);
alter table idxpart attach partition idxpart1 for values from (0) to (10);
create index idxpart_c on only idxpart (c) invisible;
create index idxpart1_c o
> Fix CI failure of doc build in v1 patch.
Thanks for the patch! I am +1 for this, but I have a few comments:
1/ In the IDENTITY case, the remote side may not be
able to handle the DEFAULT value. See the example below:
-- on the foreign server
postgres=# CREATE TABLE t2 (id int, c1 text);
CREATE
Hello Robert,
> In general, +1, although I think that the patch needs polishing in a
> bunch of areas.
Thanks for your review!
> Originally, I thought what we wanted was something like a --in-place
> option to pg_combinebackup, allowing the output directory to be the
> same as one of the input d
On Fri, 07 Feb 2025 at 10:31, Alvaro Herrera wrote:
> On 2025-Feb-07, Japin Li wrote:
>
>> Since there is no standard, how do we handle this? I prefer to use
>> the strict mode like passlib.
>
> I definitely like that passlib have documented their thought process
> thoroughly.
>
> I think using t
On 2/8/25 01:23, Tom Lane wrote:
> Tomas Vondra writes:
>> Instead, I was thinking about the "other" joins (if there are any), that
>> may add or remove rows. AFAIK we want to join the dimensions at the
>> place with the lowest cardinality - the discussion mostly assumed the
>> joins would only re
On Wed, 2025-01-15 at 21:01 +1300, David Rowley wrote:
> On Tue, 14 Jan 2025 at 09:09, Jeff Davis wrote:
> > Attached v2.
>
> This needs to be rebased due to b4a07f532.
I moved the patch to the other thread here:
https://www.postgresql.org/message-id/09b325921e50bc3a3217fb01d8eb512c89ee36f1.ca.
On Sun, 2025-01-12 at 14:54 +1300, David Rowley wrote:
> I wonder if there's some other better way of doing this. Would it be
> worth having some function like ExecCopySlotMinimalTuple() that
> accepts an additional parameter so that the palloc allocates N more
> bytes at the end?
Attached a new s
I have been reading the source code of the BgWriter, and there is some
code in BgBufferSync() that I don't fully understand.
In BgBufferSync(), we have the following code:
while (num_to_scan > 0 && reusable_buffers < upcoming_alloc_est)
{
intsync_state = SyncOneBuffer(
Tomas Vondra writes:
> Instead, I was thinking about the "other" joins (if there are any), that
> may add or remove rows. AFAIK we want to join the dimensions at the
> place with the lowest cardinality - the discussion mostly assumed the
> joins would only reduce the cardinality, in which case we'
Hi,
I have a question about the comment of UpdateFullPageWrites() called
at the end of recovery (in StartupXLOG()):
/*
* Update full_page_writes in shared memory and write an XLOG_FPW_CHANGE
* record before resource manager writes cleanup WAL records or checkpoint
* record is w
On 2/7/25 23:43, James Hunter wrote:
> On Fri, Feb 7, 2025 at 12:09 PM Tomas Vondra wrote:
>> ...
>> Yes, I think that's pretty much the idea. Except that I don't think we
>> need to look at the |F| at all - it will have more impact for small |F|,
>> of course, but it doesn't hurt for large |F|.
>
> Nathan Bossart writes:
>> On Fri, Feb 07, 2025 at 01:10:04PM -0500, Tom Lane wrote:
>>> My thought was that duplicating the logic isn't so bad, as attached.
>
>> WFM!
>
> It does fix the problem here, so I'll make it so.
Sorry for the problem and thank you for the fix!
--
Tatsuo Ishii
SRA OSS
On Mon, Feb 3, 2025 at 7:23 AM Sergey Tatarintsev
wrote:
>
> 03.02.2025 14:57, Álvaro Herrera пишет:
> > On 2025-Feb-03, Sergey Tatarintsev wrote:
> >
> >> Thanks for the note. I changed the query in the patch (v2 patch attached)
> >>
> >> Btw, an additional benefit from the patch is that we can u
On Fri, Feb 7, 2025 at 12:09 PM Tomas Vondra wrote:
> ...
> Yes, I think that's pretty much the idea. Except that I don't think we
> need to look at the |F| at all - it will have more impact for small |F|,
> of course, but it doesn't hurt for large |F|.
>
> I think it'll probably need to consider
I wrote:
> I forgot to mention a couple of questions for review:
> Should we adjust the documentation of comparePartial() to promise
> explicitly that partial_key is the same datum returned by extractQuery?
> By my reading, it kind of implies that, but it's not quite black and
> white.
> In the 0
On Thu, Feb 6, 2025 at 1:48 PM Tomas Vondra wrote:
>
> Hi,
>
> Here's a slightly simplified version of the "balancing" patch. I decided
> to stop increasing the nbucket value at runtime, even if the hashtable
> grows larger than the memory limit (which is what we used to calculate
> the initial nb
For many GUCs, special values like -1, "", etc. have some sort of special
meaning, such as disabling the feature. While the documentation seems to
be reasonably good about listing special values, the GUC descriptions are
less consistent. Many GUC descriptions don't state the special values at
all
On 08.02.2025 00:01, Matheus Alcantara wrote:
Em sex., 7 de fev. de 2025 às 17:41, Ilia Evdokimov
escreveu:
Strange, I don't have any problems to apply it on master.
postgres$ git branch
* master
postgres$ git pull
Already up to date.
postgres$ git apply
v6-0001-Clarify-display-of
On Fri, Feb 07, 2025 at 03:57:49PM -0500, Melanie Plageman wrote:
> As for relallfrozen, one of the justifications for adding it to
> pg_class is actually for the visibility it would provide. We have no
> way of knowing how many all-visible but not all-frozen pages there are
> on users' systems wit
Em sex., 7 de fev. de 2025 às 17:41, Ilia Evdokimov
escreveu:
> Strange, I don't have any problems to apply it on master.
>
> postgres$ git branch
> * master
> postgres$ git pull
> Already up to date.
> postgres$ git apply
> v6-0001-Clarify-display-of-rows-and-loops-as-decimal-fraction.p
On Fri, Feb 7, 2025 at 3:38 PM Nathan Bossart wrote:
>
> On Fri, Feb 07, 2025 at 02:21:07PM -0500, Melanie Plageman wrote:
> > On Fri, Feb 7, 2025 at 12:37 PM Nathan Bossart
> > wrote:
> >>
> >> Wouldn't relallvisible be sufficient here? We'll skip all-visible pages
> >> unless this is an anti-
On 07.02.2025 22:59, Matheus Alcantara wrote:
Hi
v6 is not applying on master, could you please rebase?
git apply v6-0001-Clarify-display-of-rows-and-loops-as-decimal-fraction.patch
error: patch failed: src/test/regress/expected/partition_prune.out:3041
error: src/test/regress/expected/partiti
On Fri, Feb 07, 2025 at 02:21:07PM -0500, Melanie Plageman wrote:
> On Fri, Feb 7, 2025 at 12:37 PM Nathan Bossart
> wrote:
>> My first reaction is to question whether
>> it makes send to have two strategies for this sort of thing:
>> autovacuum_vacuum_max_threshold for updates/deletes and this f
> On 7 Feb 2025, at 06:48, Jacob Champion
> wrote:
>
> On Thu, Feb 6, 2025 at 2:02 PM Daniel Gustafsson wrote:
>> Attached is a v46 which is v45 minus the now committed patch.
>
> Thank you! Attached is v47, which creeps ever closer to the finish line.
Great, thanks! Below are a few quick co
On 2/7/25 20:11, James Hunter wrote:
> On Wed, Feb 5, 2025 at 4:23 AM Tomas Vondra wrote:
>>
>> If the requirement is that all "dimensions" only join to the fact table
>> (which in this example would be "A" I think) through a FK, then why
>> would these joins be illegal?
>>
>> ...
>> Essentiall
Hi
I rewrote this patch. Instead of enhancing the main SQL parser, it does
post parser checks of the parse tree.
Now the patch is significantly less invasive (changes are just in plpgsql -
mostly in grammar), and it is smaller (without regress tests it has half
size).
This patch allows the detec
Hi
Em seg., 13 de jan. de 2025 às 17:18, Ilia Evdokimov
escreveu:
> I guess, it's not ideal to modify the existing example in the documentation
> of the v5 patch because readers wouldn't immediately understand why decimal
> fractions appear there. Instead, I'll add a brief note in the documenta
On Sat, 2024-07-27 at 08:34 -0700, Jeff Davis wrote:
> Attached a rough patch for the purposes of discussion. It tracks the
> ctype version separately, but doesn't do anything with it yet.
I'm withdrawing this patch due to a lack of discussion.
I may make a related proposal for v19.
Regards,
On Fri, Feb 7, 2025 at 12:37 PM Nathan Bossart wrote:
>
> On Tue, Oct 22, 2024 at 03:12:53PM -0400, Melanie Plageman wrote:
> > By considering only the unfrozen portion of the table when calculating
> > the vacuum insert threshold, we can trigger vacuums more proactively
> > on insert-heavy tables
> I'm still inlined to think the method table is a good thing to do:
>
> (a) The performance cases I tried seem implausibly bad -- running
> character classification patterns over large fields consisting only
> of
> codepoints over U+07FF.
>
> (b) The method tables seem like a better code organiz
On Wed, Feb 5, 2025 at 4:23 AM Tomas Vondra wrote:
>
> If the requirement is that all "dimensions" only join to the fact table
> (which in this example would be "A" I think) through a FK, then why
> would these joins be illegal?
>
> ...
> Essentially, this defines a "dimension" as a relation that
On Thu, Feb 6, 2025 at 9:47 PM Amit Kapila wrote:
>
> On Fri, Feb 7, 2025 at 2:18 AM Masahiko Sawada wrote:
> >
> > I'd like to confirm what users would expect of this
> > max_conflict_retention_duration option and it works as expected. IIUC
> > users would want to use this option when they want
Nathan Bossart writes:
> On Fri, Feb 07, 2025 at 01:10:04PM -0500, Tom Lane wrote:
>> My thought was that duplicating the logic isn't so bad, as attached.
> WFM!
It does fix the problem here, so I'll make it so.
regards, tom lane
On Fri, Feb 07, 2025 at 01:10:04PM -0500, Tom Lane wrote:
> Nathan Bossart writes:
>> Oops, I was already taking a look at this. I figured it'd just be
>> something like the following, although maybe there's a more elegant way.
>
> Well, the stuff with prev_chars really ought to be skipped as we
Hi,
On 2025-02-07 12:58:38 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I just did pgbench -i 100 -q via ssh and noticed it was *way* slower than I
> > expected. Did it with debian's pgbench, no such issue.
>
> > It's due to this patch.
>
> Oh! The problem is that the hunk
>
> +
Nathan Bossart writes:
> On Fri, Feb 07, 2025 at 12:58:38PM -0500, Tom Lane wrote:
>> Let me have a go at fixing it, and if it turns out to be harder
>> than I think, I'll revert it instead.
> Oops, I was already taking a look at this. I figured it'd just be
> something like the following, altho
On Fri, Feb 07, 2025 at 12:58:38PM -0500, Tom Lane wrote:
> Let me have a go at fixing it, and if it turns out to be harder
> than I think, I'll revert it instead.
Oops, I was already taking a look at this. I figured it'd just be
something like the following, although maybe there's a more elegant
On Thu, Feb 6, 2025 at 9:30 PM Amit Kapila wrote:
>
> On Fri, Feb 7, 2025 at 12:11 AM Masahiko Sawada wrote:
> >
> > On Wed, Feb 5, 2025 at 10:17 PM Amit Kapila wrote:
> > >
> > > On Thu, Feb 6, 2025 at 12:30 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > I've updated the patch accordingly.
>
Andres Freund writes:
> I just did pgbench -i 100 -q via ssh and noticed it was *way* slower than I
> expected. Did it with debian's pgbench, no such issue.
> It's due to this patch.
Oh! The problem is that the hunk
+ /*
+* If the previous progress message is longer than the cur
On Fri, Feb 07, 2025 at 12:28:16PM -0500, Andres Freund wrote:
> I just did pgbench -i 100 -q via ssh and noticed it was *way* slower than I
> expected. Did it with debian's pgbench, no such issue.
>
> It's due to this patch.
>
> /srv/dev/build/m-opt/src/bin/pgbench/pgbench -i -s 10 -Idtg -h /tm
On Tue, Oct 22, 2024 at 03:12:53PM -0400, Melanie Plageman wrote:
> By considering only the unfrozen portion of the table when calculating
> the vacuum insert threshold, we can trigger vacuums more proactively
> on insert-heavy tables. This changes the definition of
> insert_scale_factor to a perce
Hi,
On 2024-11-26 01:32:10 +0900, Fujii Masao wrote:
> On 2024/11/25 8:31, Tatsuo Ishii wrote:
> > Now that two minor releases are out, are you going to commit and
> > back-patch this?
>
> Yes, I will.
>
> But, the patch didn't apply cleanly to some back branches, so I've created
> and attached up
Tomas Vondra writes:
> On 2/7/25 01:15, Tom Lane wrote:
>> The end result of doing so is that the added opfamily members
>> wouldn't have been bound tightly to the opclass, but that does
>> not seem like a huge deal in context. They'd still have worked
>> fine AFAIK.
> I haven't tried but I assu
... at
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=572ec03cbec4690eeb5c1047b378626fe475d218
Please send comments/corrections by Sunday.
regards, tom lane
Hi Team,
A few updates regarding the meson build.
We have successfully resolved issues with the meson build on AIX, allowing the
meson configure and build to succeed.
A problem was addressed in the meson script wrt AIX (to build a nested shared
libraries), specifically in the symbolextractor.py
On Feb 7, 2025 at 22:24 +0800, Zhang Mingli , wrote:
> On Feb 6, 2025 at 18:09 +0800, Zhang Mingli , wrote:
> > On Feb 3, 2025 at 08:29 +0800, Michael Paquier , wrote:
> > > On Mon, Feb 03, 2025 at 06:22:13AM +0800, Mingli Zhang wrote:
> > > > Yes, I would like to provide a patch.
> > > >
> > > > G
On 2/7/25 01:15, Tom Lane wrote:
> Tomas Vondra writes:
>> Which is why PostGIS devs chose a different path - updating the catalogs
>> to modify the opclass definition [3], using this script [4].
>
>> That's a bit ... terrifying.
>
> Indeed. Did it not occur to them to use ALTER OPERATOR FAMILY
On 04.02.25 14:31, Peter Eisentraut wrote:
On 03.02.25 12:08, Peter Eisentraut wrote:
Yeah, actually this turned out to be unnecessary, because you can
easily obtain the AM OID from the passed-in opclass ID. So I have
fixed it that way. I have committed this whole patch set now with the
ment
On Thu, Feb 6, 2025 at 9:39 AM Peter Smith wrote:
>
> Hi Shubham.
>
> Here are some review comments for v3-0001.
>
> FYI, I skipped the review of the test code because I saw Kuroda-san
> had already posted some comments about the tests
>
> ==
> Commit message
>
> 1.
> This patch enhances the '
On Thu, Feb 6, 2025 at 7:37 AM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Shubham,
>
> Thanks for working on it. I have some comments for the patch.
>
> 01. fetch_all_databases
> ```
> +/* Placeholder function to fetch all databases from the publisher */
> +static void
> +fetch_all_databases(struct C
On Wed, Feb 5, 2025 at 5:31 PM Shlok Kyal wrote:
>
> On Wed, 5 Feb 2025 at 01:26, Shubham Khanna
> wrote:
> >
> > On Tue, Feb 4, 2025 at 3:49 PM Ashutosh Bapat
> > wrote:
> > >
> > > Hi Shubham,
> > >
> > > On Tue, Feb 4, 2025 at 2:10 PM Shubham Khanna
> > > wrote:
> > > > > >
> > > > >
> > >
As I have promised to Andres on the Discord hacking server some time
ago, I'm attaching the very brief (and potentially way too rushed)
draft of the first step into NUMA observability on PostgreSQL that was
based on his presentation [0]. It might be rough, but it is to get us
started. The patches w
On Feb 6, 2025 at 18:09 +0800, Zhang Mingli , wrote:
> On Feb 3, 2025 at 08:29 +0800, Michael Paquier , wrote:
> > On Mon, Feb 03, 2025 at 06:22:13AM +0800, Mingli Zhang wrote:
> > > Yes, I would like to provide a patch.
> > >
> > > Glad to see we have come to an agreement on this.
> >
> > Just add
> On 9 Jan 2025, at 13:50, Daniel Gustafsson wrote:
>
>> On 7 Jan 2025, at 19:25, Darek Ślusarczyk wrote:
>
>> Thanks for reviewing the patch - I've added a few changes and it looks as
>> follows:
>
> Thanks for the new version, I've tested it in CI against v17 and plan to
> commit
> it soon
On Fri, Feb 7, 2025 at 3:25 PM Pavel Stehule wrote:
>
Hi
The following review is based on v20250117.
pg_dump order seems not right.
CREATE FUNCTION public.test11(text) RETURNS text
LANGUAGE sql
AS $$select v4 $$;
CREATE VARIABLE public.v4 AS text;
first dump function then variable. rest
On Fri, Feb 7, 2025 at 8:00 AM Peter Smith wrote:
>
> Hi Nisha,
>
> Some review comments for v71-0001.
>
> ==
> src/backend/replication/slot.c
>
> SlotInvalidationCauses[]
>
> 2.
> [RS_INVAL_WAL_REMOVED] = "wal_removed",
> [RS_INVAL_HORIZON] = "rows_removed",
> [RS_INVAL_WAL_LEVEL] = "wa
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Tue, 4 Feb 2025 22:20:51 -0800,
Masahiko Sawada wrote:
>> I was just looking at bit at this series of patch labelled with v31,
>> to see what is happening here.
>>
>> In 0001, we have that:
>>
>> + /*
On 06.02.25 14:03, vignesh C wrote:
One suggestion: for the option where the user specifies
publish_generated_columns as virtual (as shown below), could we change
the error indicating that virtual generated columns are not currently
supported?
CREATE PUBLICATION pub1 FOR TABLE t1 WITH (publish_ge
On 06.02.25 00:25, Dean Rasheed wrote:
On Tue, 4 Feb 2025 at 22:36, Peter Eisentraut wrote:
Yeah, this is quite contorted. I have renamed it like you suggested.
I looked over this again and I think the patch is in good shape to be committed.
I've committed it. Thanks.
One thought that
On Fri, Feb 7, 2025 at 1:24 PM Yura Sokolov wrote:
> 07.02.2025 14:02, Yura Sokolov пишет:
> > 07.02.2025 01:26, Alexander Korotkov пишет:
> >> Hi!
> >>
> >> On Sun, Jan 19, 2025 at 2:11 AM Yura Sokolov
> >> wrote:
> >>>
> >>> During discussion of Increasing NUM_XLOGINSERT_LOCKS [1], Andres Freu
07.02.2025 14:02, Yura Sokolov пишет:
> 07.02.2025 01:26, Alexander Korotkov пишет:
>> Hi!
>>
>> On Sun, Jan 19, 2025 at 2:11 AM Yura Sokolov
>> wrote:
>>>
>>> During discussion of Increasing NUM_XLOGINSERT_LOCKS [1], Andres Freund
>>> used benchmark which creates WAL records very intensively. Wh
Recursion to child tables is incorrectly trying to locate the constraint
by name:
create table notnull_tbl1 (a int);
alter table notnull_tbl1 add constraint foo not null a not valid;
create table notnull_chld (a int);
alter table notnull_chld add constraint blah not null a not valid;
alter table
07.02.2025 01:26, Alexander Korotkov пишет:
> Hi!
>
> On Sun, Jan 19, 2025 at 2:11 AM Yura Sokolov wrote:
>>
>> During discussion of Increasing NUM_XLOGINSERT_LOCKS [1], Andres Freund
>> used benchmark which creates WAL records very intensively. While I this
>> it is not completely fair (1MB log
Hi,
> > What if we automatically move any patches to the current commitfest if new
> > patch attachments are sent to the corresponding message thread? Heck,
> > perhaps if there are any new messages *at all* in the message thread, and
> > the commitfest entry has not been closed already, we should
> On 7 Feb 2025, at 02:05, Tom Lane wrote:
>
> Do you have any further comments on this patch?
No, all steps of the patch set look good to me.
Best regards, Andrey Borodin.
On Mon, 3 Feb 2025 at 17:51, Dmitry Koterov wrote:
>
> Here is the list of tmp files:
>
> postgres@pg-101a:~/17/main/base/pgsql_tmp$ ls -la
> total 5422297
> drwx-- 2 postgres postgres 9 Feb 3 04:08 .
> drwx-- 8 postgres postgres 8 Jan 29 01:27 ..
> -rw--- 1 postgres
On 2025-Feb-07, Japin Li wrote:
> Since there is no standard, how do we handle this? I prefer to use
> the strict mode like passlib.
I definitely like that passlib have documented their thought process
thoroughly.
I think using their strict mode is good on principle, but if we're going
to do th
On 2025-Jan-13, David G. Johnston wrote:
> Hackers,
>
> Should the following paragraph in the docs be modified to point out minimum
> server version of v17 for incremental backups?
>
> pg_basebackup works with servers of the same or an older major version,
> down to 9.1. However, WAL streaming mo
> On 7 Feb 2025, at 06:54, Daniil Davydov <3daniss...@gmail.com> wrote:
>
> On Thu, Feb 6, 2025 at 8:23 PM Daniel Gustafsson wrote:
>>
>> You should include the configure.ac changes and not just the generated code
>> in
>> configure (which is fine to include for review, but the committer will
>
> On 7 Feb 2025, at 08:04, Saladin <312199...@qq.com> wrote:
>
> Dear pgsql-hackers,
>
> While reviewing the code of pg_amcheck, I discovered a potential issue that
> could lead to a memory leak. Specifically, there is a missing PQclear(result)
> call before the database connection is disconnec
On Thu, 06 Feb 2025 at 11:20, Alvaro Herrera wrote:
> On 2025-Jan-28, Bernd Helmle wrote:
>
>> Python's passlib is very strict when it comes to supported characters
>> within a salt string. It rejects everything thats not matching '[./0-
>> 9A-Za-z]'. So when you provide the example above you get
Hi,
On Wed, Feb 05, 2025 at 10:59:22AM -0800, Masahiko Sawada wrote:
> On Tue, Feb 4, 2025 at 11:48 PM Bertrand Drouvot
> wrote:
> > + if (SlotIsLogical(s) && !EnableHotStandby)
> > + ereport(FATAL,
> > + (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
> > + e
Hi!
You most probably know, that you can't build coverage for check-world test
with clang. Postgreses tests are heavy, clang profile writer uses weak hash to
generate profile file names, and you will get hash collision if you try run
postgres tests, profile files will be broken and everything
75 matches
Mail list logo
