On Monday March 31 2003 3:54, Tom Lane wrote: > "Ed L." <[EMAIL PROTECTED]> writes: > >> I am seeing this same problem on two separate machines, one brand new, > >> one older. Not sure yet what is causing it, but seems pretty unlikely > >> that it is hardware-related. > > > > I am dabbling for the first time with a (crashing) C trigger, so that > > may be the culprit here. > > Could well be, although past experience has been that crashes in C code > seldom lead directly to disk corruption. (First, the bogus code has to > overwrite a shared disk buffer. If you follow what I consider the > better path of not making your shared buffers a large fraction of the > address space, the odds of a wild store happening to hit a disk buffer > aren't high. Second, once it's corrupted a shared buffer, it has to > contrive to cause that buffer to get written out before the core dump > occurs --- in most cases, the fact that the postmaster abandons the > contents of shared memory after a backend crash protects us from this > kind of failure.) > > When you find the problem, please take note of whether there's something > involved that increases the chances of corruption getting to disk. We > might want to try to do something about it ...
It is definitely due to some rogue trigger code. Not sure what exactly, but if I remove a certain code segment the problem disappears. Ed ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
