Surely such a use case could, and more to the point *should* be met using PITR?
Regards,
- Naz.
Alvaro Herrera wrote:
A.M. wrote:
On May 24, 2007, at 14:29 , Wiebe Cazemier wrote:
On Thursday 24 May 2007 17:30, Alexander Staubo wrote:
[2] Nobody else has this, I believe, except possibly Ingres and
NonStop SQL. This means you can do a "begin transaction", then issue
"create table", "alter table", etc. ad nauseum, and in the mean time
concurrent transactions will just work. Beautiful for atomically
upgrading a production server. Oracle, of course, commits after each
DDL statements.
If this is such a rare feature, I'm very glad we chose postgresql.
I use it all
the time, and wouldn't know what to do without it. We circumvented
Ruby on
Rails' migrations, and just implemented them in SQL. Writing
migrations is a
breeze this way, and you don't have to hassle with atomicity, or
the pain when
you discover the migration doesn't work on the production server.
Indeed. Wouldn't it be a cool feature to persists transaction states
across connections so that a new connection could get access to a sub-
transaction state? That way, you could make your schema changes and
test them with any number of test clients (which designate the state
to connect with) and then you would commit when everything works.
Unfortunately, the postgresql architecture wouldn't lend itself well
to this. Still, it seems like a basic extension of the notion of sub-
transactions.
Hmm, doesn't this Just Work with two-phase commit?