On Thu, May 3, 2012 at 5:04 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > I'm inclined to think that a saner implementation would involve > splitting the userlock lockmethod into two, one transactional and one > not.
Agreed > That gets rid of the when-to-release kluges, but instead we have > to think of a way for two different lockmethods to share the same > lock keyspace. If we don't split it then we definitely need to figure > out someplace else to keep the transactionality flag. Is that even an issue? Do we really want an overlapping lock space? AFAICS you'd either use transactional or session level, but to use both seems bizarre. And if you really did need both, you can put a wrapper around the function to check whether a session level exists before you grant the transaction level lock, or vice versa. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
