Mihail Nikalayeu wrote:
> Hello!
>
> On Fri, Oct 31, 2025 at 12:17 AM Alvaro Herrera
> wrote:
> > Here's a new installment of this series, v25, including the CONCURRENTLY
> > part, which required some conflict fixes on top of the much-changed
> > v24-0001 patch.
>
> > * cluster.c
> > *
Hi Fabrice,
On Fri, 31 Oct 2025 at 17:45, Fabrice Chapuis
wrote:
> Thanks for your large analyze and explanation Alexander. If we go in the
> direction you propose and leave the option to use a suplementary flag
> allow_overwrite, may I propose you some modifications in the patch v0 you
> have a
Hi,
On Fri, Oct 31, 2025 at 01:19:50PM +0100, Álvaro Herrera wrote:
> On 2025-Oct-31, Bertrand Drouvot wrote:
>
> > After giving it more thought, I'm inclined to postpone the compiler warning
> > until XLogRecPtrIsValid() has been available for some time. The question is
> > for
> > how long?
>
Hi all,
While working on other things I noted that we have a lot of cases where
a StringInfo instance is allocated dynamically even when it is either
thrown away or destroyed at the end, which seems unnecessary, that is,
instead of using:
StringInfo info = makeStringInfo();
...
Hi Shubham.
A comment about the v17-0001.
==
1.
+ if (check_publication_exists(conn, dbinfo[i].pubname, dbinfo[i].dbname))
+ {
+ /* Reuse existing publication on publisher. */
+ pg_log_info("dry-run: would use existing publication \"%s\" in
database \"%s\"",
+ dbinfo[i].pubname, dbinfo[i].dbn
On Thu, Oct 30, 2025 at 9:08 AM shveta malik wrote:
> >
>
> > +* not filtered out, we don't count modify filteredBytes.
> > The filtered
>
> Something is wrong in this sentence.
:), here's better one
/*
* Even if we filtered out some relations, we still send a TRUNCATE
* messag
Hi Sawada-San.
Here are my review comments for v23-0001. Most of them are cosmetic
comment suggestions.
==
src/backend/access/transam/xlog.c
show_effective_wal_level:
1.
+ /*
+ * During the recovery, instead of the local wal_level value, the
+ * primary's configuration is used for effective
Hi Mahendra,
Thank you for your work on this feature.
I have just begun reviewing the latest patch and
encountered the following errors during the initial setup:
```
$ ./db/bin/pg_restore testdump_dir -C -d postgres -F d -p 5556
pg_restore: error: could not execute query: ERROR: syntax error at o
"Tristan Partin" writes:
> What is the benefit of -Dextra_include_dirs when you could use -Dc_flags
> or CFLAGS to specify extra include directories? If you tried either of
> those as an alternative, would they fix the issue? The existence of the
> option goes all the way back to the initial co
On Sun Feb 2, 2025 at 6:29 PM CST, Thomas Munro wrote:
> When I use configure/make and --with-includes=/usr/local/include, I
> see compile lines like this:
>
> ... -I../../src/interfaces/libpq -I../../src/include -I/usr/local/include ...
>
> That's important, because if I happen to have libpq head
>
> I am a bit uncomfortable regarding the design you are using here,
> where the ImportStatistics callback, if defined, takes priority over
> the existing AnalyzeForeignTable, especially regarding the fact that
> both callbacks attempt to retrieve the same data, except that the
> existing callback
On Mon, Oct 13, 2025 at 11:15 AM Peter Smith wrote:
>
> Hi Shubham.
>
> The log output looks OK now. So, I don't have any more review comments
> for this thread.
>
> Meanwhile, please watch my other pending patches [1][2] re
> pg_createsubscriber logging. If those get pushed first, then your
> pat
Hi,
On Sun, Nov 2, 2025 at 2:24 PM Xuneng Zhou wrote:
>
> Hi, Alexander!
>
> On Thu, Oct 23, 2025 at 8:58 PM Xuneng Zhou wrote:
> >
> > Hi,
> >
> > On Thu, Oct 23, 2025 at 6:46 PM Alexander Korotkov
> > wrote:
> > >
> > > Hi!
> > >
> > > In Thu, Oct 16, 2025 at 10:12 AM Xuneng Zhou wrote:
> >
The pg_buffercache_evict_{relation,all} operations can become extremely
slow when dealing with large buffer pools containing many dirty buffers.
This commit adds CHECK_FOR_INTERRUPTS calls within the underlying
Evict{Rel,All}UnpinnedBuffers functions to ensure these operations
cancellable.
And thi
On Sat, Nov 1, 2025 at 7:14 AM Heikki Linnakangas wrote:
> The patch seems harmless enough to me, no objections to committing it.
> However, I'm worried that we'll soon break it again. The new rule is
> apparently "include libpq first", but we have no way of enforcing it.
Here's a new version of
po 3. 11. 2025 v 2:22 odesílatel Philip Alger napsal:
>
> Hello,
>
>
>>
>> > I think it’s better to pfree(res).
>>
>> Would you mind to share why pfree is needed? I tried to trace this
>> with Valgrind, but even pfree(res) was present or not, there was no
>> leak detected and both compiles without
po 3. 11. 2025 v 2:18 odesílatel Philip Alger napsal:
>
> Hi Josef,
>
>> Would it make sense to rename trigger related variables to "trig"
>> prefix instead of "trg" as is done in other functions in the same file
>> (for example in function pg_get_triggerdef)?
>
>
> Not sure it would be the same a
Hello,
> > I think it’s better to pfree(res).
>
> Would you mind to share why pfree is needed? I tried to trace this
> with Valgrind, but even pfree(res) was present or not, there was no
> leak detected and both compiles without additional warnings. Wouldn't
> be res "trashed" at the end of the
Hi Josef,
Would it make sense to rename trigger related variables to "trig"
> prefix instead of "trg" as is done in other functions in the same file
> (for example in function pg_get_triggerdef)?
>
Not sure it would be the same as triggerdef uses trig, while
triggerdef_worker uses a mix of trig a
Em dom., 2 de nov. de 2025 às 13:22, Bryan Green
escreveu:
> On 11/2/2025 10:09 AM, Bryan Green wrote:
> > On 11/2/2025 8:59 AM, Ranier Vilela wrote:
> >> Hi.
> >>
> >> Per Coverity.
> >>
> >> Coverity raised the follow report:
> >>
> >> CID 1642824: (#1 of 1): Overflowed constant (INTEGER_OVERFL
Hi.
Em dom., 2 de nov. de 2025 às 13:09, Bryan Green
escreveu:
> On 11/2/2025 8:59 AM, Ranier Vilela wrote:
> > Hi.
> >
> > Per Coverity.
> >
> > Coverity raised the follow report:
> >
> > CID 1642824: (#1 of 1): Overflowed constant (INTEGER_OVERFLOW)
> > 37. overflow_const: Expression pattern_l
On 11/3/25 00:49, Peter Geoghegan wrote:
> On Sun, Oct 12, 2025 at 2:52 PM Peter Geoghegan wrote:
>> Attached in a new revision, mostly just to keep CFBot happy following
>> a recent trivial conflict introduced on master.
>
> Attached is another revision, also just to keep CFBot happy followin
On 11/2/2025 4:48 PM, Tom Lane wrote:
> Bryan Green writes:
>> There is a Y2038 bug in win32gettimeofday.c due to long being 32-bits on
>> Windows and the use of struct timeval.
>
> Yeah.
>
>> Obviously, there are a lot of places in the codebase where gettimeofday
>> is called. My question is
On Fri, Oct 31, 2025 at 12:59 AM Nazir Bilal Yavuz wrote:
> I agree with all of your points. All of them are addressed in the v2.
LGTM, so I'll go and commit this shortly. Thanks!
Thanks for the clarification.
On Sun, Nov 2, 2025 at 2:52 PM Tom Lane wrote:
> Chao Li writes:
> > Looks like the po file has been out of date, the msgid string cannot be
> found in the source file.
>
> Yeah, I was surprised not to see a fuzz marker there. Apparently
> that file hasn't been to
On Tue, Oct 28, 2025 at 02:19:00AM +0100, Mihail Nikalayeu wrote:
> On Mon, Oct 27, 2025 at 7:06 PM Noah Misch wrote:
> > Yes, I'm happy to push a patch documenting it. Would you like to propose
> > the
> > specific doc patch? I regret lacking the bandwidth to review the fix
> > patches.
>
>
Chao Li writes:
> Looks like the po file has been out of date, the msgid string cannot be found
> in the source file.
Yeah, I was surprised not to see a fuzz marker there. Apparently
that file hasn't been touched in awhile.
> Instead of manually updating the po file, I guess some build process
Bryan Green writes:
> There is a Y2038 bug in win32gettimeofday.c due to long being 32-bits on
> Windows and the use of struct timeval.
Yeah.
> Obviously, there are a lot of places in the codebase where gettimeofday
> is called. My question is whether we want to fix this now or wait with
> cro
> On Nov 2, 2025, at 04:23, Joshua Shanks wrote:
>
> Hi,
>
> I was poking around and found a typo
>
> Change "occured" to "occurred" in pg_basebackup error message.
>
> Cheers,
> Joshua
> <0001-Fix-typo-in-Vietnamese-translation-file.patch>
Looks like the po file has been out of date, the
David Rowley writes:
> On Mon, 3 Nov 2025 at 05:26, Tom Lane wrote:
>> v3 attached.
> I reviewed the changes. Looks good to me.
Thanks again! I'll get that pushed shortly.
regards, tom lane
Hello,
There is a Y2038 bug in win32gettimeofday.c due to long being 32-bits on
Windows and the use of struct timeval.
int
gettimeofday(struct timeval *tp, void *tzp)
struct timeval is defined in winsock2.h and is needed by the Windows
select() call. The 64-bit values have to be narrowed to 32-
On Mon, 3 Nov 2025 at 05:26, Tom Lane wrote:
> v3 attached.
I reviewed the changes. Looks good to me.
David
ne 2. 11. 2025 v 22:12 odesílatel Chao Li napsal:
>
> Hi Philip,
>
> Thanks for the patch. I just reviewed it and got a few comments:
>
> > On Oct 23, 2025, at 06:27, Philip Alger wrote:
> >
> >
>
> 1
> ```
> + /* Parse the trigger name to handle quoted identifiers */
> + nameList =
ne 2. 11. 2025 v 22:08 odesílatel Philip Alger napsal:
>
>
>>
doc said trigger name can not be schema-qualified,
we can not do:
CREATE TRIGGER public.modified_a BEFORE UPDATE OF a ON main_table
FOR EACH ROW WHEN (OLD.a <> NEW.a) EXECUTE PROCEDURE
trigger_func('modified_a'
PFA v3, rebased over 8a27d418f, no substantive changes whatever.
regards, tom lane
From 1af842fd2508da8275cff42cc5e2d316858d9a7f Mon Sep 17 00:00:00 2001
From: Tom Lane
Date: Sun, 2 Nov 2025 15:44:53 -0500
Subject: [PATCH v3 1/3] Revise APIs for pushJsonbValue() and assoc
Hi,
On Tue, 28 Oct 2025 at 07:19, Michael Paquier wrote:
>
> Another less invasive solution for the code tree would be to have
> meson cross-check that the list of files it defines matches with
> what's on disk. With the drop of Makefiles and ./configure at some
> point in mind, I am not convinc
>
> I am not sure we need to do anything about this.
>
Or maybe we just avoid the tranche_id from leaking
in test_dsa_resowners() by making it a static variable
and checking if we have a valid tranche id before calling
LWLockNewTrancheId()? That is the proper pattern.
--
Sami
On Fri, Oct 31, 2025 at 1:40 PM Peter Geoghegan wrote:
> On Fri, Oct 31, 2025 at 5:06 AM Victor Yegorov wrote:
> > I took a look at the patch. Proposed comments look highly valuable,
> > especially around NULLs, doesn't look immediately obvious, so definitely
> > requires a comment.
> > Looks g
Hi,
On Fri, Oct 31, 2025 at 5:50 PM Shardul Borhade wrote:
>
> Hi Xuneng,
>
> Thank you so much for the incredibly clear and detailed explanation. Your
> analysis of how I/O stats are attributed at submission time was exactly the
> information I was missing, and it completely solved the mystery
> I've discovered (with SQLsmith) that the new possible error makes
> pg_prewarm/autoprewarm fail when the error triggered during it's
> initialization and then another instance tries to acquire apw_state->lock.
>From just a quick look at this, it does not seem to be the fault
of the error message
Bryan Green writes:
> I am new to this area, but isn't the problem the filter selectivity
> estimation? The filter Filter: ((voucher_file_name IS NULL) AND
> (payment_type =
>> ANY ('{7,8}'::numeric[])) AND (status = '3'::numeric))
>> Rows Removed by Filter: 586208
>> Buffers: shared hit=95516 (m
On 11/2/2025 11:28 AM, Haiyang Li wrote:
> Hi all,
> When a query contains LIMIT/OFFSET clauses, the optimizer uses this
> information to influence path generation. For example, it may consider
> the path with the lowest startup cost and adjust the cost of paths
> accordingly.
>
> In most cases, t
"Haiyang Li" writes:
> To address this, I have added a GUC parameter to control the
> optimizer's use of LIMIT clauses for adjusting the cost of paths,
> providing a means to force intervention. We have also considered similar
> scenarios, such as MIN/MAX. Note that we still retain the optimizer's
ne 2. 11. 2025 v 18:33 odesílatel sunil s napsal:
>
> Hello Hackers,
>
> PFA rebased patch due to the code changes done in upstream commit
> 63599896545c7869f7dd28cd593e8b548983d613.
src/test/recovery/t/050_archive_enabled_standby.pl is missing the
ending newline. Is that intentional?
could be
Hi all,
When a query contains LIMIT/OFFSET clauses, the optimizer uses this
information to influence path generation. For example, it may consider
the path with the lowest startup cost and adjust the cost of paths
accordingly.
In most cases, these behaviors are beneficial and result in a more opti
ne 2. 11. 2025 v 17:21 odesílatel Tristan Partin napsal:
>
> Howdy folks,
>
> While playing around with pg_duckdb[0], a Postgres extension written in
> C++ which uses PGXS, I came across a strange build error:
>
> std=c++17 -Wno-sign-compare...
> /bin/sh: line 1: -Wno-sign-compare: command not fo
On 11/2/2025 10:50 AM, Laurenz Albe wrote:
> On Sun, 2025-11-02 at 11:47 -0500, Tom Lane wrote:
>> Bryan Green writes:
>>> On 11/2/2025 7:05 AM, Christian Ullrich wrote:
the current MSVC compiler deems it necessary to issue
warning C4053: one void operand for '?:'
for a line with CH
On Sun, 2025-11-02 at 11:47 -0500, Tom Lane wrote:
> Bryan Green writes:
> > On 11/2/2025 7:05 AM, Christian Ullrich wrote:
> > > the current MSVC compiler deems it necessary to issue
> > > warning C4053: one void operand for '?:'
> > > for a line with CHECK_FOR_INTERRUPTS(). This boils down to th
Bryan Green writes:
> On 11/2/2025 7:05 AM, Christian Ullrich wrote:
>> the current MSVC compiler deems it necessary to issue
>> warning C4053: one void operand for '?:'
>> for a line with CHECK_FOR_INTERRUPTS(). This boils down to this bit of
>> miscadmin.h (line 116 in master):
>>
>> #define IN
David Rowley writes:
> I had a look at the v2 patches. Mostly quibbles, but #4 seems like an
> oversight.
Thanks for reviewing!
> 1) For the following:
> +tuples_space = nentries * (MAXALIGN(SizeofMinimalTupleHeader) +
> + MAXALIGN(tupleWidth) +
> +
On 11/2/2025 10:09 AM, Bryan Green wrote:
> On 11/2/2025 8:59 AM, Ranier Vilela wrote:
>> Hi.
>>
>> Per Coverity.
>>
>> Coverity raised the follow report:
>>
>> CID 1642824: (#1 of 1): Overflowed constant (INTEGER_OVERFLOW)
>> 37. overflow_const: Expression pattern_len - 1ULL, where pattern_len is
On 11/2/2025 8:59 AM, Ranier Vilela wrote:
> Hi.
>
> Per Coverity.
>
> Coverity raised the follow report:
>
> CID 1642824: (#1 of 1): Overflowed constant (INTEGER_OVERFLOW)
> 37. overflow_const: Expression pattern_len - 1ULL, where pattern_len is
> known to be equal to 0, underflows the type of
On 11/2/2025 7:05 AM, Christian Ullrich wrote:
Hello,
the current MSVC compiler deems it necessary to issue
warning C4053: one void operand for '?:'
for a line with CHECK_FOR_INTERRUPTS(). This boils down to this bit of
miscadmin.h (line 116 in master):
#define INTERRUPTS_PEND
Hi,
On Mon, Sep 15, 2025 at 09:18:25PM -0300, Matheus Alcantara wrote:
> postgres=# select * from pg_available_extensions;
> name | default_version | installed_version | comment
> | location
> -+-+--
Hi.
Per Coverity.
Coverity raised the follow report:
CID 1642824: (#1 of 1): Overflowed constant (INTEGER_OVERFLOW)
37. overflow_const: Expression pattern_len - 1ULL, where pattern_len is
known to be equal to 0, underflows the type of pattern_len - 1ULL, which is
type unsigned long long.
This i
Hello,
the current MSVC compiler deems it necessary to issue
warning C4053: one void operand for '?:'
for a line with CHECK_FOR_INTERRUPTS(). This boils down to this bit of
miscadmin.h (line 116 in master):
#define INTERRUPTS_PENDING_CONDITION() \
(unlikely(UNBL
Hello, everyone!
Not sure it is related, but probably yes - got weird CI [0] issue on
BSD (patch itself does not change anything may affect that):
[19:24:12.727](0.000s) ok 1798 - unknown escape sequence, chunk size
2: correct error output
[19:24:12.727](0.000s) ok 1799 - unknown escape sequence,
Hello!
> I wonder if we should add P_ISHALFDEAD(opaque) for child page?
I am not a btree expert, but things I was able to find so far:
In commit d114cc538715e14d29d6de8b6ea1a1d5d3e0edb4 next check is added:
> bt_child_highkey_check(state, downlinkoffnum,
> child, topaque->btpo
Hi,
I was poking around and found a typo
Change "occured" to "occurred" in pg_basebackup error message.
Cheers,
Joshua
0001-Fix-typo-in-Vietnamese-translation-file.patch
Description: Binary data
On Sat, 1 Nov 2025 at 08:22, Tom Lane wrote:
> I wrote:
> > Here's a pair of patches to try to do better. The first one
> > is concerned with getting more realistic size estimates for
> > TupleHashTables in the planner. The second is some mop-up
> > that's been pending for a long time in the sam
Hello Nathan,
04.09.2025 23:37, Nathan Bossart wrote:
On Thu, Sep 04, 2025 at 12:30:27PM -0500, Sami Imseih wrote:
I liked removing the repalloc calls inside this routine and did not think
it was worth optimizing. I am OK with reverting it back. Although v1
is incorrect since it's still initial
61 matches
Mail list logo
