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
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 |