On Fri, Jan 3, 2025 at 12:11 AM Álvaro Herrera wrote:
>
>
>
> On Thu, Jan 2, 2025, at 5:49 PM, Amul Sul wrote:
>
> When adding a new FK constraint or attaching a partitioned table, where
> matching FK constraints are merged, we allow the parent constraint to be NOT
> VALID while the child constrai
Hi Japin,
Thanks so much for your test and review. As you may have noticed, this
patch has implemented the initial optimization idea and has passed only
the basic regression tests. We have planned to extend the validation to
include TAP tests after aligning the expectations with the community,
Hi Vignesh,
FYI, looks like your attached patchset was misnamed 20250204 instead
of 20250104. Anyway, it does not affect the reviews, but I am going to
refer to it as 0104 from now.
~~~
I have no comments for the patch v20250104-0001.
Some comments for the patch v20250104-0002.
==
doc/src/
On 8/26/24 08:10, Mark Dilger wrote:
> Paul, it seems what you are doing in v39-0001-Add-stratnum-GiST-support-function.patch is similar
to what I am doing in v17-0012-Convert-strategies-to-and-from-row-compare-types.patch.
Thank you inviting me to share some thoughts here! The goals of this pa
Hi David,
Thanks for the review.
> On Sun, 5 Jan 2025 at 21:03, Tatsuo Ishii wrote:
>> Attached is the v2 patch to reflect above.
>
> A quick review.
>
> I don't see any users of STRINGINFO_SMALL_SIZE, so I question the
> value in defining it.
>
> I think it might be worth adding a comment to
> I am yet to look very closely, but I think some additional columns that
> will be useful is the number of failsafe autovacuums occurred.
>
> Do you mean when the autovacuum started to prevent workaround?
>
Specifically vacuum_failsafe_age [1] when autovacuum automatically
performs a vacuum witho
Hello hackers,
I'd like to share my investigation of one mysterious stats.sql failure
occurred in December: [1].
The difference of the failure is:
--- C:/prog/bf/root/HEAD/pgsql/src/test/regress/expected/stats.out 2024-09-18
19:31:14.665516500 +
+++ C:/prog/bf/root/HEAD/pgsql.build/testrun/r
Hi Yura and Wenhui,
Thanks for kindly reviewing this work!
On 1/3/2025 9:01 PM, wenhui qiu wrote:
Hi
Thank you for your path，NUM_XLOGINSERT_LOCKS increase to 128，I
think it will be challenged，do we make it guc ？
I noticed there have been some discussions (for example, [1] and its
res
Dear Shubham,
Thanks for creating a patch. I have one comment about it.
check_publisher() assumed that the SQL function
`pg_catalog.current_setting('max_slot_wal_keep_size')`
will return the numeric, but it just return the text representation. I.e., if
the parameter is
set to 10MB, the function
On Fri, Dec 20, 2024 at 12:41 PM Nisha Moond wrote:
>
> In the test scenarios already shared on -hackers [1], where pgbench was run
> only on the publisher node in a pub-sub setup, no performance degradation was
> observed on either node.
>
>
>
> In contrast, when pgbench was run only on the sub
Hi Vignesh,
Some review comments for your v2 patch.
==
doc/src/sgml/logical-replication.sgml
1.
The initial data in existing subscribed tables are snapshotted and
- copied in a parallel instance of a special kind of apply process.
- This process will create its own replic
Hi, Zhigou
Thanks for the patch.
On Thu, 02 Jan 2025 at 09:14, "Zhou, Zhiguo" wrote:
> Hi all,
>
> I am reaching out to solicit your insights and comments on a recent
> proposal regarding the "Lock-free XLog Reservation from WAL." We have
> identified some challenges with the current WAL inser
On Fri, Jan 3, 2025 at 3:02 AM Robert Haas wrote:
>
> I think it's unhelpful that you keep calling this a "bug" when the
> behavior is clearly deliberate. Whether it's the *right* behavior is
> debatable, but it's not *accidental* behavior.
>
Ok, let's call it "not right" behaviour :). Let me fur
On 2024-12-20 02:57, Fujii Masao wrote:
On 2024/12/05 16:48, Masahiro Ikeda wrote:
On 2024-12-05 16:23, Yugo NAGATA wrote:
- Prints a progress report as each table is clustered.
+ Prints a progress report as each table is clustered,
+ at INFO level.
I feel like the comma could
While working on this:
https://www.postgresql.org/message-id/20230625.210509.1276733411677577841.t-ishii%40sranhm.sra.co.jp
I noticed that WinGetFuncArgInFrame() in nodeWindowAgg.c is hard to
read/understand. I think part of the reason is, it is long and has
large switch case and uses goto. I prop
On Thu, Dec 26, 2024 at 11:59 PM Masahiko Sawada wrote:
> The three patches look good to me.
Thanks for looking! I've pushed them all.
(The failure in drongo seems like an unrelated glitch.)
> > 4. For local memory, an allocated "control object" serves no real
> > purpose and wastes a few cycle
comment out the changes in
src/backend/utils/cache/plancache.c
// /* process session variables */
// if (OidIsValid(parsetree->resultVariable))
// {
// if (acquire)
// LockDatabaseObject(VariableRelationId, parsetree->resultVariable,
//
Hi Shubham.
The patch v6-0001 LGTM.
OTOH, if you want to be picky, the docs wording could be slightly
modified to be more consistent with the coded warning message.
CURRENT
Replication failures can occur if required WAL files are prematurely
deleted. To prevent this, the source server must set
On 29.12.24 15:13, Peter Eisentraut wrote:
I noticed a few cc.compiles() checks in meson.build don't show up in the
"meson setup" output, because they don't have a "name" argument. Also,
the "typeof" test doesn't show the name of the symbol that is currently
being tested. All this makes remot
+ /*
+ * The arguments of EXECUTE are evaluated by a direct expression
+ * executor call. This mode doesn't support session variables yet.
+ * It will be enabled later.
+ */
+ if (pstate->p_hasSessionVariables)
+ elog(ERROR, "session variable cannot be used as an argument");
it should be:
/*
> Hi Gurjeet,
>
> Thanks for looking into my patch.
>
>> On Fri, Jan 3, 2025 at 8:54 PM Tatsuo Ishii wrote:
>>>
>>> Attached is the patch for this.
>>
>> Hi Tatsuo,
>>
>> I believe the newline endings in your patches are causing the patch
>> application
>> to fail. I experienced this with you
On Tue, 31 Dec 2024 at 02:48, Peter Smith wrote:
>
> On Thu, Dec 26, 2024 at 1:37 AM vignesh C wrote:
> >
> > Hi,
> >
> > Currently, we restart the table synchronization worker after the
> > duration specified by wal_retrieve_retry_interval following the last
> > failure. While this behavior is d
On Sun, 5 Jan 2025 at 21:03, Tatsuo Ishii wrote:
> Attached is the v2 patch to reflect above.
A quick review.
I don't see any users of STRINGINFO_SMALL_SIZE, so I question the
value in defining it.
I think it might be worth adding a comment to initStringInfoExt and
makeStringInfoExt which menti
23 matches
Mail list logo
