"Ed L." <pgsql@bluepolka.net> 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 ...
regards, tom lane
