On 5/24/17 21:41, Robert Haas wrote: >> This came up in a previous thread. It is up to the publishing end what >> slot names it accepts. So running the validation locally is incorrect. > > That argument seems pretty tenuous; surely both ends are PostgreSQL, > and the rules for valid slot names aren't likely to change very often.
Remember that this could be used for upgrades and side-grades, so the local rules could change or be more restricted in the future or depending on compilation options. > But even if we accept it as true, I still don't like the idea that a > DROP can just fail, especially with no real guidance as to how to fix > things so it doesn't fail. Ideas: > > 1. If we didn't create the slot (and have never connected to it?), > don't try to drop it. That would conceptually be nice, but it would probably create a bunch of problems of its own. For one, we would need an interlock so that the first $anything that connects to the slot registers it in the local catalog as "it's mine now". > 2. Emit some kind of a HINT telling people about ALTER SUBSCRIPTION .. > SET (slot_name = NONE). The reported error is just one of many errors that can happen when DROP SUBSCRIPTION tries to drop the slot (doens't exist, still active, no permission, etc.). We don't want to give the hint that is effectively "just forget about the slot then" for all of them. So we would need some way to distinguish "you can't do this right now" from "this would never work" (400 vs 500 errors). Another way to fix this particular issue is to not verify the replication slot name before doing the drop. After all, if the name is not valid, then you can also just report that it doesn't exist. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, 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
