On 12/18/2013 01:50 PM, Andres Freund wrote:
On 2013-12-18 13:46:59 +0200, Heikki Linnakangas wrote:
On 12/18/2013 01:39 PM, Andres Freund wrote:
On 2013-12-18 13:07:51 +0200, Heikki Linnakangas wrote:
Here's another idea that doesn't involve SSI:
At COMMIT, take a new snapshot and check that the assertion still passes
with that snapshot.
I think that would work, and would be simple, although it wouldn't scale too
well.
It probably would also be very prone to deadlocks.
Hmm, since this would happen at commit, you would know all the assertions
that need to be checked at that point. You could check them e.g in Oid order
to avoid deadlocks.
I think real problem are the lock upgrades, because eventual DML will
have acquired less heavy locks.
Ah, I see. You don't need to block anyone else from modifying the table,
you just need to block anyone else from committing a transaction that
had modified the table. So the locks shouldn't interfere with regular
table locks. A ShareUpdateExclusiveLock on the assertion should do it.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
