Re: possible bug not in open items

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: possible bug not in open items
Date: 2009-04-10 18:47:32
Message-ID: 28362.1239389252@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> Here is a patch that does what I think Heikki was suggesting. If a
> proper fix is non-trivial, then I assume there's some problem with my
> patch, but I'll post it for the archives anyway.

This patch is so wrong that it's scary. You can't have
ImmediateInterruptOK true over the duration of any significant amount of
backend processing --- as an example, if you take control away in the
middle of a malloc call, you'll probably be left with a corrupt malloc
arena.

It doesn't even work to try to take control away while control is
inside, say, the OpenSSL code. The reason we have the
prepare_for_client_read/client_read_ended hooks is to allow the flag to
be turned on over a sufficiently narrow scope --- to wit, the recv()
kernel call and nothing else --- that it's safe.

AFAICS, a safe patch for this has got to involve teaching those hooks
about COPY mode.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2009-04-10 18:57:10 Re: Re: [BUGS] BUG #4027: backslash escaping notdisabled inplpgsql
Previous Message Kevin Grittner 2009-04-10 18:40:06 Re: Re: [BUGS] BUG #4027: backslash escaping notdisabled inplpgsql