On 3/31/06, Qingqing Zhou <[EMAIL PROTECTED]> wrote:
>
> ""Alex bahdushka"" <[EMAIL PROTECTED]> wrote
> >
> > (@)<2006-03-18 23:30:33.035 MST>[3791]PANIC: heap_update_redo: no block
> >
>
> According to the discussion in pgsql-hackers, to finish this case, did you
> turn off the full_page_writes p
""Alex bahdushka"" <[EMAIL PROTECTED]> wrote
>
> (@)<2006-03-18 23:30:33.035 MST>[3791]PANIC: heap_update_redo: no block
>
According to the discussion in pgsql-hackers, to finish this case, did you
turn off the full_page_writes parameter? I hope the answer is "yes" ...
Regards,
Qingqing
---
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> Actually I tried to simulate your situation, but everytime I got a neat
> recovery --
You probably filled the test table and then vacuumed within a single
checkpoint cycle, so that the replay sequence included loading data into
page 1 in the first plac
""Alex bahdushka"" <[EMAIL PROTECTED]> wrote
>
> LOG: REDO @ D/19176610; LSN D/19176644: prev D/191765E8; xid 81148979:
> Heap - clean: rel 1663/16386/16559898; blk 0
> LOG: REDO @ D/19176644; LSN D/191766A4: prev D/19176610; xid 81148979:
> Heap - move: rel 1663/16386/16559898; tid 1/1; new 0/1
> It is like the problem due to the confliction of vacuum & update. The update
> is on the page that vacuum was just removed.
>
> Before we try to understand/attack the bug exactly, first I'd like to see
> the complete xlog output. Your xlog output is imcomplete -- for example, the
> first line aft
""Alex bahdushka"" <[EMAIL PROTECTED]> wrote
>
> (@)<2006-03-25 20:54:17.528 MST>[26571]LOG: REDO @ D/19176610; LSN
> D/19176644: prev D/191765E8; xid 81148979: Heap - clean: rel
> 1663/16386/16559898; b
> (@)<2006-03-25 20:54:17.528 MST>[26571]LOG: REDO @ D/19176644; LSN
> D/191766A4: prev D/19
> Hrm ok ill see about doing either the patch or setting wal_debug to
> true (or both). However im currently on vacation till Saturday so ill
> do this first thing then and report the results back. Thank you very
> much!
Ok here is the output with wal_debug set to 1 in the config and the
final
On 3/21/06, Qingqing Zhou <[EMAIL PROTECTED]> wrote:
>
> "Tom Lane" <[EMAIL PROTECTED]> wrote
> >
> > While at it, you should extend the error message to include the relation
> > ID, so you have some idea which table is affected ... this is certainly
> > not a very informative message ...
> >
>
> E
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> (2) print verbose information after errror
If you want to do it that way, the correct thing is for the WAL replay
logic to add an error context hook to print the current WAL record,
not invent weird hacks in the error processing logic.
Compare the way
"Tom Lane" <[EMAIL PROTECTED]> wrote
> "Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> > BTW: I just realized that there is another (better) way to do so is to
> > enable WAL_DEBUG in xlog.h and SET XLOG_DEBUG=true. And that's why we
don't
> > have much error message in xlog redo.
>
> That was proba
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> BTW: I just realized that there is another (better) way to do so is to
> enable WAL_DEBUG in xlog.h and SET XLOG_DEBUG=true. And that's why we don't
> have much error message in xlog redo.
That was probably Vadim's original reasoning for not being very
"Tom Lane" <[EMAIL PROTECTED]> wrote
>
> While at it, you should extend the error message to include the relation
> ID, so you have some idea which table is affected ... this is certainly
> not a very informative message ...
>
Exactly. Please use the following version:
- elog(PANIC, "heap_update
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> Can you patch the heap/heapam.c/heap_xlog_update() like this:
> - elog(PANIC, "heap_update_redo: no block");
> + elog(PANIC, "heap_update_redo: no block: target block: %u, relation
> length: %u",
> +ItemPointerGetBlockNumber(&(xlrec->target.tid)),
""Alex bahdushka"" <[EMAIL PROTECTED]> wrote
>
> Hrm... well i obviously have restored the database by now (using
> pg_resetxlog; pg_dump; initdb; pg_restore). However i did make a
> backup of the broken directory before I created the new database. If
> anyone has any thing they would like me to
On 3/20/06, Qingqing Zhou <[EMAIL PROTECTED]> wrote:
>
> ""Alex bahdushka"" <[EMAIL PROTECTED]> wrote
> >
> > After doing some more digging, it looks like that server was missing
> > the appropriate Kpostgresql symlink in /etc/rc0.d/. So upon shutdown
> > (shutdown -h now)... my guess is it got a
""Alex bahdushka"" <[EMAIL PROTECTED]> wrote
>
> After doing some more digging, it looks like that server was missing
> the appropriate Kpostgresql symlink in /etc/rc0.d/. So upon shutdown
> (shutdown -h now)... my guess is it got a sigterm (you know where it
> says Sending all processes a TERM
On 3/19/06, Alex bahdushka <[EMAIL PROTECTED]> wrote:
> On 3/19/06, Martijn van Oosterhout wrote:
> > On Sat, Mar 18, 2006 at 11:55:35PM -0700, Alex bahdushka wrote:
> > > Hi.
> > >
> > > Upon rebooting one of our main production database servers, we were
> > > greeted with this:
> >
> > To help y
On 3/19/06, Martijn van Oosterhout wrote:
> On Sat, Mar 18, 2006 at 11:55:35PM -0700, Alex bahdushka wrote:
> > Hi.
> >
> > Upon rebooting one of our main production database servers, we were
> > greeted with this:
>
> To help you at all, we *really* need to know what version and platform
> you're
On Sat, Mar 18, 2006 at 11:55:35PM -0700, Alex bahdushka wrote:
> Hi.
>
> Upon rebooting one of our main production database servers, we were
> greeted with this:
To help you at all, we *really* need to know what version and platform
you're running. In particular, are you running the most recent
19 matches
Mail list logo
