Re: BUG #15700: PG 10 vs. 11: Large increase in memory usage whenselecting BYTEA data (maybe memory leak)
| От | Jeff Janes |
|---|---|
| Тема | Re: BUG #15700: PG 10 vs. 11: Large increase in memory usage whenselecting BYTEA data (maybe memory leak) |
| Дата | |
| Msg-id | CAMkU=1wW32K8n4ut_7zz+6HH1J068tFtpv5os=eeAgvjiQH8ZQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: BUG #15700: PG 10 vs. 11: Large increase in memory usage whenselecting BYTEA data (maybe memory leak) (Matthias Otterbach <mo@otterbach.eu>) |
| Ответы |
Re: BUG #15700: PG 10 vs. 11: Large increase in memory usage when selecting BYTEA data (maybe memory leak)
Re: BUG #15700: PG 10 vs. 11: Large increase in memory usage whenselecting BYTEA data (maybe memory leak) |
| Список | pgsql-bugs |
On Mon, Mar 18, 2019 at 2:26 PM Matthias Otterbach <mo@otterbach.eu> wrote:
>
> I confess that I'm not actually trying this with JDBC, but with
> libpq (via psql and pgbench). One could imagine that JDBC is
> presenting the query sufficiently differently to cause different
> backend behavior, say by asking for binary not text output ---
> but I tried that, no change.
Can I do anything to figure out how the JDBC driver presents the query?
You can set log_statement to 'all' to get a view of the statements issued.
Doing that, I can reproduce the problem, and it seems to be using an implicitly declared cursor (which I have not run into before). That might ring a bell for Tom.
1600 [unknown] BEGIN 00000 2019-03-18 14:36:00.120 EDT LOG: execute S_1: BEGIN
1600 [unknown] SELECT 00000 2019-03-18 14:36:00.130 EDT LOG: execute S_2/C_3: SELECT b FROM public.a
1600 [unknown] SELECT 00000 2019-03-18 14:36:00.785 EDT LOG: execute fetch from S_2/C_3: SELECT b FROM public.a
1600 [unknown] SELECT 00000 2019-03-18 14:36:01.359 EDT LOG: execute fetch from S_2/C_3: SELECT b FROM public.a
1600 [unknown] SELECT 00000 2019-03-18 14:36:01.948 EDT LOG: execute fetch from S_2/C_3: SELECT b FROM public.a
1600 [unknown] SELECT 00000 2019-03-18 14:36:02.451 EDT LOG: execute fetch from S_2/C_3: SELECT b FROM public.a
1600 [unknown] SELECT 00000 2019-03-18 14:36:03.000 EDT LOG: execute fetch from S_2/C_3: SELECT b FROM public.a
1600 [unknown] SELECT 00000 2019-03-18 14:36:03.483 EDT LOG: execute fetch from S_2/C_3: SELECT b FROM public.a
1600 [unknown] SELECT 00000 2019-03-18 14:36:04.029 EDT LOG: execute fetch from S_2/C_3: SELECT b FROM public.a
....
Cheers,
Jeff
В списке pgsql-bugs по дате отправления: