On Tue, Jan 12, 2021 at 5:09 PM Amit Kapila wrote:
>
> On Mon, Jan 11, 2021 at 5:44 PM Mark Zhao <875941...@qq.com> wrote:
> >
> > Thanks for your reply. The patch is exactly what I want.
> > My English name is Mark Zhao, which should be the current email name.
> >
>
> Pushed the fix.
Thanks Amit
On Mon, Jan 11, 2021 at 5:44 PM Mark Zhao <875941...@qq.com> wrote:
>
> Thanks for your reply. The patch is exactly what I want.
> My English name is Mark Zhao, which should be the current email name.
>
Pushed the fix.
--
With Regards,
Amit Kapila.
Thanks for your reply. The patch is exactly what I want.
My English name is Mark Zhao, which should be the current email name.
Thanks,
Mark Zhao
-- Original --
From: "Amit Kapila";
On Wed, Dec 30, 2020 at 8:03 PM 赵锐 <875941...@qq.com> wrote:
>
> The first file of Amit's patch can not only re-range the code, but also fix a
> hidden bug.
> To make it easy to see, I attach another patch.
> "RelationIdGetRelation" will increase ref on owner->relrefarr, without
> "RelationClose"
The first file of Amit's patch can not only re-range the code, but also fix a
hidden bug.
To make it easy to see, I attach another patch.
"RelationIdGetRelation" will increase ref on owner->relrefarr, without
"RelationClose", the owner->relrefarr will enlarge and re-hash.
When the capacity of own
On Fri, Apr 17, 2020 at 10:23 PM Peter Eisentraut
wrote:
> On 2020-04-09 09:28, Amit Langote wrote:
> > While figuring this out, I thought the nearby code could be rearranged
> > a bit, especially to de-duplicate the code. Also, I think
> > get_rel_sync_entry() may be a better place to set the ma
On 2020-04-09 09:28, Amit Langote wrote:
This patch makes the tests pass for me:
diff --git a/src/backend/replication/pgoutput/pgoutput.c
b/src/backend/replication/pgoutput/pgoutput.c
index 5fbf2d4367..cf6e8629c1 100644
--- a/src/backend/replication/pgoutput/pgoutput.c
+++ b/src/backend/replicat
On Thu, Apr 9, 2020 at 4:14 PM Peter Eisentraut
wrote:
> On 2020-04-09 05:39, Amit Langote wrote:
> > sub_viaroot ERROR: number of columns (2601) exceeds limit (1664)
> > sub_viaroot CONTEXT: slot "sub_viaroot", output plugin "pgoutput", in
> > the change callback, associated LSN 0/1621010
>
> I
On 2020-04-09 05:39, Amit Langote wrote:
sub_viaroot ERROR: number of columns (2601) exceeds limit (1664)
sub_viaroot CONTEXT: slot "sub_viaroot", output plugin "pgoutput", in
the change callback, associated LSN 0/1621010
I think the problem is that in maybe_send_schema(),
RelationClose(ance
On Wed, Apr 8, 2020 at 11:07 PM Amit Langote wrote:
> On Wed, Apr 8, 2020 at 9:21 PM Peter Eisentraut
> wrote:
> > On 2020-04-08 13:16, Amit Langote wrote:
> > > prion seems to have failed:
> > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prion&dt=2020-04-08%2009%3A53%3A13
> >
> > Th
On Wed, Apr 8, 2020 at 11:07 PM Amit Langote wrote:
> On Wed, Apr 8, 2020 at 9:21 PM Peter Eisentraut
> wrote:
> > I think this is because the END { } section in PostgresNode.pm shuts
> > down all running instances in immediate mode, which doesn't save
> > coverage properly.
>
> Thanks for that t
On Wed, Apr 8, 2020 at 9:21 PM Peter Eisentraut
wrote:
> On 2020-04-08 13:16, Amit Langote wrote:
> > On Wed, Apr 8, 2020 at 6:26 PM Peter Eisentraut
> > wrote:
> >> All committed.
> >>
> >> Thank you and everyone very much for working on this. I'm very happy
> >> that these two features from PG
On 2020-04-08 13:16, Amit Langote wrote:
On Wed, Apr 8, 2020 at 6:26 PM Peter Eisentraut
wrote:
All committed.
Thank you and everyone very much for working on this. I'm very happy
that these two features from PG10 have finally met. :)
Thanks a lot for reviewing and committing.
prion seems
On Wed, Apr 8, 2020 at 6:26 PM Peter Eisentraut
wrote:
> All committed.
>
> Thank you and everyone very much for working on this. I'm very happy
> that these two features from PG10 have finally met. :)
Thanks a lot for reviewing and committing.
prion seems to have failed:
https://buildfarm.post
On 2020-04-08 07:45, Amit Langote wrote:
On Wed, Apr 8, 2020 at 1:22 AM Amit Langote wrote:
On Tue, Apr 7, 2020 at 6:01 PM Peter Eisentraut
wrote:
The descriptions of the new fields in RelationSyncEntry don't seem to
match the code accurately, or at least it's confusing.
replicate_as_relid is
On Wed, Apr 8, 2020 at 1:22 AM Amit Langote wrote:
> On Tue, Apr 7, 2020 at 6:01 PM Peter Eisentraut
> wrote:
> > The descriptions of the new fields in RelationSyncEntry don't seem to
> > match the code accurately, or at least it's confusing.
> > replicate_as_relid is always filled in with an anc
Thanks for the review.
On Tue, Apr 7, 2020 at 6:01 PM Peter Eisentraut
wrote:
> On 2020-04-07 08:44, Amit Langote wrote:
> > I updated the patch to make the following changes:
> >
> > * Rewrote the tests to match in style with those committed yesterday
> > * Renamed all variables that had pubasro
On 2020-04-07 08:44, Amit Langote wrote:
I updated the patch to make the following changes:
* Rewrote the tests to match in style with those committed yesterday
* Renamed all variables that had pubasroot in it to have pubviaroot
instead to match the publication parameter
* Updated pg_publication
On Tue, Apr 7, 2020 at 12:04 AM Amit Langote wrote:
>
> On Mon, Apr 6, 2020 at 10:25 PM Peter Eisentraut
> wrote:
> > On 2020-04-03 16:25, Amit Langote wrote:
> > > On Fri, Apr 3, 2020 at 6:34 PM Amit Langote
> > > wrote:
> > >> I am checking test coverage at the moment and should have the patc
On Mon, Apr 6, 2020 at 10:25 PM Peter Eisentraut
wrote:
> On 2020-04-03 16:25, Amit Langote wrote:
> > On Fri, Apr 3, 2020 at 6:34 PM Amit Langote wrote:
> >> I am checking test coverage at the moment and should have the patches
> >> ready by sometime later today.
> >
> > Attached updated patches
On 2020-04-03 16:25, Amit Langote wrote:
On Fri, Apr 3, 2020 at 6:34 PM Amit Langote wrote:
I am checking test coverage at the moment and should have the patches
ready by sometime later today.
Attached updated patches.
Committed 0001 now. I'll work on the rest tomorrow.
--
Peter Eisentrau
Amit Langote writes:
> One thing to I must clarify: coverage for most of pgoutput.c looks
> okay on each run. I am concerned that the coverage for the code added
> by the patch is shown to be close to zero, which is a mystery to me,
> because I can confirm by other means such as debugging elogs()
On Sat, Apr 4, 2020 at 5:56 PM Petr Jelinek wrote:
> On 04/04/2020 07:25, Tom Lane wrote:
> > Petr Jelinek writes:
> >> On 03/04/2020 17:51, Tom Lane wrote:
> >>> But the forked-off children have to write the gcov files independently,
> >>> don't they?
> >
> >> Hmm that's very good point. I did s
On 04/04/2020 07:25, Tom Lane wrote:
Petr Jelinek writes:
On 03/04/2020 17:51, Tom Lane wrote:
But the forked-off children have to write the gcov files independently,
don't they?
Hmm that's very good point. I did see these missing coverage issue when
running tests that explicitly start more
Petr Jelinek writes:
> On 03/04/2020 17:51, Tom Lane wrote:
>> But the forked-off children have to write the gcov files independently,
>> don't they?
> Hmm that's very good point. I did see these missing coverage issue when
> running tests that explicitly start more instances of postgres before
On 03/04/2020 17:51, Tom Lane wrote:
Petr Jelinek writes:
On 03/04/2020 16:59, Tom Lane wrote:
Petr Jelinek writes:
AFAIK gcov can't handle multiple instances of same process being started
as it just overwrites the coverage files. So for TAP test it will report
bogus info (as in some code th
Petr Jelinek writes:
> On 03/04/2020 16:59, Tom Lane wrote:
>> Petr Jelinek writes:
>>> AFAIK gcov can't handle multiple instances of same process being started
>>> as it just overwrites the coverage files. So for TAP test it will report
>>> bogus info (as in some code that's executed will look a
On 03/04/2020 16:59, Tom Lane wrote:
Petr Jelinek writes:
AFAIK gcov can't handle multiple instances of same process being started
as it just overwrites the coverage files. So for TAP test it will report
bogus info (as in some code that's executed will look as not executed).
Hm, really? I ro
Petr Jelinek writes:
> AFAIK gcov can't handle multiple instances of same process being started
> as it just overwrites the coverage files. So for TAP test it will report
> bogus info (as in some code that's executed will look as not executed).
Hm, really? I routinely run "make check" (ie, pa
Hi,
On 03/04/2020 16:25, Amit Langote wrote:
On Fri, Apr 3, 2020 at 6:34 PM Amit Langote wrote:
I am checking test coverage at the moment and should have the patches
ready by sometime later today.
Attached updated patches.
I confirmed using a coverage build that all the new code in
logical/
On Fri, Apr 3, 2020 at 6:34 PM Amit Langote wrote:
> I am checking test coverage at the moment and should have the patches
> ready by sometime later today.
Attached updated patches.
I confirmed using a coverage build that all the new code in
logical/worker.c due to 0002 is now covered. For some
On Fri, Apr 3, 2020 at 4:52 PM Petr Jelinek wrote:
> On 02/04/2020 14:23, Peter Eisentraut wrote:
> > On 2020-03-30 17:42, Amit Langote wrote:
> >> I have updated the comments in apply_handle_tuple_routing() (see 0002)
> >> to better explain what's going on with UPDATE handling. I also
> >> rearr
Hi,
On 02/04/2020 14:23, Peter Eisentraut wrote:
On 2020-03-30 17:42, Amit Langote wrote:
I have updated the comments in apply_handle_tuple_routing() (see 0002)
to better explain what's going on with UPDATE handling. I also
rearranged the tests a bit for clarity.
Attached updated patches.
>
On 2020-03-30 17:42, Amit Langote wrote:
I have updated the comments in apply_handle_tuple_routing() (see 0002)
to better explain what's going on with UPDATE handling. I also
rearranged the tests a bit for clarity.
Attached updated patches.
Test coverage for 0002 is still a bit lacking. Plea
I have updated the comments in apply_handle_tuple_routing() (see 0002)
to better explain what's going on with UPDATE handling. I also
rearranged the tests a bit for clarity.
Attached updated patches.
--
Thank you,
Amit Langote
EnterpriseDB: http://www.enterprisedb.com
v1-0001-worker.c-refact
On Thu, Mar 26, 2020 at 11:23 PM Amit Langote wrote:
> On Wed, Mar 25, 2020 at 9:29 PM Peter Eisentraut
> wrote:
> > On 2020-03-23 06:02, Amit Langote wrote:
> > > Okay, added some tests.
> > >
> > > Attached updated patches.
> >
> > I have committed the worker.c refactoring patch.
> >
> > "Add s
On Wed, Mar 25, 2020 at 9:29 PM Peter Eisentraut
wrote:
> On 2020-03-23 06:02, Amit Langote wrote:
> > Okay, added some tests.
> >
> > Attached updated patches.
>
> I have committed the worker.c refactoring patch.
>
> "Add subscription support to replicate into partitioned tables" still
> has lack
On 2020-03-23 06:02, Amit Langote wrote:
Okay, added some tests.
Attached updated patches.
I have committed the worker.c refactoring patch.
"Add subscription support to replicate into partitioned tables" still
has lacking test coverage. Your changes in relation.c are not exercised
at all b
On Thu, Mar 19, 2020 at 11:18 PM Peter Eisentraut
wrote:
> On 2020-03-18 08:33, Amit Langote wrote:
> > By the way, I have rebased the patches, although maybe you've got your
> > own copies; attached.
>
> Looking through 0002 and 0003 now.
>
> The structure looks generally good.
Thanks for the re
On 2020-03-18 08:33, Amit Langote wrote:
By the way, I have rebased the patches, although maybe you've got your
own copies; attached.
Looking through 0002 and 0003 now.
The structure looks generally good.
In 0002, the naming of apply_handle_insert() vs.
apply_handle_do_insert() etc. seems a
On 2020-03-18 15:19, Amit Langote wrote:
On Wed, Mar 18, 2020 at 8:16 PM Peter Eisentraut
wrote:
On 2020-03-18 04:06, Amit Langote wrote:
+ if (isnull || !remote_is_publishable)
+ ereport(ERROR,
+ (errmsg("table \"%s.%s\" on the publisher is not publishable",
+
On Wed, Mar 18, 2020 at 8:16 PM Peter Eisentraut
wrote:
> On 2020-03-18 04:06, Amit Langote wrote:
> > + if (isnull || !remote_is_publishable)
> > + ereport(ERROR,
> > + (errmsg("table \"%s.%s\" on the publisher is not
> > publishable",
> > + nspname, r
On 2020-03-18 04:06, Amit Langote wrote:
+ if (isnull || !remote_is_publishable)
+ ereport(ERROR,
+ (errmsg("table \"%s.%s\" on the publisher is not publishable",
+ nspname, relname)));
Maybe add a one-line comment above this to say it's an "not suppos
On Wed, Mar 18, 2020 at 12:06 PM Amit Langote wrote:
> Hi Peter,
>
> On Mon, Mar 16, 2020 at 9:49 PM Peter Eisentraut
> wrote:
> >
> > I was trying to extract some preparatory work from the remaining patches
> > and came up with the attached. This is part of your patch 0003, but
> > also relevan
Hi Peter,
On Mon, Mar 16, 2020 at 9:49 PM Peter Eisentraut
wrote:
>
> I was trying to extract some preparatory work from the remaining patches
> and came up with the attached. This is part of your patch 0003, but
> also relevant for part 0004. The problem was that COPY (SELECT *) is
> not suffi
I was trying to extract some preparatory work from the remaining patches
and came up with the attached. This is part of your patch 0003, but
also relevant for part 0004. The problem was that COPY (SELECT *) is
not sufficient when the table has generated columns, so we need to build
the column
On Tue, Mar 10, 2020 at 5:52 PM Peter Eisentraut
wrote:
> I have committed the 0001 patch of this series (partitioned table member
> of publication). I changed the new argument of
> GetPublicationRelations() to an enum and reformatted some comments.
> I'll continue looking through the subsequent
I have committed the 0001 patch of this series (partitioned table member
of publication). I changed the new argument of
GetPublicationRelations() to an enum and reformatted some comments.
I'll continue looking through the subsequent patches.
--
Peter Eisentraut http://www.2ndQuad
On Tue, Jan 28, 2020 at 6:11 PM Peter Eisentraut
wrote:
> This structure looks good now.
Thanks for taking a look.
> However, it does seem unfortunate that in pg_get_publication_tables() we
> need to postprocess the result of GetPublicationRelations(). Since
> we're already changing the API of
Hi Amit,
Once again I went through this patch set and here are my few comments,
On Thu, 23 Jan 2020 at 11:10, Amit Langote wrote:
>
> On Wed, Jan 22, 2020 at 2:38 PM Amit Langote wrote:
> > Other than that, the updated patch contains following significant changes:
> >
> > * Changed pg_publicati
On 2020-01-23 11:10, Amit Langote wrote:
On Wed, Jan 22, 2020 at 2:38 PM Amit Langote wrote:
Other than that, the updated patch contains following significant changes:
* Changed pg_publication.c: GetPublicationRelations() so that any
published partitioned tables are expanded as needed
* Since
RELKIND_PARTITIONED_TABLE)
- ereport(ERROR,
- (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
- errmsg("\"%s\" is a partitioned table",
-
RelationGetRelationName(targetrel)),
-errde
On Wed, Jan 8, 2020 at 7:57 PM Peter Eisentraut
wrote:
> On 2020-01-07 15:18, Rafia Sabih wrote:
> > On Tue, 7 Jan 2020 at 06:02, Amit Langote wrote:
> >
> >> Rebased and updated to address your comments.
> >>
> > +
> > + Partitioned tables are not considered when FOR ALL
> > TABLES
> > +
On 2020-01-07 15:18, Rafia Sabih wrote:
On Tue, 7 Jan 2020 at 06:02, Amit Langote wrote:
Rebased and updated to address your comments.
+
+ Partitioned tables are not considered when FOR ALL TABLES
+ is specified.
+
+
What is the reason for above, I mean not for the comment but not
in
On 2020-01-07 06:01, Amit Langote wrote:
On Mon, Jan 6, 2020 at 8:25 PM Rafia Sabih wrote:
Hi Amit,
I went through this patch set once again today and here are my two cents.
Thanks Rafia.
Rebased and updated to address your comments.
Looking through 0001, I think perhaps there is a better
On Tue, 7 Jan 2020 at 06:02, Amit Langote wrote:
> Rebased and updated to address your comments.
>
+
+ Partitioned tables are not considered when FOR ALL TABLES
+ is specified.
+
+
What is the reason for above, I mean not for the comment but not
including partitioned tables in for all tab
Hi Amit,
I went through this patch set once again today and here are my two cents.
On Mon, 16 Dec 2019 at 10:19, Amit Langote wrote:
>
> Attached updated patches.
- differently partitioned setup. Attempts to replicate tables other than
- base tables will result in an error.
+ Replic
On Mon, Dec 16, 2019 at 2:50 PM Amit Langote wrote:
>
> Thanks for checking.
>
> On Thu, Dec 12, 2019 at 12:48 AM Peter Eisentraut
> wrote:
> > On 2019-12-06 08:48, Amit Langote wrote:
> > > 0001: Adding a partitioned table to a publication implicitly adds all
> > > its partitions. The receivin
On 2019-12-06 08:48, Amit Langote wrote:
0001: Adding a partitioned table to a publication implicitly adds all
its partitions. The receiving side must have tables matching the
published partitions, which is typically the case, because the same
partition tree is defined on both nodes.
This loo
On Fri, Nov 22, 2019 at 7:46 PM Peter Eisentraut
wrote:
> On 2019-11-22 07:28, Amit Langote wrote:
> > Hmm, I thought it would be more desirable to not expose a published
> > partitioned table's leaf partitions to a subscriber, because it allows
> > the target table to be defined more flexibly.
>
On Fri, Nov 22, 2019 at 4:16 PM Peter Eisentraut
wrote:
>
> On 2019-11-22 07:28, Amit Langote wrote:
>
> >> What happens when you add a leaf table directly to a publication? Is it
> >> replicated under its own identity or under its ancestor partitioned
> >> table? (What if both the leaf table an
On 2019-11-22 07:28, Amit Langote wrote:
Hmm, I thought it would be more desirable to not expose a published
partitioned table's leaf partitions to a subscriber, because it allows
the target table to be defined more flexibly.
There are multiple different variants that we probably eventually wan
Hi Peter,
On Wed, Nov 20, 2019 at 4:55 PM Peter Eisentraut
wrote:
> On 2019-11-18 09:53, Amit Langote wrote:
> > I have spent some time hacking on this. With the attached updated
> > patch, adding a partitioned table to publication results in publishing
> > the inserts, updates, deletes of the t
On 2019-11-12 02:11, Amit Langote wrote:
I don't understand why you go through great lengths to ensure that the
relkinds match between publisher and subscriber. We already ensure that
only regular tables are published and only regular tables are allowed as
subscription target. In the future, we
On 2019-11-18 09:53, Amit Langote wrote:
I have spent some time hacking on this. With the attached updated
patch, adding a partitioned table to publication results in publishing
the inserts, updates, deletes of the table's leaf partitions as
inserts, updates, deletes of the table itself (it all
On Tue, Nov 12, 2019 at 10:11 AM Amit Langote wrote:
> Initial
> syncing code can be easily modified to support any combination of
> source and target relations, but changes needed for real-time
> replication seem non-trivial.
I have spent some time hacking on this. With the attached updated
pat
On Mon, Nov 11, 2019 at 9:49 PM Peter Eisentraut
wrote:
> On 2019-11-11 08:59, Amit Langote wrote:
> > On Fri, Nov 8, 2019 at 1:27 PM Amit Langote wrote:
> >> Anyway, I've attached two patches -- 0001 is a refactoring patch. 0002
> >> implements the feature.
> >
> > 0002 didn't contain necessary
On 2019-11-11 08:59, Amit Langote wrote:
On Fri, Nov 8, 2019 at 1:27 PM Amit Langote wrote:
Anyway, I've attached two patches -- 0001 is a refactoring patch. 0002
implements the feature.
0002 didn't contain necessary pg_dump changes, which fixed in the
attached new version.
That looks more
On Fri, Nov 8, 2019 at 1:27 PM Amit Langote wrote:
> Anyway, I've attached two patches -- 0001 is a refactoring patch. 0002
> implements the feature.
0002 didn't contain necessary pg_dump changes, which fixed in the
attached new version.
Thanks,
Amit
v4-0001-Some-refactoring-of-publication-and
Hello Rafia,
On Tue, Nov 5, 2019 at 12:41 AM Rafia Sabih wrote:
> On Fri, 11 Oct 2019 at 08:06, Amit Langote wrote:
>> Thanks for sharing this case. I hadn't considered it, but you're
>> right that it should be handled sensibly. I have fixed table sync
>> code to handle this case properly. Co
Sorry about the delay.
On Mon, Nov 4, 2019 at 8:00 PM Peter Eisentraut
wrote:
> This patch seems excessively complicated to me. Why don't you just add
> the actual partitioned table to pg_publication_rel and then expand the
> partition hierarchy in pgoutput (get_rel_sync_entry() or
> GetRelation
Hi Amit,
On Fri, 11 Oct 2019 at 08:06, Amit Langote wrote:
>
> Thanks for sharing this case. I hadn't considered it, but you're
> right that it should be handled sensibly. I have fixed table sync
> code to handle this case properly. Could you please check your case
> with the attached updated
This patch seems excessively complicated to me. Why don't you just add
the actual partitioned table to pg_publication_rel and then expand the
partition hierarchy in pgoutput (get_rel_sync_entry() or
GetRelationPublications() or somewhere around there). Then you don't
need to do any work in ta
;
> > ERROR: "p" is a partitioned table
> > DETAIL: Adding partitioned tables to publications is not supported.
> > HINT: You can add the table partitions individually.
> >
> > One can do this instead:
> >
> > create publication publish_p1 for table p1;
Hi David,
On Sun, Oct 13, 2019 at 4:55 PM David Fetter wrote:
> On Mon, Oct 07, 2019 at 09:55:23AM +0900, Amit Langote wrote:
> > I propose that we make this command:
> >
> > create publication publish_p for table p;
> >
> > automatically add all the partitions to the publication. Also, any
> >
tition of p for values with (modulus 3, remainder 1);
> create table p3 partition of p for values with (modulus 3, remainder 2);
>
> create publication publish_p for table p;
> ERROR: "p" is a partitioned table
> DETAIL: Adding partitioned tables to publications is not s
, remainder 1);
create table p3 partition of p for values with (modulus 3, remainder 2);
create publication publish_p for table p;
ERROR: "p" is a partitioned table
DETAIL: Adding partitioned tables to publications is not supported.
HINT: You can add the table partitions individually.
Hello Rafia,
Great to hear that you are interested in this feature and thanks for
testing the patch.
On Thu, Oct 10, 2019 at 10:13 PM Rafia Sabih wrote:
> Lately I was exploring logical replication feature of postgresql and I found
> this addition in the scope of feature for partitioned tables
f p for values with (modulus 3, remainder 0);
> > create table p2 partition of p for values with (modulus 3, remainder 1);
> > create table p3 partition of p for values with (modulus 3, remainder 2);
> >
> > create publication publish_p for table p;
> > ERROR: "p&
for values with (modulus 3, remainder 1);
> create table p3 partition of p for values with (modulus 3, remainder 2);
>
> create publication publish_p for table p;
> ERROR: "p" is a partitioned table
> DETAIL: Adding partitioned tables to publications is not supported.
&
values with (modulus 3, remainder 2);
create publication publish_p for table p;
ERROR: "p" is a partitioned table
DETAIL: Adding partitioned tables to publications is not supported.
HINT: You can add the table partitions individually.
One can do this instead:
create publication publ
81 matches
Mail list logo