Using a VIEW as a temporary mechanism for renaming a table

From: Ben Buckman <ben(at)shyp(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Using a VIEW as a temporary mechanism for renaming a table
Date: 2016-06-08 17:57:11
Message-ID: CAFCabS6RaAmNsV+1TuvHPk3Hcatrs_QJXZYk0EqU54xtd-v9xA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hello,
I would like to rename a table with ~35k rows (on pgsql 9.4), let's say
from `oldthings` to `newthings`.
Our application is actively reading from and writing to this table, and the
code will break if the table name suddenly changes at runtime. So I can't
simply run an `ALTER TABLE oldthings RENAME TO newthings`, unless we take
downtime, which we'd prefer not to do. (I'd also prefer to avoid a data
migration from one table to another, which would require dual-writes or
some other way to handle data written during the transition.)

It seems that a reasonable approach to do this without downtime, would be
to use a temporary VIEW. We can `CREATE VIEW newthings AS SELECT * FROM
oldthings;`. Views in pg9.4 that are backed by a single table support
writes. So my plan is like this:

1. Create the view, essentially as an alias to the table.
2. In the code, change all references from the old name to the new name.
The code would "think" it's using a renamed table, but would really be
using a view.
(At this point, I expect that all basic CRUD operations on the view
should behave as if they were on the table, and that the added performance
impact would be negligible.)
3. In a transaction, drop the view and rename the table, so `newthings` is
now the original table and `oldthings` no longer exists. (In my testing,
this operation took <10ms.)
(When this is done, the view will have only existed and been used by the
application for a few minutes.)

What are people's thoughts on this approach? Is there a flaw or potential
danger that I should be aware of? Is there a simpler approach I should
consider instead?

Thank you

--

[image: Shyp]
*Ben Buckman / Platform Engineering*
www.shyp.com
Shipping made easy <https://www.shyp.com/>

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Matthew Kelly 2016-06-08 18:05:36 Re: Monitoring and insight into NOTIFY queue
Previous Message Sameer Kumar 2016-06-08 17:12:54 Re: connection pooling, many users, many datasources