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
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>>> 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.
>>
>> Really? They're supposed to
Tom Lane wrote:
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.
Really? They're supposed to be "global".
Well yeah, the TM should be assigning globally uni
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> 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?
Hmm ... if we were sure NOTIFY were the only sore spot I'd s
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 n
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I think we should set things up so that prepared transactions are
> dropped when they concern a database being dropped. Opinions?
No. A prepared transaction is one that we have guaranteed we can commit
when the 2PC manager tells us to. Reneging on th
