Re: [sqlsmith] stuck spinlock in pg_stat_get_wal_receiver after OOM

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Andreas Seltenreich <seltenreich(at)gmx(dot)de>, pgsql-hackers(at)postgresql(dot)org, 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-03 14:50:23
Message-ID: 20171003145023.nc2ffduj3qvy4b5b@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:

> > Tom Lane wrote:
> >> I don't especially like the Asserts inside spinlocks, either.
>
> > I didn't change these. It doesn't look to me that these asserts are
> > worth very much as production code.
>
> OK. If we ever see these hit in the buildfarm I might argue for
> reconsidering, but without some evidence of that sort it's not
> worth much concern.

Sure. I would be very surprised if buildfarm ever exercises this code.

> > I think the latch is only used locally. Seems that it was only put in
> > shmem to avoid a separate variable ...
>
> Hm, I'm strongly tempted to move it to a separate static variable then.
> That's not a bug fix, so maybe it only belongs in HEAD, but is there
> value in keeping the branches in sync in this code? It sounded from
> your commit message like they were pretty different already :-(

Well, there were conflicts in almost every branch, but they were pretty
minor.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-10-03 14:55:24 Re: 64-bit queryId?
Previous Message Tom Lane 2017-10-03 14:31:42 Re: [sqlsmith] stuck spinlock in pg_stat_get_wal_receiver after OOM