Re: unexpected data beyond EOF and character encoding - Mailing list pgsql-general

Sorry, forgot about the hardware.
Here's the uname -a:
Linux wdlbc22r06 2.6.5-7.244-bigsmp #1 SMP Mon Dec 12 18:32:25 UTC 2005
i686 i686 i386 GNU/Linux

 From hwinfo --cpu
01: None 00.0: 10103 CPU
  [Created at cpu.290]
  Unique ID: rdCR.j8NaKXDZtZ6
  Hardware Class: cpu
  Arch: Intel
  Vendor: "GenuineIntel"
  Model: 15.4.3 "Intel(R) Xeon(TM) CPU 3.60GHz"
  Features:

fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,lm,pni,monitor,ds_cpl,tm2,est,cid
  Clock: 3600 MHz
  Cache: 2048 kb
  Units/Processor: 2
  Config Status: cfg=new, avail=yes, need=no, active=unknown

 From hwinfo --memory
01: None 00.0: 10102 Main Memory
  [Created at memory.59]
  Unique ID: rdCR.CxwsZFjVASF
  Hardware Class: memory
  Model: "Main Memory"
  Memory Range: 0x00000000-0xfff5ba3f (rw)
  Memory Size: 4 GB
  Config Status: cfg=no, avail=yes, need=no, active=unknown

We're running on 32-bit mode for compatibility with some libraries.
How can I determine whether this is due to a buggy kernel?


Tom Lane wrote:
> Jaime Silvela <JSilvela@bear.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
>
>


***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.

Bear Stearns does not provide tax, legal or accounting advice.  You
should consult your own tax, legal and accounting advisors before
engaging in any transaction. In order for Bear Stearns to comply with
Internal Revenue Service Circular 230 (if applicable), you are notified
that any discussion of U.S. federal tax issues contained or referred to
herein is not intended or written to be used, and cannot be used, for
the purpose of:  (A) avoiding penalties that may be imposed under the
Internal Revenue Code; nor (B) promoting, marketing or recommending to
another party any transaction or matter addressed herein.
***********************************************************************