On Wed, Oct 23, 2024 at 5:21 PM Amit Kapila wrote:
> Additional comment on the 0003 patch
> +#
> =
> +# Misc test.
> +#
> +# A "normal -> generated" replication.
> +#
> +# In this test case we use DROP EXPRESSION to chan
On 2024/10/18 14:57, Yushi Ogiwara wrote:
In conclusion, I agree that:
* Update lastxid with GetTopTransactionId().
* consume_xids with 0 should raise an error.
I have attached a new patch that incorporates your suggestions.
One concern in this discussion is that the return value of th
On Wed, Oct 23, 2024 at 03:44:03PM +1100, Peter Smith wrote:
> During a code review, it was noticed that there are several places
> within logical replication where a comma-separated list of publication
> names is built explicitly. There is already a utility function (called
> 'get_publications_str
On Tue, Oct 22, 2024 at 9:42 PM Masahiko Sawada wrote:
>
> On Tue, Oct 22, 2024 at 3:50 AM Amit Kapila wrote:
> >
>
> > Considering this, I feel if find this behavior buggy then we should
> > fix this separately rather than part of this patch. What do you think?
>
> Agreed. It's better to fix it
On Tue, Oct 22, 2024 at 11:34:55AM +0200, Anthonin Bonnefoy wrote:
> On Tue, Oct 22, 2024 at 7:06 AM Michael Paquier wrote:
>> Something that
>> worries me a bit is that this changes makes the code less clean, by
>> having a SELECT-INTO specific routine called in the parse-analyze
>> paths, while
Recently (~ version v39/v40) some changes to 'get_publications_str'
calls got removed from this patchset because it was decided it was
really a separate problem, unrelated to this generated columns
feature.
FYI - I've started a new thread "Refactor to use common function
'get_publications_str'" [1
Hi,
During a code review, it was noticed that there are several places
within logical replication where a comma-separated list of publication
names is built explicitly. There is already a utility function (called
'get_publications_str') for doing this, but it was not being used in
every place it c
Hi Michael,
Thank you for the review.
On Tue, Oct 22, 2024 at 12:18 PM Michael Paquier
wrote:
> On Mon, Oct 21, 2024 at 11:54:21PM +0530, Rahila Syed wrote:
> > On the other hand, [2] provides the statistics for all backends but logs
> > them in a file, which may not be convenient for quick acc
On Tue, Oct 22, 2024 at 12:33 PM Tom Lane wrote:
> Michel Pelletier writes:
> But now we also have
> expanded records, and with your use-case as an example of an extension
> trying to do similar things, I feel like we have enough examples to
> move forward.
>
Great!
As far as the hack we we
I have gone over patch 3 from the set and worked on the comments.
Apart from that, I have modified your patch as follows:
> +/*
> + * pg_session_variables - designed for testing
> + *
> + * This is a function designed for testing and debugging. It returns the
> + * content of sessionvars as-is,
On 2024-10-22 03:24, Rahila Syed wrote:
Hi,
PostgreSQL provides following capabilities for reporting memory
contexts statistics.
1. pg_get_backend_memory_contexts(); [1]
2. pg_log_backend_memory_contexts(pid); [2]
[1] provides a view of memory context statistics for a local backend,
while [2]
On Wed, Oct 23, 2024 at 5:58 AM Peter Smith wrote:
>
> Hi Vignesh, here are some review comments for the patch v5-0001 (docs only).
>
> ==
> Commit message
>
> 1.
> The commit message only refers to this as the "streaming option", but
> an option of what? Somewhere we should mention this is an
Hi~
Upon closer inspection, I noticed that we don't implement a custom
> TAS_SPIN() for this architecture, so I quickly hacked together the attached
> patch and ran a couple of benchmarks that stressed the spinlock code. I
> found no discussion about TAS_SPIN() on ARM in the archives, but I did
>
On Tue, 2024-10-22 at 10:41 -0700, Jeff Davis wrote:
> I attached a patch that creates partitioned tables with relpages=-1,
> and updates the docs.
Does this need any changes for pg_upgrade?
Yours,
Laurenz Albe
On 15/10/2024 12:15, David Rowley wrote:
On Tue, 15 Oct 2024 at 17:48, Andrei Lepikhov wrote:
I think maybe what is worth working on is seeing if you can better
estimate the number of tiebreak comparisons by checking the number of
distinct values for each sort key. That might require what we
di
On Mon, Oct 21, 2024 at 7:20 PM David Rowley wrote:
> On Tue, 22 Oct 2024 at 14:46, David G. Johnston
> wrote:
> > We should probably at least improve the documentation in 19.17.1; this
> interaction is apparently not self-evident.
>
> Yeah, I agree. The documentation could better reflect the cu
"David G. Johnston" writes:
> On Tue, Oct 22, 2024 at 4:40 PM Erik Sjoblom wrote:
>> I hear what you are saying Tom and what I have read says that it would
>> take 24 + 12 x N bytes for the array.
> Whatever you are reading, or your interpretation of it, is flawed.
I wonder whether Erik is conf
Hi Vignesh, here are some review comments for the patch v5-0001 (docs only).
==
Commit message
1.
The commit message only refers to this as the "streaming option", but
an option of what? Somewhere we should mention this is an option of
CREATE SUBSCRIPTION.
~
2.
Previously the default value
Hi,
> I committed 0001-0004 with significant revision.
Thanks for developing good features. I tried the patch that was committed right
away.
It seems that the implementation and documentation differ on the return value
of the pg_clear_attribute_stats function.
The attached small patch fixes the
Sorry for the very late reply.
On Tue, Jul 30, 2024 at 8:54 PM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Sawada-san,
>
> > Thank you for testing!
>
> I tried to profile the vacuuming with the larger case (40 workers for the 20G
> table)
> and attached FlameGraph showed the result. IIUC, I cannot f
On Tue, Oct 22, 2024 at 4:42 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Tue, Oct 22, 2024 at 4:40 PM Erik Sjoblom wrote:
>
>> I hear what you are saying Tom and what I have read says that it would
>> take 24 + 12 x N bytes for the array.
>>
>
> Whatever you are reading, or you
On Tue, Oct 22, 2024 at 4:40 PM Erik Sjoblom wrote:
> I hear what you are saying Tom and what I have read says that it would
> take 24 + 12 x N bytes for the array.
>
Whatever you are reading, or your interpretation of it, is flawed.
David J.
On Tue, Oct 22, 2024 at 3:46 PM Erik Sjoblom wrote:
>
> Yes, I did expect that the first element should take 24+12 bytes and let's
> round that to 50 bytes.
>
Assuming the 24 is coming from the array overhead you are expecting that
storing a custom composite typed value takes zero overhead. Tha
I hear what you are saying Tom and what I have read says that it would take
24 + 12 x N bytes for the array. This isn't the case when I start adding
elements to the table. Here are some samples adding 10,000 rows with
difference elements in the composite array:
Row countArray elementsMain table si
Erik Sjoblom writes:
> I don't see why it's using 50 bytes per element. There should be just one
> 24 byte header for the array, not one per element
[ shrug... ] I just told you that's not so.
regards, tom lane
Thanks Tom for your response!
Yes, I did expect that the first element should take 24+12 bytes and let's
round that to 50 bytes.
If I store another element, I would expect another 12. (or 16 depending on
padding) and take say ~65 bytes. I'm seeing close to 100 bytes.
If I have 3 elements, it's usi
Erik Sjoblom writes:
> I’m observing a storage behavior with arrays in a table that differs from
> my expectations, and I’d appreciate your insights. I was to store key value
> pairs in a very dense data model. I don't haver the requirement of search
> so that's why I was thinking an array of a co
> I've taken most of Jeff's work, reincorporated it into roughly the
> same patch structure as before, and am posting it now.
I committed 0001-0004 with significant revision.
Regards,
Jeff Davis
Hello PostgreSQL developers,
I’m observing a storage behavior with arrays in a table that differs from
my expectations, and I’d appreciate your insights. I was to store key value
pairs in a very dense data model. I don't haver the requirement of search
so that's why I was thinking an array of a co
Michel Pelletier writes:
> Doing some benchmarking I noticed that when writing some simple graph
> algorithms in plpgsql, my objects were being constantly flattened and
> expanded. Posting my question above to pgsql-general Tom gave me some tips
> and suggested I move the thread here.
> My non-e
My colleague Salvatore Dipietro (CC'd) sent me a couple of profiles that
showed an enormous amount of s_lock() time going to the
__sync_lock_test_and_set() call in the AArch64 implementation of tas().
Upon closer inspection, I noticed that we don't implement a custom
TAS_SPIN() for this architectur
On Tue, Oct 22, 2024 at 2:17 AM Amit Kapila wrote:
>
> On Mon, Oct 21, 2024 at 8:40 PM vignesh C wrote:
> >
> > Attached v3 version patch has a caution added for the same.
> >
>
> Thanks, the patch looks good to me and I am planning to commit this
> early next week unless there are objections or
On Tue, Oct 22, 2024 at 3:21 PM David Rowley wrote:
>
> On Wed, 23 Oct 2024 at 02:08, Melanie Plageman
> wrote:
> > However, it seems like there should be a way to force an index-only
> > scan even if it is not the cheapest path. Perhaps I only think this as
> > a developer needing to test someth
Hi,
Because of the way autovacuum_vacuum_[insert]_scale_factor works,
autovacuums trigger less frequently as the relation gets larger.
See this math in relation_needs_vacanalyze:
vacinsthresh = (float4) vac_ins_base_thresh + vac_ins_scale_factor * reltuples;
For an insert-only table, nearly all
On Wed, 23 Oct 2024 at 02:08, Melanie Plageman
wrote:
> However, it seems like there should be a way to force an index-only
> scan even if it is not the cheapest path. Perhaps I only think this as
> a developer needing to test something. But if enable_indexscan
> disables index-only scan then I do
út 22. 10. 2024 v 17:37 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > I'll mark this patch as ready for committer.
>
> Pushed then. Thanks for reviewing!
>
Thank you for this patch. It is really practical
Regards
Pavel
>
> regards, tom lane
>
On Fri, 2024-10-18 at 15:14 -0400, Tom Lane wrote:
> If we are going to put data into reltuples but not relpages,
> I think I agree with setting relpages to -1 to signify
> "unknown" (analogously to -1 for reltuples). Otherwise it
> looks like the table has infinite tuple density, which is
> likel
On Tue, Oct 22, 2024 at 6:10 PM Pavel Borisov wrote:
> On Tue, 22 Oct 2024 at 11:34, Alexander Korotkov wrote:
>>
>> On Mon, Oct 21, 2024 at 2:30 PM Alexander Korotkov
>> wrote:
>> >
>> > On Mon, Oct 21, 2024 at 1:16 PM Dagfinn Ilmari Mannsåker
>> > wrote:
>> > > Alexander Korotkov writes:
>>
On Tue, 22 Oct 2024 at 12:43, Heikki Linnakangas wrote:
> MultiXactMemberFreezeThreshold looks quite bogus now. Now that
> MaxMultiXactOffset==2^64-1, you cannot get anywhere near the
> MULTIXACT_MEMBER_SAFE_THRESHOLD and MULTIXACT_MEMBER_DANGER_THRESHOLD
> values anymore. Can we just get rid of
On 2024/10/21 16:32, Bertrand Drouvot wrote:
A few random comments on it:
Thanks for the review!
1 ===
+ /* Skip backends with pid=0, as they don't hold fast-path locks
*/
+ if (proc->pid == 0)
+ continue;
What about adding a few words i
On Tue, Oct 22, 2024 at 3:50 AM Amit Kapila wrote:
>
> On Wed, Oct 9, 2024 at 10:19 PM Masahiko Sawada wrote:
> >
> > Regarding the 0001 patch, it seems to me that UPDATE and DELETE are
> > allowed on the table even if its replica identity is set to generated
> > columns that are not published. F
On Tue, 22 Oct 2024 at 16:24, Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Amit, Vignesh,
>
> > 1. Please ensure that none of the existing tests that use
> > subscriptions with large changes will be impacted due to this change.
>
> I found at least 022_twophase_cascade.pl should be fixed.
> The file ha
Pavel Stehule writes:
> I'll mark this patch as ready for committer.
Pushed then. Thanks for reviewing!
regards, tom lane
Hi, Alexander!
On Tue, 22 Oct 2024 at 11:34, Alexander Korotkov
wrote:
> On Mon, Oct 21, 2024 at 2:30 PM Alexander Korotkov
> wrote:
> >
> > On Mon, Oct 21, 2024 at 1:16 PM Dagfinn Ilmari Mannsåker
> > wrote:
> > > Alexander Korotkov writes:
> > >
> > > > On Mon, Oct 21, 2024 at 8:40 AM Andre
On 2024/10/21 23:25, Fujii Masao wrote:
On 2024/10/19 2:43, Tom Lane wrote:
Fujii Masao writes:
I've attached the latest version of the patch, now including the commit log.
Unless there are any objections, I'll proceed with committing it.
LGTM. Maybe move down the sqlca variable declar
On Mon, 21 Oct 2024 23:52:18 +0200
Alvaro Herrera wrote:
> On 2024-Oct-21, Tender Wang wrote:
>
> > I suspect that we don't need the below if
> > statement anymore.
> > /*
> > * If the referenced side is partitioned (which we know because our
> > * parent's constraint points to a different relat
Peter Eisentraut writes:
> This patch allows using regular expression functions and operators with
> nondeterministic collations.
> ...
> In summary, this patch doesn't change any functionality that currently
> works. It just removes one error message and lets regular expressions
> just run, i
On 2024-Oct-22, Jehan-Guillaume de Rorthais wrote:
> On Fri, 18 Oct 2024 16:50:59 +0200
> Alvaro Herrera wrote:
> > For branch 14, I opted to make it delete the constraints on detach.
> > This isn't ideal but unless somebody wants to spend a lot more time on
> > this, it seems the best we can do
On Fri, 18 Oct 2024 16:50:59 +0200
Alvaro Herrera wrote:
> On 2024-Sep-26, Jehan-Guillaume de Rorthais wrote:
>
> > REL_14_STABLE backport doesn't seem trivial, so I'll wait for some
> > feedback, review & decision before going further down in backpatching.
>
> Hi, thanks for these patches. I
On Tue, Oct 22, 2024 at 6:12 AM Vik Fearing wrote:
>
> On 22/10/2024 12:19, Tatsuo Ishii wrote:
>
> Acording to ISO/IEC 9075-2:2016 "4.21.2 Row pattern navigation operations",
>
>evaluates a VE
> in a row NR, which may be different than current row CR.
>
> From this I think PREV(col + 1) s
On Tue, Oct 22, 2024 at 2:30 AM Andrey M. Borodin wrote:
>
> > On 22 Oct 2024, at 00:05, Melanie Plageman
> > wrote:
> >
> > I was suggesting you call RelationGetNumberOfBlocks() once
> > current_block == last_exclusive in the callback itself.
>
> Consider following sequence of events:
>
> 0. We
Hi everyone,
Thanks for the feedback!
> > But it returns the input array as is. I think it should at least make
> > a new copy of input array.
>
> I don't think that's really necessary. We have other functions that
> will return an input value unchanged without copying it. A
> longstanding exam
On 22/10/2024 12:19, Tatsuo Ishii wrote:
Acording to ISO/IEC 9075-2:2016 "4.21.2 Row pattern navigation operations",
evaluates a VE
in a row NR, which may be different than current row CR.
From this I think PREV(col + 1) should be interpreted as:
1. go to the previous row.
2. evaluat
On Mon, Oct 21, 2024 at 9:32 PM David Rowley wrote:
>
> There's nothing new about Index Only Scans being disabled by
> enable_indexscan. Index Only Scan is chosen with your test case as all
> possible Paths are disabled and IOS is the cheapest of all Paths.
Ah, I see! Sorry, I didn't think to com
On Mon, 30 Sept 2024 at 18:05, Tom Lane
wrote:
> Yes. Our implementation restrictions preclude access to the contents
> of another session's temp tables, but it is not forbidden to do DDL
> on them so long as no content access is required. (Without this,
> it'd be problematic for example to clean
> Yes. Our implementation restrictions preclude access to the contents
> of another session's temp tables, but it is not forbidden to do DDL
> on them so long as no content access is required. (Without this,
> it'd be problematic for example to clean out a crashed session's temp
> tables. See the "
>
>
> If the relpages option contains -1 only for partitioned tables, shouldn't
> pg_set_relation_stats restrict the values that can be
>
> specified by table type? The attached patch limits the value to -1 or more
> if the target
>
> is a partition table, and 0 or more otherwise.
>
> Changing relp
Dear Amit, Vignesh,
> 1. Please ensure that none of the existing tests that use
> subscriptions with large changes will be impacted due to this change.
I found at least 022_twophase_cascade.pl should be fixed.
The file has a part which tests non-streaming case:
```
# ---
# 2P
Hi!
On Tue, Oct 22, 2024 at 12:26 PM Anton Voloshin
wrote:
> On 18/01/2024 10:52, Peter Eisentraut wrote:
> > Committed, thanks.
>
> since this patch two .pl files without FATAL in "use warnings" have been
> committed to master:
> src/test/recovery/t/043_wal_replay_wait.pl
> src/test/modules/tes
On Wed, Oct 9, 2024 at 10:19 PM Masahiko Sawada wrote:
>
> Regarding the 0001 patch, it seems to me that UPDATE and DELETE are
> allowed on the table even if its replica identity is set to generated
> columns that are not published. For example, consider the following
> scenario:
>
> create table
> On Monday, October 21, 2024, Tatsuo Ishii wrote:
>>
>> I wonder how "PREV(col + 1)" is different from "PREV(col) + 1".
>> Currently my RPR implementation does not allow PREV(col + 1). If
>> "PREV(col + 1)" is different from "PREV(col) + 1", it maybe worthwhile
>> to implement "PREV(col + 1)".
>>
On 07/09/2024 07:36, Maxim Orlov wrote:
Here is v3.
MultiXactMemberFreezeThreshold looks quite bogus now. Now that
MaxMultiXactOffset==2^64-1, you cannot get anywhere near the
MULTIXACT_MEMBER_SAFE_THRESHOLD and MULTIXACT_MEMBER_DANGER_THRESHOLD
values anymore. Can we just get rid of MultiXa
On Tue, Oct 22, 2024 at 7:06 AM Michael Paquier wrote:
> -Query *
> -transformTopLevelStmt(ParseState *pstate, RawStmt *parseTree)
>
> What's the advantage of removing this routine? Is that because you're
> pushing the initialization of stmt_location and stmt_len into
> transformOptionalSelectInt
Hello,
On 18/01/2024 10:52, Peter Eisentraut wrote:
> Committed, thanks.
since this patch two .pl files without FATAL in "use warnings" have been
committed to master:
src/test/recovery/t/043_wal_replay_wait.pl
src/test/modules/test_misc/t/006_signal_autovacuum.pl
They come from
commit 06c418e
On Mon, Oct 21, 2024 at 8:40 PM vignesh C wrote:
>
> Attached v3 version patch has a caution added for the same.
>
Thanks, the patch looks good to me and I am planning to commit this
early next week unless there are objections or any major problems. I
have slightly updated the docs and commit mes
On 22.10.24 08:41, Tom Lane wrote:
Peter Eisentraut writes:
Committed with that change. Thanks.
Should we back-patch this? (And also a67a49648d9?) It's
not hard to imagine people wanting to compile our stable
branches with C23 compilers. I might leave out v12, which
is just days away from
This patch allows using regular expression functions and operators with
nondeterministic collations.
This complements the patches "Support LIKE with nondeterministic
collations" and "Support POSITION with nondeterministic collations" but
is independent. These three together fix most of the pl
On Mon, Oct 21, 2024 at 2:30 PM Alexander Korotkov wrote:
>
> On Mon, Oct 21, 2024 at 1:16 PM Dagfinn Ilmari Mannsåker
> wrote:
> > Alexander Korotkov writes:
> >
> > > On Mon, Oct 21, 2024 at 8:40 AM Andrei Lepikhov wrote:
> > >>
> > >> On 21/10/2024 06:32, Dagfinn Ilmari Mannsåker wrote:
> >
Hi Shubham, here are some comments for v40-0003 (TAP) patch.
==
Combo tests
1.
+# =
+# The following test cases exercise logical replication for the combinations
+# where there is a generated column on one or both sid
69 matches
Mail list logo
