Re: Drop set problem - pgAdmin / Slony I

Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> There doesn't seem to be a -1 node in the sl_listen on the origin or
>> the subscriber.
>>
>> I've removed the second set that was still visible on the subscriber
>> from the sl_set table, however I'm still getting an event in the log
>> where it tries to "copy_set 2" and comes back with the error "set 2
>> not found in runtime configuration".
>>
>> Any idea on how I remove / stop this?
>
> I'll have to defer to the Slony folks on that one.

Hmm. Sounds like an event is outstanding that depends on having that
set around, on the provider, but the set was already removed...

Sounds like a case where "event surgery" would be mandated, that is,
to delete offending entries from sl_event.

Surgery is only safe when you have a very good idea of what you're
doing, and why. If you don't have that certainty, patients frequently
don't survive :-(.

Unfortunately, this situation is leaving a lot of uncertainty in
place, thereby meaning there's rather a lot of risk to the cluster in
doing such surgery :-(.

I don't know where that "-1" node is coming from, which is a big whack
of uncertainty.

>> > > I've had this happen before. Removing the cluster and setting it
>> > up
>> > > again resolves the problem, however once we are in a production
>> > > environment I can't go dropping the whole cluster and replicating
>> > all
>> > > the tables from scratch when it happens.
>> >
>> > Can you give us an exact step-by-step on how to make it happen?
>> >
>>
>> I tried to subscribe a new set with a new table in it and for some
>> reason it failed with the error mentioned. The slony logs show that
>> slony was periodically trying to subscribe on the subscriber.
>
> I mean complete step-to-step, as in exactly what you click and enter. I've
> done what is at least on the surface the same thing you have, with no
> problems. So there must be somethign in the details.
>
>> Seeing as I couldn't remove it from pgAdmin, I went in and ran a
>> slonik script to drop the set, however I didn't try to unsubscribe it
>> with slonik first. So is there a chance it's come about from me not
>> unsubscribing first?
>
> Part of it may - I don't recall offhand it the must-unsubscribe-first is a
> rqeuirement of Slonik or just of pgAdmin.

You don't need to unsubscribe first.

The stored procedure dropSet() is perfectly happy to drop the set at
any time. When the event propagates, it'll happily clear out all
traces of the set.

>> What's the law on mixing the use of pgAdmin and slonik to administer
>> slony?
>
> It shuold be ok. pgAdmin currently has the concept of an "admin node" which
> isn't compatible with the way core slony/slonik does it, but it shouldn't
> actually be causing you any problems. Some very minor functionality (some
> discovery) will not work in pgadmin if yo uset the cluster originallyi from
> slonik, but managing the servers that you've got shouldn't be a problem a
> all.
>
> And it's certainly the design goal - pgadmin shouldn't be doing anything
> that breaks "the core slony way".

They are using the same underlying stored procedures, so it *ought* to be OK.
--
"cbbrowne","@","linuxdatabases.info"
http://cbbrowne.com/info/wp.html
">WindowsNT will not accept fecal matter in its diet... it's that simple.

I suppose that is a good ward against cannibalism." -- Nick Manka