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 http://www.enterprisedb.com
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
