Re: [HACKERS] Logical Replication WIP

2017-03-03 Thread Peter Eisentraut
On 2/22/17 07:00, Petr Jelinek wrote: > On 22/02/17 12:24, Petr Jelinek wrote: >> Hi, >> >> I updated these patches for current HEAD and removed the string >> initialization in walsender as Fuji Masao committed similar fix in meantime. >> >> I also found typo/thinko in the first patch which is now

Re: [HACKERS] Logical Replication WIP

2017-02-22 Thread Petr Jelinek
On 22/02/17 12:24, Petr Jelinek wrote: > Hi, > > I updated these patches for current HEAD and removed the string > initialization in walsender as Fuji Masao committed similar fix in meantime. > > I also found typo/thinko in the first patch which is now fixed. > And of course I missed the

Re: [HACKERS] Logical Replication WIP

2017-02-22 Thread Petr Jelinek
Hi, I updated these patches for current HEAD and removed the string initialization in walsender as Fuji Masao committed similar fix in meantime. I also found typo/thinko in the first patch which is now fixed. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL

Re: [HACKERS] Logical Replication WIP

2017-01-26 Thread Petr Jelinek
On 25/01/17 18:16, Peter Eisentraut wrote: > On 1/22/17 8:11 PM, Petr Jelinek wrote: >> 0001 - Changes the libpqrcv_connect to use async libpq api so that it >> won't get stuck forever in case of connect is stuck. This is preexisting >> bug that also affects walreceiver but it's less visible there

Re: [HACKERS] Logical Replication WIP

2017-01-25 Thread Peter Eisentraut
On 1/23/17 11:19 AM, Fujii Masao wrote: > The copyright in each file that the commit of logical rep added needs to > be updated. I have fixed that. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via

Re: [HACKERS] Logical Replication WIP

2017-01-25 Thread Peter Eisentraut
On 1/22/17 8:11 PM, Petr Jelinek wrote: > 0001 - Changes the libpqrcv_connect to use async libpq api so that it > won't get stuck forever in case of connect is stuck. This is preexisting > bug that also affects walreceiver but it's less visible there as there > is no SQL interface to initiate

Re: [HACKERS] Logical Replication WIP

2017-01-23 Thread Petr Jelinek
On 23/01/17 17:19, Fujii Masao wrote: > On Sat, Jan 21, 2017 at 1:39 AM, Petr Jelinek > wrote: >> On 20/01/17 17:33, Jaime Casanova wrote: >>> On 20 January 2017 at 11:25, Petr Jelinek >>> wrote: On 20/01/17 17:05, Fujii Masao

Re: [HACKERS] Logical Replication WIP

2017-01-23 Thread Fujii Masao
On Sat, Jan 21, 2017 at 1:39 AM, Petr Jelinek wrote: > On 20/01/17 17:33, Jaime Casanova wrote: >> On 20 January 2017 at 11:25, Petr Jelinek >> wrote: >>> On 20/01/17 17:05, Fujii Masao wrote: On Fri, Jan 20, 2017 at 11:08 PM,

Re: [HACKERS] Logical Replication WIP

2017-01-23 Thread Thom Brown
On 23 January 2017 at 01:11, Petr Jelinek wrote: > On 20/01/17 22:30, Petr Jelinek wrote: >> Since it's not exactly straight forward to find when these need to be >> initialized based on commands, I decided to move the initialization code >> to

Re: [HACKERS] Logical Replication WIP

2017-01-22 Thread Petr Jelinek
On 20/01/17 22:30, Petr Jelinek wrote: > Since it's not exactly straight forward to find when these need to be > initialized based on commands, I decided to move the initialization code > to exec_replication_command() since that's always called before anything > so that makes it much less error

Re: [HACKERS] Logical Replication WIP

2017-01-20 Thread Petr Jelinek
On 20/01/17 17:23, Petr Jelinek wrote: > On 20/01/17 15:08, Peter Eisentraut wrote: >> On 1/19/17 5:01 PM, Petr Jelinek wrote: >>> There were some conflicting changes committed today so I rebased the >>> patch on top of them. >>> >>> Other than that nothing much has changed, I removed the separate

Re: [HACKERS] Logical Replication WIP

2017-01-20 Thread Robert Haas
On Fri, Jan 20, 2017 at 2:57 PM, Craig Ringer wrote: > > I don't see how a subscription can do anything useful with wal_level < > > logical? > > The upstream must have it set to logical so we can decide the change stream. > > The downstream need not. It's an independent

Re: [HACKERS] Logical Replication WIP

2017-01-20 Thread Craig Ringer
On 21 Jan. 2017 06:48, "Robert Haas" wrote: On Fri, Jan 20, 2017 at 11:39 AM, Petr Jelinek wrote: > Launcher is needed for subscriptions, subscriptions don't depend on > wal_level. I don't see how a subscription can do anything useful with

Re: [HACKERS] Logical Replication WIP

2017-01-20 Thread Robert Haas
On Fri, Jan 20, 2017 at 11:39 AM, Petr Jelinek wrote: > Launcher is needed for subscriptions, subscriptions don't depend on > wal_level. I don't see how a subscription can do anything useful with wal_level < logical? -- Robert Haas EnterpriseDB:

Re: [HACKERS] Logical Replication WIP

2017-01-20 Thread Jaime Casanova
On 20 January 2017 at 11:39, Petr Jelinek wrote: > On 20/01/17 17:33, Jaime Casanova wrote: >>> >> >> surely wal_level < logical shouldn't start a logical replication >> launcher, and after an initdb wal_level is only replica >> > > Launcher is needed for

Re: [HACKERS] Logical Replication WIP

2017-01-20 Thread Petr Jelinek
On 20/01/17 17:33, Jaime Casanova wrote: > On 20 January 2017 at 11:25, Petr Jelinek > wrote: >> On 20/01/17 17:05, Fujii Masao wrote: >>> On Fri, Jan 20, 2017 at 11:08 PM, Peter Eisentraut >>> wrote: On 1/19/17 5:01 PM, Petr

Re: [HACKERS] Logical Replication WIP

2017-01-20 Thread Jaime Casanova
On 20 January 2017 at 11:25, Petr Jelinek wrote: > On 20/01/17 17:05, Fujii Masao wrote: >> On Fri, Jan 20, 2017 at 11:08 PM, Peter Eisentraut >> wrote: >>> On 1/19/17 5:01 PM, Petr Jelinek wrote: There were some conflicting

Re: [HACKERS] Logical Replication WIP

2017-01-20 Thread Petr Jelinek
On 20/01/17 17:05, Fujii Masao wrote: > On Fri, Jan 20, 2017 at 11:08 PM, Peter Eisentraut > wrote: >> On 1/19/17 5:01 PM, Petr Jelinek wrote: >>> There were some conflicting changes committed today so I rebased the >>> patch on top of them. >>> >>> Other than

Re: [HACKERS] Logical Replication WIP

2017-01-20 Thread Petr Jelinek
On 20/01/17 15:08, Peter Eisentraut wrote: > On 1/19/17 5:01 PM, Petr Jelinek wrote: >> There were some conflicting changes committed today so I rebased the >> patch on top of them. >> >> Other than that nothing much has changed, I removed the separate sync >> commit patch, included the rename

Re: [HACKERS] Logical Replication WIP

2017-01-20 Thread Fujii Masao
On Fri, Jan 20, 2017 at 11:08 PM, Peter Eisentraut wrote: > On 1/19/17 5:01 PM, Petr Jelinek wrote: >> There were some conflicting changes committed today so I rebased the >> patch on top of them. >> >> Other than that nothing much has changed, I removed the

Re: [HACKERS] Logical Replication WIP

2017-01-20 Thread Peter Eisentraut
On 1/19/17 5:01 PM, Petr Jelinek wrote: > There were some conflicting changes committed today so I rebased the > patch on top of them. > > Other than that nothing much has changed, I removed the separate sync > commit patch, included the rename patch in the patchset and fixed the > bug around

Re: [HACKERS] Logical Replication WIP - FailedAssertion, File: "array_typanalyze.c", Line: 340

2017-01-19 Thread Erik Rijkers
On 2017-01-19 19:12, Petr Jelinek wrote: On 19/01/17 18:44, Erik Rijkers wrote: Could probably be whittled down to something shorter but I hope it's still easily reproduced. Just analyze on the pg_subscription is enough. heh. Ah well, I did find it :) Can you give the current patch

Re: [HACKERS] Logical Replication WIP - FailedAssertion, File: "array_typanalyze.c", Line: 340

2017-01-19 Thread Petr Jelinek
On 19/01/17 18:44, Erik Rijkers wrote: > > Could probably be whittled down to something shorter but I hope it's > still easily reproduced. > Just analyze on the pg_subscription is enough. Looks like it's the name[] type, when I change it to text[] like in the attached patch it works fine for

Re: [HACKERS] Logical Replication WIP - FailedAssertion, File: "array_typanalyze.c", Line: 340

2017-01-19 Thread Erik Rijkers
On 2017-01-19 01:02, Petr Jelinek wrote: This causes the replica to crash: #-- #!/bin/bash # 2 instances on 6972 (master) and 6973 (replica) # initially without publication or subscription # clean logs #echo >

Re: [HACKERS] Logical Replication WIP

2017-01-18 Thread Petr Jelinek
On 17/01/17 22:43, Robert Haas wrote: > On Tue, Jan 17, 2017 at 11:15 AM, Petr Jelinek > wrote: >>> Is there anything stopping anyone from implementing it? >> >> No, just didn't seem priority for the functionality right now. > > Why is it OK for this to not support

Re: [HACKERS] Logical Replication WIP

2017-01-17 Thread Robert Haas
On Tue, Jan 17, 2017 at 11:15 AM, Petr Jelinek wrote: >> Is there anything stopping anyone from implementing it? > > No, just didn't seem priority for the functionality right now. Why is it OK for this to not support rename like everything else does? It shouldn't

Re: [HACKERS] Logical Replication WIP

