Excerpts from Florian Pflug's message of sáb nov 27 01:29:39 -0300 2010: > On Nov26, 2010, at 21:06 , Alvaro Herrera wrote:
> > The problem with this idea is that it's not possible to implement it. > > How so? The implementation you proposed in your blog should work fine for > this. XMAX_KEY_LOCK would signal that only fields from set (B) are locked, > while XMAX_SHARE_LOCK (or however thats called, didn't check the code) would > signal that all fields are locked. These are the only two field sets that > we'd support, and for any set of columns the user specified we'd pick the > smallest superset of the set we *do* support and use that (Thus, we obtain a > key lock if only fields from a unique index where specified, and a share lock > otherwise). > > The only difference is that instead of presenting this to the user as an > entirely new lock type, we instead present it as a generalization of SHARE > locks. The advantage being that *if* we ever figure out a way to support more > fine-grained locking of fields, (say, locking only the fields contain in some > *specific* index, maybe by storing locking the index tuple), we can do so > completely transparent to the user. Oh, I see. Yeah, perhaps this could work. I'll have a look at both ends. -- Álvaro Herrera <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
