From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_background (and more parallelism infrastructure patches) |
Date: | 2014-07-26 16:02:26 |
Message-ID: | CA+TgmoZCODi+bqGseu+Fxg56ABG6GFgUv8cPgzZJZceY3CMuOg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jul 25, 2014 at 4:16 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
> On Fri, Jul 25, 2014 at 02:11:32PM -0400, Robert Haas wrote:
>> + pq_mq_busy = true;
>> +
>> + iov[0].data = &msgtype;
>> + iov[0].len = 1;
>> + iov[1].data = s;
>> + iov[1].len = len;
>> +
>> + Assert(pq_mq_handle != NULL);
>> + result = shm_mq_sendv(pq_mq_handle, iov, 2, false);
>> +
>> + pq_mq_busy = false;
>
> Don't you need a PG_TRY block here to reset pq_mq_busy?
No. If shm_mq_sendv is interrupted, we can't use the shm_mq any more.
But since that should only happen if an interrupt arrives while the
queue is full, I think that's OK. (Think about the alternatives: if
the queue is full, we have no way of notifying the launching process
without waiting for it to retrieve the results, but it might not do
that right away, and if we've been killed we need to die *now* not
later.)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-07-26 16:16:01 | Re: [RFC] Should smgrtruncate() avoid sending sinval message for temp relations |
Previous Message | Andres Freund | 2014-07-26 15:40:50 | Re: parametric block size? |