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

From: Stephen Frost <sfrost(at)snowman(dot)net>
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 15:24:38
Message-ID: 20160714152438.GN4028@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) 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.

The complaint is that there's no way to safely kill a process which has
gotten stuck in a fopen() call. I sympathize with that point of view as
there are many ways in which a process could get stuck in a fopen() or
similar call and it would be nice to have a way to kill such processes
without bouncing the entire server (though I wonder if this is a way to
end up with a dead backend that sticks around after the postmaster has
quit too, which is also quite bad...).

Thanks!

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-07-14 15:45:33 Re: Issue in pg_catalog.pg_indexes view definition
Previous Message Tom Lane 2016-07-14 14:20:42 Re: Hang issue when COPY to/from an unopened FIFO