Re: Doc tweak for huge_pages?

oblem. He also notice that THP only works for "anonymous memory mappings"[1] (shared_buffers are not anonymous). 1: https://www.kernel.org/doc/Documentation/vm/transhuge.txt Regards, -- Adrien NAYRAT signature.asc Description: OpenPGP digital signature

New GUC to sample log queries

/current/static/auto-explain.html -- Adrien NAYRAT commit 01a45625b82af0c3201f944fe91163c590a23f12 Author: anayrat Date: Wed May 30 20:27:54 2018 +0200 Add a new GUC to log a fraction of queries. diff --git a/src/backend/tcop/postgres.c b/src/backend/tcop/postgres.c index f4133953be

Re: New GUC to sample log queries

On 05/31/2018 03:34 AM, David Rowley wrote: > On 31 May 2018 at 06:44, Adrien Nayrat wrote: >> Here is a naive SELECT only bench with a dataset which fit in ram (scale >> factor >> = 100) and PGDATA and log on a ramdisk: >> shared_buffers = 4GB >> seq_p

Re: New GUC to sample log queries

On 06/24/2018 08:41 PM, Vik Fearing wrote: > On 24/06/18 13:22, Adrien Nayrat wrote: >> Attached third version of the patch with documentation. > > Hi. I'm reviewing this. Hi, thanks for your review. > >> exceeded = (log_min

Re: Explain buffers wrong counter with parallel plans

On 05/01/2018 10:57 PM, Andres Freund wrote: > Robert, you added this as an open item. I don't think it's clear that > there's a bug here, and even less clear that it's something new for > v11. Am I understanding that right? Should we close this open item? Hi, FIY this change is related to

Re: Explain buffers wrong counter with parallel plans

Hi, On 05/02/2018 05:22 PM, Robert Haas wrote: > On Tue, May 1, 2018 at 4:57 PM, Andres Freund wrote: >> Robert, you added this as an open item. I don't think it's clear that >> there's a bug here, and even less clear that it's something new for >> v11. Am I understanding

Re: Explain buffers wrong counter with parallel plans

On 04/29/2018 05:11 PM, Amit Kapila wrote: > I think you can try 'verbose' option, it will give per-worker stats. Thanks! I didn't know verbose give per-woker stats! -- Adrien signature.asc Description: OpenPGP digital signature

Re: Explain buffers wrong counter with parallel plans

On 04/29/2018 05:10 PM, Amit Kapila wrote: > Yeah, it would have been convenient, if Gather and Finalize Aggregate > displays that way as it would have been easier for users to > understand. However, as of now, the aggregated stats for parallel > workers and leader are displayed at

Re: Explain buffers wrong counter with parallel plans

On 08/03/2018 10:39 AM, Amit Kapila wrote: Thanks. I have pushed those two patches. Thanks!

Re: [HACKERS] Parallel Append implementation

On 08/01/2018 03:14 PM, Robert Haas wrote: Committed to master and v11. Thanks for the review. Thanks!

Re: Postgres 11 release notes

Hello, It seems this feature is missing in releases notes ? commit 1f6d515a67ec98194c23a5db25660856c9aab944 Author: Robert Haas Date: Mon Aug 21 14:43:01 2017 -0400 Push limit through subqueries to underlying sort, where possible. Douglas Doole, reviewed by Ashutosh Bapat and by me.

Re: New GUC to sample log queries

On 07/16/2018 05:24 PM, Robert Haas wrote: > On Sun, Jul 15, 2018 at 6:53 AM, Vik Fearing > wrote: >> Hmm. Not sure if that last word should be _sample, _sampling, _rate, or >> a combination of those. > > +1 for rate or sample_rate. I think "sample" or "sampling" without > "rate" will not be

Re: Standby reads fail when autovacuum take AEL during truncation

On 9/7/18 7:36 PM, Alexander Korotkov wrote: Please, take a look at following threads: 1.https://www.postgresql.org/message-id/c9374921e50a5e8fb1ecf04eb8c6ebc3%40postgrespro.ru 2.https://www.postgresql.org/message-id/CAHGQGwE5UqFqSq1%3DkV3QtTUtXphTdyHA-8rAj4A%3DY%2Be4kyp3BQ%40mail.gmail.com

