Re: Vacuum Question

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ed Loehr <eloehr(at)austin(dot)rr(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Vacuum Question
Date: 2000-06-06 07:18:04
Message-ID: 22661.960275884@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Ed Loehr <eloehr(at)austin(dot)rr(dot)com> writes:
>> Then, start this one in another bash window/terminal/whatever...
>>
>> % while test 1; do echo -n "`date`: "; psql -d pdb -c "vacuum analyze;
>> select count(*) from foo;"; sleep 3; done
>>
>> This seems to consistently crash after the first vacuum with the
>> following message:

This is a known gotcha that's got nothing to do with any sort of
concurrency. You can't safely send a VACUUM followed by anything
else in a single query string. The problem is that VACUUM forces a
transaction commit, which releases all transiently allocated memory
in its backend ... including the already-parsed querytrees for the
rest of the query string. Oops. (cf. comment near line 560 in
src/backend/tcop/postgres.c)

You won't see the problem if you enter "vacuum analyze; select ..."
interactively or as a script in psql, because it chops up the
commands into separate query submittals. But apparently psql
doesn't chop up a -c string. Non-psql frontends can expose the bug
as well.

It's possible that this will get cleaned up as a byproduct of the
proposed rework of transaction-local memory contexts. But it's
not a real high-priority problem, at least not IMHO. For now,
the answer is "if it hurts, don't do it ;-)"

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Vince Vielhaber 2000-06-06 11:22:57 Re: troubles installing postgresql6.4
Previous Message Ed Loehr 2000-06-06 06:18:00 Re: Vacuum Question