I wrote:
> That seems like the appropriate answer to me. I verified that we
> build cleanly and pass check-world against 1.4.0, and later I'm
> going to set up BF member longfin to use that.
Done ...
> In short, I think we should push Justin's version-check patch,
> and also fix the SGML docs
On Thu, Mar 31, 2022 at 09:10:00PM -0400, Tom Lane wrote:
> In short, I think we should push Justin's version-check patch,
> and also fix the SGML docs to say that we require zstd >= 1.4.0.
1.4.0 was released in April 2019, just 3 years ago. It does not sound
that bad to me to make this version
Robert Haas writes:
> On Thu, Mar 31, 2022 at 7:38 PM Tom Lane wrote:
>> Indeed. I tried building against 1.3.6 (mainly because it was laying
>> around) and the error reported by Devrim is just the tip of the iceberg.
>> ...
>> I wonder whether Robert's ambition to be compatible with old
On Thu, Mar 31, 2022 at 7:38 PM Tom Lane wrote:
> Indeed. I tried building against 1.3.6 (mainly because it was laying
> around) and the error reported by Devrim is just the tip of the iceberg.
> With "make -k", I see unknown-symbol failures on
>
> ZSTD_CCtx_setParameter
>
Justin Pryzby writes:
> On Thu, Mar 31, 2022 at 11:44:40AM -0400, Tom Lane wrote:
>> In view of 51c0d186d ("Allow parallel zstd compression"), I agree
>> that some clarity about the minimum supported version of zstd
>> seems essential. I don't want to be dealing with threading bugs
>> in ancient
On Thu, Mar 31, 2022 at 11:44:40AM -0400, Tom Lane wrote:
> Justin Pryzby writes:
> > Possible responses look like:
> > - Use 0 which also means "default" (need to verify that works across
> > versions);
> > - Or #ifndef ZSTD_CLEVEL_DEFAULT #define ZSTD_CLEVEL_DEFAULT 3;
> > - Add a test for
On Thu, Mar 31, 2022 at 12:37 PM Tom Lane wrote:
> Hm. After rereading 51c0d186d I see that we're not asking for
> parallel compression unless the user tells us to, so I guess
> our fallback answer for any complaints in that area can be
> "if it hurts, don't do it".
Right. We can also tell
Robert Haas writes:
> On Thu, Mar 31, 2022 at 11:44 AM Tom Lane wrote:
>> In view of 51c0d186d ("Allow parallel zstd compression"), I agree
>> that some clarity about the minimum supported version of zstd
>> seems essential. I don't want to be dealing with threading bugs
>> in ancient zstd
On Thu, Mar 31, 2022 at 12:26:46PM -0400, Robert Haas wrote:
> On Thu, Mar 31, 2022 at 11:44 AM Tom Lane wrote:
> > Justin Pryzby writes:
> > > Possible responses look like:
> > > - Use 0 which also means "default" (need to verify that works across
> > > versions);
> > > - Or #ifndef
On Thu, Mar 31, 2022 at 11:44 AM Tom Lane wrote:
> Justin Pryzby writes:
> > Possible responses look like:
> > - Use 0 which also means "default" (need to verify that works across
> > versions);
> > - Or #ifndef ZSTD_CLEVEL_DEFAULT #define ZSTD_CLEVEL_DEFAULT 3;
> > - Add a test for a
Justin Pryzby writes:
> Possible responses look like:
> - Use 0 which also means "default" (need to verify that works across
> versions);
> - Or #ifndef ZSTD_CLEVEL_DEFAULT #define ZSTD_CLEVEL_DEFAULT 3;
> - Add a test for a minimum zstd version v1.3.7. This may be a good idea for
>v15
On Thu, Mar 31, 2022 at 03:38:39PM +0100, Devrim Gündüz wrote:
> On Thu, 2022-03-31 at 10:26 -0400, Tom Lane wrote:
> > Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= writes:
> > > Latest snapshot tarball fails to build on SLES 12.5, which uses GCC
> > > 4.8-8. Build log is attached.
> >
> > Hmm, what
12 matches
Mail list logo
