-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160
Tom Lane wrote: >> Came across an odd bug while dealing with deferred foreign keys. > I'm not convinced this is a bug. Can you elaborate on this? Am I doing something wrong in my app? Someone on irc pointed out that this affects more than deferred fk, but for my purposes, here's what's happening: Table A has a primary key. Table B references that primary key. Process A periodically updates the table by doing (basically) a delete all/insert new data, inside of a transaction. Process B is adding entries to table B. If Process B happens in the "middle" of Process A, the insert to B fails as it claims that the corresponding row in table A does not exist. Short of Process A grabbing an exclusive lock on the table, I can't see a way around this. Feel free to punt this to general if this is the expected behavior. - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200710151809 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iD8DBQFHE+VUvJuQZxSWSsgRAzyGAKCveD8q0a8O2XFEkD1g5f08Z58mbgCgvHUF z4bBO7MJ0gWow1fPHJY09is= =ohAQ -----END PGP SIGNATURE----- ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster