Re: pgsql: Add wait event for fsync of WAL segments

2018-07-08 Thread Julien Rouhaud
Hi Michael, On Mon, Jul 2, 2018 at 3:23 PM, Michael Paquier wrote: > Add wait event for fsync of WAL segments > > Modified Files > -- > doc/src/sgml/monitoring.sgml | 4 I just noticed that the number of rows for the IO wait event type documentation hasn't been updated, see

Re: pgsql: Track block level checksum failures in pg_stat_database

2019-04-30 Thread Julien Rouhaud
On Tue, Apr 30, 2019 at 6:33 PM Tomas Vondra wrote: > > On Sat, Mar 09, 2019 at 06:48:11PM +, Magnus Hagander wrote: > >Track block level checksum failures in pg_stat_database > > > >This adds a column that counts how many checksum failures have occurred > >on files belonging to a specific dat

Re: pgsql: Track block level checksum failures in pg_stat_database

2019-04-30 Thread Julien Rouhaud
On Tue, Apr 30, 2019 at 11:56 PM Tom Lane wrote: > > Julien Rouhaud writes: > > On Tue, Apr 30, 2019 at 6:33 PM Tomas Vondra > > wrote: > >> It seems this commit forgot to add PgStat_MsgChecksumFailure to the > >> PgStat_Msg union. > > > Oops, indeed

Re: pgsql: Track block level checksum failures in pg_stat_database

2019-05-01 Thread Julien Rouhaud
On Wed, May 1, 2019 at 12:48 AM Julien Rouhaud wrote: > > On Tue, Apr 30, 2019 at 11:56 PM Tom Lane wrote: > > > > Julien Rouhaud writes: > > > On Tue, Apr 30, 2019 at 6:33 PM Tomas Vondra > > > wrote: > > >> It seems this commit forgot to add Pg

Re: pgsql: Track block level checksum failures in pg_stat_database

2019-05-01 Thread Julien Rouhaud
On Wed, May 1, 2019 at 12:04 PM Magnus Hagander wrote: > > Looks good to me in general > > I don't see the reasoning behind changing the name from msg_autovacuum to > msg_autovacuum_start anywhere, perhaps I missed a part of the discussion? Was > that a change intended to be part of it? That wa

Re: pgsql: Track block level checksum failures in pg_stat_database

2019-05-01 Thread Julien Rouhaud
On Wed, May 1, 2019 at 12:35 PM Magnus Hagander wrote: > > On Wed, May 1, 2019 at 12:12 PM Julien Rouhaud wrote: >> >> On Wed, May 1, 2019 at 12:04 PM Magnus Hagander wrote: >> > >> > Looks good to me in general >> > >> > I don't see th

Re: pgsql: Move pg_stat_statements query jumbling to core.

2021-04-07 Thread Julien Rouhaud
Le jeu. 8 avr. 2021 à 13:17, Andres Freund a écrit : > > This - or something in the vicinity - seems to break running the > regression tests with force_parallel_mode=regress. There's lots of > differences like > > SELECT query, calls, rows FROM pg_stat_statements ORDER BY query COLLATE > "C"; >

Re: pgsql: Move pg_stat_statements query jumbling to core.

2021-04-07 Thread Julien Rouhaud
On Thu, Apr 08, 2021 at 01:22:49PM +0800, Julien Rouhaud wrote: > Le jeu. 8 avr. 2021 à 13:17, Andres Freund a écrit : > > > > > This - or something in the vicinity - seems to break running the > > regression tests with force_parallel_mode=regress. There's

Re: pgsql: Move pg_stat_statements query jumbling to core.

2021-04-07 Thread Julien Rouhaud
On Thu, Apr 08, 2021 at 12:08:02PM +0530, Amit Kapila wrote: > On Thu, Apr 8, 2021 at 11:40 AM Julien Rouhaud wrote: > > > > That was indeed the problem. I think the best is to entirely ignore > > parallel > > workers in pg_stat_statements, > > > > I

Re: pgsql: Move pg_stat_statements query jumbling to core.

