Re: Hang issue when COPY to/from an unopened FIFO

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Kenan Yao <kyao(at)pivotal(dot)io>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Hang issue when COPY to/from an unopened FIFO
Date: 2016-07-14 18:40:34
Message-ID: 20160714184034.cos4nulxszdlylih@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2016-07-14 10:20:42 -0400, Tom Lane wrote:
> Kenan Yao <kyao(at)pivotal(dot)io> writes:
> > -- mkfifo /tmp/test.dat # bash
> > copy pg_class to '/tmp/test.dat';
> > -- try pg_cancel_backend or pg_terminate_backend from other sessions
>
> This does not seem like a supported case to me. I see few if any reasons
> to want to do that rather than doing copy-to-program or copy-to-client.
> We're certainly not going to want to add any overhead to the COPY code
> paths in order to allow it.

Agreed on that.

Said overhead would be a good reason to get rid of using buffered IO at
some point though - we're doing our own buffering anyway, and the stream
code adds noticeable overhead (doubles the cache footprint
basically). Even worse, it uses locking internally on many
platforms... In that case adding sane EINTR handling seems trivial.

Andres

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2016-07-14 18:48:57 Re: [PERFORM] 9.4 -> 9.5 regression with queries through pgbouncer on RHEL 6
Previous Message Andres Freund 2016-07-14 18:34:12 Re: Reviewing freeze map code