Standby reads fail when autovacuum take AEL during truncation

Hello hackers, I was faced on $SUBJECT on an heavily updated table and the same table heavily accessed on standby server. I notice autovacuum try to take an AEL in lazy_truncate_heap(). On primary we try during VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL (50ms) and we failed after several attempts.

Re: New GUC to sample log queries

On 06/27/2018 11:13 PM, Adrien Nayrat wrote: >> 3) Is it intentional to only sample with log_min_duration_statement and >> not also with log_duration? It seems like it should affect both. In >> both cases, the name is too generic. Something called "log_sample_rate" &

Re: [HACKERS] Parallel Append implementation

Hello, I notice Parallel append is not listed on Parallel Plans documentation : https://www.postgresql.org/docs/devel/static/parallel-plans.html If you agree I can add it to Open Items. Thanks, -- Adrien NAYRAT signature.asc Description: OpenPGP digital signature

Re: Explain buffers wrong counter with parallel plans

Hello, I tried to understand this issue and it seems Gather node only take account of this own buffer usage : create unlogged table t1 (c1 int); insert into t1 select generate_series(1,100); vacuum t1; explain (analyze,buffers,timing off,costs off) select count(*) from t1;

Explain buffers wrong counter with parallel plans

Buffers: shared read=442478 I/O Timings: read=8874.662 Planning time: 37.834 ms Execution time: 34368.817 ms (8 rows) I got similar results on 9.6. Regards, -- Adrien NAYRAT signature.asc Description: OpenPGP digital signature

Re: Postgres 11 release notes

On 9/20/18 8:47 AM, Adrien Nayrat wrote: On 8/25/18 11:24 PM, Peter Geoghegan wrote: On Sat, Aug 25, 2018 at 2:18 PM, Bruce Momjian wrote: I think that's less "our" logic and more yours, that has become established because you've done most of the major release notes for a long

Re: Postgres 11 release notes

On 10/8/18 5:20 PM, Bruce Momjian wrote: Uh, where are you looking? We don't rebuild the beta docs until the next beta release, but you can see the changes in the developer docs: https://www.postgresql.org/docs/devel/static/release-11.html I looked in doc/src/sgml/release-11.sgml

Re: Skylake-S warning

On 10/3/18 11:29 PM, Daniel Wood wrote: > If running benchmarks or you are a customer which is currently impacted by > GetSnapshotData() on high end multisocket systems be wary of Skylake-S. > > > Performance differences of nearly 2X can be seen on select only pgbench due to > nothing else but

Re: Postgres 11 release notes

On 8/25/18 11:24 PM, Peter Geoghegan wrote: > On Sat, Aug 25, 2018 at 2:18 PM, Bruce Momjian wrote: >>> I think that's less "our" logic and more yours, that has become >>> established because you've done most of the major release notes for a >>> long time. I'm not trying to say that that's wrong

Re: New GUC to sample log queries

On 11/18/18 12:47 AM, Dmitry Dolgov wrote: > This patch went through last few commitfests without any activity, but cfbot > says it still applies and doesn't break any tests. From what I see there was > some agreement about naming, so the patch is indeed needs more review. Could > anyone from the

Re: Log a sample of transactions

On 1/16/19 10:09 AM, Masahiko Sawada wrote: Since we set xact_is_sampled only when transaction starts and see it during transaction we cannot disable logging during transaction and vice versa. I can imagine the use case where user wants to disable logging during transaction. So it might be

Re: Log a sample of transactions

On 1/18/19 9:03 AM, Peter Eisentraut wrote: But if you have trouble with a specific transaction, how will a setting help that randomly logs transactions, not necessarily the one you are concerned about? Yes, it assumes your application performs same type of transaction. Maybe the use case is

Re: Log a sample of transactions

On 1/15/19 11:42 AM, Masahiko Sawada wrote: When you troubleshoot applicative issues with multi-statements transaction, you may have to log all queries to find all statements of one transaction. With high throughput, it could be hard to log all queries without causing troubles. Hm, can we use

Re: Log a sample of transactions

On 1/16/19 1:40 AM, Kuroda, Hayato wrote: By the way, I think the name of this parameter should be changed. In the Cambridge dictionary, the word "rate" means as follows: the speed at which something happens or changes, or the amount or number of times it happens or changes in a particular

Re: Log a sample of transactions

On 1/15/19 9:00 AM, Kuroda, Hayato wrote: Dear Adrien, I applied your file and faced a bug-candidate. (I have not read your source yet. Sorry.) When I tried to use tab-complition, some dirty messages were appeared. Messages I faced are attached in this mail. Best Regards, Hayato Kuroda

Log a sample of transactions

%2BZYbMLKyE2y498HJzsdFrMnW1dQ6AFJ3Mpw%40mail.gmail.com -- Adrien NAYRAT diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 4a7121a51f..7312b1022f 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -5771,6 +5771,24 @@ local0.*/var/log/postgresql

Re: No such file or directory in pg_replslot

On 12/8/18 8:21 PM, Jeremy Finzel wrote: There are 2.1 million files in pg_replslot which I don't think is normal?  Any ideas as to where I should be looking or what could cause this? Postgres spills changes on disk when you have a big transaction:

Re: New GUC to sample log queries

On 11/29/18 6:35 PM, Alvaro Herrera wrote: > > Sounds good to me (we -> you, I suppose?). I'd tweak the extra_desc for > log_min_duration_statement too, because we no longer log "all" when the > rate is <1; maybe "Zero prints all queries, subject to > log_statement_sample_rate. -1 turns this

Re: New GUC to sample log queries

On 11/29/18 10:48 PM, Alvaro Herrera wrote: Thanks! I pushed this with two changes -- one was to reword the docs a bit more, and the other was to compute in_sample only if it's going to be used (when exceeded is true). I hope this won't upset any compilers ... Thanks! I wonder if there's

Re: New GUC to sample log queries

On 11/30/18 7:42 AM, Nikolay Samokhvalov wrote: On Thu, Nov 29, 2018 at 1:49 PM Alvaro Herrera > wrote: Thanks!  I pushed this with two changes -- one was to reword the docs a bit more, and the other was to compute in_sample only if it's going to be

Re: New GUC to sample log queries

On 11/19/18 2:52 PM, Dmitry Dolgov wrote: >> On Mon, Nov 19, 2018 at 2:40 PM Tomas Vondra >> wrote: >> >> On 11/19/18 2:57 AM, Michael Paquier wrote: >>> On Sun, Nov 18, 2018 at 12:18:33PM +0100, Dmitry Dolgov wrote: Since it's hard to come up with a concise name that will mention sampling

Re: New GUC to sample log queries

On 11/26/18 12:40 AM, Thomas Munro wrote: > On Wed, Nov 21, 2018 at 9:06 PM Adrien Nayrat > wrote: >> Thanks for your comments. Here is the updated patch. I fixed a warning for >> missing parentheses in this expression: >> if ((exceeded && in_sample) || log_durati

Re: performance statistics monitoring without spamming logs

On 11/22/18 6:41 AM, Justin Pryzby wrote: and then probably look at the ratio of user CPU/clock time. Maybe pg_stat_kcache could help you : https://github.com/powa-team/pg_stat_kcache https://rjuju.github.io/postgresql/2018/07/17/pg_stat_kcache-2-1-is-out.html

Re: [Proposal] Add accumulated statistics

On 1/7/19 6:34 AM, Tsunakawa, Takayuki wrote: 1. Doesn't provide precise data Sampling could miss intermittent short waits, e.g., buffer content lock waits during checkpoints. This might make it difficult or impossible to solve transient performance problems, such as infrequent 100

Re: random() (was Re: New GUC to sample log queries)

On 12/26/18 7:45 PM, Tom Lane wrote: I wonder whether we should establish a project policy to avoid use of random() for internal purposes, ie try to get to a point where drandom() is the only caller in the backend. FYI I picked the idea from auto_explain. Maybe we will have to change

Re: Log a sample of transactions

On 1/23/19 3:12 AM, Kuroda, Hayato wrote: Dear Adrien, Hello Kuroda-san config.sgml You must document the behavior when users change the parameter during a transaction. あやしい・・・ Agreed, I added a wording. postgres.c I give you three comments. /* flag for

Re: Log a sample of transactions

Hello, On 3/27/19 7:05 AM, Masahiko Sawada wrote: Why are both of these checked? ISTM once xact_is_sampled is set, we ought not to respect a different value of log_xact_sample_rate for the rest of that transaction. I added theses checks to allow to disable logging during a sampled transaction,

Re: Log a sample of transactions

On 3/26/19 1:54 AM, Kuroda, Hayato wrote: Dear David, I have a will and already read the patch, but I thought it's not my turn. Sorry. Hello, Adrien, I did not find any test for log_min_duration that could help me. LCOV indicate there is no tests on this part (look

Re: Log a sample of transactions

On 3/27/19 10:22 AM, Adrien NAYRAT wrote: Hello, On 3/27/19 7:05 AM, Masahiko Sawada wrote: Why are both of these checked? ISTM once xact_is_sampled is set, we ought not to respect a different value of log_xact_sample_rate for the rest of that transaction. I added theses checks to allow

Re: Log a sample of transactions

On 4/3/19 11:45 PM, Alvaro Herrera wrote: On 2019-Mar-29, Adrien NAYRAT wrote: On 3/29/19 3:06 AM, Kuroda, Hayato wrote: Dear Adrien, Hello Kuroda-san, I understood the cost of randomizing is very low. Maybe it's OK.. I'll change the status to "Ready For Committer." Than

Re: Sparse bit set data structure

Hello, According to the draw and simple8b_mode struct comment, it seems there is a typo: * 20-bit integer 20-bit integer 20-bit integer * 1101 00010010 00110010 00010100 * ^ * selector * * The selector 1101 is 13 in decimal. From the

Re: Log a sample of transactions

On 3/28/19 10:45 AM, Christoph Berg wrote: Re: Adrien NAYRAT 2019-03-28 Sorry, I changed that, someone suggest using either "0" and "1", or "0.0" and "1.0" but not mixing both. Agreed with using "0.0" and "1.0". I w

Re: Log a sample of transactions

Hello, On 3/28/19 3:18 AM, Masahiko Sawada wrote: Sorry, I changed that, someone suggest using either "0" and "1", or "0.0" and "1.0" but not mixing both. Agreed with using "0.0" and "1.0". I will remove this change. --- a/src/backend/utils/misc/postgresql.conf.sample +++

Re: clean up docs for log_statement_sample_rate

On 3/28/19 2:59 PM, Justin Pryzby wrote: Following the dicussion here, https://www.postgresql.org/message-id/flat/CAD21AoB9%2By8N4%2BFan-ne-_7J5yTybPttxeVKfwUocKp4zT1vNQ%40mail.gmail.com#90a8316b1e643532e1cdb352c91c22a7 I'm proposing these changes to clean up docs for previous (more or less

Re: Log a sample of transactions

On 3/29/19 3:06 AM, Kuroda, Hayato wrote: Dear Adrien, Hello Kuroda-san, I understood the cost of randomizing is very low. Maybe it's OK.. I'll change the status to "Ready For Committer." Thanks, I hope it will be commited in PG12 as the feature is closed to log_statement_sample_rate.

Re: Log a sample of transactions

Hello, On 2/15/19 3:24 PM, Adrien NAYRAT wrote: On 2/14/19 9:14 PM, Andres Freund wrote: I wonder if this doesn't need a warning, explaining that using this when there are large transactions could lead to slowdowns. Yes, I will add some wording Warning added. It seems pretty weird

Re: Remove Deprecated Exclusive Backup Mode

On 2/22/19 7:10 PM, Robert Haas wrote: On Fri, Feb 22, 2019 at 12:35 PM Fujii Masao wrote: -1 for the removal. I think that there are still many users of an exclusive backup API, and it's not so easy to migrate their backup scripts so that only non-exclusive one is used because of the reason I

Re: Log a sample of transactions

On 2/14/19 9:14 PM, Andres Freund wrote: Hi, Hello Andres, On 2019-01-26 11:44:58 +0100, Adrien NAYRAT wrote: + + log_transaction_sample_rate (real) + + log_transaction_sample_rate configuration parameter + + + + + Set the fraction

Re: Log a sample of transactions

On 1/28/19 2:53 AM, Kuroda, Hayato wrote: > BTW, I give you a suggestion about a test. > This parameter enables users to log statements randomly, hence adding some > tests is very difficult. > Perhaps Only three cases are available: > > * When log_transaction_sample_rate is set to 1, all

Re: Log a sample of transactions

On 2/4/19 3:26 AM, Michael Paquier wrote: These would take time to execute, even if you need to measure one second, and may be hard to make stable on slow machines. Could it be acceptable if I set log_min_duration_statement = 0? Moved to next CF. Thanks

Re: PG 12 draft release notes

On 5/11/19 10:33 PM, Bruce Momjian wrote: > I have posted a draft copy of the PG 12 release notes here: > > http://momjian.us/pgsql_docs/release-12.html > > They are committed to git. It includes links to the main docs, where > appropriate. Our official developer docs will rebuild in a

Re: [PATCH] Speedup truncates of relation forks

On 6/11/19 9:34 AM, Jamison, Kirk wrote: > Hi all, > > Attached is a patch to speed up the performance of truncates of relations. > Thanks for working on this! > > *C. **Performance Test* > > I setup a synchronous streaming replication between a master-standby. > > In postgresql.conf: >

Re: idea: log_statement_sample_rate - bottom limit for sampling

On 6/18/19 8:29 PM, Pavel Stehule wrote: > > > út 18. 6. 2019 v 14:03 odesílatel Adrien Nayrat <mailto:adrien.nay...@anayrat.info>> napsal: > > Hi, > > I tried the patch, here my comment: > > > gettext_noop("Zero effective disables samp

Re: idea: log_statement_sample_rate - bottom limit for sampling

Hi, I tried the patch, here my comment: > gettext_noop("Zero effective disables sampling. " > "-1 use sampling every time (without limit)."), I do not agree with the zero case. In fact, sampling is disabled as soon as setting is less than log_min_duration_statements.

Re: [PATCH] Speedup truncates of relation forks

On 7/1/19 12:55 PM, Jamison, Kirk wrote: > On Wednesday, June 26, 2019 6:10 PM(GMT+9), Adrien Nayrat wrote: >> As far as I remember, you should see "relation" wait events (type lock) on >> standby server. This is due to startup process acquiring AccessExclusiveLock >&g

Re: [PATCH] Speedup truncates of relation forks

On 6/12/19 10:29 AM, Jamison, Kirk wrote: > >> From a user POW, the main issue with relation truncation is that it can block >> queries on standby server during truncation replay. >> >> It could be interesting if you can test this case and give results of your >> path. >> Maybe by performing read

Re: Detailed questions about pg_xact_commit_timestamp

Hi, On 7/9/19 12:22 AM, Morris de Oryx wrote: > I have some specific questions about pg_xact_commit_timestamp, and am hoping > that this is the right place to ask. I read a lot of the commentary about the > original patch, and the contributors seem to be here. If I'm asking in the > wrong >

Re: Feature: Add Greek language fulltext search

On 7/4/19 1:39 PM, Peter Eisentraut wrote: > On 2019-03-25 12:04, Panagiotis Mavrogiorgos wrote: >> Last November snowball added support for Greek language [1]. Following >> the instructions [2], I wrote a patch that adds fulltext search for >> Greek in Postgres. The patch is attached.  > > I

Re: idea: log_statement_sample_rate - bottom limit for sampling

The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: tested, failed Spec compliant: tested, failed Documentation:tested, failed I test the latest patch attached to this thread

Re: idea: log_statement_sample_rate - bottom limit for sampling

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed Sorry, I forgot to tick "passed" boxes.

Re: Optimizer items in the release notes

On 4/22/19 6:54 PM, Bruce Momjian wrote: We had a discussion in October about adding more optimizer items to the release notes: https://www.postgresql.org/message-id/flat/20181010220601.GA7807%40momjian.us#11d805ea0b0fcd0552dfa99251417cc1 There was no agreement on a change, but if

Re: Detailed questions about pg_xact_commit_timestamp

On 7/12/19 2:50 PM, Morris de Oryx wrote: > Adrien, thanks very much for answering my question. Just a couple of follow-up > points, if you don't mind. > > In our answer, you offer an example of pg_xact_commit_timestamp showing > out-of-sequence commit times: > > Session     xid          

Re: Proposal: roll pg_stat_statements into core

On 9/1/19 8:54 PM, Tom Lane wrote: >> - The overhead for most use cases is low compared to the benefit. > Please do not expect that we're going to accept such assertions > unsupported by evidence. (As a very quick-n-dirty test, I tried > "pgbench -S" and got somewhere around 4% TPS degradation

Re: idea: log_statement_sample_rate - bottom limit for sampling

On 7/28/19 12:19 AM, Tomas Vondra wrote: > Hi, > > I've started reviewing this patch, thinking that maybe I could get it > committed as it's marked as RFC. In general I agree with having this > fuature, but I think we need to rethink the GUC because the current > approach is just confusing. > >

Re: idea: log_statement_sample_rate - bottom limit for sampling

Hi, As we are at the end of this CF and there is still discussions about whether we should revert log_statement_sample_limit and log_statement_sample_rate, or try to fix it in v12. I moved this patch to next commit fest and change status from "ready for commiter" to "need review". I hope I didn't

Re: idea: log_statement_sample_rate - bottom limit for sampling

On 8/1/19 12:04 PM, Tomas Vondra wrote: > On Thu, Aug 01, 2019 at 11:47:46AM +0200, Adrien Nayrat wrote: >> Hi, >> >> As we are at the end of this CF and there is still discussions about whether >> we >> should revert log_statement_sample_limit and log_statement_

Re: Log statement sample - take two

On 11/4/19 2:08 AM, Tomas Vondra wrote: > > Seems fine to me, mostly. I think the docs should explain how > log_min_duration_statement interacts with log_min_duration_sample. > Attached is a patch doing that, by adding one para to each GUC, along > with some minor rewordings. I think the docs are

Re: Adding percentile metrics to pg_stat_statements module

some kind of sampling or add the possibility to collect only for a specific queryid. I dreamed of this kind of feature for PoWA. Thus, it could make possible to compare CDF between two days for example, before and after introducing a change. Regards, -- Adrien NAYRAT

Re: Log statement sample - take two

On 11/6/19 7:16 PM, Tomas Vondra wrote: > Pushed, with some minor tweaks and rewording to the documentation. > > The first bit, documenting the log_transaction_sample_rate as PG_SUSET, > got backpatched to 12, where it was introduced. > > regards > Thanks Tomas! -- Adrien

Re: idea: log_statement_sample_rate - bottom limit for sampling

On 11/6/19 7:21 PM, Tomas Vondra wrote: > I've pushed the reworked version of log_statement_sample_rate patch [1]. > If I understand correctly, that makes this patch unnecessary, and we > should mark it as rejected. Or do we still need it? Yes, the goal of this patch was to disable sampling and

Log statement sample - take two

tgresql.git;a=commit;h=75506195da81d75597a4025b72f8367e6c45f60d 3: https://www.postgresql.org/message-id/CAFj8pRDS8tQ3Wviw9%3DAvODyUciPSrGeMhJi_WPE%2BEB8%2B4gLL-Q%40mail.gmail.com 4: https://www.postgresql.org/message-id/20190727221948.irg6sfqh57dynoc7%40development -- Adrien NAYRAT diff --git a/doc/src/sgml/conf

pg_dump fail to not dump public schema orders

t0 FROM "C"' # Failed test 'only_dump_test_schema: should not dump REVOKE CREATE ON SCHEMA public FROM public' Regards, commit ea7c208e5ca1aedc20a49eb800ae60d4292086bf Author: Adrien Nayrat Date: Fri May 29 14:57:41 2020 +0200 Add pg_dump test for only dump public schema diff --git

Re: pg_dump fail to not dump public schema orders

On 5/29/20 3:56 PM, David G. Johnston wrote: > On Friday, May 29, 2020, Adrien Nayrat <mailto:adrien.nay...@anayrat.info>> wrote: > > Hello, > > I noticed pg_dump failed to not dump creation or comment commands for > public > schema when we explicitl

OpenSSL v3 performance regressions

? Regards, -- Adrien NAYRAT

Re: different engine for JIT

https://github.com/higuoxing/pg_asmjit It is good to see interest in this area. Current implementation is quite expensive and costing model risky. If often recommend disabling it and enabling it when it is really needed. (It is disabled by default on AWS). Regards, -- Adrien NAYRAT