On 03/11/2013 09:20 PM, Dmitry Koterov wrote:
x86_64, PostgreSQL 9.2. is run within an OpenVZ container and generates SIGBUS. PostgreSQL 9.1 has no such problem.
(OpenVZ is a linux kernel-level virtualization which adds namespaces for processes, networking, quotas etc. It works not like e.g. Xen or VMWare, because all containers share the same kernel.)
Related to SHM vs mmapped files? Seems unlikely, but I guess it could affect low-enough level work like kernel TLB usage.
At what point in Pg's execution does the SIGBUS occur? Is it always at the same place or few places in the code? It would be helpful if you could enable core files writing and get backtraces from core files or (since it's reproducible) by attaching a debugger directly to a Pg backend. See
http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD If you restore just the first half of the table or just the last half does the crash still happen? If it still happens in one part but not in another, can you do a binary search* to isolate the smallest chunk of the input file that still reliably causes the crash?
* (ie: split the file roughly in half at a record boundary and test each half. Discard the half that doesn't crash, keep the half that crashes. Repeat the process using the kept half as input until you find the smallest chunk that still crashes, or get down to a single record that causes the problem.)
Does the same data cause a crash when restored in another VM on the same OpenVZ container? What about when restored to another machine with the same OS and Pg version outside OpenVZ?
-- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
