Re: CHECK_FOR_INTERRUPTS in spgdoinsert() isn't helpful

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: CHECK_FOR_INTERRUPTS in spgdoinsert() isn't helpful
Date: 2014-05-29 20:57:19
Message-ID: CAM3SWZQYkP997-J0Yq0-FhvWnbyQfXkPtdyhe6zYq=PO_W_+BQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 29, 2014 at 1:42 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Not throw the error. (If we did, it'd turn into a PANIC, which doesn't
> seem like what we want.)

Of course, but it isn't obvious to me that that isn't what we'd want,
if the alternative is definitely that we'd be stuck in an infinite
uninterruptible loop (I guess we couldn't just avoid throwing the
error, thereby risking proceeding without locks -- and so I guess we
can basically do nothing like this in critical sections). Now, that
probably isn't the actual choice that we must face, but it also isn't
obvious to me how you can do better than not throwing the error (and
doing nothing extra) when in a critical section. That was the intent
of my original question.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Claudio Freire 2014-05-29 21:00:28 Re: Extended Prefetching using Asynchronous IO - proposal and patch
Previous Message Claudio Freire 2014-05-29 20:44:06 Re: Extended Prefetching using Asynchronous IO - proposal and patch