On Sat, 21 Jun 2025 at 22:21, Tom Lane wrote:
>
> The attached patch does what was discussed in the pgsql-docs
> thread at [1], namely change the four-argument variants of
> width_bucket() to allow their first argument to be NaN,
> treating that value as larger than any non-NaN.
>
LGTM.
I note t
Hi,
I encountered an invalid pointer access issue. Below are the steps to
reproduce the issue:
-- Create table
CREATE TABLE t1(c1 int, c2 int);
-- Create publications with each publication selecting a different column
CREATE PUBLICATION pub1 for TABLE t1(c1);
CREATE PUBLICATION pub2 for TABLE t1
Hi,
On Tue, Jul 01, 2025 at 07:46:30PM +0200, Tomas Vondra wrote:
> On 7/1/25 19:20, Bertrand Drouvot wrote:
> > Now it's just a matter of extracting the necessary pieces from
> > pg_buffercache_numa_pages()
> > so that:
> >
> > * the new view could make use of it
> > * the maintenance burden sh
On Mon, Jun 23, 2025 at 4:24 PM Shinya Kato wrote:
>
> On Wed, Jun 11, 2025 at 1:49 PM Shinya Kato wrote:
>>
>> On Thu, Jun 5, 2025 at 3:53 AM Sami Imseih wrote:
>>>
>>> > Approach 2:
>>> > - log_autovacuum_min_duration: Changed behavior, which controls only
>>> > autovacuum logging.
>>> > - log
On Wed, Jul 2, 2025 at 3:34 AM Melanie Plageman
wrote:
>
> On Tue, Jul 1, 2025 at 12:01 AM Masahiko Sawada wrote:
> >
> > I've attached the updated patches for master and backbranches (v17 and
> > v18). Please review these patches.
>
> All look good to me. One nitpick that is up to you if you wan
On Wed, Jul 2, 2025 at 10:22 AM Aya Iwata (Fujitsu)
wrote:
>
...
>
> > reloptions.c
> > --
> > - Changes that should be moved to the contrib module Why should in-core
> > reloptions know about this? See for example how "contrib/bloom" defined
> > reloptions.
>
> Thanks. We are stud
On Tue, Jul 1, 2025 at 1:17 PM Peter Smith wrote:
>
> On Sat, Jun 28, 2025 at 12:24 AM Timur Magomedov
> wrote:
> ...
> > Thanks for updates.
> > I was trying to move some code from Postgres core patch to contrib/vci.
> > Started with moving VCI options from StdRdOptions struct and
> > reloptions
Hi hackers,
While working on [1], I noticed an inconsistency in the pg_buffercache
documentation: ba2a3c2302f1 missed to add "the" before the pg_buffercache_numa()
function introduction.
PFA a tiny patch to add it for consistency purpose. Should be back-patched to
18 where pg_buffercache_numa() h
On Tue, Jul 1, 2025 at 6:10 PM Zhijie Hou (Fujitsu) wrote:
> Here is V45 patch set.
With the main patch set now stable, I am summarizing the performance tests
conducted before for reference.
In earlier tests [1], we confirmed that in a pub-sub cluster with high workload
on the publisher (via pgbe
On 2025-07-01 14:20, Masahiko Sawada wrote:
On Thu, Jun 12, 2025 at 3:47 AM Masahiko Sawada
wrote:
On Tue, Jun 10, 2025 at 1:33 PM Nathan Bossart
wrote:
>
> On Tue, Jun 10, 2025 at 12:37:48PM -0700, Masahiko Sawada wrote:
> >> > (1) adds tab completion support for the REJECT_LIMIT option, w
On Mon, Jun 30, 2025 at 4:24 PM Yugo Nagata wrote:
>
>
> > > I have a few minor comment on the patch.
> > >
> > > + if (ival < 0)
> > > + ereport(ERROR,
> > > +
> > > (errcode(ERRCODE_INV
Hi All,
The failover slots documentation [1] is good for PG - PG logical
replication, but the first two queries require pg_subscription which
may not be present in non-PG downstream. Somebody looking to setup
failover slots for non-PG subscriber may not find the page useful.
However, the third que
On Fri, Jun 27, 2025 at 03:28:18PM +0300, Mikhail Gribkov wrote:
> Attached is the updated version of the patch with test additions.
Thanks for the updated versions. A bit more variance with the LZ4
levels, even if we cannot track everything, does not sound like a bad
thing to me for the server-s
On Wed, Jul 2, 2025 at 12:01 AM David G. Johnston
wrote:
> On Tue, Jul 1, 2025 at 8:31 PM Jianghua Yang wrote:
>>
>> git show 8e673801262c66af4a54837f63ff596407835c20
>>
>>
>> effective_user = get_id();
>>
>> - if (strlen(username) == 0)
>>
>> + if (!username)
>>
>>
On Mon, Jun 30, 2025 at 3:57 PM torikoshia wrote:
>
> >> ```
> >> scan_rel = table_open(scan_oid,
> >> AccessShareLock);
> >>
> >> CopyThisRelTo(cstate, scan_rel, cstate->rel,
> >> &processed);
> >>
> >> table_close(scan
On Tue, Jul 1, 2025 at 3:39 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Tue, Jul 1, 2025 at 5:07 PM Dilip Kumar wrote:
> >
> > On Tue, Jul 1, 2025 at 2:24 PM Amit Kapila wrote:
> > >
> > > On Tue, Jul 1, 2025 at 10:53 AM Dilip Kumar wrote:
> > > >
> > > > On Tue, Jul 1, 2025 at 10:31 AM Dilip Kumar
>
On Tue, Jul 1, 2025 at 7:12 PM Amit Langote wrote:
>
> Hi Dilip,
>
> Happy to see you working on this. It’s clear a lot of thought has
> gone into the design.
Thanks, Amit. And thanks for your comment.
> On Tue, Jul 1, 2025 at 6:27 PM Dilip Kumar wrote:
> > 6) Need to perform a performance t
We try to stick with plain text and inline/bottom replies here.
On Tue, Jul 1, 2025 at 8:31 PM Jianghua Yang wrote:
> git show 8e673801262c66af4a54837f63ff596407835c20
>
>
> effective_user = get_id();
>
> - if (strlen(username) == 0)
>
> + if (!username)
>
> u
Hello hackers,
Please take a look at the June report on buildfarm failures:
# SELECT br, COUNT(*) FROM failures WHERE dt >= '2025-06-01' AND
dt < '2025-07-01' GROUP BY br;
REL_13_STABLE: 4
REL_14_STABLE: 3
REL_15_STABLE: 4
REL_16_STABLE: 6
REL_17_STABLE: 4
REL_18_STABLE: 1
master: 54
-- Total: 7
HI
> - if (!extra->inner_unique && (jointype == JOIN_SEMI ||
> - jointype == JOIN_ANTI))
> + if ((jointype == JOIN_SEMI || jointype == JOIN_ANTI) &&
> + !extra->inner_unique)
To be nitpicky, this change is meant to align with the earlier comment
modifications to improve code readability, right? Ev
On Thu, 26 Jun 2025 at 03:21, Aleksander Alekseev
wrote:
>
> Hi,
>
> > Ugh... Turns out it was a bug, there definitely should be a "New
> > patch" button on both the 19-1 and on the Drafts page. And there
> > was... but only if you were logged in as a staff user.
>
> There is now a "New patch" but
git show 8e673801262c66af4a54837f63ff596407835c20
effective_user = get_id();
- if (strlen(username) == 0)
+ if (!username)
username = effective_user;
The previous code already intended to treat a missing username as falling
back to the system user.
The chec
HI
> 2.
> Perhaps decide_wal_file_action() could be defined in filemap.c.
> While this is unrelated to WAL logging, it could also contribute to
faster
> pg_rewind operations. Should we consider ignoring log files under PGDATA
> (e.g., those in the default log/ directory)?
Agree ，Usually the lo
On Tue, Jul 1, 2025 at 7:56 PM Jianghua Yang wrote:
> Let me know if this approach seems reasonable or if you’d prefer we
> explicitly reject empty usernames with an error instead.
>
>
I'd rather we reject the ambiguous input.
David J.
Hi hackers,
While working with `initdb`, I noticed that passing an empty string to the
`-U` option (e.g., `initdb -U ''`) causes it to fail with a misleading
error:
performing post-bootstrap initialization ... 2025-07-01 19:48:42.006 PDT
[14888] FATAL: role """ does not exist at character 72
2
Hello hackers,
While updating an extension to support 18beta1, I stumbled on the removal
of `pg_attribute_noreturn()` in favor of `pg_noreturn`, which wasn't
mentioned in the release notes.
I've attached a patch for fixing this.
Best regards,
Steve Chavez
From 52c479141457ab9d7fee1a5ac8b3184a35c
On Tue, 01 Jul 2025 at 11:13, John H wrote:
> Hi,
>
> I've attached an updated version of the patch against master with the changes
> suggested.
>
> On Tue, Nov 29, 2022 at 10:03 PM Michael Paquier wrote:
>>
>> On Thu, Oct 06, 2022 at 04:08:45PM +0900, Michael Paquier wrote:
>>>
>>> There may be
On Fri, Jun 27, 2025 at 1:34 PM Fujii Masao wrote:
>
> > To do that, we need
> > 1. we checked that COMMENTS on policies, the TocEntry->tag begins with
> > "POLICY". which is true, see above code walk through.
> > 2. We also need to make sure that no other dumpComment call results in a
> > COMMENT
On Thu, Apr 10, 2025 at 7:36 PM Richard Guo wrote:
> On Wed, Apr 9, 2025 at 6:18 PM David Rowley wrote:
> > On Wed, 9 Apr 2025 at 18:48, Richard Guo wrote:
> > > Perhaps we could spend some planner cycles proving inner_unique for
> > > anti joins, so that Memoize nodes can be considered for them
Michael Paquier writes:
Hi,
> On Wed, Jul 02, 2025 at 12:38:01AM +, Andy Fan wrote:
>> However this is not true in BootstrapMode, this failure is masked by
>> default because TransactionTreeSetCommitTsData returns fast when
>> track_commit_timestamp is off.
>
> Agreed that there is no point
On Tue, Jul 1, 2025 at 10:57 PM Andrei Lepikhov wrote:
> I like the general idea of this work. But I wonder, why is a new hash
> table designed to store only the notnullattnums field? From the
> discussion, it is not apparent why not to cache all (or most of) the
> data needed for get_relation_inf
On Wed, Jun 18, 2025 at 02:13:27PM +0900, Michael Paquier wrote:
> v3 seems sensible here. Thanks for the updated patch.
I did a new pass over that. All the code blocks moved to the new file
are identical. However, it is really easy to miss the change in
bytea_string_agg_transfn() with the remo
Hi,
When working with the commit_ts module, I find the following issue:
After configure with --enable-cassert option, then initdb with:
initdb -D x2 -c track_commit_timestamp=on
Then we can get the following core dump:
0 in raise of /lib/x86_64-linux-gnu/libc.so.6
1 in abort of /lib/x86_64-
On Wed, Jul 02, 2025 at 12:38:01AM +, Andy Fan wrote:
> However this is not true in BootstrapMode, this failure is masked by
> default because TransactionTreeSetCommitTsData returns fast when
> track_commit_timestamp is off.
Agreed that there is no point in registering a commit timestamp in
th
Committed.
--
nathan
Hi Tomas-san,
> > - Divide the patch more and more
> > - to allow committers to consider pros and cons and push one by one
> > - 15 patches is the maximum amount
> > - Separate features to some committable group
> >
>
> Yes. Both parts need to be divided into small (but meaningful) pieces.
On Tue, Jul 01, 2025 at 10:01:37PM +0200, Michael Banck wrote:
> On Tue, Jul 01, 2025 at 12:41:50PM -0400, Tom Lane wrote:
>> Pushed, after some fooling with the comments and commit messages.
>
> Thanks! Also for back-patching them.
Catching up on this thread after-the-fact, specifically looking
On Sat, Jun 28, 2025 at 11:44:52AM +0800, cca5507 wrote:
> If I understand correctly, this may break the basic principle:
>
> The aim is to build a snapshot that behaves the same as a
> freshly taken MVCC snapshot would have at the time the
> XLogRecord was generated.
Please note that we prefer
On Mon, Jun 30, 2025 at 03:37:08PM +0300, Sami Imseih wrote:
> rebased patch.
There were two extra pg_stat_statements_reset() calls added to
cursors.sql that were not necessary. I have also cut by one the
number of FETCH queries with the numbers, as it does not change the
coverage outcome, tweake
On Tue, Sep 10, 2024 at 11:49 AM Jacob Champion
wrote:
> I need to switch away from this for a bit.
"a bit"
In an effort to get this unstuck (and ideally solved during this
commitfest) here are my most recent thoughts:
> I agree that PQconsumeInput() needs to ensure that the transport
> buffers
Michael Banck writes:
> On Tue, Jul 01, 2025 at 12:41:50PM -0400, Tom Lane wrote:
> | * If didn't define IOV_MAX, define our own. X/Open requires at
> | * least 16. (GNU Hurd apparently feel that they're not bound by X/Open,
> | * because they don't define this symbol at all.)
> I personally d
Arseniy Mukhin writes:
> I tried the patch and it compiles and works as expected. Several minor
> things I noticed:
Thanks for looking at it!
> 1) btree_gin.c
>case BTEqualStrategyNumber:
> if (cmp > 0)
> res = -1; /* keep scanning */
> else if (cmp
rebased
--
nathan
>From 90985d810f3bed653d3d73553e6236d1f7fb7154 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Mon, 28 Apr 2025 14:52:11 -0500
Subject: [PATCH v3 1/1] Teach pg_upgrade to handle in-place tablespaces.
Presently, pg_upgrade assumes that all non-default tablespaces
don't move
On 7/1/25 19:20, Bertrand Drouvot wrote:
> Hi,
>
> On Tue, Jul 01, 2025 at 06:45:37PM +0200, Tomas Vondra wrote:
>> On 7/1/25 18:34, Bertrand Drouvot wrote:
>>
>> But isn't the _numa view good enough for this? Sure, you need NUMA
>> support for it, and it may take a fair amount of time, but how of
Hi,
On Tue, Jul 01, 2025 at 12:41:50PM -0400, Tom Lane wrote:
> Michael Banck writes:
> > please find attached the current patches required to get master built
> > and the testsuites run on Debian's hurd-i386 port. I have not had the
> > time to test the hurd-amd64 port in the same fashion, but w
Hi Jakub,
FYI I've posted my experimental NUMA patch series here:
https://www.postgresql.org/message-id/099b9433-2855-4f1b-b421-d078a5d82017%40vondra.me
I've considered posting it to this thread, but it seemed sufficiently
different to start a new thread.
regards
--
Tomas Vondra
Hi,
This is a WIP version of a patch series I'm working on, adding some
basic NUMA awareness for a couple parts of our shared memory (shared
buffers, etc.). It's based on Andres' experimental patches he spoke
about at pgconf.eu 2024 [1], and while it's improved and polished in
various ways, it's s
Committed.
--
nathan
On Tue, Jul 1, 2025 at 2:03 PM Heikki Linnakangas wrote:
> I like how this makes row comparisons less special. To be honest I don't
> quite understand what the bug was, I'd have to dig much deeper into this
> to swap enough context into my memory for that.
If you're interested, I can provide you
On Tue, Jul 1, 2025 at 12:01 AM Masahiko Sawada wrote:
>
> I've attached the updated patches for master and backbranches (v17 and
> v18). Please review these patches.
All look good to me. One nitpick that is up to you if you want to
change: the comment
* Return the number of tuples deleted from
Hi,
I've attached an updated version of the patch against master with the changes
suggested.
On Tue, Nov 29, 2022 at 10:03 PM Michael Paquier wrote:
>
> On Thu, Oct 06, 2022 at 04:08:45PM +0900, Michael Paquier wrote:
>>
>> There may be something I am missing here, but there is no need to care
On 01/07/2025 19:37, Peter Geoghegan wrote:
On Fri, Jun 27, 2025 at 5:35 PM Peter Geoghegan wrote:
Attached is v4, which is largely just a polished version of v3. It has
improved comments and more worked out commit messages. Plus the second
patch (the row compare patch) now teaches _bt_first to
> On 1 Jul 2025, at 17:42, Tom Lane wrote:
> There are some minor typos in the proposed commit message, too.
It seems that my grasp of the english language went on holiday before I did.
The attached v9 is hopefully less terrible.
--
Daniel Gustafsson
v9-0001-pg_dump-Fix-compression-API-error
Hi,
On Tue, Jul 01, 2025 at 06:45:37PM +0200, Tomas Vondra wrote:
> On 7/1/25 18:34, Bertrand Drouvot wrote:
>
> But isn't the _numa view good enough for this? Sure, you need NUMA
> support for it, and it may take a fair amount of time, but how often you
> need to do such queries?
Not that often
On Tue, Jul 1, 2025 at 1:15 AM Jelte Fennema-Nio wrote:
>
> Pretending that
> libpq is the "golden standard" for our protocol just seems plain wrong
> to me.
Not what I said. I'm saying that if a server implementation claims
Postgres compatibility but fails to talk to deployed versions of libpq
i
On 17.06.25 20:50, Dean Rasheed wrote:
On Tue, 17 Jun 2025 at 13:56, jian he wrote:
On Tue, Jun 17, 2025 at 7:42 PM Peter Eisentraut wrote:
However, I see your point that it contrasts with the attidentity code
just above.
Perhaps a way to resolve this would be to rewrite the comment someth
On 7/1/25 18:34, Bertrand Drouvot wrote:
> Hi,
>
> On Tue, Jul 01, 2025 at 04:31:01PM +0200, Tomas Vondra wrote:
>> On 7/1/25 15:45, Bertrand Drouvot wrote:
>>
>> I took a quick look on this,
>
> Thanks for looking at it!
>
>> and I doubt we want to change the schema of
>> pg_buffercache like th
Michael Banck writes:
> please find attached the current patches required to get master built
> and the testsuites run on Debian's hurd-i386 port. I have not had the
> time to test the hurd-amd64 port in the same fashion, but will do so
> next.
Pushed, after some fooling with the comments and com
On Fri, Jun 27, 2025 at 5:35 PM Peter Geoghegan wrote:
> Attached is v4, which is largely just a polished version of v3. It has
> improved comments and more worked out commit messages. Plus the second
> patch (the row compare patch) now teaches _bt_first to fully rely on
> scan key requiredness ma
Hi,
On Tue, Jul 01, 2025 at 04:31:01PM +0200, Tomas Vondra wrote:
> On 7/1/25 15:45, Bertrand Drouvot wrote:
>
> I took a quick look on this,
Thanks for looking at it!
> and I doubt we want to change the schema of
> pg_buffercache like this. Adding columns is fine, but it seems rather
> wrong t
Committed.
--
nathan
Daniel Gustafsson writes:
> In preparing for concluding this I've attached a v8 which is the patchset in
> v7
> squashed into a single commit with an attempt at a commit message.
Glancing through this, I observe a couple of minor typos:
+ * Returns number of bytes read (this might be less t
>> Perhaps we should think about removing this description, what do you think?
> I think it's a good topic for another patch/thread. Chances are it's not
> the only description that could be updated.
Sure, that could be taken up after this patch.
> That's what I mean. I think it should say
>
>
> On 1 Jul 2025, at 17:11, Tomas Vondra wrote:
> On 7/1/25 16:24, Daniel Gustafsson wrote:
>> This version has been tested against v17 and v16 where it applies and passes
>> all tests (the latter isn't as assuring as it should be since there is a lack
>> of testcoverage).
>
> Could you elaborate
On 7/1/25 16:24, Daniel Gustafsson wrote:
>> On 26 Jun 2025, at 20:01, Daniel Gustafsson wrote:
>>
>>> On 26 Jun 2025, at 15:33, Tom Lane wrote:
>>
>>> So on the whole I prefer the "void" approach. I'm not dead
>>> set on that though, it's just a niggling worry.
>>
>> I think the likelyhood o
On Wed, 2025-06-11 at 12:15 -0700, Jeff Davis wrote:
> I changed this to a global_libc_locale that includes both LC_COLLATE
> and LC_CTYPE (from datcollate and datctype), in case an extension is
> relying on strcoll for some reason.
..
> This patch series, at least so far, is designed to have zer
Hi,
Thanks for updating the patch and I've read
v17-0001-COPY-on_error-set_null.patch and here are some comments.
+COPY x from stdin (on_error set_null, reject_limit 2);
+ERROR: COPY REJECT_LIMIT requires ON_ERROR to be set to IGNORE
I understand that REJECT_LIMIT is out of scope for this
On 7/1/25 15:45, Bertrand Drouvot wrote:
> Hi,
>
> On Thu, Apr 10, 2025 at 03:05:29PM +, Bertrand Drouvot wrote:
>> Hi,
>>
>> On Thu, Apr 10, 2025 at 09:58:18AM -0500, Nathan Bossart wrote:
>>> On Thu, Apr 10, 2025 at 03:35:24PM +0200, Tomas Vondra wrote:
This seems like a good idea in pr
Hi Ashutosh,
Thanks for the patch.
Ashutosh Bapat , 30 Haz 2025 Pzt, 13:14
tarihinde şunu yazdı:
> The replica identity of a given table is not a property of
> publication, per say, so it's arguable whether it should be included
> in pg_publication_tables or not. But the output seems to be usefu
On 6/26/2025 1:07 PM, Zhou, Zhiguo wrote:
Hi Hackers,
This patch addresses severe LWLock contention observed on high-core systems
where hundreds of processors concurrently access frequently-shared locks.
Specifically for ProcArrayLock (exhibiting 93.5% shared-mode acquires), we
implement a new
> On 26 Jun 2025, at 20:01, Daniel Gustafsson wrote:
>
>> On 26 Jun 2025, at 15:33, Tom Lane wrote:
>
>> So on the whole I prefer the "void" approach. I'm not dead
>> set on that though, it's just a niggling worry.
>
> I think the likelyhood of it being a problem in practice is pretty slim, b
John Naylor writes:
> On Tue, Jul 1, 2025 at 10:36 AM Tom Lane wrote:
>> Hmpfh. No objection to your patch, but I wonder why
>> "headerscheck --cplusplus" didn't find this? Can we get it
>> to do so?
> Good question, and it turns out it catches it just fine, but you have
> to configure with CP
Hi,
On 2025-07-01 09:57:18 -0400, Andres Freund wrote:
> On 2025-06-26 13:07:49 +0800, Zhou, Zhiguo wrote:
> > This patch addresses severe LWLock contention observed on high-core systems
> > where hundreds of processors concurrently access frequently-shared locks.
> > Specifically for ProcArrayLoc
On Tue, Jul 1, 2025 at 4:23 PM Amit Kapila wrote:
>
> On Mon, Jun 30, 2025 at 3:24 PM Ashutosh Bapat
> wrote:
> >
> > Hi All,
> > In a recent logical replication issue, there were multiple replication
> > slots involved, each using a different publication. Thus the amount of
> > data that was rep
On 7/1/25 11:04, Jakub Wartak wrote:
> On Mon, Jun 30, 2025 at 9:23 PM Tomas Vondra wrote:
>>
>> I wasn't suggesting to do "numactl --interleave=all". My argument was
>> simply that doing numa_interleave_memory() has most of the same issues,
>> because it's oblivious to what's stored in the sha
On Tue, 01 Jul 2025 at 13:39, Álvaro Herrera wrote:
> On 2025-Jul-01, Japin Li wrote:
>
>> This inconsistency, while minor, could be confusing when cross-referencing
>> LSNs within pg_waldump's own output or when parsing it programmatically.
>
> I agree that we should fix this, but I'd rather add
On 30/6/2025 09:26, Richard Guo wrote:
On Wed, May 28, 2025 at 6:28 PM Richard Guo wrote:
Yeah, this patchset is targeted for v19. Maybe we could be more
aggressive and have 0001 and 0002 in v18? (no chance for 0003 though)
This patchset does not apply anymore due to 2c0ed86d3. Here is a ne
Hi,
On 2025-06-26 13:07:49 +0800, Zhou, Zhiguo wrote:
> This patch addresses severe LWLock contention observed on high-core systems
> where hundreds of processors concurrently access frequently-shared locks.
> Specifically for ProcArrayLock (exhibiting 93.5% shared-mode acquires), we
> implement a
Hi,
On Thu, Apr 10, 2025 at 03:05:29PM +, Bertrand Drouvot wrote:
> Hi,
>
> On Thu, Apr 10, 2025 at 09:58:18AM -0500, Nathan Bossart wrote:
> > On Thu, Apr 10, 2025 at 03:35:24PM +0200, Tomas Vondra wrote:
> > > This seems like a good idea in principle, but at this point it has to
> > > wait
Hi Dilip,
Happy to see you working on this. It’s clear a lot of thought has
gone into the design.
On Tue, Jul 1, 2025 at 6:27 PM Dilip Kumar wrote:
> 6) Need to perform a performance test, for SELECT/UPDATE/INSERT cases,
> we already know the VACUUM performance.
One point I want to check my un
Hi,
On Tue, Jul 1, 2025 at 5:47 PM Yugo Nagata wrote:
>
> On Mon, 30 Jun 2025 18:32:47 +0700
> Daniil Davydov <3daniss...@gmail.com> wrote:
>
> > On Mon, Jun 30, 2025 at 3:47 PM Yugo Nagata wrote:
> > >
> > > I agree with Tom Lane that the behavior is expected, although it would be
> > > better
On 2025-Jul-01, Japin Li wrote:
> This inconsistency, while minor, could be confusing when cross-referencing
> LSNs within pg_waldump's own output or when parsing it programmatically.
I agree that we should fix this, but I'd rather add the missing zeros
than remove these ones (the only ones we ha
On 7/1/25 06:06, Bertrand Drouvot wrote:
> Hi,
>
> On Mon, Jun 30, 2025 at 08:56:43PM +0200, Tomas Vondra wrote:
>> In particular it now uses "chunking" instead of "batching". I believe
>> bathing is "combining multiple requests into a single one", but we're
>> doing exactly the opposite - split
On Sun, 13 Apr 2025 at 17:40, Abhishek Chanda wrote:
>
> Thanks for the feedback, attached an updated patch that changes most
> of those "Did not find" messages to empty tables. I did not change two
> sets, listDbRoleSettings and listTables both have comments describing
> that these are deliberate
On 04.06.25 08:15, Peter Eisentraut wrote:
On 03.06.25 06:51, Michael Paquier wrote:
Dropping VS 2015 and going up to VS 2019 brings other benefits,
__VA_ARGS__ coming in mind.
Yes, this was going to be my next step. As we're already talking about
it, here is my proposed patch.
For an expl
On Mon, Jun 30, 2025 at 3:24 PM Ashutosh Bapat
wrote:
>
> Hi All,
> In a recent logical replication issue, there were multiple replication
> slots involved, each using a different publication. Thus the amount of
> data that was replicated through each slot was expected to be
> different. However,
On 2025-Jun-30, Nathan Bossart wrote:
> These functions have been around for a while, but commits 48b5aa3 and
> 15afb7d were only back-patched to v16. Any objections if I apply them
> down to v13 now?
None here.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"
On Mon, 30 Jun 2025 18:32:47 +0700
Daniil Davydov <3daniss...@gmail.com> wrote:
> Hi,
>
> On Mon, Jun 30, 2025 at 3:47 PM Yugo Nagata wrote:
> >
> > On Fri, 27 Jun 2025 18:53:02 +0700
> > Daniil Davydov <3daniss...@gmail.com> wrote:
> > > This patch fixes postgres behavior if I first create a fu
On 18.06.25 11:46, Bertrand Drouvot wrote:
Hi,
On Tue, Jun 17, 2025 at 07:21:13AM +0200, Peter Eisentraut wrote:
On 12.06.25 08:26, jian he wrote:
in contrib/amcheck/verify_heapam.c, check_tuple
report_corruption(ctx,
psprintf("number of attributes %u exce
On Mon, Jun 30, 2025 at 3:21 PM Nisha Moond wrote:
>
> Please find the attached v20250630 patch set addressing above comments
> and other comments in [1],[2],[3] and [4].
Thanks for the patches. I am still in process of reviewing it but
please find few comments:
1)
+ if (pset.sversion >= 18)
Hi, all
I've noticed an inconsistency in the LSN format printed by pg_waldump,
specifically concerning the lsn: and prev fields in the output.
$ pg_waldump /tmp/pgdata02/pg_wal/0001000A 2>/dev/null
|grep 'AB10260'
rmgr: XLOGlen (rec/tot):114/ 114, tx:
On Fri, Mar 28, 2025 at 4:22 AM Tom Lane wrote:
>
> v3 needed to rebase over 55527368b. (I guess "git am" cannot
> tolerate any fuzz at all?) No changes of any significance
> whatsoever.
>
> regards, tom lane
>
Hi!
Thank you for working on this.
I tried the patch and i
On 24.05.25 12:34, Florents Tselai wrote:
On 24 May 2025, at 12:24 PM, Álvaro Herrera wrote:
On 2025-May-24, Florents Tselai wrote:
I aggree with having more READMEs around the src tree.
It’s true that a lot of doc content found in VII. Internals is dev-oriented,
but imho it should be clos
On Tue, Jul 1, 2025 at 2:24 PM Amit Kapila wrote:
>
> On Tue, Jul 1, 2025 at 10:53 AM Dilip Kumar wrote:
> >
> > On Tue, Jul 1, 2025 at 10:31 AM Dilip Kumar wrote:
> > >
> > > On Mon, Jun 30, 2025 at 6:59 PM Zhijie Hou (Fujitsu)
> > > wrote:
> > > >
> > > > On Mon, Jun 30, 2025 at 7:22 PM Amit
On Mon, Jun 30, 2025 at 9:23 PM Tomas Vondra wrote:
>
> I wasn't suggesting to do "numactl --interleave=all". My argument was
> simply that doing numa_interleave_memory() has most of the same issues,
> because it's oblivious to what's stored in the shared memory. Sure, the
> fact that local memory
> On 29 Jun 2025, at 12:56, Peter Eisentraut wrote:
>
> On 27.06.25 11:15, Daniel Gustafsson wrote:
>>> On 26 Jun 2025, at 23:06, Daniel Gustafsson wrote:
>>> I'll propose changes for these comments in the morning when coffee has been
>>> had.
>> The attached moves to logging on stderr along wit
On Tue, Jul 1, 2025 at 10:53 AM Dilip Kumar wrote:
>
> On Tue, Jul 1, 2025 at 10:31 AM Dilip Kumar wrote:
> >
> > On Mon, Jun 30, 2025 at 6:59 PM Zhijie Hou (Fujitsu)
> > wrote:
> > >
> > > On Mon, Jun 30, 2025 at 7:22 PM Amit Kapila wrote:
> > > >
> >
> > I was looking at 0001, it mostly looks
On 16.01.25 06:38, Peter Smith wrote:
On Thu, Jan 16, 2025 at 3:26 PM Tom Lane wrote:
Peter Smith writes:
During some recent reviews, I came across some comments mentioning "toast" ...
TOAST is a PostgreSQL acronym for "The Oversized-Attribute Storage
Technique" [1].
It is indeed an acrony
On Tue, 1 Jul 2025 at 00:23, Jacob Champion
wrote:
> when other people say "Postgres wire-compatible",
> they're talking about us.
Many people instead are talking about JDBC (Java) or the Npgsql (C#).
These are both much better implementations of the protocol than libpq
is IMO (e.g. libpq still c
Hi,
On Mon, 30 Jun 2025 at 18:01, Andres Freund wrote:
>
> Hi,
>
> On 2025-06-30 16:01:04 +0300, Nazir Bilal Yavuz wrote:
> > This patch aims to improve 027_stream_regress test's regression test
> > error reporting per Andres' suggestion [1].
>
> Thanks for working on that!
>
>
> One thing I don'
1 - 100 of 104 matches
Mail list logo
