Re: Temporary Views Cleanup Issue

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: 赵宇鹏(宇彭) <zhaoyupeng(dot)zyp(at)alibaba-inc(dot)com>
Cc: "pgsql-hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Temporary Views Cleanup Issue
Date: 2025-01-06 14:27:16
Message-ID: 1297045.1736173636@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"=?UTF-8?B?6LW15a6H6bmPKOWuh+W9rSk=?=" <zhaoyupeng(dot)zyp(at)alibaba-inc(dot)com> writes:
> I have discovered a peculiar issue: after creating a temporary view, if the
> backend process exits abnormally, the temporary view is not cleaned up. However,
> if a temporary table is created and the backend process exits abnormally, the
> temporary table is cleaned up.

I think this is intentional. A temp table may consume enough disk
space that it's worth hacking up autovacuum to remove the space.
The same cannot be said of other kinds of objects. (If we had
temp materialized views, they might be worth cleaning up ... but
we don't.) So we might as well leave the rest for the normal
RemoveTempRelations call the next time somebody uses the temp
namespace.

Also, I don't buy the argument that it's better for autovacuum to be
aggressive here. RemoveTempRelations will cope if, say, a temp view
has a dependency on another one. autovacuum might fail entirely
(blocking additional cleanup), if it happens to try to delete the
wrong one first. So we should minimize the amount of stuff we expect
autovacuum to accomplish.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2025-01-06 14:41:54 Re: initdb -c "track_commit_timestamp=on" crashes in case of debug build
Previous Message Robert Haas 2025-01-06 14:20:18 Re: Fwd: Re: A new look at old NFS readdir() problems?