Thread: Make StringInfo available to frontend code.
Hi,
This patch, in a slightly rougher form, was submitted as part of [1],
but it seems worth bringing up separately, rather than just committing
hearing no objections.
From the commit message:
Make StringInfo available to frontend code.
There's plenty places in frontend code that could benefit from a
string buffer implementation. Some because it yields simpler and
faster code, and some others because of the desire to share code
between backend and frontend.
While there is a string buffer implementation available to frontend
code, libpq's PQExpBuffer, it is clunkier than stringinfo, it
introduces a libpq dependency, doesn't allow for sharing between
frontend and backend code, and has a higher API/ABI stability
requirement due to being exposed via libpq.
Therefore it seems best to just making StringInfo being usable by
frontend code. There's not much to do for that, except for rewriting
two subsequent elog/ereport calls into others types of error
reporting, and deciding on a maximum string length.
For the maximum string size I decided to privately define MaxAllocSize
to the same value as used in the backend. It seems likely that we'll
want to reconsider this for both backend and frontend code in the not
too far away future.
For now I've left stringinfo.h in lib/, rather than common/, to reduce
the likelihood of unnecessary breakage. We could alternatively decide
to provide a redirecting stringinfo.h in lib/, or just not provide
compatibility.
I'm still using stringinfo in the aforementioned thread, and I also want
to use it in a few more places. On the more ambitious side I really
would like to have a minimal version of elog.h available in the backend,
and that would really be a lot easier with stringinfo available.
I also would like to submit a few patches expanding stringinfo's
capabilities and performance, and it seems to me it'd be better to do so
after moving (lest they introduce new FE vs BE compat issues).
This allows us to remove compat.c hackery providing some stringinfo
functionality for pg_waldump (which now actually needs to pass in a
StringInfo...). I briefly played with converting more code in
pg_waldump.c than just that one call to StringInfo, but it seems that'd
be best done separately.
Comments?
Greetings,
Andres Freund
[1] https://postgr.es/m/20190920051857.2fhnvhvx4qdddviz@alap3.anarazel.de
Attachment
At Tue, 29 Oct 2019 17:10:01 -0700, Andres Freund <andres@anarazel.de> wrote in
> Hi,
>
> This patch, in a slightly rougher form, was submitted as part of [1],
> but it seems worth bringing up separately, rather than just committing
> hearing no objections.
..
> I'm still using stringinfo in the aforementioned thread, and I also want
> to use it in a few more places. On the more ambitious side I really
> would like to have a minimal version of elog.h available in the backend,
> and that would really be a lot easier with stringinfo available.
>
> I also would like to submit a few patches expanding stringinfo's
> capabilities and performance, and it seems to me it'd be better to do so
> after moving (lest they introduce new FE vs BE compat issues).
>
>
> This allows us to remove compat.c hackery providing some stringinfo
> functionality for pg_waldump (which now actually needs to pass in a
> StringInfo...). I briefly played with converting more code in
> pg_waldump.c than just that one call to StringInfo, but it seems that'd
> be best done separately.
>
> Comments?
It uses different form for the same message for FE and BE.
common/stringinfo.c:289-
> BE: ereport(ERROR,
> (errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
> errmsg("out of memory"),
> errdetail("Cannot enlarge string buffer containing %d
> bytes by %d more bytes.",
>
> FE: + _("out of memory\n\nCannot enlarge string buffer containing %d
> bytes by %d more bytes.\n"),
.po files will be smaller and more stable if we keep the same
translation unit for the same messages. That being said it doesn't
matter if it is tentative and the minimal elog.h for frontend comes
soon.
> /* It's possible we could use a different value for this in frontend code */
> #define MaxAllocSize ((Size) 0x3fffffff) /* 1 gigabyte - 1 */
The same symbol is defined for frontend in psprint.c. Isn't it better
merge them and place it in postgres_fe.h?
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
Hi,
On 2019-10-30 10:58:59 +0900, Kyotaro Horiguchi wrote:
> At Tue, 29 Oct 2019 17:10:01 -0700, Andres Freund <andres@anarazel.de> wrote in
> > Hi,
> >
> > This patch, in a slightly rougher form, was submitted as part of [1],
> > but it seems worth bringing up separately, rather than just committing
> > hearing no objections.
> ..
> > I'm still using stringinfo in the aforementioned thread, and I also want
> > to use it in a few more places. On the more ambitious side I really
> > would like to have a minimal version of elog.h available in the backend,
> > and that would really be a lot easier with stringinfo available.
> >
> > I also would like to submit a few patches expanding stringinfo's
> > capabilities and performance, and it seems to me it'd be better to do so
> > after moving (lest they introduce new FE vs BE compat issues).
> >
> >
> > This allows us to remove compat.c hackery providing some stringinfo
> > functionality for pg_waldump (which now actually needs to pass in a
> > StringInfo...). I briefly played with converting more code in
> > pg_waldump.c than just that one call to StringInfo, but it seems that'd
> > be best done separately.
> >
> > Comments?
>
> It uses different form for the same message for FE and BE.
> common/stringinfo.c:289-
> > BE: ereport(ERROR,
> > (errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
> > errmsg("out of memory"),
> > errdetail("Cannot enlarge string buffer containing %d
> > bytes by %d more bytes.",
> >
> > FE: + _("out of memory\n\nCannot enlarge string buffer containing %d
> > bytes by %d more bytes.\n"),
>
> .po files will be smaller and more stable if we keep the same
> translation unit for the same messages. That being said it doesn't
> matter if it is tentative and the minimal elog.h for frontend comes
> soon.
I'm inclined to think that the contortions necessary to allow reusing
the translation strings here would be more work than worthwhile. Also,
do we even try to share the translations between backend and frontend?
> > /* It's possible we could use a different value for this in frontend code */
> > #define MaxAllocSize ((Size) 0x3fffffff) /* 1 gigabyte - 1 */
>
> The same symbol is defined for frontend in psprint.c. Isn't it better
> merge them and place it in postgres_fe.h?
No, I don't think so. I'd rather have less than more code depend on it.
Greetings,
Andres Freund
Hello.
At Tue, 29 Oct 2019 19:06:38 -0700, Andres Freund <andres@anarazel.de> wrote in
> Hi,
>
> On 2019-10-30 10:58:59 +0900, Kyotaro Horiguchi wrote:
> > At Tue, 29 Oct 2019 17:10:01 -0700, Andres Freund <andres@anarazel.de> wrote in
> > > Hi,
> > >
> > > This patch, in a slightly rougher form, was submitted as part of [1],
> > > but it seems worth bringing up separately, rather than just committing
> > > hearing no objections.
> > ..
> > > I'm still using stringinfo in the aforementioned thread, and I also want
> > > to use it in a few more places. On the more ambitious side I really
> > > would like to have a minimal version of elog.h available in the backend,
> > > and that would really be a lot easier with stringinfo available.
> > >
> > > I also would like to submit a few patches expanding stringinfo's
> > > capabilities and performance, and it seems to me it'd be better to do so
> > > after moving (lest they introduce new FE vs BE compat issues).
> > >
> > >
> > > This allows us to remove compat.c hackery providing some stringinfo
> > > functionality for pg_waldump (which now actually needs to pass in a
> > > StringInfo...). I briefly played with converting more code in
> > > pg_waldump.c than just that one call to StringInfo, but it seems that'd
> > > be best done separately.
> > >
> > > Comments?
> >
> > It uses different form for the same message for FE and BE.
>
> > common/stringinfo.c:289-
> > > BE: ereport(ERROR,
> > > (errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
> > > errmsg("out of memory"),
> > > errdetail("Cannot enlarge string buffer containing %d
> > > bytes by %d more bytes.",
> > >
> > > FE: + _("out of memory\n\nCannot enlarge string buffer containing %d
> > > bytes by %d more bytes.\n"),
> >
> > .po files will be smaller and more stable if we keep the same
> > translation unit for the same messages. That being said it doesn't
> > matter if it is tentative and the minimal elog.h for frontend comes
> > soon.
>
> I'm inclined to think that the contortions necessary to allow reusing
> the translation strings here would be more work than worthwhile. Also,
Maybe so for doing that in this stage. So I expect that elog.h for FE
comes.
> the translation strings here would be more work than worthwhile. Also,
> do we even try to share the translations between backend and frontend?
No. I don't mean that. FE and BE have their own .po files, anyway.
> > > /* It's possible we could use a different value for this in frontend code */
> > > #define MaxAllocSize ((Size) 0x3fffffff) /* 1 gigabyte - 1 */
> >
> > The same symbol is defined for frontend in psprint.c. Isn't it better
> > merge them and place it in postgres_fe.h?
>
> No, I don't think so. I'd rather have less than more code depend on it.
Ok, understoold. Thanks for the reply.
regards.
> On 30 Oct 2019, at 01:10, Andres Freund <andres@anarazel.de> wrote: > Make StringInfo available to frontend code. I’ve certainly wanted just that on multiple occasions, so +1 on this. > Therefore it seems best to just making StringInfo being usable by > frontend code. There's not much to do for that, except for rewriting > two subsequent elog/ereport calls into others types of error > reporting, and deciding on a maximum string length. Skimming (but not testing) the patch, it seems a reasonable approach. + * StringInfo provides an extensible string data type. It can be used to It might be useful to point out the upper bound on the extensibility in the rewrite of this sentence, and that it’s not guaranteed to be consistent between frontend and backend. > I'm still using stringinfo in the aforementioned thread, and I also want > to use it in a few more places. On the more ambitious side I really > would like to have a minimal version of elog.h available in the backend, > and that would really be a lot easier with stringinfo available. s/backend/frontend/? cheers ./daniel
Hi, On 2019-11-01 23:19:33 +0100, Daniel Gustafsson wrote: > > On 30 Oct 2019, at 01:10, Andres Freund <andres@anarazel.de> wrote: > > > Make StringInfo available to frontend code. > > I’ve certainly wanted just that on multiple occasions, so +1 on this. Cool. > + * StringInfo provides an extensible string data type. It can be used to > > It might be useful to point out the upper bound on the extensibility in the > rewrite of this sentence, and that it’s not guaranteed to be consistent between > frontend and backend. Hm. Something like 'Currently the maximum length of a StringInfo is 1GB.'? I don't really think it's worth pointing out that they may not be consistent, when they currently are... And I suspect we should just fix the length limit to be higher for both, perhaps somehow allowing to limit the length for the backend cases where we want to error out if a string gets too long (possibly adding a separate initialization API that allows to specify the memory allocation flags or such). > > I'm still using stringinfo in the aforementioned thread, and I also want > > to use it in a few more places. On the more ambitious side I really > > would like to have a minimal version of elog.h available in the backend, > > and that would really be a lot easier with stringinfo available. > > s/backend/frontend/? Indeed. Thanks for looking, Andres Freund
> On 2 Nov 2019, at 03:21, Andres Freund <andres@anarazel.de> wrote: > On 2019-11-01 23:19:33 +0100, Daniel Gustafsson wrote: >> + * StringInfo provides an extensible string data type. It can be used to >> >> It might be useful to point out the upper bound on the extensibility in the >> rewrite of this sentence, and that it’s not guaranteed to be consistent between >> frontend and backend. > > Hm. Something like 'Currently the maximum length of a StringInfo is > 1GB.’? Something along those lines (or the define/mechanism with which the upper boundary controlled, simply stating the limit seems more straightforward.) > I don't really think it's worth pointing out that they may not be > consistent, when they currently are… Good point. > And I suspect we should just fix the length limit to be higher for both, > perhaps somehow allowing to limit the length for the backend cases where > we want to error out if a string gets too long (possibly adding a > separate initialization API that allows to specify the memory allocation > flags or such). Sounds reasonable, maybe even where one can set errhint/errdetail on the “out of memory” error to get better reporting on failures. cheers ./daniel
Hi, On 2019-11-02 23:57:06 +0100, Daniel Gustafsson wrote: > > On 2 Nov 2019, at 03:21, Andres Freund <andres@anarazel.de> wrote: > > On 2019-11-01 23:19:33 +0100, Daniel Gustafsson wrote: > > >> + * StringInfo provides an extensible string data type. It can be used to > >> > >> It might be useful to point out the upper bound on the extensibility in the > >> rewrite of this sentence, and that it’s not guaranteed to be consistent between > >> frontend and backend. > > > > Hm. Something like 'Currently the maximum length of a StringInfo is > > 1GB.’? > > Something along those lines (or the define/mechanism with which the upper > boundary controlled, simply stating the limit seems more straightforward.) Pushed now, with a variation of my suggestion above. As nobody commented on that, I've not adjusted the location of stringinfo.h. If somebody has feelings about it being in the wrong place, and whether to put a redirecting header in place, or whether to just break extensions using stringinfo, ... > > And I suspect we should just fix the length limit to be higher for both, > > perhaps somehow allowing to limit the length for the backend cases where > > we want to error out if a string gets too long (possibly adding a > > separate initialization API that allows to specify the memory allocation > > flags or such). > > Sounds reasonable, maybe even where one can set errhint/errdetail on the “out > of memory” error to get better reporting on failures. That seems too much customization for the caller / too much added complexity, for the little gain it'd provide. Normally if a caller wants something like that, they can push something onto the error context stack, and get context information out that way. Greetings, Andres Freund