On Fri, Mar 24, 2006 at 09:47:20AM -0400, Alvaro Herrera wrote: > Jim C. Nasby wrote: > > On Fri, Mar 24, 2006 at 08:39:02AM -0400, Alvaro Herrera wrote: > > > Jim C. Nasby wrote: > > > > > > > Why would the content of the old_table be unreliable? If we've replayed > > > > logs up to the point of the CTAS then any data that would be visible to > > > > the CTAS should be fine, no? > > > > > > > > Though, the way Tom put it in one of his replies it sounds like WAL > > > > doesn't do any kind of statement logging, only data logging. If that's > > > > the case I'm not sure that the CTAS would actually get replayed. But I > > > > suspect I'm just misunderstanding... > > > > > > The CTAS doesn't get logged (nor replayed obviously). What happens is > > > that the involved files are fsync'ed before transaction commit, AFAIR. > > > > Ahh, yes, that sounds right. Might be a nice gain to be had if there was > > some way to log the statement, but I suspect getting WAL to support that > > would be extremely non-trivial. > > None at all, at least in the current incarnation, I think, because said > query execution is dependent on the contents of the FSM, which is itself > dependent on the timing of VACUUM and other stuff. Such an action, > running with a different FSM content, can very trivially cause data > corruption. Oh, duh, because subsiquent operations will depend on the heap being in a very specific state. Oh well. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@xxxxxxxxxxxxx Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
