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

Dear Tom Lane, dear pgsql-bugs list,

thanks for your reply and attempt to reproduce my memory issue.

Am 2019-03-18 17:33, schrieb Tom Lane:
> PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
>
>> I know that I'm also using the JDBC driver here which of course could
>> also
>> cause the bug, it might be a JDBC driver bug for which I should report
>> a bug
>> elsewhere.
>
> 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?
Is there any information available if I increase a log level or enable
any debugging output in the PostgreSQL server?

I tried increasing log levels a little bit, but actually I do not know
if it gives any more information:

log_min_messages = debug5
log_min_error_statement = debug5

debug_print_parse = on
debug_print_rewritten = on
debug_print_plan = on
debug_pretty_print = on
log_connections = on
log_disconnections = on
log_duration = on
log_error_verbosity = verbose

You can find an extract from the logfile at
https://pastebin.com/5eB0t0uS (filtered for my process id which caused
the crash even though there were not many other processes as I use this
virtual machine solely for this test query).

> I think there must be some other moving parts you haven't mentioned.
> Maybe you have some PG extension(s) installed?

Actually I hope not, that is why I tried to reproduce the problem with a
vanilla Ubuntu and PostgreSQL installation in a virtual machine - to
make sure that there are no other extensions or anything influence my
issue. Actually "postgres=# select * from pg_extension;" returns:

extname | extowner | extnamespace | extrelocatable | extversion |
extconfig | extcondition
---------+----------+--------------+----------------+------------+-----------+--------------
plpgsql | 10 | 11 | f | 1.0 |
|
(1 row)

Best regards, Matthias Otterbach