On Wed, Jul 24, 2013 at 10:57:14AM -0400, Tom Lane wrote:
I wrote:
The only thing here that really bothers me is that a crash during DROP
DATABASE/TABLESPACE could leave us with a partially populated db/ts
that's still accessible through the system catalogs. ...
I guess one thing we
Hello,
I've encountered a bug of PITR that corrupts the database. I'm willing to
submit the patch to fix it, but I'm wondering what approach is appropriate.
Could you give me your opinions?
[Problem]
I cannot connect to the database after performing the following steps:
1. CREATE DATABASE
On 2013-07-24 19:30:09 +0900, MauMau wrote:
I've encountered a bug of PITR that corrupts the database. I'm willing to
submit the patch to fix it, but I'm wondering what approach is appropriate.
Could you give me your opinions?
[Problem]
I cannot connect to the database after performing the
On 2013-07-24 12:59:43 +0200, Andres Freund wrote:
Approach 2
Like the DROP TABLE/INDEX case, piggyback the directory deletion record on
the transaction commit record, and eliminate the directory deletion record
altogether.
I don't think burdening commit records with that makes sense.
Andres Freund and...@2ndquadrant.com wrote:
On 2013-07-24 12:59:43 +0200, Andres Freund wrote:
Approach 2
Like the DROP TABLE/INDEX case, piggyback the directory deletion
record on
the transaction commit record, and eliminate the directory deletion
record
altogether.
I don't think
On 2013-07-24 15:45:52 +0300, Heikki Linnakangas wrote:
Andres Freund and...@2ndquadrant.com wrote:
On 2013-07-24 12:59:43 +0200, Andres Freund wrote:
Approach 2
What we imo could do would be to drop the tablespaces in a *separate*
transaction *after* the transaction that removed the
Andres Freund and...@2ndquadrant.com wrote:
On 2013-07-24 15:45:52 +0300, Heikki Linnakangas wrote:
Andres Freund and...@2ndquadrant.com wrote:
On 2013-07-24 12:59:43 +0200, Andres Freund wrote:
Approach 2
What we imo could do would be to drop the tablespaces in a
*separate*
transaction
Heikki Linnakangas hlinnakan...@vmware.com writes:
That's no different from CREATE TABLE / INDEX and DROP TABLE / INDEX. E.g. If
you crash after CREATE TABLE but before COMMIT, the file is leaked. But it's
just a waste of space, everything still works.
Well, it is different, because if you
On 2013-07-24 16:15:59 +0300, Heikki Linnakangas wrote:
For DROP DATABASE, without something like incomplete actions,
piggybacking on the commit record doesn't solve the issue of
CHECKPOINTS
either, because the commit record you piggybacked on could have
committed before a checkpoint, while
I wrote:
The only thing here that really bothers me is that a crash during DROP
DATABASE/TABLESPACE could leave us with a partially populated db/ts
that's still accessible through the system catalogs. ...
I guess one thing we could do is create a flag file, say
dead.dont.use, in the
On 2013-07-24 10:57:14 -0400, Tom Lane wrote:
I wrote:
The only thing here that really bothers me is that a crash during DROP
DATABASE/TABLESPACE could leave us with a partially populated db/ts
that's still accessible through the system catalogs. ...
I guess one thing we could do is
11 matches
Mail list logo
