On Mon, 2007-12-31 at 18:35 -0500, Tom Lane wrote:
> "Mason Hale" <[EMAIL PROTECTED]> writes:
> >> This could be the kernel's fault, but I'm wondering whether the
> >> RAID controller is going south.
>
> > To clarify a bit further -- on the production server, the data is written to
> > a 10-disk R
The following bug has been logged online:
Bug reference: 3847
Logged by: Mark Reid
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: Debian Linux
Description:plpython trigger caches table structure - doesn't see
new / changed columns
Details
"Mason Hale" <[EMAIL PROTECTED]> writes:
>> This could be the kernel's fault, but I'm wondering whether the
>> RAID controller is going south.
> To clarify a bit further -- on the production server, the data is written to
> a 10-disk RAID 1+0, but the pg_xlog directory is symlinked to a separate,
Hello Tom --
a thousand thanks for taking the time to walk through those files.
This could be the kernel's fault, but I'm wondering whether the
> RAID controller is going south. Offhand it seems like the controller
> would be the only place that would be likely to explain both the
> bogus-data an
"Mason Hale" <[EMAIL PROTECTED]> writes:
>> If you'd send them to me privately, I'd be interested.
> I will send these to you right away.
Okay, the 00058 file looks pretty sane, except for what we already knew
about the first page being overwritten with a much later shutdown
checkpoint. All the
On Dec 31, 2007 12:51 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Mason Hale" <[EMAIL PROTECTED]> writes:
> > If it is some mysterious hardware or kernel error -- any suggestions for
> how
> > I should go about narrowing that down?
>
> The first thing to ask is whether you're running an up-to-date
"Mason Hale" <[EMAIL PROTECTED]> writes:
> If it is some mysterious hardware or kernel error -- any suggestions for how
> I should go about narrowing that down?
The first thing to ask is whether you're running an up-to-date kernel
(and whose is it).
> Finally, if it would help to see the full wal
>
> Something else interesting about that: the apparent interloper page
> contains just a single WAL record, which appears to be a shutdown
> checkpoint bearing the timestamp "Thu Dec 27 2007, 16:55:01 EST".
> Not sure if Mason can correlate that with any recent activity...
>
Nothing jumps to mind
On Mon, 2007-12-31 at 13:14 -0500, Tom Lane wrote:
> "Mason Hale" <[EMAIL PROTECTED]> writes:
> > [EMAIL PROTECTED] wal_archive]$ od -x 000104220058 | head -n15
> > 000 d05e 0002 0001 0423 c100
> > 020 f7df 472e e701 4728 0100 2000
> > 040 a1db 81e6
"Mason Hale" <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wal_archive]$ od -x 000104220058 | head -n15
> 000 d05e 0002 0001 0423 c100
> 020 f7df 472e e701 4728 0100 2000
> 040 a1db 81e6 0423 0068 c000
> 060 0048 002c 0
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Mon, 2007-12-31 at 12:33 -0500, Tom Lane wrote:
>> Actually, the other problem with that theory is that the slave swallowed
>> the file without complaint.
> No, it barfed. Mason showed us a recovery script, so it came from the
> slave.
No, it barfed
On Mon, 2007-12-31 at 12:33 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Mon, 2007-12-31 at 11:53 -0500, Tom Lane wrote:
> >> The state of the ...0058 file might be explained by the theory that
> >> you'd archived it a bit too late (after the first page had been
> >> over
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Mon, 2007-12-31 at 11:53 -0500, Tom Lane wrote:
>> The state of the ...0058 file might be explained by the theory that
>> you'd archived it a bit too late (after the first page had been
>> overwritten with newer WAL data),
> The interlock with .ready a
"Mason Hale" <[EMAIL PROTECTED]> writes:
> Tom, I'll send these to you privately.
Thanks. I don't see anything particularly surprising there though.
What I was wondering about was whether your application was in the
habit of doing repeated no-op updates on the same "entry" row.
The pg_filedump o
On Mon, 2007-12-31 at 11:53 -0500, Tom Lane wrote:
> It might be worth trawling through both files to check the page headers
> (every 8K) and see which ones agree with expectation and which don't.
> The state of the ...0058 file might be explained by the theory that
> you'd archived it a bit too l
"Mason Hale" <[EMAIL PROTECTED]> writes:
> On Dec 31, 2007 9:48 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Do you by any chance still have 000104220058 and
>> 000104220059 archived? If so it would be useful to
>> look at the first dozen lines of "od -x" dump of each of them
Tom, I'll send these to you privately.
Mason
On Dec 31, 2007 10:22 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Mason Hale" <[EMAIL PROTECTED]> writes:
> >> Can you show us all the triggers on this table?
>
> > Here they are:
>
> > Triggers:
> > entry_correct_published_at_trigger BEFORE INSERT
"Mason Hale" <[EMAIL PROTECTED]> writes:
>> Can you show us all the triggers on this table?
> Here they are:
> Triggers:
> entry_correct_published_at_trigger BEFORE INSERT OR UPDATE ON entry FOR
> EACH ROW EXECUTE PROCEDURE correct_published_at()
> entry_feed_page_trigger BEFORE INSERT OR
On Dec 31, 2007 9:48 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Mason Hale" <[EMAIL PROTECTED]> writes:
> >> I think you misread Mason's post of 20:23 GMT-6 where he says the
> >> created_at values are the *same*, not different. Mason's previous bug
> >> report 3724 also had duplicate rows with ma
"Mason Hale" <[EMAIL PROTECTED]> writes:
>> I think you misread Mason's post of 20:23 GMT-6 where he says the
>> created_at values are the *same*, not different. Mason's previous bug
>> report 3724 also had duplicate rows with matching created_at values.
> Yes, to confirm, the created_at values ar
>
>
> I think you misread Mason's post of 20:23 GMT-6 where he says the
> created_at values are the *same*, not different. Mason's previous bug
> report 3724 also had duplicate rows with matching created_at values.
>
Yes, to confirm, the created_at values are the same. The *only* values that
are d
On Mon, 2007-12-31 at 01:27 -0500, Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > "Tom Lane" <[EMAIL PROTECTED]> writes:
> >> I wonder whether it's just a coincidence that these have the same offset
> >> number...
>
> > I can't imagine any Postgres bug which would depend on the of
>
>
> Can you show us all the triggers on this table?
Here they are:
Triggers:
entry_correct_published_at_trigger BEFORE INSERT OR UPDATE ON entry FOR
EACH ROW EXECUTE PROCEDURE correct_published_at()
entry_feed_page_trigger BEFORE INSERT OR UPDATE ON entry FOR EACH ROW
EXECUTE PROCEDURE
Trolling through my server log I found this error:
2007-12-30 20:02:08 CST (10.11.199.136) PANIC: right sibling's left-link
doesn't match
2007-12-30 20:02:08 CST (10.11.199.136) STATEMENT: update bdu.entry set
title=$1, author=$2, description_type=$3, description_length=$4,
description=$5, publis
On Dec 30, 2007 12:09 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Mason Hale" <[EMAIL PROTECTED]> writes:
> > Given my experience, the reliability of unique indexes is becoming
> somewhat
> > suspect. Please help. ;-)
>
> Well, as in the previous report, there is not enough information here to
> of
25 matches
Mail list logo
