Alvaro Herrera [EMAIL PROTECTED] writes:
But at awakening, the user will get this:
ERROR: relation 66002 deleted while still in use
This is ugly -- I don't think there is a way to get out of it.
There had better be a way, since (I suppose) the ERROR is preventing the
commit from succeeding
On Tue, May 31, 2005 at 02:09:56AM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
But at awakening, the user will get this:
ERROR: relation 66002 deleted while still in use
This is ugly -- I don't think there is a way to get out of it.
There had better be a way, since
Alvaro Herrera [EMAIL PROTECTED] writes:
No, the ERROR is in a completely unrelated transaction. The scenario
again is this:
CREATE TABLE foo ();
BEGIN;
DROP TABLE foo;
PREPARE TRANSACTION 'foo';
SELECT * FROM foo;
-- hangs
On Tue, May 31, 2005 at 10:44:58AM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
No, the ERROR is in a completely unrelated transaction. The scenario
again is this:
CREATE TABLE foo ();
BEGIN;
DROP TABLE foo;
PREPARE TRANSACTION 'foo';
On Fri, May 27, 2005 at 11:12:06AM -0400, Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Looking at the sequence, at least the relcache init file stuff looks if
not broken at least a bit heavy-handed...
I was planning to change that ;-) ... using separate 2PC action records
Heikki Linnakangas [EMAIL PROTECTED] writes:
Looking at the sequence, at least the relcache init file stuff looks if
not broken at least a bit heavy-handed...
I was planning to change that ;-) ... using separate 2PC action records
for the relcache init file actions would make it much better.
Alvaro Herrera [EMAIL PROTECTED] writes:
I'm wondering what should happen at prepare time so that my own cache
is correct.
Good point. As far as the local caches are concerned, we probably have
to make it look like the transaction rolled back. I think Heikki
already had code in there to send
