| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com>, Alanoly Andrews <alanolya(at)invera(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [HACKERS] postgres 9.0 crash when bringing up hot standby |
| Date: | 2010-08-12 21:54:49 |
| Message-ID: | 6819.1281650089@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin pgsql-hackers |
I wrote:
> I wonder if the problem is not so much libpqwalreceiver as the
> walreceiver process. Maybe an ordinary backend process does some
> prerequisite initialization that walreceiver is missing. Hard to
> guess what, though ... I can't think of anything dlopen() depends on
> that should be under our control.
Actually, that idea is easily tested: try doing
LOAD 'libpqwalreceiver';
in a regular backend process.
If that still crashes, it might be useful to truss or strace the backend
while it runs the command, and compare that to the trace of
LOAD 'dblink';
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Victor Hugo | 2010-08-13 12:25:19 | PGexpress v4.11 + postgresql 8.4.4 |
| Previous Message | Tom Lane | 2010-08-12 21:40:20 | Re: [HACKERS] postgres 9.0 crash when bringing up hot standby |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2010-08-12 22:08:33 | Re: including backend ID in relpath of temp rels - updated patch |
| Previous Message | Tom Lane | 2010-08-12 21:40:20 | Re: [HACKERS] postgres 9.0 crash when bringing up hot standby |