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. 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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