2017-01-17 Thread Petr Jelinek
On 17/01/17 17:11, Peter Eisentraut wrote: > On 1/15/17 1:48 PM, Petr Jelinek wrote: >> It's meant to decouple the synchronous commit setting for logical >> replication workers from the one set for normal clients. Now that we >> have owners for subscription and subscription runs as that owner,

Re: [HACKERS] Logical Replication WIP

2017-01-17 Thread Petr Jelinek
On 17/01/17 17:09, Peter Eisentraut wrote: > >> Yes, that will need some discussion about corner case behaviour. For >> example, have partitioned table 'foo' which is in publication, then you >> have table 'bar' which is not in publication, you attach it to the >> partitioned table 'foo', should

Re: [HACKERS] Logical Replication WIP

2017-01-17 Thread Peter Eisentraut
On 1/15/17 1:48 PM, Petr Jelinek wrote: > It's meant to decouple the synchronous commit setting for logical > replication workers from the one set for normal clients. Now that we > have owners for subscription and subscription runs as that owner, maybe > we could do that via ALTER USER. I was

Re: [HACKERS] Logical Replication WIP

2017-01-17 Thread Peter Eisentraut
On 1/15/17 5:20 PM, Petr Jelinek wrote: > Well, it's 4 because max_worker_processes is 8, I think default > max_worker_processes should be higher than > max_logical_replication_workers so that's why I picked 4. If we are okay > wit bumping the max_worker_processes a bit, I am all for increasing >

Re: [HACKERS] Logical Replication WIP

2017-01-17 Thread Peter Eisentraut
On 1/15/17 2:28 PM, Petr Jelinek wrote: > Well the preinstalled information_schema is excluded by the > FirstNormalObjectId filter as it's created by initdb. If user drops and > recreates it that means it was created as user object. > > My opinion is that FOR ALL TABLES should replicate all user

Re: [HACKERS] Logical Replication WIP

2017-01-15 Thread Petr Jelinek
On 15/01/17 23:57, Erik Rijkers wrote: > On 2017-01-15 23:20, Petr Jelinek wrote: > >> 0001-Add-PUBLICATION-catalogs-and-DDL-v18.patch >> 0002-Add-SUBSCRIPTION-catalog-and-DDL-v18.patch >> 0003-Define-logical-replication-protocol-and-output-plugi-v18.patch >>

Re: [HACKERS] Logical Replication WIP

2017-01-15 Thread Erik Rijkers
On 2017-01-15 23:20, Petr Jelinek wrote: 0001-Add-PUBLICATION-catalogs-and-DDL-v18.patch 0002-Add-SUBSCRIPTION-catalog-and-DDL-v18.patch 0003-Define-logical-replication-protocol-and-output-plugi-v18.patch 0004-Add-logical-replication-workers-v18.patch

Re: [HACKERS] Logical Replication WIP

2017-01-15 Thread Petr Jelinek
On 15/01/17 20:20, Euler Taveira wrote: > On 15-01-2017 15:13, Petr Jelinek wrote: >> I am not quite sure I agree with this. Either it's system object and we >> don't replicate it (which I would have considered to be anything with >> Oid < FirstNormalObjectId) or it's user made and then it should

Re: [HACKERS] Logical Replication WIP

2017-01-15 Thread Euler Taveira
On 15-01-2017 15:13, Petr Jelinek wrote: > I am not quite sure I agree with this. Either it's system object and we > don't replicate it (which I would have considered to be anything with > Oid < FirstNormalObjectId) or it's user made and then it should be > replicated. Filtering by schema name is

Re: [HACKERS] Logical Replication WIP

2017-01-15 Thread Petr Jelinek
On 06/01/17 21:26, Peter Eisentraut wrote: > 0005-Add-separate-synchronous-commit-control-for-logical--v16.patch.gz > > This looks a little bit hackish. I'm not sure how this would behave > properly when either synchronous_commit or > logical_replication_synchronous_commit is changed at run time

Re: [HACKERS] Logical Replication WIP

2017-01-15 Thread Petr Jelinek
On 11/01/17 22:30, Peter Eisentraut wrote: > On 1/11/17 3:35 PM, Petr Jelinek wrote: >> On 11/01/17 18:32, Peter Eisentraut wrote: >>> On 1/11/17 3:29 AM, Petr Jelinek wrote: Okay, looking into my notes, I originally did this because we did not allow adding tables without pkeys to

Re: [HACKERS] Logical Replication WIP

2017-01-11 Thread Peter Eisentraut
On 1/11/17 3:35 PM, Petr Jelinek wrote: > On 11/01/17 18:32, Peter Eisentraut wrote: >> On 1/11/17 3:29 AM, Petr Jelinek wrote: >>> Okay, looking into my notes, I originally did this because we did not >>> allow adding tables without pkeys to publications which effectively >>> prohibited FOR ALL

Re: [HACKERS] Logical Replication WIP

2017-01-11 Thread Peter Eisentraut
On 1/11/17 3:35 PM, Petr Jelinek wrote: > On 11/01/17 18:27, Peter Eisentraut wrote: >> On 1/11/17 3:11 AM, Petr Jelinek wrote: >>> That will not help, issue is that we consider names for origins to be >>> unique across cluster while subscription names are per database so if >>> there is origin

