On Thu, Aug 12, 2010 at 6:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Thu, Aug 12, 2010 at 5:29 PM, Alvaro Herrera
>> <alvherre@commandprompt.com> wrote:
>>> What about having autovacuum silenty drop the catalog entry if it's a
>>> temp entry for which the underlying file does not exist?
>
>> I think that would be subject to race conditions.
>
> Well, autovacuum's willingness to drop sufficiently old temp tables
> would already risk any such race conditions. However ...
I don't think we do. It only drops them if the backend isn't running.And even if the backend starts running after we
checkand before we
drop it, that's OK. We're only dropping the OLD table, which by
definition isn't relevant to the new session. Perhaps we should be
taking a lock on the relation first, but I think that can only really
bite us if the relation were dropped and a new relation were created
with the same OID - in that case, we might drop an unrelated table,
though it's vanishingly unlikely in practice.
>> The current
>> mechanism is actually pretty good, and I think we can build on it if
>> we want to do more, rather than inventing something new. We just need
>> to be specific about what problem we're trying to solve.
>
> ... I agree with this point. This idea wouldn't fix the concern I had
> about the existence of pg_class entries with no underlying file: if that
> causes any issues we'd have to fix them anyway. So I'm not sure what
> the gain is.
Right.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company