| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Cc: | Julien Rouhaud <rjuju123(at)gmail(dot)com>, Paul Ramsey <pramsey(at)cleverelephant(dot)ca>, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, fuzk <fuzk80_76(at)163(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: ERROR: XX000: cannot update SecondarySnapshot during a parallel operation |
| Date: | 2019-03-15 03:45:27 |
| Message-ID: | 11343.1552621527@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> A fast way to find out would be to get one of these people who can
> reproduce the problem to recompile PostgreSQL with that error changed
> to a PANIC, and examine the resulting smoldering core. (Someone had a
> proposal to make PostgreSQL errors optionally dump the function call
> stack with backtrace(3) even in regular production builds, which would
> make this kind of investigations go faster, I wonder what happened to
> that.)
Can't speak for other people, but I remember experimenting with
glibc's backtrace(3) and being so underwhelmed by the usefulness
of the information presented that I thought incorporating it would
be mostly a waste of effort. Maybe there's an argument that it's
better than nothing at all; but I think we'd still be driven to
asking people to get stack traces with better tools.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Noah Misch | 2019-03-15 03:46:31 | Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes |
| Previous Message | fuzk | 2019-03-15 02:12:05 | Re:Re: ERROR: XX000: cannot update SecondarySnapshot during a parallel operation |