| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Andreas Seltenreich <seltenreich(at)gmx(dot)de> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
| Subject: | Re: [sqlsmith] stuck spinlock in pg_stat_get_wal_receiver after OOM |
| Date: | 2017-10-02 21:08:05 |
| Message-ID: | 20171002210805.x4lxxmarluen6rfg@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2017-10-02 22:56:49 +0200, Andreas Seltenreich wrote:
> Hi,
>
> low-memory testing with REL_10_STABLE at 1f19550a87 produced the
> following PANIC:
>
> stuck spinlock detected at pg_stat_get_wal_receiver, walreceiver.c:1397
Ugh.
> I was about to wrap the pstrdup()s with a PG_TRY block, but I can't find
> a spinlock being released in a PG_CATCH block anywhere, so maybe that's
> a bad idea?
Yes, that'd be a bad idea. It's not great to have memcpys in a critical
section, but it's way better than pallocs. So we need to use some local
buffers that this get copied to.
This seems to have been introduced as part of b1a9bad9e74 and then
9ed551e0a4f. Authors CCed.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tatsuo Ishii | 2017-10-02 21:09:31 | Re: list of credits for release notes |
| Previous Message | Thomas Munro | 2017-10-02 21:05:16 | Re: [sqlsmith] stuck spinlock in pg_stat_get_wal_receiver after OOM |