Mark Stosberg <mark at summersault.com> writes:
> I had an 1.1.5 install of slony to play with that I wanted to destroy
> and replace with 1.2.1. (This was just a testing environment.).
>
> However, I was getting this error returned:
>
> "Table with id 36 not found"
>
> It would be a lot more user friendly if this message came with some hint
> want to do next, and preferably also printed the table name.

There are three places where that error can be returned.  

In all three cases, I wouldn't expect to be able to consult sl_table
to figure out which table it was that wasn't found.  The nature of the
failure suggests that the table isn't findable.

> Here is the workaround that I was able to use:
>
> 1. I connected to the database involved, and reviewed the tables known
> to slon:
> select tab_id, tab_relname from _saveapet.sl_table;
>
> Table "36" had been dropped while slon wasn't running.
>
> 2. I deleted the related row:
> delete from _saveapet.sl_table where tab_id = 36;
>
> Now I could finish uninstalling the node.

Luckily enough, the problem was evidently that you had dropped the
table, so there was some idea left (in sl_table) as to what table it
was.  That's not something I'd consider I could "expect."

> It would also seem that slonik could have just saved the the trouble
> here and skipped the troublesome row, since the whole table was able to
> get destroyed anyway...

That is worthy of thought, although I'd not be inclined to blindly
proceed towards that before thinking through whether there may be
problems with that approach...
-- 
select 'cbbrowne' || '@' || 'ca.afilias.info';
<http://dba2.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)