Re: [HACKERS] A 2 phase commit weirdness
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 ... Unrelated question: is it intended that the prepared transactions are visible cross-database through pg_prepared_xacts? That is a good question. Can a backend running in a different database execute the COMMIT (or ROLLBACK)? Offhand I'd bet that will not work, which suggests we'd better make the view per-database. [ thinks a bit more... ] We might be able to make it work, but there seems like a lot of potential for bugs/fragility there. Might be best to take the narrow definition to start with. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] A 2 phase commit weirdness
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 (I suppose) the ERROR is preventing the commit from succeeding ... 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 COMMIT TRANSACTION 'foo'; ERROR, relation deleted while still in use So it's a rather contorted situation to begin with. Unrelated question: is it intended that the prepared transactions are visible cross-database through pg_prepared_xacts? That is a good question. Can a backend running in a different database execute the COMMIT (or ROLLBACK)? Offhand I'd bet that will not work, which suggests we'd better make the view per-database. [ thinks a bit more... ] We might be able to make it work, but there seems like a lot of potential for bugs/fragility there. Might be best to take the narrow definition to start with. Ok. -- Alvaro Herrera (alvherre[a]surnet.cl) El sentido de las cosas no viene de las cosas, sino de las inteligencias que las aplican a sus problemas diarios en busca del progreso. (Ernesto Hernández-Novich) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] A 2 phase commit weirdness
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 COMMIT TRANSACTION 'foo'; ERROR, relation deleted while still in use Oh. Well, you get that now without any use of PREPARE; it's not clear what else we could do, except possibly make the message a bit more user-friendly. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] A 2 phase commit weirdness
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'; SELECT * FROM foo; -- hangs COMMIT TRANSACTION 'foo'; ERROR, relation deleted while still in use Oh. Well, you get that now without any use of PREPARE; it's not clear what else we could do, except possibly make the message a bit more user-friendly. Ah, you are right, sorry :-) I was imagining I had to cope with that but evidently not. -- Alvaro Herrera (alvherre[a]surnet.cl) Granting software the freedom to evolve guarantees only different results, not better ones. (Zygo Blaxell) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] A 2 phase commit weirdness
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 for the relcache init file actions would make it much better. Hum, do you mean separate for 2PC only, or make'em completely separate invalidation messages? I fixed the problem I had -- it was very easy to make the messages get processed locally. However strangeness can still happen. Consider: create table foo (); begin; drop table foo; prepare transaction 'foo'; Now any backend that tries to access table foo will block, because the 'foo' prepared transaction has acquired a lock on it. However the table is still visible in the catalogs, as it should be. It can easily be awakened by other backend doing commit transaction 'foo'; 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. Unrelated question: is it intended that the prepared transactions are visible cross-database through pg_prepared_xacts? -- Alvaro Herrera (alvherre[a]surnet.cl) No single strategy is always right (Unless the boss says so) (Larry Wall) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] A 2 phase commit weirdness
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. Now consider this scenario: backend A: Do updates that cause an init file invalidation backend A: Commit begins backend A: unlink init file backend B starts and recreates init file backend A: send inval message backend C starts and reads the now stale init file No problem, because C will receive A's inval messages after that. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] A 2 phase commit weirdness
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 the right inval messages when the prepared transaction ultimately commits ... but we'll have to check that that sequence does the right things ... Do I need to send the inval messages to me? Is this even possible? inval.c is less than readable, isn't it :-( But yes, and yes. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
