Daniel Farina <daniel@heroku.com> writes:
> but just today we promoted another system via streaming replication to
> pick up the planner fix in 9.1.5 (did you know: that planner bug seems
> to make GIN FTS indexes un-used in non-exotic cases, and one goes to
> seqscan?), and then a 40MB GIN index bloated to two gigs on a 1.5GB
> table over the course of maybe six hours.
I think this is probably unrelated to what Josh was griping about:
even granting that the system forgot any free space that had been
available within the original 40MB, that couldn't in itself lead
to eating more than another 40MB, no? My guess is something is
broken about the oldest-xmin-horizon mechanism, such that VACUUM
is failing to recover space. Can you put together a self-contained
test case that exhibits similar growth?
regards, tom lane
