From: | Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com> |
---|---|
To: | Daniel Verite <daniel(at)manitou-mail(dot)org> |
Cc: | vignesh C <vignesh21(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: psql's FETCH_COUNT (cursor) is not being respected for CTEs |
Date: | 2024-02-08 11:06:33 |
Message-ID: | CAKZiRmw1p_Rz3vYLFB9kXdP2mObrsmJ2NA4uCEeJ6pjLWf1pfQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Daniel,
On Tue, Jan 30, 2024 at 3:29 PM Daniel Verite <daniel(at)manitou-mail(dot)org> wrote:
> PFA a rebased version.
Thanks for the patch! I've tested it using my original reproducer and
it works great now against the original problem description. I've
taken a quick look at the patch, it looks good for me. I've tested
using -Werror for both gcc 10.2 and clang 11.0 and it was clean. I
have one slight doubt:
when I run with default pager (more or less):
\set FETCH_COUNT 1000
WITH data AS (SELECT generate_series(1, 20000000) as Total) select
repeat('a',100) || data.Total || repeat('b', 800) as total_pat from
data;
-- it enters pager, a skip couple of pages and then "q"
.. then - both backend and psql - go into 100% CPU as it were still
receiving (that doesn't happen e.g. with export PAGER=cat). So I'm
not sure, maybe ExecQueryAndProcessResults() should somewhat faster
abort when the $PAGER is exiting normally(?).
And oh , btw, in v6-0001 (so if you would be sending v7 for any other
reason -- other reviewers -- maybe worth realigning it as detail):
+ int PQsetChunkedRowsMode(PGconn *conn,
+ int maxRows);
but the code has (so "maxRows" != "chunkSize"):
+PQsetChunkedRowsMode(PGconn *conn, int chunkSize)
-J.
From | Date | Subject | |
---|---|---|---|
Next Message | shveta malik | 2024-02-08 11:06:37 | Re: Synchronizing slots from primary to standby |
Previous Message | Mats Kindahl | 2024-02-08 11:06:23 | Re: glibc qsort() vulnerability |