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: