Thread: psql client quits after 1st command
Hi all. Under Linux I'm trying to communicate to an instance of the psql client running in the background through a couple of named pipes. I'd like to do something like this: $ mkfifo /tmp/pg_ipipe /tmp/pg_opipe $ psql -d testdb -U testuser < /tmp/pg_ipipe > /tmp/pg_opipe & ... $ echo "\t" > /tmp/pg_ipipe $ echo "select count(*) from test_table;" > /tmp/pg_ipipe $ read COUNT < /tmp/pg_opipe The psql client connects to the DB abd waits for the first commad coming from the "pg_ipipe" and executes it. Fine. The problem is that it quits soon after instead of waiting for the second (and any subsequent) command, as we all see in the usual command line usage. I've also tried to add a "--file -" with no luck. It seems that when the psql is getting the input from a named pipe acts as if the "--command" option were active. I'm sure I'm missing something. But don't know what. Is there any hint? MTIA! -- Vincenzo Romano ---- Maybe Computers will never become as intelligent as Humans. For sure they won't ever become so stupid. [VR-1987]
Vincenzo Romano <vincenzo.romano@gmail.com> writes: > Hi all. > > Under Linux I'm trying to communicate to an instance of the psql client > running in the background through a couple of named pipes. > I'd like to do something like this: > > $ mkfifo /tmp/pg_ipipe /tmp/pg_opipe > $ psql -d testdb -U testuser < /tmp/pg_ipipe > /tmp/pg_opipe & > ... > $ echo "\t" > /tmp/pg_ipipe > $ echo "select count(*) from test_table;" > /tmp/pg_ipipe > $ read COUNT < /tmp/pg_opipe > > The psql client connects to the DB abd waits for the first commad coming from > the "pg_ipipe" and executes it. Fine. > The problem is that it quits soon after instead of waiting for the second (and > any subsequent) command, as we all see in the usual command line usage. > I've also tried to add a "--file -" with no luck. > It seems that when the psql is getting the input from a named pipe acts as if > the "--command" option were active. > > I'm sure I'm missing something. But don't know what. > Is there any hint? psql gets an EOF on the named pipe when the first shell command exits. You need to batch all your commands and send them in one shell command, so it keeps the pipe open until it's done. -Doug
On Friday 02 March 2007 17:07 Douglas McNaught wrote: > Vincenzo Romano <vincenzo.romano@gmail.com> writes: > > Hi all. > > > > Under Linux I'm trying to communicate to an instance of the psql client > > running in the background through a couple of named pipes. > > I'd like to do something like this: > > > > $ mkfifo /tmp/pg_ipipe /tmp/pg_opipe > > $ psql -d testdb -U testuser < /tmp/pg_ipipe > /tmp/pg_opipe & > > ... > > $ echo "\t" > /tmp/pg_ipipe > > $ echo "select count(*) from test_table;" > /tmp/pg_ipipe > > $ read COUNT < /tmp/pg_opipe > > > > The psql client connects to the DB abd waits for the first commad coming > > from the "pg_ipipe" and executes it. Fine. > > The problem is that it quits soon after instead of waiting for the second > > (and any subsequent) command, as we all see in the usual command line > > usage. I've also tried to add a "--file -" with no luck. > > It seems that when the psql is getting the input from a named pipe acts > > as if the "--command" option were active. > > > > I'm sure I'm missing something. But don't know what. > > Is there any hint? > > psql gets an EOF on the named pipe when the first shell command > exits. You need to batch all your commands and send them in one shell > command, so it keeps the pipe open until it's done. > > -Doug Using "echo -n" instead of the plain "echo" to avoid sending the EOL makes the psql client behaving the same way: quitting after the first complete command. This makes useless the input redirection from anything other than a file. I'm now going to read the sourcecode for the psql client. Maybe it's a (kind of) bug in the psql code. -- Vincenzo Romano ---- Maybe Computers will never become as intelligent as Humans. For sure they won't ever become so stupid. [VR-1987]
On Fri, Mar 02, 2007 at 05:26:03PM +0100, Vincenzo Romano wrote: > > psql gets an EOF on the named pipe when the first shell command > > exits. You need to batch all your commands and send them in one shell > > command, so it keeps the pipe open until it's done. > > > > -Doug > > Using "echo -n" instead of the plain "echo" to avoid sending the EOL makes the > psql client behaving the same way: quitting after the first complete command. > This makes useless the input redirection from anything other than a file. No, it's exactly as he said: the FIFO only works once. As soon as you've piped something into it and the echo closes the pipe, it closes for psql also. As far as it's concerned you've quit, so it exits. Replace the psql commmand with "cat" and you'll see exactly the same effect. I don't think you can acheive the effect you want with a FIFO. Maybe a UDP socket will work as it doesn't require a permanent connection. Hope this helps, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
Attachment
Martijn van Oosterhout <kleptog@svana.org> writes:
> I don't think you can acheive the effect you want with a FIFO.
I think Doug had it right: the trick is to have some process holding the
FIFO open for write throughout the procedure, so that the reader (psql)
doesn't see an EOF. This doesn't necessarily have to be the same
process(es) that're actually putting data into the FIFO.
Per the read(2) man page:
When attempting to read from an empty pipe or FIFO:
o If no process has the pipe open for writing, read() will
return 0 to indicate end-of-file.
o If some process has the pipe open for writing and O_NONBLOCK
is set, read() will return -1 and set errnoto EAGAIN.
o If some process has the pipe open for writing and O_NONBLOCK
is clear, read() will block until some data is written or the
pipe is closed by all processes that had the pipe open for
writing.
regards, tom lane
Good point Tom. I failed to go little deeper in the problem. So the final test for me is that the whole bash script along with its echos is to be globally directed to the pipes. On Friday 02 March 2007 19:43 Tom Lane wrote: > Martijn van Oosterhout <kleptog@svana.org> writes: > > I don't think you can acheive the effect you want with a FIFO. > > I think Doug had it right: the trick is to have some process holding the > FIFO open for write throughout the procedure, so that the reader (psql) > doesn't see an EOF. This doesn't necessarily have to be the same > process(es) that're actually putting data into the FIFO. > > Per the read(2) man page: > > When attempting to read from an empty pipe or FIFO: > > o If no process has the pipe open for writing, read() will > return 0 to indicate end-of-file. > > o If some process has the pipe open for writing and O_NONBLOCK > is set, read() will return -1 and set errnoto EAGAIN. > > o If some process has the pipe open for writing and O_NONBLOCK > is clear, read() will block until some data is written or the > pipe is closed by all processes that had the pipe open for > writing. > > regards, tom lane -- Vincenzo Romano ---- Maybe Computers will never become as intelligent as Humans. For sure they won't ever become so stupid. [VR-1987]