Re: [HACKERS] [sqlsmith] stuck spinlock in pg_stat_get_wal_receiverafter OOM
От | Alvaro Herrera |
---|---|
Тема | Re: [HACKERS] [sqlsmith] stuck spinlock in pg_stat_get_wal_receiverafter OOM |
Дата | |
Msg-id | 20171003145023.nc2ffduj3qvy4b5b@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: [HACKERS] [sqlsmith] stuck spinlock in pg_stat_get_wal_receiver after OOM (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] [sqlsmith] stuck spinlock in pg_stat_get_wal_receiver after OOM
|
Список | pgsql-hackers |
Tom Lane wrote: > Alvaro Herrera <alvherre@alvh.no-ip.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: