Re: Logical decoding on standby
От | Craig Ringer |
---|---|
Тема | Re: Logical decoding on standby |
Дата | |
Msg-id | CAMsr+YGjZRqo-boCF9z5Bc1WZ_10RjMLtNSTsaa=kkE9_GmTag@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Logical decoding on standby (Craig Ringer <craig@2ndquadrant.com>) |
Ответы |
Re: Logical decoding on standby
|
Список | pgsql-hackers |
Hi Here's the next patch in the split-up series, drop db-specific (logical) replication slots on DROP DATABASE. Current behaviour is to ERROR if logical slots exist on the DB, whether in-use or not. With this patch we can DROP a database if it has logical slots so long as they are not active. I haven't added any sort of syntax for this, it's just done unconditionally. I don't see any sensible way to stop a slot becoming active after we check for active slots and begin the actual database DROP, since ReplicationSlotAcquire will happily acquire a db-specific slot for a different DB and the only lock it takes is a shared lock on ReplicationSlotControlLock, which we presumably don't want to hold throughout DROP DATABASE. So this patch makes ReplicationSlotAcquire check that the slot database matches the current database and refuse to acquire the slot if it does not. The only sensible reason to acquire a slot from a different DB is to drop it, and then it's only a convenience at best. Slot drop is the only user-visible behaviour change, since all other activity on logical slots happened when the backend was already connected to the slot's DB. Appropriate docs changes have been made and tests added. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: