From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jaime Silvela <JSilvela(at)bear(dot)com> |
Cc: | Postgres General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: unexpected data beyond EOF and character encoding |
Date: | 2007-03-28 15:02:30 |
Message-ID: | 24872.1175094150@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Jaime Silvela <JSilvela(at)bear(dot)com> writes:
> The kernel is Linux 2.6.5
2.6.5.what (give us full uname -a output please)? On what hardware?
If memory serves, we had some reason to think that it only occurred on
specific 64-bit multi-CPU platforms, so I'm not just asking idly.
The error check was put in as a consequence of this thread:
http://archives.postgresql.org/pgsql-admin/2006-09/msg00250.php
> So I take it that this happens on the restore part, not the dump part then?
It's definitely a write failure not a read failure. Per the code comments:
* We get here only in the corner case where we are trying to extend
* the relation but we found a pre-existing buffer marked BM_VALID.
* This can happen because mdread doesn't complain about reads beyond
* EOF --- which is arguably bogus, but changing it seems tricky ---
* and so a previous attempt to read a block just beyond EOF could
* have left a "valid" zero-filled buffer. Unfortunately, we have
* also seen this case occurring because of buggy Linux kernels that
* sometimes return an lseek(SEEK_END) result that doesn't account for
* a recent write. In that situation, the pre-existing buffer would
* contain valid data that we don't want to overwrite. Since the
* legitimate cases should always have left a zero-filled buffer,
* complain if not PageIsNew.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-03-28 15:07:54 | Re: Slow sequential scans on one DB but not another; fragmentation? |
Previous Message | Jaime Silvela | 2007-03-28 14:52:26 | Re: unexpected data beyond EOF and character encoding |