Fri Dec 3 22:48:23 PST 2004
- Previous message: [Slony1-general] large objects
- Next message: [Slony1-general] large objects
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>> 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 >
- Previous message: [Slony1-general] large objects
- Next message: [Slony1-general] large objects
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-general mailing list