2021-04-08 Thread Julien Rouhaud
On Thu, Apr 08, 2021 at 02:52:26PM +0530, Amit Kapila wrote: > > Yeah, we do pass instrumentation flags from leader to worker but not > the one allocated via pg_stat_staments (pgss_ExecutorStart {... > queryDesc->totaltime ...}. Ah indeed, I now remember that problem that I had to deal with in so

Re: pgsql: Move pg_stat_statements query jumbling to core.

2021-04-08 Thread Julien Rouhaud
On Thu, Apr 08, 2021 at 03:52:02PM +0530, Amit Kapila wrote: > On Thu, Apr 8, 2021 at 3:11 PM Julien Rouhaud wrote: > > > > On Thu, Apr 08, 2021 at 02:52:26PM +0530, Amit Kapila wrote: > > > > > > Yeah, we do pass instrumentation flags from leader to worker bu

Re: pgsql: Move pg_stat_statements query jumbling to core.

2021-04-08 Thread Julien Rouhaud
On Thu, Apr 08, 2021 at 11:16:24AM -0400, Bruce Momjian wrote: > On Thu, Apr 8, 2021 at 02:11:02PM +0800, Julien Rouhaud wrote: > > > oh, I think it's because parallel workers now have the queryid of the main > > > query. Probably ignoring parallel workers in the executo

Re: pgsql: doc: first draft of the PG 14 release notes

2021-05-09 Thread Julien Rouhaud
On Mon, May 10, 2021 at 05:59:09AM +, Bruce Momjian wrote: > doc: first draft of the PG 14 release notes I just spotted a minor typo: +Improve tab completion (Vignesh C,, Michael [...] The comma is duplicated.

Re: pgsql: Add option to use ICU as global locale provider

2022-03-17 Thread Julien Rouhaud
Hi, On Fri, Mar 18, 2022 at 11:01:11AM +0900, Michael Paquier wrote: > > FYI, prion is complaining here: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prion&dt=2022-03-18%2001%3A43%3A13 > > Some details: > # Failed test 'fails for invalid ICU locale: matches' > # at t/001_initdb.p

Re: pgsql: Add option to use ICU as global locale provider

2022-03-17 Thread Julien Rouhaud
On Fri, Mar 18, 2022 at 06:15:47PM +1300, Thomas Munro wrote: > > No idea what's happening here but one observation is that that animal > is running an older distro that shipped with ICU 5.0. Commit b8f9a2a6 > may hold a clue... Right. I'm setting up a similar podman environment, hopefully more

Re: pgsql: Add option to use ICU as global locale provider

2022-03-18 Thread Julien Rouhaud
On Fri, Mar 18, 2022 at 02:36:48PM +0800, Julien Rouhaud wrote: > On Fri, Mar 18, 2022 at 06:15:47PM +1300, Thomas Munro wrote: > > > > No idea what's happening here but one observation is that that animal > > is running an older distro that shipped with ICU 5.0. Comm

Re: pgsql: Add backtrace support for error reporting

2019-11-09 Thread Julien Rouhaud
On Fri, Nov 8, 2019 at 11:30 PM Amit Langote wrote: > > On Sat, Nov 9, 2019 at 3:52 Alvaro Herrera wrote: >> >> Add backtrace support for error reporting > > > Yay, thanks! +1 that's very cool!

Re: pgsql: Make parser rely more heavily on the ParseNamespaceItem data str

2020-01-02 Thread Julien Rouhaud
On Thu, Jan 2, 2020 at 6:41 PM Tom Lane wrote: > > Tom Lane writes: > > Make parser rely more heavily on the ParseNamespaceItem data structure. > > Hmm, the buildfarm seems to think this screwed up something affecting > collations. Looking ... My animal is using fr_FR collation by default, and

Re: pgsql: Make parser rely more heavily on the ParseNamespaceItem data str

2020-01-02 Thread Julien Rouhaud
On Thu, Jan 2, 2020 at 7:50 PM Tom Lane wrote: > > Julien Rouhaud writes: > > On Thu, Jan 2, 2020 at 6:41 PM Tom Lane wrote: > >> Hmm, the buildfarm seems to think this screwed up something affecting > >> collations. Looking ... > > > Is ORDER BY 1 CO

Re: pgsql: Include information on buffer usage during planning phase, in EX

2020-04-03 Thread Julien Rouhaud
On Fri, Apr 03, 2020 at 03:24:41PM +0900, Fujii Masao wrote: > > > On 2020/04/03 12:30, Tom Lane wrote: > > Fujii Masao writes: > > > On 2020/04/03 11:58, Michael Paquier wrote: > > > > prion did not like that: > > > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prion&dt=2020-04-03%2

Re: pgsql: Include information on buffer usage during planning phase, in EX

2020-04-03 Thread Julien Rouhaud
On Fri, Apr 03, 2020 at 09:27:38PM +0900, Fujii Masao wrote: > > > On 2020/04/03 16:43, Julien Rouhaud wrote: > > On Fri, Apr 03, 2020 at 03:24:41PM +0900, Fujii Masao wrote: > > > > > > > > > On 2020/04/03 12:30, Tom Lane wrote: > > > &

Re: pgsql: Include information on buffer usage during planning phase, in EX

2020-04-03 Thread Julien Rouhaud
On Fri, Apr 3, 2020 at 8:16 PM Fujii Masao wrote: > > On 2020/04/04 2:46, Tom Lane wrote: > > Fujii Masao writes: > >> Many thanks! Pushed. > > > > Looks like you didn't un-revert the main patch? > > Right now, pushed! I was waiting for my test to finish > without errors before commit. Anyway tha

Re: pgsql: Support FETCH FIRST WITH TIES

2020-04-11 Thread Julien Rouhaud
Hi Álvaro, On Tue, Apr 7, 2020 at 10:28 PM Alvaro Herrera wrote: > > Support FETCH FIRST WITH TIES > > WITH TIES is an option to the FETCH FIRST N ROWS clause (the SQL > standard's spelling of LIMIT), where you additionally get rows that > compare equal to the last of those N rows by the columns

Re: pgsql: Add pg_relation_check_pages() to check on-disk pages of a relati

2020-10-27 Thread Julien Rouhaud
Le mer. 28 oct. 2020 à 13:11, Michael Paquier a écrit : > On Wed, Oct 28, 2020 at 01:41:01PM +0900, Michael Paquier wrote: > > Yes, thanks. I was already investigating it. No need for a > > back-trace, I have been able to reproduce it here avec some -m32'ing > > with gcc: > > And this was just

Re: pgsql: Centralize horizon determination for temp tables, fixing bug due

2020-10-28 Thread Julien Rouhaud
On Thu, Oct 29, 2020 at 9:07 AM Andres Freund wrote: > > Centralize horizon determination for temp tables, fixing bug due to skew. Lapwing just reported some problem (https://brekka.postgresql.org/cgi-bin/show_log.pl?nm=lapwing&dt=2020-10-29%2002%3A40%3A14): === 1 of 93 test

Re: pgsql: Fix broken cast on MSVC

2022-08-29 Thread Julien Rouhaud
Hi, On Mon, Aug 29, 2022 at 10:45:43AM +, John Naylor wrote: > > +/* > + * Exactly like vector32_is_highbit_set except for the input type, so it > + * looks at each byte separately. > + * > + * [...] > + */ > +#ifndef USE_NO_SIMD > +static inline bool > +vector32_is_highbit_set(const Vector32

Re: pgsql: Refactor code handling the names of files loaded in hba.c

2022-10-25 Thread Julien Rouhaud
Hi, On Wed, Oct 26, 2022 at 02:53:08AM +, Michael Paquier wrote: > Refactor code handling the names of files loaded in hba.c For the record there is a couple of thinko in the extracted patch: @@ -1063,6 +1064,7 @@ HbaLine * parse_hba_line(TokenizedAuthLine *tok_line, int elevel) { int

Re: pgsql: Refactor code handling the names of files loaded in hba.c

2022-10-25 Thread Julien Rouhaud
On Wed, Oct 26, 2022 at 12:54:24PM +0900, Michael Paquier wrote: > On Wed, Oct 26, 2022 at 11:27:30AM +0800, Julien Rouhaud wrote: > > I fixed it in the v14 sent on the main thread, unfortunately sent a bit too > > late. > > Nya, yeah. It looks like I fat-fingered a

Re: pgsql: Extend sendFileWithContent() to handle custom content length in

2023-11-12 Thread Julien Rouhaud
Hi, On Sun, Nov 12, 2023 at 11:36:58PM +, Michael Paquier wrote: > Extend sendFileWithContent() to handle custom content length in basebackup.c > [...] > The patch extends sendFileWithContent() to be able to handle this case, > where len < 0 can be used to indicate an arbitrary length rather t