Re: BUG #15700: PG 10 vs. 11: Large increase in memory usage when selecting BYTEA data (maybe memory leak)
От | Tom Lane |
---|---|
Тема | Re: BUG #15700: PG 10 vs. 11: Large increase in memory usage when selecting BYTEA data (maybe memory leak) |
Дата | |
Msg-id | 16717.1552926811@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #15700: PG 10 vs. 11: Large increase in memory usage when selecting BYTEA data (maybe memory leak) (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #15700: PG 10 vs. 11: Large increase in memory usage whenselecting BYTEA data (maybe memory leak)
|
Список | pgsql-bugs |
PG Bug reporting form <noreply@postgresql.org> writes: > [ apparent backend memory leak when processing wide rows ] FWIW, I tried to reproduce this without success, on both HEAD and v11 branch tip. It's possible that this is a bug somebody fixed since 11.2, but I see no mention of relevant memory leaks in the commit log. Still, it's hard to interpret this: > ExecutorState: 4294976384 total in 17 blocks; 4080 free (0 chunks); > 4294972304 used as anything but a leak in ExecutorState. For comparison, when I try this same example here, I get a fairly steady value of ExecutorState: 134225984 total in 2 blocks; 5144 free (1 chunks); 134220840 used > 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. I think there must be some other moving parts you haven't mentioned. Maybe you have some PG extension(s) installed? regards, tom lane
В списке pgsql-bugs по дате отправления: