Re: Replacing a table

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Replacing a table
Дата
Msg-id 584.1036004584@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Replacing a table  (Francisco Reyes <lists@natserv.com>)
Список pgsql-general
Francisco Reyes <lists@natserv.com> writes:
> I thought that given that the queries for these report tables take 20 to
> 30 minutes I would try something like
> begin
> drop
> select ... into table
> commit

> However once I ran a test case I was unable to connect to the table.

Yeah, because the DROP will acquire exclusive lock on the table;
this approach is rollback-safe but not transaction-friendly.
Consider

begin
select into new_table
drop table
alter table new_table rename to table
commit

which does not hold the exclusive lock as long.

> What would be the way to replace tables?
> The output is fairly small so I was thinking about something like:
> Create data to cursor
> drop table
> select from cursor into table

If you don't mind copying the data then this is probably the best
bet:

begin
select ... into temp table ttable
lock table table
delete from table
insert into table select * from ttable
drop table ttable
commit

(A vacuum or truncate would be nice here to actually remove the deleted
rows, but you can't put either inside a transaction block at present.
A "vacuum table" outside the transaction block will have to do instead.)

The reason this is better is that it doesn't DROP the table, which means
you do not lose indexes, foreign keys, views, etc that reference the
table.  Also it eliminates a race condition: someone trying to access
the old table just after you drop it would get an error, even though
there is a new table of the same name by the time he gets to proceed.

            regards, tom lane

В списке pgsql-general по дате отправления:

Предыдущее
От: Richard Huxton
Дата:
Сообщение: Re: newbie question for return date
Следующее
От: Tom Lane
Дата:
Сообщение: Re: permission prob: granted, but still denied