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]