summaryrefslogtreecommitdiff
path: root/src/timezone/scheck.c
diff options
context:
space:
mode:
authorAndres Freund <andres@anarazel.de>2025-08-27 19:12:11 -0400
committerAndres Freund <andres@anarazel.de>2025-08-27 19:12:11 -0400
commit5865150b6d535ecea241e9ad3038564cb7768b9a (patch)
treeb8df0c85d14ed150e9031515e4e96f5e3500bada /src/timezone/scheck.c
parent310d04169a41c20fa2e84ba6e40cffc10b8fa065 (diff)
aio: Stop using enum bitfields due to bad code generationHEADorigin/masterorigin/HEADmaster
During an investigation into rather odd aio related errors on macos, observed by Alexander and Konstantin, we started to wonder if bitfield access is related to the error. At the moment it looks like it is related, we cannot reproduce the failures when replacing the bitfields. In addition, the problem can only be reproduced with some compiler [versions] and not everyone has been able to reproduce the issue. The observed problem is that, very rarely, PgAioHandle->{state,target} are in an inconsistent state, after having been checked to be in a valid state not long before, triggering an assertion failure. Unfortunately, this could be caused by wrong compiler code generation or somehow of missing memory barriers - we don't really know. In theory there should not be any concurrent write access to the handle in the state the bug is triggered, as the handle was idle and is just being initialized. Separately from the bug, we observed that at least gcc and clang generate rather terrible code for the bitfield access. Even if it's not clear if the observed assertion failure is actually caused by the bitfield somehow, the bad code generation alone is sufficient reason to stop using bitfields. Therefore, replace the enum bitfields with uint8s and instead cast in each switch statement. Reported-by: Alexander Lakhin <exclusion@gmail.com> Reported-by: Konstantin Knizhnik <knizhnik@garret.ru> Discussion: https://postgr.es/m/1500090.1745443021@sss.pgh.pa.us Backpatch-through: 18
Diffstat (limited to 'src/timezone/scheck.c')
0 files changed, 0 insertions, 0 deletions