agora inbox for [email protected]
help / color / mirror / Atom feedOngoing issues with representation of empty arrays
42+ messages / 8 participants
[nested] [flat]
* Ongoing issues with representation of empty arrays
@ 2017-04-11 00:57 Andrew Gierth <[email protected]>
2017-04-11 01:48 ` Re: Ongoing issues with representation of empty arrays David G. Johnston <[email protected]>
2017-04-11 03:50 ` Re: Ongoing issues with representation of empty arrays Tom Lane <[email protected]>
2017-04-19 20:10 ` Re: Ongoing issues with representation of empty arrays David G. Johnston <[email protected]>
0 siblings, 3 replies; 42+ messages in thread
From: Andrew Gierth @ 2017-04-11 00:57 UTC (permalink / raw)
To: pgsql-hackers
The distinction between the standard representation of '{}' as an array
with zero dimensions and nonstandard representations as a 1-dimensional
array with zero elements has come up in a couple of contexts on the IRC
channel recently.
First is contrib/intarray, _AGAIN_ (see past bugs such as #7730):
select array_dims(('{1,2}'::integer[] & '{3}'));
array_dims
------------
[1:0]
(1 row)
regression=# select ('{1,2}'::integer[] & '{3}') = '{}';
?column?
----------
f
(1 row)
Worse, the fact that the fix for #7730 (commit c155f654) only did a
very partial job means that it's now inconsistent:
regression=# select (a - b), (a & c), (a - b) = (a & c)
from (values (array[1,2],array[1,2],array[3])) v(a,b,c);
?column? | ?column? | ?column?
----------+----------+----------
{} | {} | f
(1 row)
I plan to fix this one properly, unless anyone has any objections.
Second is aclitem[], past bug #8395 which was not really resolved; empty
ACLs are actually 1-dim arrays of length 0, and all the ACL functions
insist on that, which means that you can't call aclexplode('{}') for
example:
https://www.postgresql.org/message-id/flat/CA%2BTgmoZdDpTJDUVsgzRhoCctidUqLDyO8bdYwgLD5p8DwHtMcQ%40m...
It's much less clear what to do about this one. Thoughts?
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Ongoing issues with representation of empty arrays
2017-04-11 00:57 Ongoing issues with representation of empty arrays Andrew Gierth <[email protected]>
@ 2017-04-11 01:48 ` David G. Johnston <[email protected]>
2 siblings, 0 replies; 42+ messages in thread
From: David G. Johnston @ 2017-04-11 01:48 UTC (permalink / raw)
To: Andrew Gierth <[email protected]>; +Cc: pgsql-hackers
On Mon, Apr 10, 2017 at 5:57 PM, Andrew Gierth <[email protected]>
wrote:
> Second is aclitem[], past bug #8395 which was not really resolved; empty
> ACLs are actually 1-dim arrays of length 0, and all the ACL functions
> insist on that, which means that you can't call aclexplode('{}') for
> example:
>
> https://www.postgresql.org/message-id/flat/CA%
> 2BTgmoZdDpTJDUVsgzRhoCctidUqLDyO8bdYwgLD5p8DwHtMcQ%40mail.gmail.com
>
> It's much less clear what to do about this one. Thoughts?
>
After a quick Google search to get a feel for the landscape...
At a high level the Access Control System is a high-risk area - it seems
like the above anomaly doesn't outweigh the risk of slogging through and
changing the mechanics. But maybe I'm being overly paranoid in my
inexperience...
The question I'd have is whether people are doing '{}'::aclitem[] out of
habit or because there is no other way, in SQL, to generate an empty ACL
array? If its the later we probably should supply one even if its not
documented for external use; none of these other functions are.
I.e., a no-arg "newacl" function where: array_length(newacl(), 1) => 0
IOW - the response to Bug # 8395 is to make #3 workable with the correct
syntax. That #2 would continue to return false is maybe annoying but
unless we are prepared (and capable) of making '{}'::aclitem[] an error I
don't see that we should worry about it.
David J.
p.s. A side question is whether a handful of reports and a couple of PGXN
extensions suggest that we should consider user-facing documenting some of
these things.
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Ongoing issues with representation of empty arrays
2017-04-11 00:57 Ongoing issues with representation of empty arrays Andrew Gierth <[email protected]>
@ 2017-04-11 03:50 ` Tom Lane <[email protected]>
2017-04-11 04:17 ` Re: Ongoing issues with representation of empty arrays Andrew Gierth <[email protected]>
2 siblings, 1 reply; 42+ messages in thread
From: Tom Lane @ 2017-04-11 03:50 UTC (permalink / raw)
To: Andrew Gierth <[email protected]>; +Cc: pgsql-hackers
Andrew Gierth <[email protected]> writes:
> The distinction between the standard representation of '{}' as an array
> with zero dimensions and nonstandard representations as a 1-dimensional
> array with zero elements has come up in a couple of contexts on the IRC
> channel recently.
> First is contrib/intarray, _AGAIN_ (see past bugs such as #7730):
> ...
> I plan to fix this one properly, unless anyone has any objections.
Just to clarify, what do you think is "properly"?
> Second is aclitem[], past bug #8395 which was not really resolved; empty
> ACLs are actually 1-dim arrays of length 0, and all the ACL functions
> insist on that, which means that you can't call aclexplode('{}') for
> example:
> It's much less clear what to do about this one. Thoughts?
My instinct is to be conservative in what you send and liberal in what you
accept. In this context that would probably mean fixing aclitem-related
functions to accept both 0-dimensional and 1-dimensional-0-length inputs.
(Actually, is there a reason to be picky about the input dimensionality at
all, rather than just iterating over whatever the array contents are?)
Also, if we've got any functions that create aclitem[] values, fix them to
generate the standard representation of empty arrays.
regards, tom lane
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Ongoing issues with representation of empty arrays
2017-04-11 00:57 Ongoing issues with representation of empty arrays Andrew Gierth <[email protected]>
2017-04-11 03:50 ` Re: Ongoing issues with representation of empty arrays Tom Lane <[email protected]>
@ 2017-04-11 04:17 ` Andrew Gierth <[email protected]>
2017-04-19 20:36 ` Re: Ongoing issues with representation of empty arrays Merlin Moncure <[email protected]>
0 siblings, 1 reply; 42+ messages in thread
From: Andrew Gierth @ 2017-04-11 04:17 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: pgsql-hackers
>>>>> "Tom" == Tom Lane <[email protected]> writes:
>> First is contrib/intarray, _AGAIN_ (see past bugs such as #7730):
>> ...
>> I plan to fix this one properly, unless anyone has any objections.
Tom> Just to clarify, what do you think is "properly"?
I would say, that any time an intarray function returns an empty result
it should be the standard 0-dimensional representation that every other
array operation uses. The intarray functions all seem already able to
take such values as inputs. Also there should be regression tests for
this (none of intarray's existing tests have any empty arrays at all).
>> Second is aclitem[], past bug #8395 which was not really resolved; empty
>> ACLs are actually 1-dim arrays of length 0, and all the ACL functions
>> insist on that, which means that you can't call aclexplode('{}') for
>> example:
>> It's much less clear what to do about this one. Thoughts?
Tom> My instinct is to be conservative in what you send and liberal in
Tom> what you accept. In this context that would probably mean fixing
Tom> aclitem-related functions to accept both 0-dimensional and
Tom> 1-dimensional-0-length inputs.
Tom> (Actually, is there a reason to be picky about the input
Tom> dimensionality at all, rather than just iterating over whatever
Tom> the array contents are?)
Currently there is this:
#define ACL_NUM(ACL) (ARR_DIMS(ACL)[0])
which is obviously wrong for dimensions other than exactly 1. I don't
_think_ there's any great obstacle to fixing this; the only code that
would care about number of dimensions would be allocacl, and since
there'd be no obvious reason to preserve the shape of an aclitem[]
anywhere, that could just do 0 or 1 dimensions.
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Ongoing issues with representation of empty arrays
2017-04-11 00:57 Ongoing issues with representation of empty arrays Andrew Gierth <[email protected]>
2017-04-11 03:50 ` Re: Ongoing issues with representation of empty arrays Tom Lane <[email protected]>
2017-04-11 04:17 ` Re: Ongoing issues with representation of empty arrays Andrew Gierth <[email protected]>
@ 2017-04-19 20:36 ` Merlin Moncure <[email protected]>
0 siblings, 0 replies; 42+ messages in thread
From: Merlin Moncure @ 2017-04-19 20:36 UTC (permalink / raw)
To: Andrew Gierth <[email protected]>; +Cc: Tom Lane <[email protected]>; pgsql-hackers
On Mon, Apr 10, 2017 at 11:17 PM, Andrew Gierth
<[email protected]> wrote:
>>>>>> "Tom" == Tom Lane <[email protected]> writes:
>
> >> First is contrib/intarray, _AGAIN_ (see past bugs such as #7730):
> >> ...
> >> I plan to fix this one properly, unless anyone has any objections.
>
> Tom> Just to clarify, what do you think is "properly"?
>
> I would say, that any time an intarray function returns an empty result
> it should be the standard 0-dimensional representation that every other
> array operation uses. The intarray functions all seem already able to
> take such values as inputs. Also there should be regression tests for
> this (none of intarray's existing tests have any empty arrays at all).
Are there any impacts outside of intarray?
merlin
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Ongoing issues with representation of empty arrays
2017-04-11 00:57 Ongoing issues with representation of empty arrays Andrew Gierth <[email protected]>
@ 2017-04-19 20:10 ` David G. Johnston <[email protected]>
2 siblings, 0 replies; 42+ messages in thread
From: David G. Johnston @ 2017-04-19 20:10 UTC (permalink / raw)
To: Andrew Gierth <[email protected]>; +Cc: pgsql-hackers
On Mon, Apr 10, 2017 at 4:57 PM, Andrew Gierth <[email protected]>
wrote:
> The distinction between the standard representation of '{}' as an array
> with zero dimensions and nonstandard representations as a 1-dimensional
> array with zero elements has come up in a couple of contexts on the IRC
> channel recently.
>
Just to add to the listing of annoyances.
The following makes me want some way, in SQL, to create an empty
1-dimensional array ...
SELECT array_agg(e_arr)
FROM ( VALUES (ARRAY['1']::text[]), (ARRAY[]::text[]) ) v (e_arr);
--ERROR: cannot accumulate arrays of different dimensionality
We moved the goals posts nicely with bac27394a1c but not being able to mix
empty and non-empty arrays is problematic. Ideally an empty array could
become an array of any dimension on-the-fly so that if even explicitly
dimensioned input to array_agg is 1-dimensioned then all empty arrays would
be promoted to 1-dimension and the resultant output would become two
dimensional. unnest'ing such a structure would pose its own challenges
though...
David J.
^ permalink raw reply [nested|flat] 42+ messages in thread
* [PATCH] Disable autovacuum for BRIN test table
@ 2020-08-17 20:20 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 42+ messages in thread
From: Alvaro Herrera @ 2020-08-17 20:20 UTC (permalink / raw)
This should improve stability in the tests.
Per buildfarm member hyrax (CLOBBER_CACHE_ALWAYS) via Tom Lane.
Discussion: https://postgr.es/m/[email protected]
---
src/test/regress/expected/brin.out | 2 +-
src/test/regress/sql/brin.sql | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/test/regress/expected/brin.out b/src/test/regress/expected/brin.out
index 0b14c73fc6..18403498df 100644
--- a/src/test/regress/expected/brin.out
+++ b/src/test/regress/expected/brin.out
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
substr(stringu1, 1, 1)::"char",
diff --git a/src/test/regress/sql/brin.sql b/src/test/regress/sql/brin.sql
index 1289e76ecb..d1a82474f3 100644
--- a/src/test/regress/sql/brin.sql
+++ b/src/test/regress/sql/brin.sql
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
--
2.20.1
--WIyZ46R2i8wDzkSu--
^ permalink raw reply [nested|flat] 42+ messages in thread
* [PATCH] Disable autovacuum for BRIN test table
@ 2020-08-17 20:20 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 42+ messages in thread
From: Alvaro Herrera @ 2020-08-17 20:20 UTC (permalink / raw)
This should improve stability in the tests.
Per buildfarm member hyrax (CLOBBER_CACHE_ALWAYS) via Tom Lane.
Discussion: https://postgr.es/m/[email protected]
---
src/test/regress/expected/brin.out | 2 +-
src/test/regress/sql/brin.sql | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/test/regress/expected/brin.out b/src/test/regress/expected/brin.out
index 0b14c73fc6..18403498df 100644
--- a/src/test/regress/expected/brin.out
+++ b/src/test/regress/expected/brin.out
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
substr(stringu1, 1, 1)::"char",
diff --git a/src/test/regress/sql/brin.sql b/src/test/regress/sql/brin.sql
index 1289e76ecb..d1a82474f3 100644
--- a/src/test/regress/sql/brin.sql
+++ b/src/test/regress/sql/brin.sql
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
--
2.20.1
--WIyZ46R2i8wDzkSu--
^ permalink raw reply [nested|flat] 42+ messages in thread
* [PATCH] Disable autovacuum for BRIN test table
@ 2020-08-17 20:20 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 42+ messages in thread
From: Alvaro Herrera @ 2020-08-17 20:20 UTC (permalink / raw)
This should improve stability in the tests.
Per buildfarm member hyrax (CLOBBER_CACHE_ALWAYS) via Tom Lane.
Discussion: https://postgr.es/m/[email protected]
---
src/test/regress/expected/brin.out | 2 +-
src/test/regress/sql/brin.sql | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/test/regress/expected/brin.out b/src/test/regress/expected/brin.out
index 0b14c73fc6..18403498df 100644
--- a/src/test/regress/expected/brin.out
+++ b/src/test/regress/expected/brin.out
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
substr(stringu1, 1, 1)::"char",
diff --git a/src/test/regress/sql/brin.sql b/src/test/regress/sql/brin.sql
index 1289e76ecb..d1a82474f3 100644
--- a/src/test/regress/sql/brin.sql
+++ b/src/test/regress/sql/brin.sql
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
--
2.20.1
--WIyZ46R2i8wDzkSu--
^ permalink raw reply [nested|flat] 42+ messages in thread
* [PATCH] Disable autovacuum for BRIN test table
@ 2020-08-17 20:20 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 42+ messages in thread
From: Alvaro Herrera @ 2020-08-17 20:20 UTC (permalink / raw)
This should improve stability in the tests.
Per buildfarm member hyrax (CLOBBER_CACHE_ALWAYS) via Tom Lane.
Discussion: https://postgr.es/m/[email protected]
---
src/test/regress/expected/brin.out | 2 +-
src/test/regress/sql/brin.sql | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/test/regress/expected/brin.out b/src/test/regress/expected/brin.out
index 0b14c73fc6..18403498df 100644
--- a/src/test/regress/expected/brin.out
+++ b/src/test/regress/expected/brin.out
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
substr(stringu1, 1, 1)::"char",
diff --git a/src/test/regress/sql/brin.sql b/src/test/regress/sql/brin.sql
index 1289e76ecb..d1a82474f3 100644
--- a/src/test/regress/sql/brin.sql
+++ b/src/test/regress/sql/brin.sql
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
--
2.20.1
--WIyZ46R2i8wDzkSu--
^ permalink raw reply [nested|flat] 42+ messages in thread
* [PATCH] Disable autovacuum for BRIN test table
@ 2020-08-17 20:20 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 42+ messages in thread
From: Alvaro Herrera @ 2020-08-17 20:20 UTC (permalink / raw)
This should improve stability in the tests.
Per buildfarm member hyrax (CLOBBER_CACHE_ALWAYS) via Tom Lane.
Discussion: https://postgr.es/m/[email protected]
---
src/test/regress/expected/brin.out | 2 +-
src/test/regress/sql/brin.sql | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/test/regress/expected/brin.out b/src/test/regress/expected/brin.out
index 0b14c73fc6..18403498df 100644
--- a/src/test/regress/expected/brin.out
+++ b/src/test/regress/expected/brin.out
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
substr(stringu1, 1, 1)::"char",
diff --git a/src/test/regress/sql/brin.sql b/src/test/regress/sql/brin.sql
index 1289e76ecb..d1a82474f3 100644
--- a/src/test/regress/sql/brin.sql
+++ b/src/test/regress/sql/brin.sql
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
--
2.20.1
--WIyZ46R2i8wDzkSu--
^ permalink raw reply [nested|flat] 42+ messages in thread
* [PATCH] Disable autovacuum for BRIN test table
@ 2020-08-17 20:20 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 42+ messages in thread
From: Alvaro Herrera @ 2020-08-17 20:20 UTC (permalink / raw)
This should improve stability in the tests.
Per buildfarm member hyrax (CLOBBER_CACHE_ALWAYS) via Tom Lane.
Discussion: https://postgr.es/m/[email protected]
---
src/test/regress/expected/brin.out | 2 +-
src/test/regress/sql/brin.sql | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/test/regress/expected/brin.out b/src/test/regress/expected/brin.out
index 0b14c73fc6..18403498df 100644
--- a/src/test/regress/expected/brin.out
+++ b/src/test/regress/expected/brin.out
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
substr(stringu1, 1, 1)::"char",
diff --git a/src/test/regress/sql/brin.sql b/src/test/regress/sql/brin.sql
index 1289e76ecb..d1a82474f3 100644
--- a/src/test/regress/sql/brin.sql
+++ b/src/test/regress/sql/brin.sql
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
--
2.20.1
--WIyZ46R2i8wDzkSu--
^ permalink raw reply [nested|flat] 42+ messages in thread
* [PATCH] Disable autovacuum for BRIN test table
@ 2020-08-17 20:20 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 42+ messages in thread
From: Alvaro Herrera @ 2020-08-17 20:20 UTC (permalink / raw)
This should improve stability in the tests.
Per buildfarm member hyrax (CLOBBER_CACHE_ALWAYS) via Tom Lane.
Discussion: https://postgr.es/m/[email protected]
---
src/test/regress/expected/brin.out | 2 +-
src/test/regress/sql/brin.sql | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/test/regress/expected/brin.out b/src/test/regress/expected/brin.out
index 0b14c73fc6..18403498df 100644
--- a/src/test/regress/expected/brin.out
+++ b/src/test/regress/expected/brin.out
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
substr(stringu1, 1, 1)::"char",
diff --git a/src/test/regress/sql/brin.sql b/src/test/regress/sql/brin.sql
index 1289e76ecb..d1a82474f3 100644
--- a/src/test/regress/sql/brin.sql
+++ b/src/test/regress/sql/brin.sql
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
--
2.20.1
--WIyZ46R2i8wDzkSu--
^ permalink raw reply [nested|flat] 42+ messages in thread
* [PATCH] Disable autovacuum for BRIN test table
@ 2020-08-17 20:20 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 42+ messages in thread
From: Alvaro Herrera @ 2020-08-17 20:20 UTC (permalink / raw)
This should improve stability in the tests.
Per buildfarm member hyrax (CLOBBER_CACHE_ALWAYS) via Tom Lane.
Discussion: https://postgr.es/m/[email protected]
---
src/test/regress/expected/brin.out | 2 +-
src/test/regress/sql/brin.sql | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/test/regress/expected/brin.out b/src/test/regress/expected/brin.out
index 0b14c73fc6..18403498df 100644
--- a/src/test/regress/expected/brin.out
+++ b/src/test/regress/expected/brin.out
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
substr(stringu1, 1, 1)::"char",
diff --git a/src/test/regress/sql/brin.sql b/src/test/regress/sql/brin.sql
index 1289e76ecb..d1a82474f3 100644
--- a/src/test/regress/sql/brin.sql
+++ b/src/test/regress/sql/brin.sql
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
--
2.20.1
--WIyZ46R2i8wDzkSu--
^ permalink raw reply [nested|flat] 42+ messages in thread
* [PATCH] Disable autovacuum for BRIN test table
@ 2020-08-17 20:20 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 42+ messages in thread
From: Alvaro Herrera @ 2020-08-17 20:20 UTC (permalink / raw)
This should improve stability in the tests.
Per buildfarm member hyrax (CLOBBER_CACHE_ALWAYS) via Tom Lane.
Discussion: https://postgr.es/m/[email protected]
---
src/test/regress/expected/brin.out | 2 +-
src/test/regress/sql/brin.sql | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/test/regress/expected/brin.out b/src/test/regress/expected/brin.out
index 0b14c73fc6..18403498df 100644
--- a/src/test/regress/expected/brin.out
+++ b/src/test/regress/expected/brin.out
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
substr(stringu1, 1, 1)::"char",
diff --git a/src/test/regress/sql/brin.sql b/src/test/regress/sql/brin.sql
index 1289e76ecb..d1a82474f3 100644
--- a/src/test/regress/sql/brin.sql
+++ b/src/test/regress/sql/brin.sql
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
--
2.20.1
--WIyZ46R2i8wDzkSu--
^ permalink raw reply [nested|flat] 42+ messages in thread
* [PATCH] Disable autovacuum for BRIN test table
@ 2020-08-17 20:20 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 42+ messages in thread
From: Alvaro Herrera @ 2020-08-17 20:20 UTC (permalink / raw)
This should improve stability in the tests.
Per buildfarm member hyrax (CLOBBER_CACHE_ALWAYS) via Tom Lane.
Discussion: https://postgr.es/m/[email protected]
---
src/test/regress/expected/brin.out | 2 +-
src/test/regress/sql/brin.sql | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/test/regress/expected/brin.out b/src/test/regress/expected/brin.out
index 0b14c73fc6..18403498df 100644
--- a/src/test/regress/expected/brin.out
+++ b/src/test/regress/expected/brin.out
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
substr(stringu1, 1, 1)::"char",
diff --git a/src/test/regress/sql/brin.sql b/src/test/regress/sql/brin.sql
index 1289e76ecb..d1a82474f3 100644
--- a/src/test/regress/sql/brin.sql
+++ b/src/test/regress/sql/brin.sql
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
--
2.20.1
--WIyZ46R2i8wDzkSu--
^ permalink raw reply [nested|flat] 42+ messages in thread
* [PATCH] Disable autovacuum for BRIN test table
@ 2020-08-17 20:20 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 42+ messages in thread
From: Alvaro Herrera @ 2020-08-17 20:20 UTC (permalink / raw)
This should improve stability in the tests.
Per buildfarm member hyrax (CLOBBER_CACHE_ALWAYS) via Tom Lane.
Discussion: https://postgr.es/m/[email protected]
---
src/test/regress/expected/brin.out | 2 +-
src/test/regress/sql/brin.sql | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/test/regress/expected/brin.out b/src/test/regress/expected/brin.out
index 0b14c73fc6..18403498df 100644
--- a/src/test/regress/expected/brin.out
+++ b/src/test/regress/expected/brin.out
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
substr(stringu1, 1, 1)::"char",
diff --git a/src/test/regress/sql/brin.sql b/src/test/regress/sql/brin.sql
index 1289e76ecb..d1a82474f3 100644
--- a/src/test/regress/sql/brin.sql
+++ b/src/test/regress/sql/brin.sql
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
--
2.20.1
--WIyZ46R2i8wDzkSu--
^ permalink raw reply [nested|flat] 42+ messages in thread
* [PATCH] Disable autovacuum for BRIN test table
@ 2020-08-17 20:20 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 42+ messages in thread
From: Alvaro Herrera @ 2020-08-17 20:20 UTC (permalink / raw)
This should improve stability in the tests.
Per buildfarm member hyrax (CLOBBER_CACHE_ALWAYS) via Tom Lane.
Discussion: https://postgr.es/m/[email protected]
---
src/test/regress/expected/brin.out | 2 +-
src/test/regress/sql/brin.sql | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/test/regress/expected/brin.out b/src/test/regress/expected/brin.out
index 0b14c73fc6..18403498df 100644
--- a/src/test/regress/expected/brin.out
+++ b/src/test/regress/expected/brin.out
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
substr(stringu1, 1, 1)::"char",
diff --git a/src/test/regress/sql/brin.sql b/src/test/regress/sql/brin.sql
index 1289e76ecb..d1a82474f3 100644
--- a/src/test/regress/sql/brin.sql
+++ b/src/test/regress/sql/brin.sql
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
--
2.20.1
--WIyZ46R2i8wDzkSu--
^ permalink raw reply [nested|flat] 42+ messages in thread
* [PATCH] Disable autovacuum for BRIN test table
@ 2020-08-17 20:20 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 42+ messages in thread
From: Alvaro Herrera @ 2020-08-17 20:20 UTC (permalink / raw)
This should improve stability in the tests.
Per buildfarm member hyrax (CLOBBER_CACHE_ALWAYS) via Tom Lane.
Discussion: https://postgr.es/m/[email protected]
---
src/test/regress/expected/brin.out | 2 +-
src/test/regress/sql/brin.sql | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/test/regress/expected/brin.out b/src/test/regress/expected/brin.out
index 0b14c73fc6..18403498df 100644
--- a/src/test/regress/expected/brin.out
+++ b/src/test/regress/expected/brin.out
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
substr(stringu1, 1, 1)::"char",
diff --git a/src/test/regress/sql/brin.sql b/src/test/regress/sql/brin.sql
index 1289e76ecb..d1a82474f3 100644
--- a/src/test/regress/sql/brin.sql
+++ b/src/test/regress/sql/brin.sql
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
--
2.20.1
--WIyZ46R2i8wDzkSu--
^ permalink raw reply [nested|flat] 42+ messages in thread
* [PATCH] Disable autovacuum for BRIN test table
@ 2020-08-17 20:20 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 42+ messages in thread
From: Alvaro Herrera @ 2020-08-17 20:20 UTC (permalink / raw)
This should improve stability in the tests.
Per buildfarm member hyrax (CLOBBER_CACHE_ALWAYS) via Tom Lane.
Discussion: https://postgr.es/m/[email protected]
---
src/test/regress/expected/brin.out | 2 +-
src/test/regress/sql/brin.sql | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/test/regress/expected/brin.out b/src/test/regress/expected/brin.out
index 0b14c73fc6..18403498df 100644
--- a/src/test/regress/expected/brin.out
+++ b/src/test/regress/expected/brin.out
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
substr(stringu1, 1, 1)::"char",
diff --git a/src/test/regress/sql/brin.sql b/src/test/regress/sql/brin.sql
index 1289e76ecb..d1a82474f3 100644
--- a/src/test/regress/sql/brin.sql
+++ b/src/test/regress/sql/brin.sql
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
--
2.20.1
--WIyZ46R2i8wDzkSu--
^ permalink raw reply [nested|flat] 42+ messages in thread
* [PATCH] Disable autovacuum for BRIN test table
@ 2020-08-17 20:20 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 42+ messages in thread
From: Alvaro Herrera @ 2020-08-17 20:20 UTC (permalink / raw)
This should improve stability in the tests.
Per buildfarm member hyrax (CLOBBER_CACHE_ALWAYS) via Tom Lane.
Discussion: https://postgr.es/m/[email protected]
---
src/test/regress/expected/brin.out | 2 +-
src/test/regress/sql/brin.sql | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/test/regress/expected/brin.out b/src/test/regress/expected/brin.out
index 0b14c73fc6..18403498df 100644
--- a/src/test/regress/expected/brin.out
+++ b/src/test/regress/expected/brin.out
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
substr(stringu1, 1, 1)::"char",
diff --git a/src/test/regress/sql/brin.sql b/src/test/regress/sql/brin.sql
index 1289e76ecb..d1a82474f3 100644
--- a/src/test/regress/sql/brin.sql
+++ b/src/test/regress/sql/brin.sql
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
--
2.20.1
--WIyZ46R2i8wDzkSu--
^ permalink raw reply [nested|flat] 42+ messages in thread
* [PATCH] Disable autovacuum for BRIN test table
@ 2020-08-17 20:20 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 42+ messages in thread
From: Alvaro Herrera @ 2020-08-17 20:20 UTC (permalink / raw)
This should improve stability in the tests.
Per buildfarm member hyrax (CLOBBER_CACHE_ALWAYS) via Tom Lane.
Discussion: https://postgr.es/m/[email protected]
---
src/test/regress/expected/brin.out | 2 +-
src/test/regress/sql/brin.sql | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/test/regress/expected/brin.out b/src/test/regress/expected/brin.out
index 0b14c73fc6..18403498df 100644
--- a/src/test/regress/expected/brin.out
+++ b/src/test/regress/expected/brin.out
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
substr(stringu1, 1, 1)::"char",
diff --git a/src/test/regress/sql/brin.sql b/src/test/regress/sql/brin.sql
index 1289e76ecb..d1a82474f3 100644
--- a/src/test/regress/sql/brin.sql
+++ b/src/test/regress/sql/brin.sql
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
--
2.20.1
--WIyZ46R2i8wDzkSu--
^ permalink raw reply [nested|flat] 42+ messages in thread
* [PATCH] Disable autovacuum for BRIN test table
@ 2020-08-17 20:20 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 42+ messages in thread
From: Alvaro Herrera @ 2020-08-17 20:20 UTC (permalink / raw)
This should improve stability in the tests.
Per buildfarm member hyrax (CLOBBER_CACHE_ALWAYS) via Tom Lane.
Discussion: https://postgr.es/m/[email protected]
---
src/test/regress/expected/brin.out | 2 +-
src/test/regress/sql/brin.sql | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/test/regress/expected/brin.out b/src/test/regress/expected/brin.out
index 0b14c73fc6..18403498df 100644
--- a/src/test/regress/expected/brin.out
+++ b/src/test/regress/expected/brin.out
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
substr(stringu1, 1, 1)::"char",
diff --git a/src/test/regress/sql/brin.sql b/src/test/regress/sql/brin.sql
index 1289e76ecb..d1a82474f3 100644
--- a/src/test/regress/sql/brin.sql
+++ b/src/test/regress/sql/brin.sql
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
--
2.20.1
--WIyZ46R2i8wDzkSu--
^ permalink raw reply [nested|flat] 42+ messages in thread
* [PATCH] Disable autovacuum for BRIN test table
@ 2020-08-17 20:20 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 42+ messages in thread
From: Alvaro Herrera @ 2020-08-17 20:20 UTC (permalink / raw)
This should improve stability in the tests.
Per buildfarm member hyrax (CLOBBER_CACHE_ALWAYS) via Tom Lane.
Discussion: https://postgr.es/m/[email protected]
---
src/test/regress/expected/brin.out | 2 +-
src/test/regress/sql/brin.sql | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/test/regress/expected/brin.out b/src/test/regress/expected/brin.out
index 0b14c73fc6..18403498df 100644
--- a/src/test/regress/expected/brin.out
+++ b/src/test/regress/expected/brin.out
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
substr(stringu1, 1, 1)::"char",
diff --git a/src/test/regress/sql/brin.sql b/src/test/regress/sql/brin.sql
index 1289e76ecb..d1a82474f3 100644
--- a/src/test/regress/sql/brin.sql
+++ b/src/test/regress/sql/brin.sql
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
--
2.20.1
--WIyZ46R2i8wDzkSu--
^ permalink raw reply [nested|flat] 42+ messages in thread
* [PATCH] Disable autovacuum for BRIN test table
@ 2020-08-17 20:20 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 42+ messages in thread
From: Alvaro Herrera @ 2020-08-17 20:20 UTC (permalink / raw)
This should improve stability in the tests.
Per buildfarm member hyrax (CLOBBER_CACHE_ALWAYS) via Tom Lane.
Discussion: https://postgr.es/m/[email protected]
---
src/test/regress/expected/brin.out | 2 +-
src/test/regress/sql/brin.sql | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/test/regress/expected/brin.out b/src/test/regress/expected/brin.out
index 0b14c73fc6..18403498df 100644
--- a/src/test/regress/expected/brin.out
+++ b/src/test/regress/expected/brin.out
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
substr(stringu1, 1, 1)::"char",
diff --git a/src/test/regress/sql/brin.sql b/src/test/regress/sql/brin.sql
index 1289e76ecb..d1a82474f3 100644
--- a/src/test/regress/sql/brin.sql
+++ b/src/test/regress/sql/brin.sql
@@ -26,7 +26,7 @@ CREATE TABLE brintest (byteacol bytea,
int4rangecol int4range,
lsncol pg_lsn,
boxcol box
-) WITH (fillfactor=10);
+) WITH (fillfactor=10, autovacuum_enabled=off);
INSERT INTO brintest SELECT
repeat(stringu1, 8)::bytea,
--
2.20.1
--WIyZ46R2i8wDzkSu--
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Estimating HugePages Requirements?
@ 2022-03-15 22:44 Nathan Bossart <[email protected]>
2022-03-21 22:12 ` Re: Estimating HugePages Requirements? Nathan Bossart <[email protected]>
2022-03-23 06:25 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
0 siblings, 2 replies; 42+ messages in thread
From: Nathan Bossart @ 2022-03-15 22:44 UTC (permalink / raw)
To: Magnus Hagander <[email protected]>; +Cc: Michael Paquier <[email protected]>; Bossart, Nathan <[email protected]>; Fujii Masao <[email protected]>; Justin Pryzby <[email protected]>; Andres Freund <[email protected]>; Mark Dilger <[email protected]>; Don Seiler <[email protected]>; pgsql-hackers
On Tue, Mar 15, 2022 at 11:02:37PM +0100, Magnus Hagander wrote:
> I think we're talking about two different things here.
>
> I think the "avoid extra logging" would be worth seeing if we can
> address for 15.
A simple approach could be to just set log_min_messages to PANIC before
exiting. I've attached a patch for this. With this patch, we'll still see
a FATAL if we try to use 'postgres -C' for a runtime-computed GUC on a
running server, and there will be no extra output as long as the user sets
log_min_messages to INFO or higher (i.e., not a DEBUG* value). For
comparison, 'postgres -C' for a non-runtime-computed GUC does not emit
extra output as long as the user sets log_min_messages to DEBUG2 or higher.
> The "able to run on a live cluster" seems a lot bigger and more scary
> and not 15 material.
+1
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Attachments:
[text/x-diff] v2-0001-don-t-emit-shutdown-messages-for-postgres-C-with-.patch (841B, ../../20220315224439.GA1133771@nathanxps13/2-v2-0001-don-t-emit-shutdown-messages-for-postgres-C-with-.patch)
download | inline diff:
From cdfd1ad00ca1d8afbfcbafc1f684b5ba9cc43eb6 Mon Sep 17 00:00:00 2001
From: Nathan Bossart <[email protected]>
Date: Tue, 15 Mar 2022 15:36:41 -0700
Subject: [PATCH v2 1/1] don't emit shutdown messages for 'postgres -C' with
runtime-computed GUCs
---
src/backend/postmaster/postmaster.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c
index 80bb269599..bf48bc6326 100644
--- a/src/backend/postmaster/postmaster.c
+++ b/src/backend/postmaster/postmaster.c
@@ -1066,6 +1066,10 @@ PostmasterMain(int argc, char *argv[])
false, false);
puts(config_val ? config_val : "");
+
+ /* don't emit shutdown messages */
+ SetConfigOption("log_min_messages", "PANIC", PGC_INTERNAL, PGC_S_OVERRIDE);
+
ExitPostmaster(0);
}
--
2.25.1
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Estimating HugePages Requirements?
2022-03-15 22:44 Re: Estimating HugePages Requirements? Nathan Bossart <[email protected]>
@ 2022-03-21 22:12 ` Nathan Bossart <[email protected]>
1 sibling, 0 replies; 42+ messages in thread
From: Nathan Bossart @ 2022-03-21 22:12 UTC (permalink / raw)
To: Magnus Hagander <[email protected]>; +Cc: Michael Paquier <[email protected]>; Bossart, Nathan <[email protected]>; Fujii Masao <[email protected]>; Justin Pryzby <[email protected]>; Andres Freund <[email protected]>; Mark Dilger <[email protected]>; Don Seiler <[email protected]>; pgsql-hackers
On Tue, Mar 15, 2022 at 03:44:39PM -0700, Nathan Bossart wrote:
> A simple approach could be to just set log_min_messages to PANIC before
> exiting. I've attached a patch for this. With this patch, we'll still see
> a FATAL if we try to use 'postgres -C' for a runtime-computed GUC on a
> running server, and there will be no extra output as long as the user sets
> log_min_messages to INFO or higher (i.e., not a DEBUG* value). For
> comparison, 'postgres -C' for a non-runtime-computed GUC does not emit
> extra output as long as the user sets log_min_messages to DEBUG2 or higher.
I created a commitfest entry for this:
https://commitfest.postgresql.org/38/3596/
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Estimating HugePages Requirements?
2022-03-15 22:44 Re: Estimating HugePages Requirements? Nathan Bossart <[email protected]>
@ 2022-03-23 06:25 ` Michael Paquier <[email protected]>
2022-03-24 12:10 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-03-24 13:07 ` Re: Estimating HugePages Requirements? Magnus Hagander <[email protected]>
1 sibling, 2 replies; 42+ messages in thread
From: Michael Paquier @ 2022-03-23 06:25 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: Magnus Hagander <[email protected]>; Bossart, Nathan <[email protected]>; Fujii Masao <[email protected]>; Justin Pryzby <[email protected]>; Andres Freund <[email protected]>; Mark Dilger <[email protected]>; Don Seiler <[email protected]>; pgsql-hackers
On Tue, Mar 15, 2022 at 03:44:39PM -0700, Nathan Bossart wrote:
> A simple approach could be to just set log_min_messages to PANIC before
> exiting. I've attached a patch for this. With this patch, we'll still see
> a FATAL if we try to use 'postgres -C' for a runtime-computed GUC on a
> running server, and there will be no extra output as long as the user sets
> log_min_messages to INFO or higher (i.e., not a DEBUG* value). For
> comparison, 'postgres -C' for a non-runtime-computed GUC does not emit
> extra output as long as the user sets log_min_messages to DEBUG2 or higher.
> puts(config_val ? config_val : "");
> +
> + /* don't emit shutdown messages */
> + SetConfigOption("log_min_messages", "PANIC", PGC_INTERNAL, PGC_S_OVERRIDE);
> +
> ExitPostmaster(0);
That's fancy, but I don't like that much. And this would not protect
either against any messages generated before this code path, either,
even if that should be enough for the current HEAD .
My solution for the docs is perhaps too confusing for the end-user,
and we are talking about a Linux-only thing here anyway. So, at the
end, I am tempted to just add the "2> /dev/null" as suggested upthread
by Nathan and call it a day. Does that sound fine?
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Estimating HugePages Requirements?
2022-03-15 22:44 Re: Estimating HugePages Requirements? Nathan Bossart <[email protected]>
2022-03-23 06:25 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
@ 2022-03-24 12:10 ` Michael Paquier <[email protected]>
1 sibling, 0 replies; 42+ messages in thread
From: Michael Paquier @ 2022-03-24 12:10 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: Magnus Hagander <[email protected]>; Bossart, Nathan <[email protected]>; Fujii Masao <[email protected]>; Justin Pryzby <[email protected]>; Andres Freund <[email protected]>; Mark Dilger <[email protected]>; Don Seiler <[email protected]>; pgsql-hackers
On Wed, Mar 23, 2022 at 03:25:48PM +0900, Michael Paquier wrote:
> My solution for the docs is perhaps too confusing for the end-user,
> and we are talking about a Linux-only thing here anyway. So, at the
> end, I am tempted to just add the "2> /dev/null" as suggested upthread
> by Nathan and call it a day.
This still sounds like the best way to go for now, so done this way as
of bbd4951.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Estimating HugePages Requirements?
2022-03-15 22:44 Re: Estimating HugePages Requirements? Nathan Bossart <[email protected]>
2022-03-23 06:25 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
@ 2022-03-24 13:07 ` Magnus Hagander <[email protected]>
2022-03-24 20:31 ` Re: Estimating HugePages Requirements? Nathan Bossart <[email protected]>
2022-04-19 22:12 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
1 sibling, 2 replies; 42+ messages in thread
From: Magnus Hagander @ 2022-03-24 13:07 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Nathan Bossart <[email protected]>; Bossart, Nathan <[email protected]>; Fujii Masao <[email protected]>; Justin Pryzby <[email protected]>; Andres Freund <[email protected]>; Mark Dilger <[email protected]>; Don Seiler <[email protected]>; pgsql-hackers
On Wed, Mar 23, 2022 at 7:25 AM Michael Paquier <[email protected]> wrote:
>
> On Tue, Mar 15, 2022 at 03:44:39PM -0700, Nathan Bossart wrote:
> > A simple approach could be to just set log_min_messages to PANIC before
> > exiting. I've attached a patch for this. With this patch, we'll still see
> > a FATAL if we try to use 'postgres -C' for a runtime-computed GUC on a
> > running server, and there will be no extra output as long as the user sets
> > log_min_messages to INFO or higher (i.e., not a DEBUG* value). For
> > comparison, 'postgres -C' for a non-runtime-computed GUC does not emit
> > extra output as long as the user sets log_min_messages to DEBUG2 or higher.
>
> > puts(config_val ? config_val : "");
> > +
> > + /* don't emit shutdown messages */
> > + SetConfigOption("log_min_messages", "PANIC", PGC_INTERNAL, PGC_S_OVERRIDE);
> > +
> > ExitPostmaster(0);
>
> That's fancy, but I don't like that much. And this would not protect
> either against any messages generated before this code path, either,
But neither would the suggestion of redirecting stderr to /dev/null.
In fact, doing the redirect it will *also* throw away any FATAL that
happens. In fact, using the 2>/dev/null method, we *also* remove the
message that says there's another postmaster running in this
directory, which is strictly worse than the override of
log_min_messages.
That said, the redirect can be removed without recompiling postgres,
so it is probably still hte better choice as a temporary workaround.
But we should really look into getting a better solution in place once
we start on 16.
> My solution for the docs is perhaps too confusing for the end-user,
> and we are talking about a Linux-only thing here anyway. So, at the
> end, I am tempted to just add the "2> /dev/null" as suggested upthread
> by Nathan and call it a day. Does that sound fine?
What would be a linux only thing?
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Estimating HugePages Requirements?
2022-03-15 22:44 Re: Estimating HugePages Requirements? Nathan Bossart <[email protected]>
2022-03-23 06:25 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-03-24 13:07 ` Re: Estimating HugePages Requirements? Magnus Hagander <[email protected]>
@ 2022-03-24 20:31 ` Nathan Bossart <[email protected]>
2022-03-28 17:35 ` Re: Estimating HugePages Requirements? Nathan Bossart <[email protected]>
1 sibling, 1 reply; 42+ messages in thread
From: Nathan Bossart @ 2022-03-24 20:31 UTC (permalink / raw)
To: Magnus Hagander <[email protected]>; +Cc: Michael Paquier <[email protected]>; Bossart, Nathan <[email protected]>; Fujii Masao <[email protected]>; Justin Pryzby <[email protected]>; Andres Freund <[email protected]>; Mark Dilger <[email protected]>; Don Seiler <[email protected]>; pgsql-hackers
On Thu, Mar 24, 2022 at 02:07:26PM +0100, Magnus Hagander wrote:
> On Wed, Mar 23, 2022 at 7:25 AM Michael Paquier <[email protected]> wrote:
>> On Tue, Mar 15, 2022 at 03:44:39PM -0700, Nathan Bossart wrote:
>> > A simple approach could be to just set log_min_messages to PANIC before
>> > exiting. I've attached a patch for this. With this patch, we'll still see
>> > a FATAL if we try to use 'postgres -C' for a runtime-computed GUC on a
>> > running server, and there will be no extra output as long as the user sets
>> > log_min_messages to INFO or higher (i.e., not a DEBUG* value). For
>> > comparison, 'postgres -C' for a non-runtime-computed GUC does not emit
>> > extra output as long as the user sets log_min_messages to DEBUG2 or higher.
>>
>> > puts(config_val ? config_val : "");
>> > +
>> > + /* don't emit shutdown messages */
>> > + SetConfigOption("log_min_messages", "PANIC", PGC_INTERNAL, PGC_S_OVERRIDE);
>> > +
>> > ExitPostmaster(0);
>>
>> That's fancy, but I don't like that much. And this would not protect
>> either against any messages generated before this code path, either,
>
> But neither would the suggestion of redirecting stderr to /dev/null.
> In fact, doing the redirect it will *also* throw away any FATAL that
> happens. In fact, using the 2>/dev/null method, we *also* remove the
> message that says there's another postmaster running in this
> directory, which is strictly worse than the override of
> log_min_messages.
>
> That said, the redirect can be removed without recompiling postgres,
> so it is probably still hte better choice as a temporary workaround.
> But we should really look into getting a better solution in place once
> we start on 16.
A couple of other options to consider:
1) Always set log_min_messages to WARNING/ERROR/FATAL for 'postgres -C'.
We might need some special logic for handling the case where the user is
inspecting the log_min_messages parameter. With this approach, you'd
probably never get extra output unless something was wrong (e.g., database
already running when inspecting a runtime-computed GUC). Also, this would
silence any extra output that you might see today with non-runtime-computed
GUCs.
2) Add some way to skip just the shutdown message (e.g., a variable set
when output_config_variable is true). With this approach, you wouldn't get
extra output by default, but you still might if log_min_messages is set to
something like DEBUG3. This wouldn't impact any extra output that you see
today with non-runtime-computed GUCs.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Estimating HugePages Requirements?
2022-03-15 22:44 Re: Estimating HugePages Requirements? Nathan Bossart <[email protected]>
2022-03-23 06:25 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-03-24 13:07 ` Re: Estimating HugePages Requirements? Magnus Hagander <[email protected]>
2022-03-24 20:31 ` Re: Estimating HugePages Requirements? Nathan Bossart <[email protected]>
@ 2022-03-28 17:35 ` Nathan Bossart <[email protected]>
0 siblings, 0 replies; 42+ messages in thread
From: Nathan Bossart @ 2022-03-28 17:35 UTC (permalink / raw)
To: Magnus Hagander <[email protected]>; +Cc: Michael Paquier <[email protected]>; Bossart, Nathan <[email protected]>; Fujii Masao <[email protected]>; Justin Pryzby <[email protected]>; Andres Freund <[email protected]>; Mark Dilger <[email protected]>; Don Seiler <[email protected]>; pgsql-hackers
On Thu, Mar 24, 2022 at 01:31:08PM -0700, Nathan Bossart wrote:
> A couple of other options to consider:
>
> 1) Always set log_min_messages to WARNING/ERROR/FATAL for 'postgres -C'.
> We might need some special logic for handling the case where the user is
> inspecting the log_min_messages parameter. With this approach, you'd
> probably never get extra output unless something was wrong (e.g., database
> already running when inspecting a runtime-computed GUC). Also, this would
> silence any extra output that you might see today with non-runtime-computed
> GUCs.
>
> 2) Add some way to skip just the shutdown message (e.g., a variable set
> when output_config_variable is true). With this approach, you wouldn't get
> extra output by default, but you still might if log_min_messages is set to
> something like DEBUG3. This wouldn't impact any extra output that you see
> today with non-runtime-computed GUCs.
I've attached a first attempt at option 1.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Estimating HugePages Requirements?
2022-03-15 22:44 Re: Estimating HugePages Requirements? Nathan Bossart <[email protected]>
2022-03-23 06:25 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-03-24 13:07 ` Re: Estimating HugePages Requirements? Magnus Hagander <[email protected]>
@ 2022-04-19 22:12 ` Michael Paquier <[email protected]>
2022-04-22 07:49 ` Re: Estimating HugePages Requirements? Magnus Hagander <[email protected]>
1 sibling, 1 reply; 42+ messages in thread
From: Michael Paquier @ 2022-04-19 22:12 UTC (permalink / raw)
To: Magnus Hagander <[email protected]>; +Cc: Nathan Bossart <[email protected]>; Bossart, Nathan <[email protected]>; Fujii Masao <[email protected]>; Justin Pryzby <[email protected]>; Andres Freund <[email protected]>; Mark Dilger <[email protected]>; Don Seiler <[email protected]>; pgsql-hackers
On Thu, Mar 24, 2022 at 02:07:26PM +0100, Magnus Hagander wrote:
> But neither would the suggestion of redirecting stderr to /dev/null.
> In fact, doing the redirect it will *also* throw away any FATAL that
> happens. In fact, using the 2>/dev/null method, we *also* remove the
> message that says there's another postmaster running in this
> directory, which is strictly worse than the override of
> log_min_messages.
Well, we could also tweak more the command with a redirection of
stderr to a log file or such, and tell to look at it for errors.
> That said, the redirect can be removed without recompiling postgres,
> so it is probably still hte better choice as a temporary workaround.
> But we should really look into getting a better solution in place once
> we start on 16.
But do we really need a better or more invasive solution for already
running servers though? A SHOW command would be able to do the work
already in this case. This would lack consistency compared to the
offline case, but we are not without option either. That leaves the
case where the server is running, has allocated memory but is not
ready to accept connections, like crash recovery, still this use case
looks rather thin to me.
>> My solution for the docs is perhaps too confusing for the end-user,
>> and we are talking about a Linux-only thing here anyway. So, at the
>> end, I am tempted to just add the "2> /dev/null" as suggested upthread
>> by Nathan and call it a day. Does that sound fine?
>
> What would be a linux only thing?
Perhaps not at some point in the future. Now that's under a section
of the docs only for Linux.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Estimating HugePages Requirements?
2022-03-15 22:44 Re: Estimating HugePages Requirements? Nathan Bossart <[email protected]>
2022-03-23 06:25 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-03-24 13:07 ` Re: Estimating HugePages Requirements? Magnus Hagander <[email protected]>
2022-04-19 22:12 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
@ 2022-04-22 07:49 ` Magnus Hagander <[email protected]>
2022-04-25 00:15 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
0 siblings, 1 reply; 42+ messages in thread
From: Magnus Hagander @ 2022-04-22 07:49 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Nathan Bossart <[email protected]>; Bossart, Nathan <[email protected]>; Fujii Masao <[email protected]>; Justin Pryzby <[email protected]>; Andres Freund <[email protected]>; Mark Dilger <[email protected]>; Don Seiler <[email protected]>; pgsql-hackers
On Wed, Apr 20, 2022, 00:12 Michael Paquier <[email protected]> wrote:
> On Thu, Mar 24, 2022 at 02:07:26PM +0100, Magnus Hagander wrote:
> > But neither would the suggestion of redirecting stderr to /dev/null.
> > In fact, doing the redirect it will *also* throw away any FATAL that
> > happens. In fact, using the 2>/dev/null method, we *also* remove the
> > message that says there's another postmaster running in this
> > directory, which is strictly worse than the override of
> > log_min_messages.
>
> Well, we could also tweak more the command with a redirection of
> stderr to a log file or such, and tell to look at it for errors.
>
That's would be a pretty terrible ux though.
> > That said, the redirect can be removed without recompiling postgres,
> > so it is probably still hte better choice as a temporary workaround.
> > But we should really look into getting a better solution in place once
> > we start on 16.
>
> But do we really need a better or more invasive solution for already
> running servers though? A SHOW command would be able to do the work
> already in this case. This would lack consistency compared to the
> offline case, but we are not without option either. That leaves the
> case where the server is running, has allocated memory but is not
> ready to accept connections, like crash recovery, still this use case
> looks rather thin to me.
I agree that thats a very narrow use case. And I'm nog sure the use case of
a running server is even that important here - it's really the offline one
that's important. Or rather, the really compelling one is when there is a
server running but I want to check the value offline because it will
change. SHOW doesn't help there because it shows the value based on the
currently running configuration, not the new one after a restart.
I don't agree that the redirect is a solution. It's a workaround.
>> My solution for the docs is perhaps too confusing for the end-user,
> >> and we are talking about a Linux-only thing here anyway. So, at the
> >> end, I am tempted to just add the "2> /dev/null" as suggested upthread
> >> by Nathan and call it a day. Does that sound fine?
> >
> > What would be a linux only thing?
>
> Perhaps not at some point in the future. Now that's under a section
> of the docs only for Linux.
>
Hmm. So what's the solution on windows? I guess maybe it's not as important
there because there is no limit on huge pages, but generally getting the
expected shared memory usage might be useful? Just significantly less
important.
/Magnus
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Estimating HugePages Requirements?
2022-03-15 22:44 Re: Estimating HugePages Requirements? Nathan Bossart <[email protected]>
2022-03-23 06:25 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-03-24 13:07 ` Re: Estimating HugePages Requirements? Magnus Hagander <[email protected]>
2022-04-19 22:12 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-04-22 07:49 ` Re: Estimating HugePages Requirements? Magnus Hagander <[email protected]>
@ 2022-04-25 00:15 ` Michael Paquier <[email protected]>
2022-04-25 14:55 ` Re: Estimating HugePages Requirements? Magnus Hagander <[email protected]>
0 siblings, 1 reply; 42+ messages in thread
From: Michael Paquier @ 2022-04-25 00:15 UTC (permalink / raw)
To: Magnus Hagander <[email protected]>; +Cc: Nathan Bossart <[email protected]>; Bossart, Nathan <[email protected]>; Fujii Masao <[email protected]>; Justin Pryzby <[email protected]>; Andres Freund <[email protected]>; Mark Dilger <[email protected]>; Don Seiler <[email protected]>; pgsql-hackers
On Fri, Apr 22, 2022 at 09:49:34AM +0200, Magnus Hagander wrote:
> I agree that thats a very narrow use case. And I'm not sure the use case of
> a running server is even that important here - it's really the offline one
> that's important. Or rather, the really compelling one is when there is a
> server running but I want to check the value offline because it will
> change. SHOW doesn't help there because it shows the value based on the
> currently running configuration, not the new one after a restart.
You mean the case of a server where one would directly change
postgresql.conf on a running server, and use postgres -C to see how
much the kernel settings need to be changed before the restart?
> Hmm. So what's the solution on windows? I guess maybe it's not as important
> there because there is no limit on huge pages, but generally getting the
> expected shared memory usage might be useful? Just significantly less
> important.
Contrary to Linux, we don't need to care about the number of large
pages that are necessary because there is no equivalent of
vm.nr_hugepages on Windows (see [1]), do we? If that were the case,
we'd have a use case for huge_page_size, additionally.
That's the case where shared_memory_size_in_huge_pages comes in
handy, as much as does huge_page_size, and note that
shared_memory_size works on WIN32.
[1]: https://docs.microsoft.com/en-us/windows/win32/memory/large-page-support
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Estimating HugePages Requirements?
2022-03-15 22:44 Re: Estimating HugePages Requirements? Nathan Bossart <[email protected]>
2022-03-23 06:25 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-03-24 13:07 ` Re: Estimating HugePages Requirements? Magnus Hagander <[email protected]>
2022-04-19 22:12 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-04-22 07:49 ` Re: Estimating HugePages Requirements? Magnus Hagander <[email protected]>
2022-04-25 00:15 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
@ 2022-04-25 14:55 ` Magnus Hagander <[email protected]>
2022-04-26 01:34 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
0 siblings, 1 reply; 42+ messages in thread
From: Magnus Hagander @ 2022-04-25 14:55 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Nathan Bossart <[email protected]>; Bossart, Nathan <[email protected]>; Fujii Masao <[email protected]>; Justin Pryzby <[email protected]>; Andres Freund <[email protected]>; Mark Dilger <[email protected]>; Don Seiler <[email protected]>; pgsql-hackers
On Mon, Apr 25, 2022 at 2:15 AM Michael Paquier <[email protected]> wrote:
> On Fri, Apr 22, 2022 at 09:49:34AM +0200, Magnus Hagander wrote:
> > I agree that thats a very narrow use case. And I'm not sure the use case
> of
> > a running server is even that important here - it's really the offline
> one
> > that's important. Or rather, the really compelling one is when there is a
> > server running but I want to check the value offline because it will
> > change. SHOW doesn't help there because it shows the value based on the
> > currently running configuration, not the new one after a restart.
>
> You mean the case of a server where one would directly change
> postgresql.conf on a running server, and use postgres -C to see how
> much the kernel settings need to be changed before the restart?
>
Yes.
AIUI that was the original use-case for this feature. It certainly was for
me :)
> Hmm. So what's the solution on windows? I guess maybe it's not as
> important
> > there because there is no limit on huge pages, but generally getting the
> > expected shared memory usage might be useful? Just significantly less
> > important.
>
> Contrary to Linux, we don't need to care about the number of large
> pages that are necessary because there is no equivalent of
> vm.nr_hugepages on Windows (see [1]), do we? If that were the case,
> we'd have a use case for huge_page_size, additionally.
>
Right, for this one in particular -- that's what I meant with my comment
about there not being a limit. But this feature works for other settings as
well, not just the huge pages one. Exactly what the use-cases are can
vary, but surely they would have the same problems wrt redirects?
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/;
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Estimating HugePages Requirements?
2022-03-15 22:44 Re: Estimating HugePages Requirements? Nathan Bossart <[email protected]>
2022-03-23 06:25 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-03-24 13:07 ` Re: Estimating HugePages Requirements? Magnus Hagander <[email protected]>
2022-04-19 22:12 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-04-22 07:49 ` Re: Estimating HugePages Requirements? Magnus Hagander <[email protected]>
2022-04-25 00:15 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-04-25 14:55 ` Re: Estimating HugePages Requirements? Magnus Hagander <[email protected]>
@ 2022-04-26 01:34 ` Michael Paquier <[email protected]>
2022-05-06 17:13 ` Re: Estimating HugePages Requirements? Nathan Bossart <[email protected]>
0 siblings, 1 reply; 42+ messages in thread
From: Michael Paquier @ 2022-04-26 01:34 UTC (permalink / raw)
To: Magnus Hagander <[email protected]>; +Cc: Nathan Bossart <[email protected]>; Bossart, Nathan <[email protected]>; Fujii Masao <[email protected]>; Justin Pryzby <[email protected]>; Andres Freund <[email protected]>; Mark Dilger <[email protected]>; Don Seiler <[email protected]>; pgsql-hackers
On Mon, Apr 25, 2022 at 04:55:25PM +0200, Magnus Hagander wrote:
> AIUI that was the original use-case for this feature. It certainly was for
> me :)
Perhaps we'd be fine with relaxing the requirements here knowing that
the control file should never be larger than PG_CONTROL_MAX_SAFE_SIZE
(aka the read should be atomic so it could be made lockless). At the
end of the day, to be absolutely correct in the shmem size estimation,
I think that we are going to need what's proposed here or the sizing
may not be right depending on how extensions adjust GUCs after they
load their _PG_init():
https://www.postgresql.org/message-id/20220419154658.GA2487941@nathanxps13
That's a bit independent, but not completely unrelated either
depending on how exact you want your number of estimated huge pages to
be. Just wanted to mention it.
>> Contrary to Linux, we don't need to care about the number of large
>> pages that are necessary because there is no equivalent of
>> vm.nr_hugepages on Windows (see [1]), do we? If that were the case,
>> we'd have a use case for huge_page_size, additionally.
>
> Right, for this one in particular -- that's what I meant with my comment
> about there not being a limit. But this feature works for other settings as
> well, not just the huge pages one. Exactly what the use-cases are can
> vary, but surely they would have the same problems wrt redirects?
Yes, the redirection issue would apply to all the run-time GUCs.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../YmdMDiCCyVJLlB%[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Estimating HugePages Requirements?
2022-03-15 22:44 Re: Estimating HugePages Requirements? Nathan Bossart <[email protected]>
2022-03-23 06:25 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-03-24 13:07 ` Re: Estimating HugePages Requirements? Magnus Hagander <[email protected]>
2022-04-19 22:12 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-04-22 07:49 ` Re: Estimating HugePages Requirements? Magnus Hagander <[email protected]>
2022-04-25 00:15 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-04-25 14:55 ` Re: Estimating HugePages Requirements? Magnus Hagander <[email protected]>
2022-04-26 01:34 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
@ 2022-05-06 17:13 ` Nathan Bossart <[email protected]>
2022-05-09 06:53 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
0 siblings, 1 reply; 42+ messages in thread
From: Nathan Bossart @ 2022-05-06 17:13 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Magnus Hagander <[email protected]>; Bossart, Nathan <[email protected]>; Fujii Masao <[email protected]>; Justin Pryzby <[email protected]>; Andres Freund <[email protected]>; Mark Dilger <[email protected]>; Don Seiler <[email protected]>; pgsql-hackers
On Tue, Apr 26, 2022 at 10:34:06AM +0900, Michael Paquier wrote:
> Yes, the redirection issue would apply to all the run-time GUCs.
Should this be tracked as an open item for v15? There was another recent
report about the extra log output [0].
[0] https://www.postgresql.org/message-id/YnARlI5nvbziobR4%40momjian.us
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Estimating HugePages Requirements?
2022-03-15 22:44 Re: Estimating HugePages Requirements? Nathan Bossart <[email protected]>
2022-03-23 06:25 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-03-24 13:07 ` Re: Estimating HugePages Requirements? Magnus Hagander <[email protected]>
2022-04-19 22:12 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-04-22 07:49 ` Re: Estimating HugePages Requirements? Magnus Hagander <[email protected]>
2022-04-25 00:15 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-04-25 14:55 ` Re: Estimating HugePages Requirements? Magnus Hagander <[email protected]>
2022-04-26 01:34 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-05-06 17:13 ` Re: Estimating HugePages Requirements? Nathan Bossart <[email protected]>
@ 2022-05-09 06:53 ` Michael Paquier <[email protected]>
2022-05-10 16:12 ` Re: Estimating HugePages Requirements? Nathan Bossart <[email protected]>
0 siblings, 1 reply; 42+ messages in thread
From: Michael Paquier @ 2022-05-09 06:53 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: Magnus Hagander <[email protected]>; Bossart, Nathan <[email protected]>; Fujii Masao <[email protected]>; Justin Pryzby <[email protected]>; Andres Freund <[email protected]>; Mark Dilger <[email protected]>; Don Seiler <[email protected]>; pgsql-hackers
On Fri, May 06, 2022 at 10:13:18AM -0700, Nathan Bossart wrote:
> On Tue, Apr 26, 2022 at 10:34:06AM +0900, Michael Paquier wrote:
>> Yes, the redirection issue would apply to all the run-time GUCs.
>
> Should this be tracked as an open item for v15? There was another recent
> report about the extra log output [0].
That makes it for two complaints on two separate threads. So an open
item seems adapted to adjust this behavior.
I have looked at the patch posted at [1], and I don't quite understand
why you need the extra dance with log_min_messages. Why don't you
just set the GUC at the end of the code path in PostmasterMain() where
we print non-runtime-computed parameters? I am not really worrying
about users deciding to set log_min_messages to PANIC in
postgresql.conf when it comes to postgres -C, TBH, as they'd miss the
FATAL messages if the command is attempted on a server already
starting.
Per se the attached.
[1]: https://www.postgresql.org/message-id/20220328173503.GA137769@nathanxps13
--
Michael
Attachments:
[text/x-diff] v4-0001-Silence-extra-logging-with-postgres-C.patch (2.2K, ../../[email protected]/2-v4-0001-Silence-extra-logging-with-postgres-C.patch)
download | inline diff:
From 3b8a7f8079955cd59a5a318adf6938cdd3c29c6b Mon Sep 17 00:00:00 2001
From: Michael Paquier <[email protected]>
Date: Mon, 9 May 2022 15:50:19 +0900
Subject: [PATCH v4] Silence extra logging with 'postgres -C'.
Presently, the server may emit a variety of extra log messages when
inspecting GUC values. For example, when inspecting a runtime-computed
GUC, the server will always emit a "database system is shut down" LOG
(unless the user has set log_min_messages higher than LOG). To avoid
these extra log messages, this change sets log_min_messages to FATAL
when -C is used (even if set to PANIC in postgresql.conf). At FATAL,
the user will still receive messages explaining why a GUC's value cannot
be inspected.
---
src/backend/postmaster/postmaster.c | 10 ++++++++++
doc/src/sgml/runtime.sgml | 2 +-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c
index ce4007bb2c..38b63bc215 100644
--- a/src/backend/postmaster/postmaster.c
+++ b/src/backend/postmaster/postmaster.c
@@ -913,6 +913,16 @@ PostmasterMain(int argc, char *argv[])
puts(config_val ? config_val : "");
ExitPostmaster(0);
}
+
+ /*
+ * A runtime-computed GUC will be printed later on. As we initialize
+ * a server startup sequence, silence any log messages that may show up
+ * in the output generated. FATAL and more severe messages are useful
+ * to show, even if one would only expect at least PANIC. LOG entries
+ * are hidden.
+ */
+ SetConfigOption("log_min_messages", "FATAL", PGC_INTERNAL,
+ PGC_S_OVERRIDE);
}
/* Verify that DataDir looks reasonable */
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index 4465c876b1..62cec614d3 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -1448,7 +1448,7 @@ export PG_OOM_ADJUST_VALUE=0
server must be shut down to view this runtime-computed parameter.
This might look like:
<programlisting>
-$ <userinput>postgres -D $PGDATA -C shared_memory_size_in_huge_pages 2> /dev/null</userinput>
+$ <userinput>postgres -D $PGDATA -C shared_memory_size_in_huge_pages</userinput>
3170
$ <userinput>grep ^Hugepagesize /proc/meminfo</userinput>
Hugepagesize: 2048 kB
--
2.36.0
[application/pgp-signature] signature.asc (833B, ../../[email protected]/3-signature.asc)
download
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Estimating HugePages Requirements?
2022-03-15 22:44 Re: Estimating HugePages Requirements? Nathan Bossart <[email protected]>
2022-03-23 06:25 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-03-24 13:07 ` Re: Estimating HugePages Requirements? Magnus Hagander <[email protected]>
2022-04-19 22:12 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-04-22 07:49 ` Re: Estimating HugePages Requirements? Magnus Hagander <[email protected]>
2022-04-25 00:15 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-04-25 14:55 ` Re: Estimating HugePages Requirements? Magnus Hagander <[email protected]>
2022-04-26 01:34 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-05-06 17:13 ` Re: Estimating HugePages Requirements? Nathan Bossart <[email protected]>
2022-05-09 06:53 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
@ 2022-05-10 16:12 ` Nathan Bossart <[email protected]>
2022-05-11 05:34 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
0 siblings, 1 reply; 42+ messages in thread
From: Nathan Bossart @ 2022-05-10 16:12 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Magnus Hagander <[email protected]>; Bossart, Nathan <[email protected]>; Fujii Masao <[email protected]>; Justin Pryzby <[email protected]>; Andres Freund <[email protected]>; Mark Dilger <[email protected]>; Don Seiler <[email protected]>; pgsql-hackers
On Mon, May 09, 2022 at 03:53:24PM +0900, Michael Paquier wrote:
> I have looked at the patch posted at [1], and I don't quite understand
> why you need the extra dance with log_min_messages. Why don't you
> just set the GUC at the end of the code path in PostmasterMain() where
> we print non-runtime-computed parameters?
The log_min_messages dance avoids extra output when inspecting
non-runtime-computed GUCs, like this:
~/pgdata$ postgres -D . -C log_min_messages -c log_min_messages=debug5
debug5
2022-05-10 09:06:04.728 PDT [3715607] DEBUG: shmem_exit(0): 0 before_shmem_exit callbacks to make
2022-05-10 09:06:04.728 PDT [3715607] DEBUG: shmem_exit(0): 0 on_shmem_exit callbacks to make
2022-05-10 09:06:04.728 PDT [3715607] DEBUG: proc_exit(0): 0 callbacks to make
2022-05-10 09:06:04.728 PDT [3715607] DEBUG: exit(0)
AFAICT you need to set log_min_messages to at least DEBUG3 to see extra
output for the non-runtime-computed GUCs, so it might not be worth the
added complexity.
> I am not really worrying
> about users deciding to set log_min_messages to PANIC in
> postgresql.conf when it comes to postgres -C, TBH, as they'd miss the
> FATAL messages if the command is attempted on a server already
> starting.
I don't have a strong opinion on this one.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Estimating HugePages Requirements?
2022-03-15 22:44 Re: Estimating HugePages Requirements? Nathan Bossart <[email protected]>
2022-03-23 06:25 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-03-24 13:07 ` Re: Estimating HugePages Requirements? Magnus Hagander <[email protected]>
2022-04-19 22:12 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-04-22 07:49 ` Re: Estimating HugePages Requirements? Magnus Hagander <[email protected]>
2022-04-25 00:15 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-04-25 14:55 ` Re: Estimating HugePages Requirements? Magnus Hagander <[email protected]>
2022-04-26 01:34 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-05-06 17:13 ` Re: Estimating HugePages Requirements? Nathan Bossart <[email protected]>
2022-05-09 06:53 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-05-10 16:12 ` Re: Estimating HugePages Requirements? Nathan Bossart <[email protected]>
@ 2022-05-11 05:34 ` Michael Paquier <[email protected]>
2022-05-11 15:57 ` Re: Estimating HugePages Requirements? Nathan Bossart <[email protected]>
0 siblings, 1 reply; 42+ messages in thread
From: Michael Paquier @ 2022-05-11 05:34 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: Magnus Hagander <[email protected]>; Bossart, Nathan <[email protected]>; Fujii Masao <[email protected]>; Justin Pryzby <[email protected]>; Andres Freund <[email protected]>; Mark Dilger <[email protected]>; Don Seiler <[email protected]>; pgsql-hackers
On Tue, May 10, 2022 at 09:12:49AM -0700, Nathan Bossart wrote:
> AFAICT you need to set log_min_messages to at least DEBUG3 to see extra
> output for the non-runtime-computed GUCs, so it might not be worth the
> added complexity.
This set of messages is showing up for ages with zero complaints from
the field AFAIK, and nobody would use this level of logging except
developers. One thing that overriding log_min_messages to FATAL does,
however, is to not show anymore those debug3 messages when querying a
runtime-computed GUC, but that's the kind of things we'd hide. Your
patch would hide those entries in both cases. Perhaps we could do
that, but at the end, I don't really see any need to complicate this
code path more than necessary, and this is enough to silence the logs
in the cases we care about basically all the time, even if the log
levels are reduced a bit on a given cluster. Hence, I have applied
the simplest solution to just enforce a log_min_messages=FATAL when
requesting a runtime GUC.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Estimating HugePages Requirements?
2022-03-15 22:44 Re: Estimating HugePages Requirements? Nathan Bossart <[email protected]>
2022-03-23 06:25 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-03-24 13:07 ` Re: Estimating HugePages Requirements? Magnus Hagander <[email protected]>
2022-04-19 22:12 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-04-22 07:49 ` Re: Estimating HugePages Requirements? Magnus Hagander <[email protected]>
2022-04-25 00:15 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-04-25 14:55 ` Re: Estimating HugePages Requirements? Magnus Hagander <[email protected]>
2022-04-26 01:34 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-05-06 17:13 ` Re: Estimating HugePages Requirements? Nathan Bossart <[email protected]>
2022-05-09 06:53 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-05-10 16:12 ` Re: Estimating HugePages Requirements? Nathan Bossart <[email protected]>
2022-05-11 05:34 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
@ 2022-05-11 15:57 ` Nathan Bossart <[email protected]>
0 siblings, 0 replies; 42+ messages in thread
From: Nathan Bossart @ 2022-05-11 15:57 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Magnus Hagander <[email protected]>; Bossart, Nathan <[email protected]>; Fujii Masao <[email protected]>; Justin Pryzby <[email protected]>; Andres Freund <[email protected]>; Mark Dilger <[email protected]>; Don Seiler <[email protected]>; pgsql-hackers
On Wed, May 11, 2022 at 02:34:25PM +0900, Michael Paquier wrote:
> Hence, I have applied
> the simplest solution to just enforce a log_min_messages=FATAL when
> requesting a runtime GUC.
Thanks!
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 42+ messages in thread
end of thread, other threads:[~2022-05-11 15:57 UTC | newest]
Thread overview: 42+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2017-04-11 00:57 Ongoing issues with representation of empty arrays Andrew Gierth <[email protected]>
2017-04-11 01:48 ` David G. Johnston <[email protected]>
2017-04-11 03:50 ` Tom Lane <[email protected]>
2017-04-11 04:17 ` Andrew Gierth <[email protected]>
2017-04-19 20:36 ` Merlin Moncure <[email protected]>
2017-04-19 20:10 ` David G. Johnston <[email protected]>
2020-08-17 20:20 [PATCH] Disable autovacuum for BRIN test table Alvaro Herrera <[email protected]>
2020-08-17 20:20 [PATCH] Disable autovacuum for BRIN test table Alvaro Herrera <[email protected]>
2020-08-17 20:20 [PATCH] Disable autovacuum for BRIN test table Alvaro Herrera <[email protected]>
2020-08-17 20:20 [PATCH] Disable autovacuum for BRIN test table Alvaro Herrera <[email protected]>
2020-08-17 20:20 [PATCH] Disable autovacuum for BRIN test table Alvaro Herrera <[email protected]>
2020-08-17 20:20 [PATCH] Disable autovacuum for BRIN test table Alvaro Herrera <[email protected]>
2020-08-17 20:20 [PATCH] Disable autovacuum for BRIN test table Alvaro Herrera <[email protected]>
2020-08-17 20:20 [PATCH] Disable autovacuum for BRIN test table Alvaro Herrera <[email protected]>
2020-08-17 20:20 [PATCH] Disable autovacuum for BRIN test table Alvaro Herrera <[email protected]>
2020-08-17 20:20 [PATCH] Disable autovacuum for BRIN test table Alvaro Herrera <[email protected]>
2020-08-17 20:20 [PATCH] Disable autovacuum for BRIN test table Alvaro Herrera <[email protected]>
2020-08-17 20:20 [PATCH] Disable autovacuum for BRIN test table Alvaro Herrera <[email protected]>
2020-08-17 20:20 [PATCH] Disable autovacuum for BRIN test table Alvaro Herrera <[email protected]>
2020-08-17 20:20 [PATCH] Disable autovacuum for BRIN test table Alvaro Herrera <[email protected]>
2020-08-17 20:20 [PATCH] Disable autovacuum for BRIN test table Alvaro Herrera <[email protected]>
2020-08-17 20:20 [PATCH] Disable autovacuum for BRIN test table Alvaro Herrera <[email protected]>
2020-08-17 20:20 [PATCH] Disable autovacuum for BRIN test table Alvaro Herrera <[email protected]>
2020-08-17 20:20 [PATCH] Disable autovacuum for BRIN test table Alvaro Herrera <[email protected]>
2020-08-17 20:20 [PATCH] Disable autovacuum for BRIN test table Alvaro Herrera <[email protected]>
2022-03-15 22:44 Re: Estimating HugePages Requirements? Nathan Bossart <[email protected]>
2022-03-21 22:12 ` Re: Estimating HugePages Requirements? Nathan Bossart <[email protected]>
2022-03-23 06:25 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-03-24 12:10 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-03-24 13:07 ` Re: Estimating HugePages Requirements? Magnus Hagander <[email protected]>
2022-03-24 20:31 ` Re: Estimating HugePages Requirements? Nathan Bossart <[email protected]>
2022-03-28 17:35 ` Re: Estimating HugePages Requirements? Nathan Bossart <[email protected]>
2022-04-19 22:12 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-04-22 07:49 ` Re: Estimating HugePages Requirements? Magnus Hagander <[email protected]>
2022-04-25 00:15 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-04-25 14:55 ` Re: Estimating HugePages Requirements? Magnus Hagander <[email protected]>
2022-04-26 01:34 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-05-06 17:13 ` Re: Estimating HugePages Requirements? Nathan Bossart <[email protected]>
2022-05-09 06:53 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-05-10 16:12 ` Re: Estimating HugePages Requirements? Nathan Bossart <[email protected]>
2022-05-11 05:34 ` Re: Estimating HugePages Requirements? Michael Paquier <[email protected]>
2022-05-11 15:57 ` Re: Estimating HugePages Requirements? Nathan Bossart <[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