Joe Maldonado and I have a vexing problem with PostgreSQL 7.4.5 (we are
using the PGDG RPMs on a RedHat 9 system). He posted about this briefly
with the subject "info on strange error messages on postgresql" on this
list, but I'll start from the beginning. About once per week the
database ent
Tom Lane wrote:
I can absolutely, positively say that that dump is not from the parent
postmaster. It's a backend.
That makes sense. I'm still a bit puzzled about why new clients can't
connect when the problem happens, though. Does the parent postmaster
need some resource from one of the b
Tom Lane wrote:
I was sort of expecting you to come back and say that you
thought the process might have done 640K TRUNCATEs over its lifespan,
but I guess not?
That's possible. The process does twelve TRUNCATEs every minute. The
problem we're talking about seems to occur only when the syste
Tom Lane wrote:
I suppose what we are looking at here is some operation that is
invalidating a relcache entry but failing to clear it.
Hm. After discussing this with people here we have a hypothesis. The
process that issues the TRUNCATE command does something a little
peculiar: every minute
Tom Lane wrote:
Found it --- the actual leak is in index_create, not in TRUNCATE or
CLUSTER at all; and it's been there a really long time.
Patch for 7.4 branch attached.
Excellent! Does index_create refer to something that is invoked as a
consequence of CREATE INDEX? I'm looking through the
Tom Lane wrote:
TRUNCATE and CLUSTER both rebuild indexes, so they'd also trigger the
leak.
Sorry to bug you again, but I have two quick followup questions: (1) is
the leak you discovered fixed on the 8.0 branch? and (2) would closing
the database connection once per day be a reasonable way t
