Re: BUG #15700: PG 10 vs. 11: Large increase in memory usage when selecting BYTEA data (maybe memory leak)

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