On Fri, Jan 18, 2008 at 11:07:27AM -0500, Christopher Browne wrote:
> >> > > 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.
Ok. Good. Then I think the reason it's not sup****ted in pgAdmin is simply
because it made the GUI simpler to require that ;-)
//Magnus
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
|
