Обсуждение: Making temp tables' toast tables be temp
Currently, a toast table attached to a temporary table is treated much as though it were a regular permanent table: accesses to it go through shared buffers and are WAL-logged. Aside from the obvious performance penalties, this means that backends may sometimes acquire open file pointers for temporary toast tables of other backends, which can have unpleasant consequences. Yesterday someone reported running out of disk space because of dangling references to nominally-dropped temp tables: http://archives.postgresql.org/pgsql-bugs/2007-07/msg00122.php So I'm thinking it might be time to fix this. After checking the code, it seems like it'd be a reasonably small patch if we establish a convention that toast tables for a temp schema pg_temp_nnn are kept in an associated dedicated schema, named something like pg_temp_nnn_toast or pg_toast_temp_nnn. Then functions like isOtherTempNamespace() could still recognize these tables as temp. It'd mean a bit more clutter in pg_namespace though. Comments? regards, tom lane
"Tom Lane" <tgl@sss.pgh.pa.us> writes: > So I'm thinking it might be time to fix this. After checking the > code, it seems like it'd be a reasonably small patch if we establish > a convention that toast tables for a temp schema pg_temp_nnn are > kept in an associated dedicated schema, named something like > pg_temp_nnn_toast or pg_toast_temp_nnn. Then functions like > isOtherTempNamespace() could still recognize these tables as temp. > It'd mean a bit more clutter in pg_namespace though. Why not just in the same pg_temp namespace? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
Gregory Stark <stark@enterprisedb.com> writes: > "Tom Lane" <tgl@sss.pgh.pa.us> writes: >> So I'm thinking it might be time to fix this. After checking the >> code, it seems like it'd be a reasonably small patch if we establish >> a convention that toast tables for a temp schema pg_temp_nnn are >> kept in an associated dedicated schema, named something like >> pg_temp_nnn_toast or pg_toast_temp_nnn. Then functions like >> isOtherTempNamespace() could still recognize these tables as temp. >> It'd mean a bit more clutter in pg_namespace though. > Why not just in the same pg_temp namespace? Well, there's a risk of collisions with user table names; not a big risk maybe but not nil. Also, that would be in the search path, making the toast tables "visible" so that they'd be displayed by things like psql's \dt. Keeping toast tables in their own schema that's not in the path has worked well for us since 7.3, and I don't want to give it up. Any thoughts about which naming convention to use? pg_temp_nnn_toast or pg_temp_toast_nnn would emphasize the "temp-ness" while pg_toast_temp_nnn would emphasize the "toast-ness". It'd be roughly the same as far as the backend is concerned (since it mostly deals with OIDs not names anyway), and I'm not too sure whether any client-side code would care or what its preference would be. regards, tom lane