Sigh...maybe it's hopeless, after all...

>Two problems with this.
>
>a) An existing LOB can be opened and modified without the 
>referencing row containing its oid being upated at all. So if 
>you just select the oid and lo_open, lo_write, lo_close, 
>there's nothing that will trigger.

This particular use-case wouldn't come up in our application - there
would always
be some other associated field update, but of course if you can't handle
the 
general case it's not something that will work for everybody.

>b) Deferring the read of the LOB until the subscriber actually 
>processes the SYNC bears the risk that if transaction x 
>updates the LOB, then a SYNC happens, then transaction y 
>deletes the LOB before that SYNC in the middle gets processed 
>by the subscribers, there's no data for the update procedure 
>left, leading to an inconsistent, visible state in the subscriber.

Oh. I guess large object operations are out-of-transaction then? (Guess
I
can RTFM on that one....) This scenario is also not likely in our
application,
but I had hoped to do something generally useful. Oh well.

>Without triggers on pg_largeobject, it is impossible to make 
>LO replication transparent for Slony-I.

In fact, even triggers were possible, it would still be problematic,
from what I can see,
because the data gets broken up into multiple rows in that table.

>A crufty workaround would be that the application must call 
>some special function after doing lo_close or lo_delete but 
>before commit, which records the entire LOB content at that 
>time in the replication log. 
>Needless to say that that application then will be responsible 
>to never forget to call this function, and that it will break 
>at the moment you don't have slony installed in that DB.

Thanks for the info, depressing though it is ;-)

- DAP