From: | Zeugswetter Andreas SEV <ZeugswetterA(at)wien(dot)spardat(dot)at> |
---|---|
To: | "'Vadim Mikheev'" <vadim(at)krs(dot)ru> |
Cc: | "'PostgreSQL Developers List'" <hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions |
Date: | 1999-12-01 10:20:39 |
Message-ID: | 219F68D65015D011A8E000006F8590C603FDC19B@sdexcsrv1.f000.d0188.sd.spardat.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Yes, that is true. As long as the storage manager relies on
> the filesystem for
> table names, this will be a problem, unless filesystem
> deletions are delayed
> until COMMIT, and filesystem creates are undone at a ROLLBACK.
I like Bruce's idea of altering the filename from tablename_segnr
to tablename_OID_segnr.
Then a leftover new or old file will not be a problem, since it has a
guaranteed different name.
The cleanup of leftover old (or rolled back new files) could then be
a job that vacuum does.
Vadim needs _oid_ in the filenames for WAL anyway.
This solves create and drop table.
The alter table should imho keep an exclusive lock on the
pg_class row for that table + exclusive on the usertable
until transaction commit.
(Thus fails if table access is not exclusive)
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Vadim Mikheev | 1999-12-01 10:28:36 | Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions |
Previous Message | Hiroshi Inoue | 1999-12-01 10:11:25 | Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions |