Horton

Re: Security lessons from liblzma

Jelte Fennema-Nio <postgres@jeltef.nl>

View thread
From: Jelte Fennema-Nio <postgres@jeltef.nl>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, Peter Eisentraut <peter@eisentraut.org>, Andres Freund <andres@anarazel.de>, Bruce Momjian <bruce@momjian.us>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2024-04-04T21:02:38Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Introduce a non-recursive JSON parser

On Thu, 4 Apr 2024 at 22:56, Daniel Gustafsson <daniel@yesql.se> wrote:
>
> > On 4 Apr 2024, at 22:47, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >
> > Robert Haas <robertmhaas@gmail.com> writes:
> >> On Thu, Apr 4, 2024 at 4:25 PM Daniel Gustafsson <daniel@yesql.se> wrote:
> >>> I don't disagree, like I said that very email: it's non-trivial and I wish we
> >>> could make it better somehow, but I don't hav an abundance of good ideas.
> >
> >> Is the basic issue that we can't rely on the necessary toolchain to be
> >> present on every machine where someone might try to build PostgreSQL?
> >
> > IIUC, it's not really that, but that regenerating these files is
> > expensive; multiple seconds even on fast machines.  Putting that
> > into tests that are run many times a day is unappetizing.
>
> That's one aspect of it.  We could cache the results of course to amortize the
> cost over multiple test-runs but at the end of the day it will add time to
> test-runs regardless of what we do.

How about we make it meson/make targets, so they are simply cached
just like any of our other build artefacts are cached. Then only clean
builds are impacted, not every test run.