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-h
> 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
> 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
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 up
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 wer
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
Hi.
Upon rebooting one of our main production database servers, we were
greeted with this:
(@)<2006-03-18 23:30:32.687 MST>[3791]LOG: database system was
interrupted while in recovery at 2006-03-18 23:30:26 MST
(@)<2006-03-18 23:30:32.687 MST>[3791]HINT: This probably means that
some data is co
