public inbox for [email protected]
help / color / mirror / Atom feed[PATCH 8/8] default to --with-lz4
6+ messages / 3 participants
[nested] [flat]
* [PATCH 8/8] default to --with-lz4
@ 2021-03-10 09:14 Dilip Kumar <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Dilip Kumar @ 2021-03-10 09:14 UTC (permalink / raw)
this is meant to excercize the new feature in the CIs, and not meant to be merged
---
configure | 6 ++++--
configure.ac | 4 ++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/configure b/configure
index 440d1e8ce5..b411ed1cb4 100755
--- a/configure
+++ b/configure
@@ -1575,7 +1575,7 @@ Optional Packages:
--with-system-tzdata=DIR
use system time zone data in DIR
--without-zlib do not use Zlib
- --with-lz4 build with LZ4 support
+ --without-lz4 build without LZ4 support
--with-gnu-ld assume the C compiler uses GNU ld [default=no]
--with-ssl=LIB use LIB for SSL/TLS support (openssl)
--with-openssl obsolete spelling of --with-ssl=openssl
@@ -8598,7 +8598,9 @@ $as_echo "#define USE_LZ4 1" >>confdefs.h
esac
else
- with_lz4=no
+ with_lz4=yes
+
+$as_echo "#define USE_LZ4 1" >>confdefs.h
fi
diff --git a/configure.ac b/configure.ac
index 780791ae8a..392784d55c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -990,8 +990,8 @@ AC_SUBST(with_zlib)
# LZ4
#
AC_MSG_CHECKING([whether to build with LZ4 support])
-PGAC_ARG_BOOL(with, lz4, no, [build with LZ4 support],
- [AC_DEFINE([USE_LZ4], 1, [Define to 1 to build with LZ4 support. (--with-lz4)])])
+PGAC_ARG_BOOL(with, lz4, yes, [build without LZ4 support],
+ [AC_DEFINE([USE_LZ4], 1, [Define to 1 to build without LZ4 support. (--without-lz4)])])
AC_MSG_RESULT([$with_lz4])
AC_SUBST(with_lz4)
--
2.17.0
--C94crkcyjafcjHxo--
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: pg_basebackup check vs Windows file path limits
@ 2023-07-03 14:12 Andrew Dunstan <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Dunstan @ 2023-07-03 14:12 UTC (permalink / raw)
To: pgsql-hackers
On 2023-07-02 Su 09:15, Andrew Dunstan wrote:
>
> The buildfarm animal fairywren has been failing the tests for
> pg_basebackup because it can't create a file with a path longer than
> 255 chars. This has just been tripped because for release 16 it's
> running TAP tests, and the branch name is part of the file path, and
> "REL_16_STABLE" is longer than "HEAD". I did think of chdir'ing into
> the directory to create the file, but experimentation shows that
> doesn't solve matters. I also adjusted the machine's settings related
> to long file names, but to no avail, so for now I propose to reduce
> slightly the name of the long file so it still exercises the check for
> file names longer than 100 but doesn't trip this up on fairywren. But
> that's a bandaid. I don't have a good solution for now.
>
I've pushed a better solution, which creates the file via a short
symlink. Experimentation on fairywren showed this working.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: pg_basebackup check vs Windows file path limits
@ 2023-07-03 14:16 Daniel Gustafsson <[email protected]>
parent: Andrew Dunstan <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Daniel Gustafsson @ 2023-07-03 14:16 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; +Cc: pgsql-hackers
> On 3 Jul 2023, at 16:12, Andrew Dunstan <[email protected]> wrote:
> I've pushed a better solution, which creates the file via a short symlink. Experimentation on fairywren showed this working.
The buildfarm seems a tad upset after this?
--
Daniel Gustafsson
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: pg_basebackup check vs Windows file path limits
@ 2023-07-03 15:18 Andrew Dunstan <[email protected]>
parent: Daniel Gustafsson <[email protected]>
0 siblings, 2 replies; 6+ messages in thread
From: Andrew Dunstan @ 2023-07-03 15:18 UTC (permalink / raw)
To: Daniel Gustafsson <[email protected]>; +Cc: pgsql-hackers
On 2023-07-03 Mo 10:16, Daniel Gustafsson wrote:
>> On 3 Jul 2023, at 16:12, Andrew Dunstan<[email protected]> wrote:
>> I've pushed a better solution, which creates the file via a short symlink. Experimentation on fairywren showed this working.
> The buildfarm seems a tad upset after this?
>
Yeah :-(
I think it should be fixing itself now.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: pg_basebackup check vs Windows file path limits
@ 2023-07-03 15:19 Daniel Gustafsson <[email protected]>
parent: Andrew Dunstan <[email protected]>
1 sibling, 0 replies; 6+ messages in thread
From: Daniel Gustafsson @ 2023-07-03 15:19 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; +Cc: pgsql-hackers
> On 3 Jul 2023, at 17:18, Andrew Dunstan <[email protected]> wrote:
> On 2023-07-03 Mo 10:16, Daniel Gustafsson wrote:
>>> On 3 Jul 2023, at 16:12, Andrew Dunstan <[email protected]>
>>> wrote:
>>>
>>> I've pushed a better solution, which creates the file via a short symlink. Experimentation on fairywren showed this working.
>>>
>> The buildfarm seems a tad upset after this?
>
> Yeah :-(
>
> I think it should be fixing itself now.
Yeah, thanks for speedy fix!
--
Daniel Gustafsson
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: pg_basebackup check vs Windows file path limits
@ 2023-07-04 18:19 Andrew Dunstan <[email protected]>
parent: Andrew Dunstan <[email protected]>
1 sibling, 0 replies; 6+ messages in thread
From: Andrew Dunstan @ 2023-07-04 18:19 UTC (permalink / raw)
To: Daniel Gustafsson <[email protected]>; +Cc: pgsql-hackers
On 2023-07-03 Mo 11:18, Andrew Dunstan wrote:
>
>
> On 2023-07-03 Mo 10:16, Daniel Gustafsson wrote:
>>> On 3 Jul 2023, at 16:12, Andrew Dunstan<[email protected]> wrote:
>>> I've pushed a better solution, which creates the file via a short symlink. Experimentation on fairywren showed this working.
>> The buildfarm seems a tad upset after this?
>>
>
> Yeah :-(
>
> I think it should be fixing itself now.
>
>
>
But sadly we're kinda back where we started. fairywren is failing on
REL_16_STABLE. Before the changes the failure occurred because the test
script was unable to create the file with a path > 255. Now that we have
a way to create the file the test for pg_basebackup to reject files with
names > 100 fails, I presume because the server can't actually see the
file. At this stage I'm thinking the best thing would be to skip the
test altogether on windows if the path is longer than 255.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2023-07-04 18:19 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-03-10 09:14 [PATCH 8/8] default to --with-lz4 Dilip Kumar <[email protected]>
2023-07-03 14:12 Re: pg_basebackup check vs Windows file path limits Andrew Dunstan <[email protected]>
2023-07-03 14:16 ` Re: pg_basebackup check vs Windows file path limits Daniel Gustafsson <[email protected]>
2023-07-03 15:18 ` Re: pg_basebackup check vs Windows file path limits Andrew Dunstan <[email protected]>
2023-07-03 15:19 ` Re: pg_basebackup check vs Windows file path limits Daniel Gustafsson <[email protected]>
2023-07-04 18:19 ` Re: pg_basebackup check vs Windows file path limits Andrew Dunstan <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox