Re: [HACKERS] bitfield and gcc
On Mon, Feb 13, 2012 at 5:38 AM, Marti Raudsepp wrote: > On Sat, Feb 11, 2012 at 01:54, Gaetano Mendola wrote: >> I wonder if somewhere in Postgres source "we" are relying on the GCC >> "correct behaviour" regarding the read-modify-write of bitfield in >> structures. > > Probably not. I'm pretty sure that we don't have any bitfields, since > not all compilers are happy with them. And it looks like this behavior > doesn't affect other kinds of struct fields. We do, actually: see spgist_private.h, itemid.h, regis.h, spell.h, and ts_type.h. And maybe some others. I'm not aware, however, of any cases where we put a lock in the same structure as a bitfield, so I think we might be OK in that regard. But the bit about <64-bit spinlocks next to other stuff is a bit alarming. I continue to be astonished at the degree to which the gcc developers seem not to care about the POLA. Padding out all of our spinlocks to 64 bits would not be free: it would cost us significantly in memory usage, if nothing else. I understand that it's not possible to modify individual bits in a bitfield atomically, but generating a 64-bit-wide read-modify-write when the underlying base type is 4 bytes or less is almost pure evil, IMHO. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] bitfield and gcc
On Sat, Feb 11, 2012 at 01:54, Gaetano Mendola wrote: > I wonder if somewhere in Postgres source "we" are relying on the GCC > "correct behaviour" regarding the read-modify-write of bitfield in > structures. Probably not. I'm pretty sure that we don't have any bitfields, since not all compilers are happy with them. And it looks like this behavior doesn't affect other kinds of struct fields. It sounds like the GCC guys are saying that it's theoretically possible that the compiler will generate 64-bit read-modify-writes regardless of the struct member types. In this light, PostgreSQL code is not "correct" -- our slock_t uses a char type on i386/AMD64/SPARC and 32-bit int on IA-64/PPC64. There are plenty of places where it's adjacent to other small fields. However, I don't think the latter is a problem with any compilers in practice, as that would break a lot more code than just btrfs and Postgres. Regards, Marti -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] bitfield and gcc
I wonder if somewhere in Postgres source "we" are relying on the GCC "correct behaviour" regarding the read-modify-write of bitfield in structures. Take a read at this https://lwn.net/Articles/478657/ sorry if this was already mentioned. Regards Gaetano Mendola -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers