Re: Replacing a table

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Francisco Reyes <lists(at)natserv(dot)com>
Cc: pgsql General List <pgsql-general(at)postgresql(dot)org>
Subject: Re: Replacing a table
Date: 2002-10-30 19:03:04
Message-ID: 584.1036004584@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Francisco Reyes <lists(at)natserv(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2002-10-30 19:06:11 Re: permission prob: granted, but still denied
Previous Message Richard Huxton 2002-10-30 19:02:42 Re: backing up corrupt database