Christoph Berg <m...@debian.org> writes: > 10beta3 and 9.6.4 are both failing during initdb on mips64el on > Debian/sid (unstable): > All other architectures have succeeded, as well as the 9.6.4 build for > Debian/stretch (stable) on mips64el. The difference might be the > compiler version (6.3.0 vs 7.1.0).
It's hard to explain that stack trace other than as a compiler bug. There shouldn't be any event triggers active here, so EventTriggerBeginCompleteQuery should have done nothing and returned false. I don't put complete faith in gdb reports of local variable values, but it says needCleanup = 0 '\000' which agrees with that. Also the core dump appears to be because currentEventTriggerState is NULL (please check that), which is expected if EventTriggerBeginCompleteQuery did nothing. However, then EventTriggerEndCompleteQuery should not have gotten called at all. I suspect you could work around this with bool isCompleteQuery = (context <= PROCESS_UTILITY_QUERY); - bool needCleanup; + volatile bool needCleanup; bool commandCollected = false; If that fixes it, it's definitely a compiler bug. That function does not change needCleanup after the sigsetjmp call, so per POSIX it should not have to label the variable volatile. This is far from being the first such bug we've seen though. regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers