Re: Security lessons from liblzma
От | Jelte Fennema-Nio |
---|---|
Тема | Re: Security lessons from liblzma |
Дата | |
Msg-id | CAGECzQRP9ktcv2AVjJuFeW7BL67LXFfbZxdHMS_8tYGZvsTG3g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Security lessons from liblzma (Daniel Gustafsson <daniel@yesql.se>) |
Ответы |
Re: Security lessons from liblzma
Re: Security lessons from liblzma |
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: