On Wed, 2006-10-18 at 15:56 +0100, Simon Riggs wrote:
On Tue, 2006-10-17 at 22:29 -0400, Tom Lane wrote:
The answer that ultimately emerged was that they'd been running a
nightly maintenance script that did REINDEX SYSTEM (among other things
I suppose). The PITR base backup included
Simon Riggs wrote:
RelationCacheInitFileInvalidate() is also called on each
FinishPreparedTransaction().
It's only called if the prepared transaction invalidated the init file.
If that is called 100% of the time, then we
can skip writing an additional record for prepared transactions by
On Tue, 2006-10-17 at 22:29 -0400, Tom Lane wrote:
Dirk Lutzebaeck and I just spent a tense couple of hours trying to
figure out why a large database Down Under wasn't coming up after being
reloaded from a base backup plus PITR recovery. The symptoms were that
the recovery went fine, but
On Wed, 2006-10-18 at 12:49 +1000, Gavin Sherry wrote:
We don't actually need to *update* the file, per se, we only need to
remove it if no longer valid --- the next incoming backend will rebuild
it. I could see fixing this by making WAL recovery run around and zap
all the .init files
Simon Riggs [EMAIL PROTECTED] writes:
RelationCacheInitFileInvalidate() is also called on each
FinishPreparedTransaction().
Surely not...
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
On Wed, 2006-10-18 at 13:24 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
RelationCacheInitFileInvalidate() is also called on each
FinishPreparedTransaction().
Surely not...
I take that to mean there's nothing special about prepared transactions
and invalidating the rel
Dirk Lutzebaeck and I just spent a tense couple of hours trying to
figure out why a large database Down Under wasn't coming up after being
reloaded from a base backup plus PITR recovery. The symptoms were that
the recovery went fine, but backend processes would fail at startup or
soon after with
On Tue, 17 Oct 2006, Tom Lane wrote:
Dirk Lutzebaeck and I just spent a tense couple of hours trying to
figure out why a large database Down Under wasn't coming up after being
reloaded from a base backup plus PITR recovery. The symptoms were that
the recovery went fine, but backend processes
