On Wed, Nov 26, 2014 at 12:35:27PM +0100, Christoph Berg wrote:
> Re: Heikki Linnakangas 2014-11-26 <54759BC0.4070505@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 a completely
> > different codepath and could be fixed independently of DROP DATABASE.
>
> Err right. Too early in the morning...
>
> > >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
> > >recovery_target_time to run into. (We could still fix this properly
> > >later, but this idea seems like a good fix for a practical problem
> > >that doesn't break anything else.)
> >
> > Yeah, seems reasonable.
>
> Here's a first shot at a patch. It's not working yet because I think
> the commit isn't doing anything because no work was done in the
> transaction yet.
Where are we on this?
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +