>> 1) remote_worker.c sync_event, for a given table insert/update, 
>> detects the presence of an oid field. This would require inspecting 
>> more schema metadata about the tables in the set, of course. I'm 
>> already on shaky ground, here, because I don't fully understand yet 
>> how this sync_event works.
>Well we wouldn't scan for oid but instead add another command 
>to slonik, that tells that a specific attribute refrences an oid.

OK. I was just going by what I see in sl_log_1.log_cmddata field, which made me think
one would have to sniff out the relevant field name from the string, but as I said I 
haven't quite grok'd the code yet.

Is there already a slonik command that adds info about a table? All I saw was TABLE ADD KEY... If 
we added the database support for flagging oid fields for tables in a given set, maybe this
could just be populated by slonik at SET ADD TABLE time by querying the catalog? It could be kept 
out of the slonik interface that way. But maybe there are other metadata-type changes planned
for slonik which would fit in with this?

>For this how does the large object dump/restore facility work 
>in PG now (I think it's a contrib package)

I wasn't even aware of that. I'll take a look.

>> I'm sure there are a hundred holes in this, so I'd appreciate 
>> comments. Or if it's completely impossible then somebody can put me 
>> out of my misery immediately....
>
>Provided we can get around the possibility of oid collisions 
>in some nice way I think this method could work.  Do you want 
>to take the legwork time and provide us (me) with a breakdown 
>of how the LO dump/restore stuff does it? 
>and if it's not too ugly, and time permitting I'llsee about  
>hacking around on this a bit.

Assuming we were always updating the replicated oid field with the oid of the lob
created locally, then it seems like local collisions wouldn't happen. It's a little
weird with all of these different oids floating around on different nodes, though, so
who knows....

Sure, I'll take a look at the LO dump/restore stuff. Thanks for the pointer.

- DAP


>
>>
>> Thanks.
>>
>> - DAP
>> 
>---------------------------------------------------------------
>------------
>>------- David Parker    Tazz Networks    (401) 709-5130
>> ?
>> _______________________________________________
>> Slony1-general mailing list
>> Slony1-general at gborg.postgresql.org
>> http://gborg.postgresql.org/mailman/listinfo/slony1-general
>
>--
>Darcy Buskermolen
>Wavefire Technologies Corp.
>ph: 250.717.0200
>fx:  250.763.1759
>http://www.wavefire.com
>