On Sat, 22 Jul 2006 22:13:49 -0400 (EDT)
cbbrowne at ca.afilias.info wrote:

> > Ah OK - I'm sure I read "somewhere" that you could just execute ALTER
> > TABLE on each node manually if needed. I shall update our DBA with this
> > new knowledge :)
> 
> If you can find that in documentation, *I* should get shot...

:)
 
> Altering tables directly is most definitely a Very Bad Thing To Do.  I
> think that is made fairly clear in the admin guide; where not, I'll
> underline the point...

Your message didn't go to the list (only to me and Jan), so I'll include its content here for posterity.
 
> <http://cbbrowne.com/info/ddlchanges.html>
> - This page should mention that the "altertableforreplication()" function
> is vital, and why, and that's the specific place where your system broke.
> 
> <http://cbbrowne.com/info/bestpractices.html>
> - The "Best Practices" is crystal clear on this...
> 
> # Changes that must be applied using execute script
>     * All instances of ALTER TABLE
> 
> <http://www.varlena.com/GeneralBits/88.php>
> Elein's article is quite clear, too, addressing the point in the very
> first paragraph.
> 
> I'll augment docs to mention a "why," in that first section.  But for
> sure, there are two good places to look at that do make this pretty
> clear...

Righto message understood - I can only assume I misread something, or I'd had one too many glasses of something very pleasant at the time and the magic fairies altered the thought pattern as it went into memory =)

I'm actually very relieved that this has turned out simply to be a UBD [1] error. Those we can deal with. It's just random 'Doesn't work for no good reason' that wind me up.

Anyway, thanks to Jan and yourself for verbose and timely response in getting this solved. 

> > :) I only asked because it's the first question I'll be asked on Monday,
> > and the answer 'shit happens' is only going to destroy any confidence
> > management has left in Postgres as a viable enterprise solution. I give it
> > 6 months and we'll be on SQL Server. <slump>
> 
> I understand that pain; I haven't had it with PostgreSQL/Slony-I, but have
> with such things as Oracle / R/3, and I'm wincing at what is forthcoming
> there in the meeting Monday.

Like I say, this wasn't a software failure, but a human failure... at least now our weeks of 'replication problems' have been resolved, so we're just back to our normal performance issues with PG itself, but that's a whole other world that Tom, Simon and co. are dealing with :)

Cheers,
Gavin.


[1] http://dictionary.reference.com/search?q=ubd