| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "George Pavlov" <gpavlov(at)mynewplace(dot)com> |
| Cc: | "Ed L(dot)" <pgsql(at)bluepolka(dot)net>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: query log corrupted-looking entries |
| Date: | 2007-06-08 01:17:41 |
| Message-ID: | 11458.1181265461@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers |
"George Pavlov" <gpavlov(at)mynewplace(dot)com> writes:
> I tried the patch and it has no effect whatsoever -- even with the
> patch, under the correct load the corrupted entries are coming fast and
> furious (I found a load profile on my app that reproduces these very
> clearly).
What are the total lengths of the log entries in which you see the
failure? (The "length" here includes all the lines belonging to a
single logical entry, eg, ERROR, DETAIL, HINT.)
I believe that this shouldn't be happening except in the case in which
the entry-interpolated-into exceeds PIPE_BUF bytes. I'm not entirely
sure what PIPE_BUF is on Linux machines, but IIRC the Posix spec says it
has to be at least 512, and on older Unix kernels it tends to be 8K.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2007-06-08 01:25:08 | Re: Creditcard Number Security was Re: Encrypted column |
| Previous Message | Richard P. Welty | 2007-06-08 01:03:15 | Re: Creditcard Number Security was Re: Encrypted column |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2007-06-08 01:19:50 | Re: .conf File Organization WAS: Controlling Load Distributed Checkpoints |
| Previous Message | Alvaro Herrera | 2007-06-08 01:12:31 | Re: [COMMITTERS] pgsql: Avoid losing track of data for shared tables in pgstats. |