Basically I want to do this:
begin;
lock table a;
alter table a rename to b;
alter table a1 rename to a;
drop table b;
commit;
i.e. gain control and replace my old table while no one has access to it.
Basically I want to do this:
begin;
lock table a;
alter table a rename to b;
alter table a1 rename to a;
drop table b;
commit;
i.e. gain control and replace my old table while no one has access to it.
Simpler:
BEGIN;
DROP TABLE a;
ALTER TABLE a1 RENAME TO a;
COMMIT;
DROP TABLE
acquires an ACCESS EXCLUSIVE
lock on the table anyway. An explicit LOCK
command is no better. And renaming a dead guy is just a waste of time.
You may want to write-lock the old table while preparing the new, to prevent writes in between. Then you'd issue a lock like this earlier in the process:
LOCK TABLE a IN SHARE MODE;
What happens to concurrent transactions trying to access the table? It's not that simple, read this:
Explains why you may have seen error messages like this:
ERROR: could not open relation with OID 123456
FOREIGN KEY
constraints referencing the table, views referencing the table, etc. The DROP
will fail. If you DROP ... CASCADE
then the referencing views, constraints, etc are dropped, and will not be recreated when you create / rename the replacement table into place. There is not currently a convenient way to "swap" two tables and keep FK constraints etc. –
Plantar Create SQL-backup, make changes you need directly at the backup.sql file and restore database. I used this trick when have added INHERIT for group of tables (Postgres dbms) to remove inherited fields from subtable.
I would use answer#13, but I agree, it will not inherit the constraints, and drop table might fail
© 2022 - 2024 — McMap. All rights reserved.