rgr@cslab.de wrote:
> We are using QNX 6.5 SP 1 and a port based on the pkgsrc.
I thought we no longer supported QNX ... in fact, I think we removed it
before the 8.2 release. So what's this port you're using? This
probably means a heavily patched source.
Author: Bruce Momjian <bruce@momjian.us>
Branch: master Release: REL8_2_BR [6f84b2da7] 2006-01-05 02:43:38 +0000
Remove QNX file.
Author: Bruce Momjian <bruce@momjian.us>
Branch: master Release: REL8_2_BR [a1675649e] 2006-01-05 01:56:30 +0000
Remove QNX port.
> ---1519657-2013-11-01 00:10:23 CET:ERROR: could not seek to block 149256 in
> file "pg_tblspc/17639/PG_9.0_201008051/16387/28109.1": Interrupted function
> call
> ---1519657-2013-11-01 00:10:23 CET:CONTEXT: writing block 149256 of
> relation pg_tblspc/17639/PG_9.0_201008051/16387/28109
This is also a bit funny. Normally each segment is 1GB long, unless you
configure it otherwise; this means a segment has only 131072 blocks.
But you have at least 149256 blocks here.
I wonder if the problem is mishandling of signals -- i.e. perhaps the
port is at fault, or maybe it was right in 8.3 but we changed something
that would affect the port, and it wasn't properly updated to match.
> ---1507368-2013-11-01 00:11:58 CET:LOG: background writer process (PID
> 1519657) was terminated by signal 11: segmentation violation
> ---1507368-2013-11-01 00:11:58 CET:LOG: terminating any other active server
> processes
>
>
> contents of the dump-file:
>
>
> #0 0x00000000 in ?? ()
> #1 0x08205ef4 in BackgroundWriterMain ()
> #2 0x080e2759 in AuxiliaryProcessMain ()
Not very useful, is it :-(
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
