On March 22, 2015 12:17:57 PM GMT+01:00, Christoph Berg wrote:
>Re: Bruce Momjian 2015-03-20 <20150320223549.gz6...@momjian.us>
>> > > >So my suggestion for a simple fix would be to make DROP DATABASE
>> > > >execute a short fake transaction before it starts deleting files
>and
>> > > >then contin
Re: Bruce Momjian 2015-03-20 <20150320223549.gz6...@momjian.us>
> > > >So my suggestion for a simple fix would be to make DROP DATABASE
> > > >execute a short fake transaction before it starts deleting files and
> > > >then continue as before. This would serve as a stopping point for
> > > >recover
On Wed, Nov 26, 2014 at 12:35:27PM +0100, Christoph Berg wrote:
> Re: Heikki Linnakangas 2014-11-26 <54759bc0.4070...@vmware.com>
> > >Oh ok. So this is an artifact of the non-transactionality (is this a
> > >word?) of CREATE DATABASE.
> >
> > DROP DATABASE. CREATE DATABASE is a different story. I
Re: Heikki Linnakangas 2014-11-26 <54759bc0.4070...@vmware.com>
> >Oh ok. So this is an artifact of the non-transactionality (is this a
> >word?) of CREATE DATABASE.
>
> DROP DATABASE. CREATE DATABASE is a different story. It does similar
> non-transactional tricks and has similar issues, but it's
On 11/26/2014 11:19 AM, Christoph Berg wrote:
Re: Heikki Linnakangas 2014-11-25 <5474b848.3060...@vmware.com>
db1 is registered in pg_database, but the directory is missing on
disk.
Yeah, DROP DATABASE cheats. It deletes all the files first, and commits the
transaction only after that. There's
Re: Heikki Linnakangas 2014-11-25 <5474b848.3060...@vmware.com>
> >db1 is registered in pg_database, but the directory is missing on
> >disk.
>
> Yeah, DROP DATABASE cheats. It deletes all the files first, and commits the
> transaction only after that. There's this comment at the end of dropdb()
>
On 11/25/2014 11:01 PM, Tomas Vondra wrote:
[snip]
So you could see the same after crash recovery, but it's a lot easier to
reproduce with PITR.
So we remove the files, and if there happens to be a crash at the right
moment, it results in a database with a record in pg_database, but no
director
On 25.11.2014 18:11, Heikki Linnakangas wrote:
> On 11/25/2014 06:06 PM, Christoph Berg wrote:
>
>> db1 is registered in pg_database, but the directory is missing on
>> disk.
>
> Yeah, DROP DATABASE cheats. It deletes all the files first, and commits
> the transaction only after that. There's this
On 11/25/2014 06:06 PM, Christoph Berg wrote:
In 9.3.5, if I set up archiving, create a database, pull a base
backup, look at the clock, drop database, stop the server, rm -rf
datadir, put back the backup, edit recovery.conf:
cd /tmp; initdb foo
edit postgresql.conf with archive_mode = on, archi
In 9.3.5, if I set up archiving, create a database, pull a base
backup, look at the clock, drop database, stop the server, rm -rf
datadir, put back the backup, edit recovery.conf:
cd /tmp; initdb foo
edit postgresql.conf with archive_mode = on, archive_command,
max_wal_senders = 1, wal_level = hot
10 matches
Mail list logo
