On Fri, Aug 16, 2024 at 11:48 AM shveta malik wrote:
>
> On Fri, Aug 16, 2024 at 10:46 AM shveta malik wrote:
> >
> > 3)
> > For update_exists(), we dump:
> > Key (a, b)=(2, 1)
> >
> > For delete_missing, update_missing, update_differ, we dump:
> > Replica identity (a, b)=(2, 1).
> >
> > For upda
On Fri, Aug 16, 2024 at 10:46 AM shveta malik wrote:
>
> On Thu, Aug 15, 2024 at 12:47 PM Zhijie Hou (Fujitsu)
> wrote:
> >
> > Thanks. I have checked and merged the changes. Here is the V15 patch
> > which addressed above comments.
>
> Thanks for the patch. Please find few comments and queries:
On Fri, Aug 16, 2024 at 10:46 AM shveta malik wrote:
>
> 3)
> For update_exists(), we dump:
> Key (a, b)=(2, 1)
>
> For delete_missing, update_missing, update_differ, we dump:
> Replica identity (a, b)=(2, 1).
>
> For update_exists as well, shouldn't we dump 'Replica identity'? Only
> for insert c
On Thu, Aug 15, 2024 at 12:47 PM Zhijie Hou (Fujitsu)
wrote:
>
> Thanks. I have checked and merged the changes. Here is the V15 patch
> which addressed above comments.
Thanks for the patch. Please find few comments and queries:
1)
For various conflicts , we have these in Logs:
Replica identity (
Junwang Zhao 于2024年8月15日周四 18:03写道：
> On Wed, Aug 14, 2024 at 2:35 PM Steven Niu wrote:
> >
> > Junwang, Kirill,
> >
> > The split work has been done. I created a new patch for removing
> redundant smgrclose() function as attached.
> > Please help review it.
>
> Patch looks good, actually you ca
Hi Vignesh. I looked at the latest v20240815* patch set.
I have only the following few comments for patch v20240815-0004, below.
==
Commit message.
Please see the attachment for some suggested updates.
==
src/backend/commands/subscriptioncmds.c
CreateSubscription:
nit - fix wording in
On 14.08.24 03:12, Andreas Karlsson wrote:
On 8/10/24 9:10 AM, Peter Eisentraut wrote:
Thoughts?
I like it. Not because of the security issue but mainly because it is
more correct to do it this way. Plus the old code running stat() on
Windows also made little sense.
I think this simple fix
On Wed, 14 Aug 2024 11:32:14 +
Bertrand Drouvot wrote:
> Hi hackers,
>
> while working on a replication slot tool (idea is to put it in contrib, not
> shared yet), I realized that "pg_replslot" is being used > 25 times in
> .c files.
>
> I think it would make sense to replace those occurren
On Wed, Aug 14, 2024 at 7:45 PM Michail Nikolaev
wrote:
>
> > This is as expected, and we have documented this in the code comments. We
> > don't
> > need to report a conflict if the conflicting tuple has been removed or
> > updated
> > due to concurrent transaction. The same is true if the tran
On Thu, 15 Aug 2024 at 12:55, Peter Smith wrote:
>
> Hi Hackers,
>
> While reviewing another logical replication thread [1], I found an
> ERROR scenario that seems to be untested.
>
> TEST CASE: Attempt CREATE SUBSCRIPTION where the subscriber table is
> missing some expected column(s).
>
> Attach
On Thu, Aug 15, 2024 at 5:34 PM Nathan Bossart
wrote:
> Now to 0002...
>
> - if (-element > nelements)
> + if (element == PG_INT32_MIN || -element > nelements)
>
> This seems like a good opportunity to use our new pg_abs_s32() function,
> and godbolt.org [0] seems to i
On Thu, Aug 8, 2024 at 4:54 AM Paul Jungwirth
wrote:
>
> Rebased to e56ccc8e42.
I only applied to 0001-0003.
in create_table.sgml, I saw the WITHOUT OVERLAPS change is mainly in
table_constraint.
but we didn't touch alter_table.sgml.
Do we also need to change alter_table.sgml correspondingly?
+
On Fri, Aug 16, 2024 at 9:09 AM Thomas Munro wrote:
> On Fri, Aug 16, 2024 at 1:25 AM Peter Eisentraut wrote:
> > It should just be initdb doing that and then initializing the server
> > with concrete values based on that.
>
> Right.
>
> > I guess technically some of these GUC settings default to
>
>
> function attribute_statsitics_update() is significantly shorter. (Thank
> you for a good set of tests, by the way, which sped up the refactoring
> process.)
>
yw
> * Remind me why the new stats completely replace the new row, rather
> than updating only the statistic kinds that are speci
On Thu, Aug 15, 2024 at 11:11 PM Heikki Linnakangas wrote:
> There's a similar function in initdb, check_locale_name. I wonder if
> that could reuse the same code.
Thanks, between this comment and some observations from Peter E and
Tom, I think I have a better plan now. I think they should *not*
On 2024-Aug-14, Bertrand Drouvot wrote:
> Out of curiosity, checking the sizes of affected files (O2, no debug):
>
> with patch:
>
>textdata bss dec hex filename
> 30304 0 8 303127668
> src/backend/replication/logical/reorderbuffer.o
> without patch:
>
On Thu, 2024-08-15 at 01:57 -0700, Jeff Davis wrote:
> On Sun, 2024-08-04 at 01:09 -0400, Corey Huinker wrote:
> >
> > > I believe 0001 and 0002 are in good shape API-wise, and I can
> > > start
> > > getting those committed. I will try to clean up the code in the
> > > process.
>
> Attached v26j
On Fri, 9 Aug 2024 at 18:10, Andreas Karlsson wrote:
> On 8/8/24 2:18 PM, Abdoulaye Ba wrote:
> > I am submitting a patch to add hooks for the functions
> > pg_total_relation_size and pg_indexes_size. These hooks allow for custom
> > behaviour to be injected into these functions, which can be use
Hello,
On 2024-Aug-14, Jelte Fennema-Nio wrote:
> The following removed comments seems useful to keep (I realize I
> already removed them in a previous version of the patch, but I don't
> think I did that on purpose)
> [...]
Ah, yeah, I agree. I put them back, and pushed 0005, 6 and 7 as a
sing
On Thu, Aug 15, 2024 at 3:04 PM Heikki Linnakangas wrote:
> Perhaps we should even change it to return
> 30 for protocol version 3.0, and just leave a note in the docs like
> "in older versions of libpq, this returned 3 for protocol version 3.0".
I think that would absolutely break current co
On Thu, Aug 15, 2024 at 5:47 PM Matthias van de Meent
wrote:
> > > I'm asking, because
> > > I'm not very convinced that 'primitive scans' are a useful metric
> > > across all (or even: most) index AMs (e.g. BRIN probably never will
> > > have a 'primitive scans' metric that differs from the loop
On 15/08/2024 23:20, Robert Haas wrote:
On Thu, Aug 15, 2024 at 1:13 PM Heikki Linnakangas wrote:
Added a "protocol_version" libpq option for that. It defaults to "auto",
but you can set it to "3.1" or "3.0" to force the version. It makes it
easier to test that the backwards-compatibility works
On 14/08/2024 21:04, Jelte Fennema-Nio wrote:
On Wed, 7 Aug 2024 at 22:10, Robert Haas wrote:
I respect that, but I don't want to get flamed for doing something
that might be controversial without anybody else endorsing it. I'll
commit this if it gets some support, but not otherwise. I'm willin
On Thu, 15 Aug 2024 at 23:10, Peter Geoghegan wrote:
>
> On Thu, Aug 15, 2024 at 4:34 PM Matthias van de Meent
> wrote:
> > > Attached patch has EXPLAIN ANALYZE display the total number of
> > > primitive index scans for all 3 kinds of index scan node. This is
> > > useful for index scans that ha
On Thu, Aug 15, 2024 at 4:58 PM Alena Rybakina
wrote:
> I think that it is enough to pass the IndexScanDesc parameter to the function
> - this saves us from having to define the planstate type twice.
>
> For this reason, I suggest some changes that I think may improve your patch.
Perhaps it's a
I've committed 0001. Now to 0002...
- if (-element > nelements)
+ if (element == PG_INT32_MIN || -element > nelements)
This seems like a good opportunity to use our new pg_abs_s32() function,
and godbolt.org [0] seems to indicate that it might produce better code,
too
On Wed, Aug 14, 2024 at 06:00:06AM +, Bertrand Drouvot wrote:
> I gave it more thoughts and I don't think we have to choose between the two.
> The 1 Hz approach reduces the number of interrupts and Sami's patch provides a
> way to get "accurate" delay in case of interrupts. I think both have th
On Thu, Aug 8, 2024 at 01:48:49PM +0200, Jelte Fennema-Nio wrote:
> SUMMARY OF THREAD
>
> The design of patch 0001 is agreed upon by everyone on the thread (so
> far). This adds the PARTIAL_AGGREGATE label for aggregates, which will
> cause the finalfunc not to run. It also starts using PARTIAL_A
On Thu, Aug 15, 2024 at 4:34 PM Matthias van de Meent
wrote:
> > Attached patch has EXPLAIN ANALYZE display the total number of
> > primitive index scans for all 3 kinds of index scan node. This is
> > useful for index scans that happen to use SAOP arrays. It also seems
> > almost essential to off
On Fri, Aug 16, 2024 at 1:25 AM Peter Eisentraut wrote:
> On 15.08.24 00:43, Thomas Munro wrote:
> > "" is a problem however... the special value for "native environment"
> > is returned as a real locale name, which we probably still need in
> > places. We could change that to newlocale("") + que
On 05.07.24 16:18, Jim Jones wrote:
> On 02.07.24 18:02, Jim Jones wrote:
>> It basically does the following:
>>
>> * When casting an XML value to a SQL data type, XML values containing
>> XSD literals will be converted to their equivalent SQL data type.
>> * When casting from a SQL data type to
On Wed, Aug 07, 2024 at 02:01:30PM -0400, Robert Haas wrote:
> Also, for the notes to be useful, we'd probably need some conventions
> about how we, as a project, want to use them. If everyone does
> something different, the result isn't likely to be all that great.
What did you have in mind? Wou
Hi! Thank you for your work on this subject!
On 15.08.2024 22:22, Peter Geoghegan wrote:
Attached patch has EXPLAIN ANALYZE display the total number of
primitive index scans for all 3 kinds of index scan node. This is
useful for index scans that happen to use SAOP arrays. It also seems
almost es
Hello again,
On Tue, Aug 13, 2024 at 12:48 AM Euler Taveira wrote:
> I'm curious about your use case. Is it just because the internal function has
> a
> different signature or your tool is capable of apply logical replication
> changes
> in parallel using the SQL API?
The latter is correct, it
On Thu, 15 Aug 2024 at 21:23, Peter Geoghegan wrote:
>
> Attached patch has EXPLAIN ANALYZE display the total number of
> primitive index scans for all 3 kinds of index scan node. This is
> useful for index scans that happen to use SAOP arrays. It also seems
> almost essential to offer this kind o
I wrote:
> Thanks, done. Here's a revised patchset.
The cfbot points out that I should probably have marked progname
as "static" in 0008. I'm not going to repost the patchset just for
that, though.
regards, tom lane
On Thu, Aug 15, 2024 at 1:13 PM Heikki Linnakangas wrote:
> Added a "protocol_version" libpq option for that. It defaults to "auto",
> but you can set it to "3.1" or "3.0" to force the version. It makes it
> easier to test that the backwards-compatibility works, too.
Over on the "Add new protocol
Attached patch has EXPLAIN ANALYZE display the total number of
primitive index scans for all 3 kinds of index scan node. This is
useful for index scans that happen to use SAOP arrays. It also seems
almost essential to offer this kind of instrumentation for the skip
scan patch [1]. Skip scan works b
Hi!
On 07.08.2024 04:11, Alexander Korotkov wrote:
On Mon, Aug 5, 2024 at 11:24 PM Alena Rybakina
wrote:
Ok, thank you for your work)
I think we can leave only the two added libraries in the first patch,
others are superfluous.
Thank you.
I also have fixed some grammar issues.
While reviewi
On Sun, Jul 7, 2024 at 09:52:27PM +,
fujii.y...@df.mitsubishielectric.co.jp wrote:
> Hi Bruce.
>
> > From: Bruce Momjian
> > Is there a reason the documentation is no longer a part of this patch?
> > Can I help you keep it current?
>
> Here are the reasons:
> Reason1. The approach differ
On Thu, Aug 15, 2024 at 02:56:00PM +0800, jian he wrote:
> i am confused with
> "
> +#elif defined(HAVE_INT128)
> + uint128 res = -((int128) a);
> "
> I thought "unsigned" means non-negative, therefore uint128 means non-negative.
> therefore "int128 res = -((int128) a);" makes sense to me.
Ah, th
On Thu, 25 Jul 2024 at 18:03, Laurenz Albe wrote:
> Thanks for the review!
>
> On Wed, 2024-07-24 at 15:27 +0200, Rafia Sabih wrote:
> > I liked the idea for this patch. I will also go for the default being
> > an empty string.
> > I went through this patch and have some comments on the code,
> >
(sorry for the formatting, my mobile phone doesn't have the capabilities I
usually get when using my laptop)
On Thu, 15 Aug 2024, 16:02 Jelte Fennema-Nio, wrote:
> On Thu, 15 Aug 2024 at 15:33, Peter Eisentraut
> wrote:
> > Maybe this kind of thing should rather be on the linked-to web page, no
I'm back to working on the main patch here, to make cancellation keys
longer. New rebased version attached, with all the FIXMEs and TODOs from
the earlier version fixed. There was a lot of bitrot, too.
The first patch now introduces timingsafe_bcmp(), a function borrowed
from OpenBSD to perfor
On Sat, Aug 10, 2024 at 10:35:46AM -0500, Nathan Bossart wrote:
> Another option might be to combine all the queries for a task into a single
> string and then send that in one PQsendQuery() call. That may be a simpler
> way to eliminate the time between queries.
I tried this out and didn't see a
On Thu, 8 Aug 2024 at 16:24, Shlok Kyal wrote:
>
> On Wed, 31 Jul 2024 at 11:17, Shlok Kyal wrote:
> >
> > On Wed, 31 Jul 2024 at 09:36, Amit Kapila wrote:
> > >
> > > On Wed, Jul 31, 2024 at 3:27 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Wed, Jul 24, 2024 at 9:53 PM Amit Kapila
> >
On Thu, Aug 15, 2024 at 8:57 AM Amit Langote wrote:
> TBH, it's more of a hunch that people who are not involved in this
> development might find the new reality, whereby the execution is not
> racefree until ExecutorRun(), hard to reason about.
I'm confused by what you mean here by "racefree". A
Hello Joe,
05.08.2024 02:55, Joseph Koshakow wrote:
On Fri, Jun 14, 2024 at 8:00 AM Alexander Lakhin wrote:
>
> And the most interesting case to me:
> SET temp_buffers TO 10;
>
> CREATE TEMP TABLE t(i int PRIMARY KEY);
> INSERT INTO t VALUES(1);
>
...
Alex, are you able to
On Wed, Aug 14, 2024 at 2:04 PM Jelte Fennema-Nio wrote:
> Applied all 0002 feedback. Although I used Min(proto,
> PG_PROTOCOL_LATEST) because Max results in the wrong value.
Picky, picky. :-)
Committed.
> Makes sense. I'm not in too much of a hurry with this specific one. So
> I'll leave it li
On Thu, Aug 15, 2024 at 11:25:25AM +0800, SAMEER KUMAR wrote:
> I think it is important to indicate that the group leader is responsible
> for clearing the transaction ID/transaction status of other backends
> (including this one).
Your proposal is
Waiting for the group leader process to
On Thu, Aug 15, 2024 at 12:40:29AM +0200, Jelte Fennema-Nio wrote:
> I'd like to send an automatic mail to a thread whenever it gets added
> to a commitfest. Since this would impact everyone that's subscribed to
> the mailinglist I'd like some feedback on this. This mail would
> include:
I haven't
On Mon, Jul 1, 2024 at 3:17 PM Ashutosh Bapat
wrote:
> Hi All,
> While reviewing Richard's patch for grouping sets, I stumbled upon
> following explain output
>
> explain (costs off)
> select distinct on (a, b) a, b
> from (values (1, 1), (2, 2)) as t (a, b) where a = b
> group by grouping sets((
Peter Eisentraut writes:
> On 14.08.24 17:46, Paul Jungwirth wrote:
>> Are you doing something to get macro expansion? I've never gotten my gdb
>> to see #defines, although in theory this configure line should do it,
>> right?:
> Oh I see, you don't have the F_* constants available then. Maybe
On Thu, 15 Aug 2024 at 15:33, Peter Eisentraut wrote:
> Maybe this kind of thing should rather be on the linked-to web page, not
> in every email.
Yeah, I'll first put a code snippet on the page for the commitfest entry.
> But a more serious concern here is that the patches created by the cfbot
On 13.04.24 23:04, Tomas Vondra wrote:
While preparing a differential code coverage report between 16 and HEAD, one
thing that stands out is the parallel brin build code. Neither on
coverage.postgresql.org nor locally is that code reached during our tests.
Thanks for pointing this out, it's de
On Thu, 15 Aug 2024 at 15:28, Peter Eisentraut wrote:
> How would you attach such an email to a thread? Where in the thread
> would you attach it? I'm not quite sure how well that would work.
My idea would be to have the commitfest app send it in reply to the
message id that was entered in the
On 15.08.24 09:59, Jelte Fennema-Nio wrote:
I realized a 5th thing that I would want in the email and cf entry page
5. A copy-pastable set of git command that checks out the patch by
downloading it from the cfbot repo like this:
git config branch.cf/5107.remote
https://github.com/postgresql-cfb
On 15.08.24 00:40, Jelte Fennema-Nio wrote:
I'd like to send an automatic mail to a thread whenever it gets added
to a commitfest. Since this would impact everyone that's subscribed to
the mailinglist I'd like some feedback on this. This mail would
include:
1. A very short blurb like: "This thre
On 15.08.24 00:43, Thomas Munro wrote:
"" is a problem however... the special value for "native environment"
is returned as a real locale name, which we probably still need in
places. We could change that to newlocale("") + query instead, but
Where do we need that in the server?
It should jus
On 15.08.24 09:20, Michael Banck wrote:
On Wed, Aug 14, 2024 at 06:05:19PM -0700, Jeff Davis wrote:
That looks good to me. Does anyone have a different opinion? If not,
I'll go ahead and commit (but not backport) this change.
What is the rationale not to backpatch this? The error message chang
Hi all,
On Tue, Aug 13, 2024 at 10:08 PM Robert Haas wrote:
> And it's not like we have statistics anywhere that you can look at to
> see how much CPU time you spent computing checksums, so if a user DOES
> have a performance problem that would not have occurred if checksums
> had been disabled,
On Thu, Aug 15, 2024 at 9:56 AM Jeff Davis wrote:
> Is there any sample code that implements late locking for a FDW? I'm
> not quite clear on how it's supposed to work.
See the patch in [1]. It would not apply to HEAD anymore, though.
Best regards,
Etsuro Fujita
[1] https://www.postgresql.org/
On 15/08/2024 11:03, Thomas Munro wrote:
Here's a new patch to add to this pile, this time for check_locale().
I also improved the error handling and comments in the other patches.
There's a similar function in initdb, check_locale_name. I wonder if
that could reuse the same code.
I wonder if
Hi,
> Perhaps we should also add casts between bytea and the integer/numeric
> types. That might be easier to use than functions in some
> circumstances.
>
> When casting a numeric to an integer, the result is rounded to the
> nearest integer, and NaN/Inf generate errors, so we should probably do
Hi hackers,
I noticed that there is a magic number which can be replaced by CATCACHE_MAXKEYS
in struct cachedesc, I checked some other struct like CatCache, CatCTup, they
all use CATCACHE_MAXKEYS.
I did some search on pg-hackers, and found an old thread[0] that
Robert proposed to change
the maxim
On Thu, 15 Aug 2024 at 05:20, Joel Jacobson wrote:
>
> On Wed, Aug 14, 2024, at 19:25, Joel Jacobson wrote:
> > What do we want to happen if passing a numeric with decimal digits,
> > to decimal_to_bytes()? It must be an error, right?
> >
> > Example: SELECT decimal_to_bytes(1.23);
>
> Hmm, an err
On Wed, Aug 14, 2024 at 2:35 PM Steven Niu wrote:
>
> Junwang, Kirill,
>
> The split work has been done. I created a new patch for removing redundant
> smgrclose() function as attached.
> Please help review it.
Patch looks good, actually you can make the refactoring code as v3-0002-xxx
by using:
On Wed, 14 Aug 2024 at 07:31, Joel Jacobson wrote:
>
> I think this is acceptable, since it produces more correct results.
>
Thanks for checking. I did a bit more testing myself and didn't see
any problems, so I have committed both these patches.
> In addition, I've traced the rscale_adjustment
On 15.8.24 11:49, Alena Rybakina wrote:
I have some suggestions:
1. pgstatfuncs.c in functions tuplestore_put_for_database() and
tuplestore_put_for_relation you can remove 'nulls' array if
you're sure that columns cannot be NULL.
We need to use this for tuplestore_putvalues function.
On Wed, Aug 14, 2024 at 11:17 AM Tristan Partin wrote:
> Thanks for picking this up. I think your patch looks really good.
Thanks for looking!
> Are
> you familiar with gcc's function poisoning?
>
> #include
> #pragma GCC poison puts
>
> int main(){
> #pragma GCC
On Thu, Aug 15, 2024 at 11:00 AM Jeff Davis wrote:
> On Thu, 2024-08-15 at 10:43 +1200, Thomas Munro wrote:
> > So I think the solution could perhaps be something like: in some
> > early
> > startup phase before there are any threads, we nail down all the
> > locale categories to "C" (or whatever
On Monday, August 12, 2024 7:11 PM Michail Nikolaev
wrote:
> > In my test, if the tuple is updated and new tuple is in the same page,
> > heapam_index_fetch_tuple should find the new tuple using HOT chain. So,
> > it's a
> > bit unclear to me how the updated tuple is missing. Maybe I missed som
Here's a new patch to add to this pile, this time for check_locale().
I also improved the error handling and comments in the other patches.
From 4831ff4373b9d713c78e303d9758de347aadfc2f Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Tue, 13 Aug 2024 14:15:54 +1200
Subject: [PATCH v3 1/3] Provid
On Thu, Aug 15, 2024 at 09:49:04AM +0200, Jakub Wartak wrote:
> On Wed, Aug 7, 2024 at 4:18 PM Greg Sabino Mullane wrote:
> >
> > On Wed, Aug 7, 2024 at 4:43 AM Michael Banck wrote:
> >>
> >> I think the last time we dicussed this the consensus was that
> >> computational overhead of computing th
On Thu, 15 Aug 2024 at 05:17, Euler Taveira wrote:
> +1. Regarding the CI link, I would be good if the CF entry automatically adds
> a
> link to the CI run. It can be a separate field or even add it to "Links".
I'm on it. I think this email should be a subset of the info on the CF
entry webpage,
On 14.08.24 17:46, Paul Jungwirth wrote:
On 8/14/24 02:16, Peter Eisentraut wrote:
On 12.08.24 23:15, Paul Jungwirth wrote:
On 8/12/24 04:32, Aleksander Alekseev wrote:
[...] This function takes a Datum and the appropriate out function,
and returns a char *. So you
can do this:
(gdb) call fo
Hi Greg and others
On Tue, Aug 13, 2024 at 4:42 PM Greg Sabino Mullane wrote:
>
> On Thu, Aug 8, 2024 at 6:11 AM Peter Eisentraut wrote:
>
>>
>> My understanding was that the reason for some hesitation about adopting data
>> checksums was the performance impact. Not the checksumming itself, bu
On Wed, Aug 7, 2024 at 4:18 PM Greg Sabino Mullane wrote:
>
> On Wed, Aug 7, 2024 at 4:43 AM Michael Banck wrote:
>>
>> I think the last time we dicussed this the consensus was that
>> computational overhead of computing the checksums is pretty small for
>> most systems (so the above change seems
On Tue, Jul 23, 2024 at 9:23 AM Peter Smith wrote:
>
> On Fri, Jul 19, 2024 at 4:01 PM Shlok Kyal wrote:
> >
> > On Thu, 18 Jul 2024 at 13:55, Peter Smith wrote:
> > >
> > > Hi, here are some review comments for v19-0002
> > > ==
> > > src/test/subscription/t/004_sync.pl
> > >
> > > 1.
> > >
On Thu, 15 Aug 2024 at 01:19, Tom Lane wrote:
> +1 for the basic idea.
That's great to hear.
> Not sure about your 3 & 4 points though, especially if that'd
> mean some delay in sending the mail. For one thing, wouldn't those
> links be stale as soon as the initial patch got replaced?
I recen
Hi Hackers,
While reviewing another logical replication thread [1], I found an
ERROR scenario that seems to be untested.
TEST CASE: Attempt CREATE SUBSCRIPTION where the subscriber table is
missing some expected column(s).
Attached is a patch to add the missing test for this error message.
Hi,
On Wed, Aug 14, 2024 at 06:05:19PM -0700, Jeff Davis wrote:
> That looks good to me. Does anyone have a different opinion? If not,
> I'll go ahead and commit (but not backport) this change.
What is the rationale not to backpatch this? The error message changes,
but we do not translate configu
On 15.08.24 02:43, Tom Lane wrote:
I wrote:
Here's a rebased but otherwise identical patchset. I also added
an 0007 that removes check_rules.pl as threatened.
I've done some more work on this and hope to post an updated patchset
tomorrow. Before that though, is there any objection to going a
On Wednesday, August 14, 2024 10:15 PM Michail Nikolaev
wrote:
> > This is as expected, and we have documented this in the code comments. We
> > don't
> > need to report a conflict if the conflicting tuple has been removed or
> > updated
> > due to concurrent transaction. The same is true if t
On Wednesday, August 14, 2024 7:02 PM Amit Kapila
wrote:
>
> On Wed, Aug 14, 2024 at 8:05 AM Zhijie Hou (Fujitsu)
> wrote:
> >
> > Here is the V14 patch.
> >
>
> Review comments:
> 1.
> ReportApplyConflict()
> {
> ...
> + ereport(elevel,
> + errcode(ERRCODE_INTEGRITY_CONSTRAINT_VIOLATION),
> +
85 matches
Mail list logo
