Added to TODO:

* Improve failure message when DROP DATABASE is used on a database that
  has prepared transactions


Heikki Linnakangas wrote:
> Alvaro Herrera wrote:
> > I think we should set things up so that prepared transactions are
> > dropped when they concern a database being dropped.  Opinions?
> Agreed, if you want to drop the database, you don't care about the 
> transactions in it anymore.
> It seems straightforward to implement. We'll need a version of
> FinishPreparedTransaction that takes an xid instead of a global
> transaction id. Then that needs to be called at roughly the same time as
> DatabaseCancelAutovacuumActivity. Preferably there isn't a wide window 
> between rolling back the prepared transactions and committing to 
> dropping the database...
> I just realized that you can prepare a transaction in one database, 
> connect to another database in the same cluster, and issue a "COMMIT 
> PREPARED" there. At least NOTIFY/LISTEN gets confused when you do that, 
> and sends the notification to the another database, not the one where 
> the original transaction was running :(.
> Do we consider committing a transaction from another database a feature, 
> and fix NOTIFY/LISTEN, or should COMMIT PREPARED throw an error if 
> you're not connected to the same database?
> Actually, I think we should completely separate the namespaces of the 
> global transaction identifiers, so that you could use the same gid in 
> two different databases without a conflict.
> -- 
>    Heikki Linnakangas
>    EnterpriseDB
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?

  Bruce Momjian  <[EMAIL PROTECTED]>

  + If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at


Reply via email to