Re: [HACKERS] Logical Replication WIP

2017-01-11 Thread Petr Jelinek
On 11/01/17 18:27, Peter Eisentraut wrote: > On 1/11/17 3:11 AM, Petr Jelinek wrote: >> That will not help, issue is that we consider names for origins to be >> unique across cluster while subscription names are per database so if >> there is origin per subscription (which there has to be) it will

Re: [HACKERS] Logical Replication WIP

2017-01-11 Thread Petr Jelinek
On 11/01/17 18:32, Peter Eisentraut wrote: > On 1/11/17 3:29 AM, Petr Jelinek wrote: >> Okay, looking into my notes, I originally did this because we did not >> allow adding tables without pkeys to publications which effectively >> prohibited FOR ALL TABLES publication from working because of >>

Re: [HACKERS] Logical Replication WIP

2017-01-11 Thread Peter Eisentraut
On 1/11/17 3:29 AM, Petr Jelinek wrote: > Okay, looking into my notes, I originally did this because we did not > allow adding tables without pkeys to publications which effectively > prohibited FOR ALL TABLES publication from working because of > information_schema without this. Since this is no

Re: [HACKERS] Logical Replication WIP

2017-01-11 Thread Peter Eisentraut
On 1/11/17 3:11 AM, Petr Jelinek wrote: > That will not help, issue is that we consider names for origins to be > unique across cluster while subscription names are per database so if > there is origin per subscription (which there has to be) it will always > clash if we just use the name. I

Re: [HACKERS] Logical Replication WIP

2017-01-11 Thread Petr Jelinek
On 10/01/17 15:06, Peter Eisentraut wrote: > On 1/3/17 5:23 PM, Petr Jelinek wrote: >> I got this remark about IsCatalogClass() from Andres offline as well, >> but it's not true, it only checks for FirstNormalObjectId for objects in >> pg_catalog and toast schemas, not anywhere else. > > I see

Re: [HACKERS] Logical Replication WIP

2017-01-11 Thread Petr Jelinek
On 10/01/17 14:52, Peter Eisentraut wrote: > On 1/2/17 8:32 AM, Petr Jelinek wrote: >> On 02/01/17 05:23, Steve Singer wrote: >>> but I can't drop the subscription either >>> >>> >>> test_b=# drop subscription mysub; >>> ERROR: could not drop replication origin with OID 1, in use by PID 24996 >>>

Re: [HACKERS] Logical Replication WIP

2017-01-10 Thread Peter Eisentraut
On 1/3/17 5:23 PM, Petr Jelinek wrote: > I got this remark about IsCatalogClass() from Andres offline as well, > but it's not true, it only checks for FirstNormalObjectId for objects in > pg_catalog and toast schemas, not anywhere else. I see your statement is correct, but I'm not sure the

Re: [HACKERS] Logical Replication WIP

2017-01-10 Thread Peter Eisentraut
On 1/2/17 8:32 AM, Petr Jelinek wrote: > On 02/01/17 05:23, Steve Singer wrote: >> but I can't drop the subscription either >> >> >> test_b=# drop subscription mysub; >> ERROR: could not drop replication origin with OID 1, in use by PID 24996 >> >> alter subscription mysub disable; >> ALTER

Re: [HACKERS] Logical Replication WIP

2017-01-06 Thread Peter Eisentraut
0005-Add-separate-synchronous-commit-control-for-logical--v16.patch.gz This looks a little bit hackish. I'm not sure how this would behave properly when either synchronous_commit or logical_replication_synchronous_commit is changed at run time with a reload. I'm thinking maybe this and perhaps

Re: [HACKERS] Logical Replication WIP

2017-01-06 Thread Peter Eisentraut
Comments on 0004-Add-logical-replication-workers-v16.patch.gz: I didn't find any major problems. At times while I was testing strange things it was not clear why "nothing is happening". I'll do some more checking in that direction. Fixup patch attached that enhances some error messages, fixes

Re: [HACKERS] Logical Replication WIP

2017-01-04 Thread Peter Eisentraut
0003-Define-logical-replication-protocol-and-output-plugi-v16.patch.gz looks good now, documentation is clear now. Another fixup patch to remove excessive includes. ;-) -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training &

Re: [HACKERS] Logical Replication WIP

2017-01-04 Thread Peter Eisentraut
Some small patches for 0002-Add-SUBSCRIPTION-catalog-and-DDL-v16.patch.gz: - Add a get_subscription_name() function - Remove call for ApplyLauncherWakeupAtCommit() (rebasing error?) - Remove some unused include files (same as before) - Rename pg_dump --no-create-subscription-slot to

Re: [HACKERS] Logical Replication WIP

2017-01-04 Thread Petr Jelinek
On 03/01/17 22:51, Peter Eisentraut wrote: > On 1/3/17 2:39 PM, Peter Eisentraut wrote: >> In 0001-Add-PUBLICATION-catalogs-and-DDL-v16.patch.gz, > > Attached are a couple of small fixes for this. Feel free to ignore the > removal of the header files if they are needed by later patches. >

