After exporting and re-importing (pg9.5 -> 9.5), this has gone away. We
changed quite a few variables in the import (non-parallel, letting full
index builds proceed, etc.), so not 100% sure what the issue was; as you
suggested, doesn't that pg9.5 itself was the problem (though not sure on
pg_dump/restore).
Thanks,
Michael J. Bommarito II, CEO
Bommarito Consulting, LLC
*Web:* http://www.bommaritollc.com
*Mobile:* +1 (646) 450-3387
On Sat, Jul 18, 2015 at 12:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Michael Bommarito <michael@bommaritollc.com> writes:
> > Compiled from source with --debug using 9.5alpha1 with -O0 -ggdb
> > -fno-omit-frame-pointer -mno-red-zone. Reset to default postgresql.conf.
> > Was able to generate segfaults repeatedly loading pghero dashboard.
> First,
> > some errors from the pg logs.
> > 2015-07-18 15:07:58 UTC [27112-1] postgres@database ERROR: attribute
> > number 2 exceeds number of columns 0
> > 2015-07-18 15:08:23 UTC [27112-3] postgres@database ERROR: invalid
> > varattno 66
> > 2015-07-18 15:17:19 UTC [3605-1] postgres@database ERROR: tupdesc
> > reference 0x2bdd8a8 is not owned by resource owner Portal
> > 2015-07-18 15:48:38 UTC [10281-1] postgres@database ERROR: tupdesc
> > reference 0xf77248 is not owned by resource owner Portal
>
> I'm starting to wonder about flaky hardware and/or compiler bugs. 9.5
> seems completely unreliable for you, but we're not seeing any similar
> reports from anyone else. Is 9.4 reliable on the same machine + same
> build environment?
>
> > Program received signal SIGQUIT, Quit.
>
> Catching a SIGQUIT isn't very helpful; that just means you're one of
> the server processes that got force-terminated after some other one
> crashed.
>
> regards, tom lane
>