pgsql: Refactor pg_get_line() to expose an alternative StringInfo-based

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: pgsql: Refactor pg_get_line() to expose an alternative StringInfo-based
Date: 2020-09-06 18:13:50
Message-ID: E1kEzAk-0002hn-DA@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Refactor pg_get_line() to expose an alternative StringInfo-based API.

Letting the caller provide a StringInfo to read into is helpful when
the caller needs to merge lines or otherwise modify the data after
it's been read. Notably, now the code added by commit 8f8154a50
can use pg_get_line_append() instead of having its own copy of that
logic. A follow-on commit will also make use of this.

Also, since StringInfo buffers are a minimum of 1KB long, blindly
using pg_get_line() in a loop can eat a lot more memory than one would
expect. I discovered for instance that commit e0f05cd5b caused initdb
to consume circa 10MB to read postgres.bki, even though that's under
1MB worth of data. A less memory-hungry alternative is to re-use the
same StringInfo for all lines and pg_strdup the results.

Discussion: https://postgr.es/m/1315832.1599345736@sss.pgh.pa.us

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/8e3c58e6e459b285d37edb6129e412ed25cd90c1

Modified Files
--------------
src/backend/libpq/hba.c | 40 +++++++++-----------------
src/bin/initdb/initdb.c | 12 ++++++--
src/common/pg_get_line.c | 70 +++++++++++++++++++++++++++++++--------------
src/include/common/string.h | 3 ++
4 files changed, 75 insertions(+), 50 deletions(-)

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2020-09-07 01:40:54 pgsql: Split Makefile symbol CFLAGS_VECTOR into two symbols.
Previous Message Magnus Hagander 2020-09-06 17:31:11 pgsql: Change path in example of file_fdw for logs