Re: clog_redo causing very long recovery time - Mailing list pgsql-hackers

From Tom Lane
Subject Re: clog_redo causing very long recovery time
Date
Msg-id 2373.1304654453@sss.pgh.pa.us
Whole thread Raw
In response to Re: clog_redo causing very long recovery time  (Joe Conway <mail@joeconway.com>)
Responses Re: clog_redo causing very long recovery time  (Joe Conway <joe.conway@credativ.com>)
List pgsql-hackers
Joe Conway <mail@joeconway.com> writes:
> Right -- I think another similar problem exists in GetNewMultiXactId
> where ExtendMultiXactOffset could succeed and write an XLOG entry and
> then  ExtendMultiXactMember could fail before advancing nextMXact. The
> problem in this case is that they both write XLOG entries, so a simple
> reversal doesn't help.

Hmm.  Maybe we need a real fix then.  I was just sitting here
speculating about whether we'd ever decide we need to WAL-log
pg_subtrans --- because if we did, my solution would fail.

I still think that the right fix is to avoid emitting redundant
XLOG records in the first place, rather than hacking recovery
to not process them.  Possibly we could modify slru.c so that
it could be determined whether zeroing of the current page had
already happened.  In a quick look, it looks like noting whether
latest_page_number had already been advanced to that page might
do the trick.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: clog_redo causing very long recovery time
Next
From: Dan Ports
Date:
Subject: Re: Why is RegisterPredicateLockingXid called while holding XidGenLock?