From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | pgsql-patches(at)postgresql(dot)org |
Subject: | psql: flush output in cursor-fetch mode |
Date: | 2007-06-20 22:51:52 |
Message-ID: | 1182379912.8660.12.camel@dell.linuxdev.us.dell.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
psql's "FETCH_COUNT" feature is useful for incrementally displaying the
results of a long-running query. However, psql fails to flush its output
stream as new rows from the partial result set are produced, which means
that partial query results may not be visible to the client until the
stdio buffer is eventually flushed or the query produces its complete
result set.
Example:
$ cat ~/test.sql
-- a contrived function to get a query that slowly produces
-- more rows
create function slow_func() returns boolean as
$$
begin
perform pg_sleep(2);
return true;
end;
$$ language plpgsql;
neilc=# \i ~/test.sql
CREATE FUNCTION
neilc=# create table t1 (a int, b int);
CREATE TABLE
neilc=# insert into t1 values (5, 10), (10, 15), (20, 25), (30, 35);
INSERT 0 4
neilc=# \set FETCH_COUNT 1
neilc=# select * from t1 where slow_func() is true;
With CVS HEAD, no output is visible until the complete result set has
been produced, at which point all 4 rows are printed. This is
undesirable: since the client has gone to the trouble of FETCH'ing the
rows one-at-a-time, it should display the partial result set before
issuing another FETCH.
Attached is a patch that fixes this, by calling fflush() on the psql
output stream after each call to printQuery() in ExecQueryUsingCursor().
-Neil
Attachment | Content-Type | Size |
---|---|---|
psql_fetch_count_fflush-1.patch | text/x-patch | 806 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-06-21 00:13:53 | Re: Load Distributed Checkpoints, take 3 |
Previous Message | Gregory Stark | 2007-06-20 19:17:09 | Re: [HACKERS] 'Waiting on lock' |