Re: [HACKERS] Logical Replication WIP

2017-01-03 Thread Petr Jelinek
On 03/01/17 20:39, Peter Eisentraut wrote: > In 0001-Add-PUBLICATION-catalogs-and-DDL-v16.patch.gz, > > +static bool > +is_publishable_class(Oid relid, Form_pg_class reltuple) > +{ > + return reltuple->relkind == RELKIND_RELATION && > + !IsCatalogClass(relid, reltuple) && > +

Re: [HACKERS] Logical Replication WIP

2017-01-03 Thread Peter Eisentraut
On 1/3/17 2:39 PM, Peter Eisentraut wrote: > In 0001-Add-PUBLICATION-catalogs-and-DDL-v16.patch.gz, Attached are a couple of small fixes for this. Feel free to ignore the removal of the header files if they are needed by later patches. -- Peter Eisentraut

Re: [HACKERS] Logical Replication WIP

2017-01-03 Thread Peter Eisentraut
In 0001-Add-PUBLICATION-catalogs-and-DDL-v16.patch.gz, +static bool +is_publishable_class(Oid relid, Form_pg_class reltuple) +{ + return reltuple->relkind == RELKIND_RELATION && + !IsCatalogClass(relid, reltuple) && + reltuple->relpersistence ==

Re: [HACKERS] Logical Replication WIP

2017-01-02 Thread Petr Jelinek
On 02/01/17 05:23, Steve Singer wrote: > On 12/30/2016 05:53 AM, Petr Jelinek wrote: >> Hi, >> >> I rebased this for the changes made to inheritance and merged in the >> fixes that I previously sent separately. >> >> >> > > > I'm not sure if the following is expected or not > > I have 1

Re: [HACKERS] Logical Replication WIP

2017-01-01 Thread Steve Singer
On 12/30/2016 05:53 AM, Petr Jelinek wrote: Hi, I rebased this for the changes made to inheritance and merged in the fixes that I previously sent separately. I'm not sure if the following is expected or not I have 1 publisher and 1 subscriber. I then do pg_dump on my subscriber ./pg_dump

Re: [HACKERS] Logical Replication WIP

2016-12-30 Thread Erik Rijkers
On 2016-12-30 11:53, Petr Jelinek wrote: I rebased this for the changes made to inheritance and merged in the 0002-Add-SUBSCRIPTION-catalog-and-DDL-v16.patch.gz (~31 KB) couple of orthography errors in messages --- ./src/backend/commands/subscriptioncmds.c.orig 2016-12-30

Re: [HACKERS] Logical Replication WIP

2016-12-30 Thread Erik Rijkers
On 2016-12-30 11:53, Petr Jelinek wrote: I rebased this for the changes made to inheritance and merged in the 0002-Add-SUBSCRIPTION-catalog-and-DDL-v16.patch.gz (~31 KB) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Logical Replication WIP

2016-12-20 Thread Petr Jelinek
On 20/12/16 10:56, Erik Rijkers wrote: > On 2016-12-20 10:48, Petr Jelinek wrote: > > Here is another small thing: > > $ psql -d testdb -p 6972 > psql (10devel_logical_replication_20161220_1008_db80acfc9d50) > Type "help" for help. > > testdb=# drop publication if exists xxx; > ERROR:

Re: [HACKERS] Logical Replication WIP

2016-12-20 Thread Erik Rijkers
On 2016-12-20 10:48, Petr Jelinek wrote: Here is another small thing: $ psql -d testdb -p 6972 psql (10devel_logical_replication_20161220_1008_db80acfc9d50) Type "help" for help. testdb=# drop publication if exists xxx; ERROR: unrecognized object type: 28 testdb=# drop subscription if

Re: [HACKERS] Logical Replication WIP

2016-12-20 Thread Petr Jelinek
On 20/12/16 10:41, Erik Rijkers wrote: > On 2016-12-20 09:43, Petr Jelinek wrote: > >> Thanks, this was very useful. We had wrong attribute index arithmetics >> in the place where we verify that replica identities match well enough. > > Well, I spent a lot of time on the whole thing so I am glad

Re: [HACKERS] Logical Replication WIP

2016-12-20 Thread Erik Rijkers
On 2016-12-20 09:43, Petr Jelinek wrote: Thanks, this was very useful. We had wrong attribute index arithmetics in the place where we verify that replica identities match well enough. Well, I spent a lot of time on the whole thing so I am glad it's not just something stupid I did :) BTW

Re: [HACKERS] Logical Replication WIP

2016-12-19 Thread Erik Rijkers
On 2016-12-19 08:04, Erik Rijkers wrote: On 2016-12-18 11:12, Petr Jelinek wrote: (now using latest: patchset:) 0001-Add-PUBLICATION-catalogs-and-DDL-v14.patch 0002-Add-SUBSCRIPTION-catalog-and-DDL-v14.patch 0003-Define-logical-replication-protocol-and-output-plugi-v14.patch

Re: [HACKERS] Logical Replication WIP

2016-12-19 Thread Petr Jelinek
On 19/12/16 15:39, Steve Singer wrote: > On 12/18/2016 09:04 PM, Petr Jelinek wrote: >> On 18/12/16 19:02, Steve Singer wrote: >> >>> pg_dump is also generating warnings >>> >>> pg_dump: [archiver] WARNING: don't know how to set owner for object type >>> SUBSCRIPTION >>> >>> I know that the plan

Re: [HACKERS] Logical Replication WIP

2016-12-19 Thread Steve Singer
On 12/18/2016 09:04 PM, Petr Jelinek wrote: On 18/12/16 19:02, Steve Singer wrote: pg_dump is also generating warnings pg_dump: [archiver] WARNING: don't know how to set owner for object type SUBSCRIPTION I know that the plan is to add proper ACL's for publications and subscriptions later. I

Re: [HACKERS] Logical Replication WIP

2016-12-19 Thread Petr Jelinek
On 19/12/16 08:04, Erik Rijkers wrote: > On 2016-12-18 11:12, Petr Jelinek wrote: > > (now using latest: patchset:) > > 0001-Add-PUBLICATION-catalogs-and-DDL-v14.patch > 0002-Add-SUBSCRIPTION-catalog-and-DDL-v14.patch > 0003-Define-logical-replication-protocol-and-output-plugi-v14.patch >

Re: [HACKERS] Logical Replication WIP

2016-12-18 Thread Erik Rijkers
On 2016-12-18 11:12, Petr Jelinek wrote: (now using latest: patchset:) 0001-Add-PUBLICATION-catalogs-and-DDL-v14.patch 0002-Add-SUBSCRIPTION-catalog-and-DDL-v14.patch 0003-Define-logical-replication-protocol-and-output-plugi-v14.patch 0004-Add-logical-replication-workers-v14.patch

Re: [HACKERS] Logical Replication WIP

2016-12-18 Thread Steve Singer
On 12/18/2016 05:28 AM, Petr Jelinek wrote: On 17/12/16 18:34, Steve Singer wrote: On 12/16/2016 07:49 AM, Petr Jelinek wrote: Yeah subscriptions are per database. I don't want to make v14 just for these 2 changes as that would make life harder for anybody code-reviewing the v13 so attached

Re: [HACKERS] Logical Replication WIP

2016-12-18 Thread Petr Jelinek
On 17/12/16 18:34, Steve Singer wrote: > On 12/16/2016 07:49 AM, Petr Jelinek wrote: >> Hi, >> >> attached is version 13 of the patch. >> >> I merged in changes from PeterE. And did following changes: >> - fixed the ownership error messages for both provider and subscriber >> - added ability to

Re: [HACKERS] Logical Replication WIP

2016-12-18 Thread Petr Jelinek
On 17/12/16 13:37, Erik Rijkers wrote: > On 2016-12-16 13:49, Petr Jelinek wrote: >> >> version 13 of the patch. >> >> 0001-Add-PUBLICATION-catalogs-and-DDL-v13.patch.gz (~32 KB) >> 0002-Add-SUBSCRIPTION-catalog-and-DDL-v13.patch.gz (~28 KB) >> 0003-Define-logical-rep...utput-plugi-v13.patch.gz

Re: [HACKERS] Logical Replication WIP

2016-12-17 Thread Steve Singer
On 12/16/2016 07:49 AM, Petr Jelinek wrote: Hi, attached is version 13 of the patch. I merged in changes from PeterE. And did following changes: - fixed the ownership error messages for both provider and subscriber - added ability to send invalidation message to invalidate whole relcache and

Re: [HACKERS] Logical Replication WIP

2016-12-17 Thread Erik Rijkers
On 2016-12-16 13:49, Petr Jelinek wrote: version 13 of the patch. 0001-Add-PUBLICATION-catalogs-and-DDL-v13.patch.gz (~32 KB) 0002-Add-SUBSCRIPTION-catalog-and-DDL-v13.patch.gz (~28 KB) 0003-Define-logical-rep...utput-plugi-v13.patch.gz (~13 KB)

Re: [HACKERS] Logical Replication WIP

2016-12-15 Thread Petr Jelinek
On 15/12/16 13:06, Craig Ringer wrote: > On 15 Dec. 2016 18:19, "Petr Jelinek" > wrote: > > On 13/12/16 21:42, Peter Eisentraut wrote: > > On 12/10/16 2:48 AM, Petr Jelinek wrote: > >> Attached new version with your

Re: [HACKERS] Logical Replication WIP

2016-12-15 Thread Craig Ringer
On 15 Dec. 2016 18:19, "Petr Jelinek" wrote: On 13/12/16 21:42, Peter Eisentraut wrote: > On 12/10/16 2:48 AM, Petr Jelinek wrote: >> Attached new version with your updates and rebased on top of the current >> HEAD (the partitioning patch produced quite a few

Re: [HACKERS] Logical Replication WIP

2016-12-15 Thread Petr Jelinek
On 13/12/16 21:42, Peter Eisentraut wrote: > On 12/10/16 2:48 AM, Petr Jelinek wrote: >> Attached new version with your updates and rebased on top of the current >> HEAD (the partitioning patch produced quite a few conflicts). > > I have attached a few more "fixup" patches, mostly with some

Re: [HACKERS] Logical Replication WIP

2016-12-15 Thread Petr Jelinek
On 13/12/16 01:33, Andres Freund wrote: > > On 2016-12-12 09:18:48 -0500, Peter Eisentraut wrote: >> On 12/8/16 4:10 PM, Petr Jelinek wrote: >>> On 08/12/16 20:16, Peter Eisentraut wrote: On 12/6/16 11:58 AM, Peter Eisentraut wrote: > On 12/5/16 6:24 PM, Petr Jelinek wrote: >> I

Re: [HACKERS] Logical Replication WIP

2016-12-13 Thread Petr Jelinek
On 13/12/16 21:42, Peter Eisentraut wrote: > On 12/10/16 2:48 AM, Petr Jelinek wrote: >> Attached new version with your updates and rebased on top of the current >> HEAD (the partitioning patch produced quite a few conflicts). > > I have attached a few more "fixup" patches, mostly with some

Re: [HACKERS] Logical Replication WIP

2016-12-13 Thread Petr Jelinek
On 13/12/16 22:05, Andres Freund wrote: > Hi, > > On 2016-12-13 15:42:17 -0500, Peter Eisentraut wrote: >> I think this is getting very close to the point where it's committable. >> So if anyone else has major concerns about the whole approach and >> perhaps the way the new code in 0005 is

Re: [HACKERS] Logical Replication WIP

2016-12-13 Thread Petr Jelinek
On 14/12/16 01:26, Peter Eisentraut wrote: > On 12/12/16 7:33 PM, Andres Freund wrote: >> +-- test switching between slots in a session >> +SELECT 'init' FROM pg_create_logical_replication_slot('regression_slot1', >> 'test_decoding', true); >> +SELECT 'init' FROM

Re: [HACKERS] Logical Replication WIP

2016-12-13 Thread Peter Eisentraut
On 12/12/16 7:33 PM, Andres Freund wrote: > +-- test switching between slots in a session > +SELECT 'init' FROM pg_create_logical_replication_slot('regression_slot1', > 'test_decoding', true); > +SELECT 'init' FROM pg_create_logical_replication_slot('regression_slot2', > 'test_decoding', true);

Re: [HACKERS] Logical Replication WIP

2016-12-13 Thread Andres Freund
On 2016-12-13 06:55:31 +0100, Petr Jelinek wrote: > >> This is a quadratic algorithm - that could bite us... Not sure if we > >> need to care. If we want to fix it, one approach owuld be to use > >> RangeVarGetRelid() instead, and then do a qsort/deduplicate before > >> actually opening the

Re: [HACKERS] Logical Replication WIP

2016-12-13 Thread Andres Freund
Hi, On 2016-12-13 15:42:17 -0500, Peter Eisentraut wrote: > I think this is getting very close to the point where it's committable. > So if anyone else has major concerns about the whole approach and > perhaps the way the new code in 0005 is organized, now would be the time ... Uh. The whole

Re: [HACKERS] Logical Replication WIP

2016-12-13 Thread Peter Eisentraut
On 12/10/16 2:48 AM, Petr Jelinek wrote: > Attached new version with your updates and rebased on top of the current > HEAD (the partitioning patch produced quite a few conflicts). I have attached a few more "fixup" patches, mostly with some editing of documentation and comments and some compiler

Re: [HACKERS] Logical Replication WIP

2016-12-12 Thread Petr Jelinek
On 13/12/16 03:26, Petr Jelinek wrote: > On 13/12/16 02:41, Andres Freund wrote: >> On 2016-12-10 08:48:55 +0100, Petr Jelinek wrote: >> >>> +static List * >>> +OpenTableList(List *tables) >>> +{ >>> + List *relids = NIL; >>> + List *rels = NIL; >>> + ListCell *lc; >>> + >>> +

Re: [HACKERS] Logical Replication WIP

2016-12-12 Thread Petr Jelinek
On 13/12/16 02:41, Andres Freund wrote: > On 2016-12-10 08:48:55 +0100, Petr Jelinek wrote: > >> diff --git a/src/backend/catalog/pg_publication.c >> b/src/backend/catalog/pg_publication.c >> new file mode 100644 >> index 000..e3560b7 >> --- /dev/null >> +++

Re: [HACKERS] Logical Replication WIP

2016-12-12 Thread Andres Freund
On 2016-12-10 08:48:55 +0100, Petr Jelinek wrote: > diff --git a/src/backend/catalog/pg_publication.c > b/src/backend/catalog/pg_publication.c > new file mode 100644 > index 000..e3560b7 > --- /dev/null > +++ b/src/backend/catalog/pg_publication.c > + > +Datum

Re: [HACKERS] Logical Replication WIP

2016-12-12 Thread Petr Jelinek
On 13/12/16 01:33, Andres Freund wrote: > HJi, > > On 2016-12-12 09:18:48 -0500, Peter Eisentraut wrote: >> On 12/8/16 4:10 PM, Petr Jelinek wrote: >>> On 08/12/16 20:16, Peter Eisentraut wrote: On 12/6/16 11:58 AM, Peter Eisentraut wrote: > On 12/5/16 6:24 PM, Petr Jelinek wrote: >>

Re: [HACKERS] Logical Replication WIP

2016-12-12 Thread Andres Freund
HJi, On 2016-12-12 09:18:48 -0500, Peter Eisentraut wrote: > On 12/8/16 4:10 PM, Petr Jelinek wrote: > > On 08/12/16 20:16, Peter Eisentraut wrote: > >> On 12/6/16 11:58 AM, Peter Eisentraut wrote: > >>> On 12/5/16 6:24 PM, Petr Jelinek wrote: > I think that the removal of changes to

Re: [HACKERS] Logical Replication WIP

2016-12-12 Thread Peter Eisentraut
On 12/8/16 4:10 PM, Petr Jelinek wrote: > On 08/12/16 20:16, Peter Eisentraut wrote: >> On 12/6/16 11:58 AM, Peter Eisentraut wrote: >>> On 12/5/16 6:24 PM, Petr Jelinek wrote: I think that the removal of changes to ReplicationSlotAcquire() that you did will result in making it

Re: [HACKERS] Logical Replication WIP

2016-12-09 Thread Petr Jelinek
Hi, On 09/12/16 22:00, Erik Rijkers wrote: > On 2016-12-09 17:08, Peter Eisentraut wrote: > > Your earlier 0001-Add-support-for-temporary-replication-slots.patch > could be applied instead of the similarly named, original patch by Petr. > (I used 19fcc0058ecc8e5eb756547006bc1b24a93cbb80 to apply

Re: [HACKERS] Logical Replication WIP

2016-12-09 Thread Erik Rijkers
On 2016-12-09 17:08, Peter Eisentraut wrote: Your earlier 0001-Add-support-for-temporary-replication-slots.patch could be applied instead of the similarly named, original patch by Petr. (I used 19fcc0058ecc8e5eb756547006bc1b24a93cbb80 to apply this patch-set to) (And it was, by the way,

Re: [HACKERS] Logical Replication WIP

2016-12-09 Thread Peter Eisentraut
Here is a "fixup" patch for 0002-Add-PUBLICATION-catalogs-and-DDL-v11.patch.gz with some minor fixes. Two issues that should be addressed: 1. I think ALTER PUBLICATION does not need to require CREATE privilege on the database. That should be easy to change. 2. By requiring only SELECT

Re: [HACKERS] Logical Replication WIP

2016-12-08 Thread Petr Jelinek
On 08/12/16 20:16, Peter Eisentraut wrote: > On 12/6/16 11:58 AM, Peter Eisentraut wrote: >> On 12/5/16 6:24 PM, Petr Jelinek wrote: >>> I think that the removal of changes to ReplicationSlotAcquire() that you >>> did will result in making it impossible to reacquire temporary slot once >>> you

Re: [HACKERS] Logical Replication WIP

2016-12-08 Thread Peter Eisentraut
On 12/6/16 11:58 AM, Peter Eisentraut wrote: > On 12/5/16 6:24 PM, Petr Jelinek wrote: >> I think that the removal of changes to ReplicationSlotAcquire() that you >> did will result in making it impossible to reacquire temporary slot once >> you switched to different one in the session as the if

Re: [HACKERS] Logical Replication WIP

2016-12-06 Thread Peter Eisentraut
On 12/5/16 6:24 PM, Petr Jelinek wrote: > I think that the removal of changes to ReplicationSlotAcquire() that you > did will result in making it impossible to reacquire temporary slot once > you switched to different one in the session as the if (active_pid != 0) > will always be true for temp

Re: [HACKERS] Logical Replication WIP

2016-12-05 Thread Andres Freund
On 2016-12-02 12:37:49 -0500, Peter Eisentraut wrote: > On 11/20/16 1:02 PM, Petr Jelinek wrote: > > 0001: > > This is the reworked approach to temporary slots that I sent earlier. > > Andres, you had expressed an interest in this. Will you be able to > review it soon? Yep. Needed to get that

Re: [HACKERS] Logical Replication WIP

2016-12-05 Thread Petr Jelinek
On 04/12/16 02:06, Peter Eisentraut wrote: > I massaged the temporary replication slot patch a bit. I changed the > column name in pg_stat_replication_slots from "persistent" to > "temporary" and flipped the logical sense, so that it is consistent with > the creation commands. I also adjusted

Re: [HACKERS] Logical Replication WIP

2016-12-04 Thread Haribabu Kommi
On Sun, Dec 4, 2016 at 12:06 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > I massaged the temporary replication slot patch a bit. I changed the > column name in pg_stat_replication_slots from "persistent" to > "temporary" and flipped the logical sense, so that it is

Re: [HACKERS] Logical Replication WIP

2016-12-03 Thread Peter Eisentraut
I massaged the temporary replication slot patch a bit. I changed the column name in pg_stat_replication_slots from "persistent" to "temporary" and flipped the logical sense, so that it is consistent with the creation commands. I also adjusted some comments and removed some changes in

  1   2   3   >