Re: [HACKERS] Logical Replication WIP - Mailing list pgsql-hackers
| From | Petr Jelinek |
|---|---|
| Subject | Re: [HACKERS] Logical Replication WIP |
| Date | |
| Msg-id | 4ab07092-5fa3-8b73-f0cd-59f360cab55e@2ndquadrant.com Whole thread Raw |
| In response to | Re: [HACKERS] Logical Replication WIP (Steve Singer <steve@ssinger.info>) |
| Responses |
Re: [HACKERS] Logical Replication WIP
|
| List | pgsql-hackers |
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 send invalidation message to invalidate whole
>> relcache and use it in publication code
>> - added the post creation/alter/drop hooks
>> - removed parts of docs that refer to initial sync (which does not exist
>> yet)
>> - added timeout handling/retry, etc to apply/launcher based on the GUCs
>> that exist for wal receiver (they could use renaming though)
>> - improved feedback behavior
>> - apply worker now uses owner of the subscription as connection user
>> - more tests
>> - check for max_replication_slots in launcher
>> - clarify the update 'K' sub-message description in protocol
>
> A few things I've noticed so far
>
> If I shutdown the publisher I see the following in the log
>
> 2016-12-17 11:33:49.548 EST [1891] LOG: worker process: ?)G? (PID 1987)
> exited with exit code 1
>
> but then if I shutdown the subscriber postmaster and restart it switches to
> 2016-12-17 11:43:09.628 EST [2373] LOG: worker process: ???? (PID 2393)
> exited with exit code 1
>
> Not sure where the 'G' was coming from (other times I have seen an 'I'
> here or other random characters)
>
Uninitialized bgw_name for apply worker. Rather silly bug. Fixed.
>
> I don't think we are cleaning up subscriptions on a drop database
>
> If I do the following
>
> 1) Create a subscription in a new database
> 2) Stop the publisher
> 3) Drop the database on the subscriber
>
> test=# create subscription mysuba connection 'host=localhost dbname=test
> port=5440' publication mypub;
> test=# \c b
> b=# drop database test;
> DROP DATABASE
> b=# select * FROM pg_subscription ;
> subdbid | subname | subowner | subenabled | subconninfo |
> subslotname | subpublications
> ---------+---------+----------+------------+--------------------------------------+-------------+-----------------
>
> 16384 | mysuba | 10 | t | host=localhost dbname=test
> port=5440 | mysuba | {mypub}
>
Good one. I added check that prevents dropping database when there is
subscription defined for it. I think we can't cascade here as
subscription may or may not hold resources (slot) in another
instance/database so preventing the drop is best we can do.
>
> Also I don't think I can now drop mysuba
> b=# drop subscription mysuba;
> ERROR: subscription "mysuba" does not exist
>
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 is diff with
above fixes that applies on top of v13.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachment
pgsql-hackers by date: