On 25/05/17 23:26, Peter Eisentraut wrote: > 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). >
This specific error returns ERRCODE_UNDEFINED_OBJECT error code so we could check for it and offer hint only for this case. -- 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
