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
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
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 da
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
Heikki Linnakangas 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 crash partway through
Andres Freund wrote:
>On 2013-07-24 15:45:52 +0300, Heikki Linnakangas wrote:
>> Andres Freund wrote:
>> >On 2013-07-24 12:59:43 +0200, Andres Freund wrote:
>> >> >
>> >> What we imo could do would be to drop the tablespaces in a
>*separate*
>> >> transaction *after* the transaction that removed
On 2013-07-24 15:45:52 +0300, Heikki Linnakangas wrote:
> Andres Freund wrote:
> >On 2013-07-24 12:59:43 +0200, Andres Freund wrote:
> >> >
> >> What we imo could do would be to drop the tablespaces in a *separate*
> >> transaction *after* the transaction that removed the pg_tablespace
> >> entry
Andres Freund wrote:
>On 2013-07-24 12:59:43 +0200, Andres Freund wrote:
>> >
>> > 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 re
On 2013-07-24 12:59:43 +0200, Andres Freund wrote:
> >
> > 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. It
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 performin
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 m
11 matches
Mail list logo
