| From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Simon Riggs <simon(dot)riggs(at)2ndquadrant(dot)com>, Thom Brown <thom(at)linux(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Logical decoding on standby |
| Date: | 2017-03-27 08:03:48 |
| Message-ID: | CAMsr+YEsrUf0sq9RtK7cy2wM7+pUQQ22LzPU-FzVOBL7PROwhg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 27 March 2017 at 14:08, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
> So this patch makes ReplicationSlotAcquire check that the slot
> database matches the current database and refuse to acquire the slot
> if it does not.
New patch attached that drops above requirement, so slots can still be
dropped from any DB.
This introduces a narrow race window where DROP DATABASE may ERROR if
somebody connects to a different database and runs a
pg_drop_replication_slot(...) for one of the slots being dropped by
DROP DATABASE after we check for active slots but before we've dropped
the slot. But it's hard to hit and it's pretty harmless; the worst
possible result is dropping one or more of the slots before we ERROR
out of the DROP. But you clearly didn't want them anyway, since you
were dropping the DB and dropping some slots at the same time.
I think this one's ready to go.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| Attachment | Content-Type | Size |
|---|---|---|
| drop-database-drop-slots-v2.patch | text/x-patch | 14.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2017-03-27 08:18:15 | Re: increasing the default WAL segment size |
| Previous Message | Simon Riggs | 2017-03-27 07:51:32 | Re: Monitoring roles patch |