alex <an@clickware.de> writes: > Given that the problem occurred on two different machines we are very > sure that it is *not* a hardware problem. I wouldn't be so sure, especially not when the behavior looks like a hardware problem in every other respect. You've heard of common-mode failures, no? Do both machines have RAM chips from the same batch, for instance? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

Gregory Stark <stark@enterprisedb.com> writes: > I don't understand this 9728 bytes. Postgres blocks are 8192 bytes. Are you > saying one whole block is trashed and then part, but not all, of the next > block? > What's the block size of the ZFS filesystem? And what exactly does the trash > data look like? It seems relevant that 9728 is a multiple of 512 (and not of any larger power of 2). That makes it sound like the misfeasance happened at the disk block level. Postgres doesn't internally deal in 512-byte chunks anywhere I can think of, so to posit a DB bug you have to come up with some other explanation why exactly that much of the block got trashed. A filesystem-level software bug is not out of the question, though this still smells to me like it's a hardware issue of some kind. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match