Re: [HACKERS] [PATCH v3] pg_progress() SQL function to monitor progression of long running SQL queries/utilities

2017-08-01 19:57 GMT+02:00 Robert Haas <robertmh...@gmail.com>: > On Tue, Aug 1, 2017 at 12:35 PM, Remi Colinet <remi.coli...@gmail.com> > wrote: > > I did it in version 2 of the patch. > > I'am skeptical about the use of JSON, XML, and others in such output. > &g

Re: [HACKERS] [PATCH v3] pg_progress() SQL function to monitor progression of long running SQL queries/utilities

+ "blocks percent": 22, + "Filter": "(md5 ~~ '%cb%'::text)" + } + }

Re: [HACKERS] [PATCH v3] pg_progress() SQL function to monitor progression of long running SQL queries/utilities

2017-07-26 16:24 GMT+02:00 Pavel Stehule <pavel.steh...@gmail.com>: > > > 2017-07-26 15:27 GMT+02:00 Robert Haas <robertmh...@gmail.com>: > >> On Wed, Jun 21, 2017 at 10:01 AM, Remi Colinet <remi.coli...@gmail.com> >> wrote: >> > test=# SELECT

Re: [HACKERS] [PATCH v3] pg_progress() SQL function to monitor progression of long running SQL queries/utilities

2017-07-26 15:27 GMT+02:00 Robert Haas <robertmh...@gmail.com>: > On Wed, Jun 21, 2017 at 10:01 AM, Remi Colinet <remi.coli...@gmail.com> > wrote: > > test=# SELECT pid, ppid, bid, concat(repeat(' ', 3 * indent),name), > value, > > unit FROM pg_progr

Re: [HACKERS] [PATCH] pg_reload_backend to signal SIGHUP to a specific backend

Hi Yugo, The patch looks fine. Installed and tested. But a similar function already exists for the Postmaster process. Datum pg_reload_conf(PG_FUNCTION_ARGS) { if (kill(PostmasterPid, SIGHUP)) { ereport(WARNING, (errmsg("failed to

Re: [HACKERS] [PATCH v2] Progress command to monitor progression of long running SQL queries

2017-05-16 8:17 GMT+02:00 Michael Paquier : > On Sat, May 13, 2017 at 10:53 AM, Robert Haas > wrote: > > On Wed, May 10, 2017 at 10:05 PM, Michael Paquier > > wrote: > >> Regarding the patch, this is way to close to

Re: [HACKERS] [PATCH v2] Progress command to monitor progression of long running SQL queries

2017-05-13 14:38 GMT+02:00 Amit Kapila <amit.kapil...@gmail.com>: > On Wed, May 10, 2017 at 10:10 PM, Remi Colinet <remi.coli...@gmail.com> > wrote: > > > > Parallel queries can also be monitored. The same mecanism is used to > monitor > > child workers wi

Re: [HACKERS] [PATCH v2] Progress command to monitor progression of long running SQL queries

2017-05-13 3:53 GMT+02:00 Robert Haas : > On Wed, May 10, 2017 at 10:05 PM, Michael Paquier > wrote: > > Regarding the patch, this is way to close to the progress facility > > already in place. So why don't you extend it for the executor? > > I

Re: [HACKERS] [PATCH v2] Progress command to monitor progression of long running SQL queries

Stehule <pavel.steh...@gmail.com>: > Hi > > 2017-05-10 18:40 GMT+02:00 Remi Colinet <remi.coli...@gmail.com>: > >> Hello, >> >> This is version 2 of the new command name PROGRESS which I wrote in order >> to monitor long running SQL queries in a Postg

Re: [HACKERS] [PATCH v2] Progress command to monitor progression of long running SQL queries

2017-05-11 4:05 GMT+02:00 Michael Paquier <michael.paqu...@gmail.com>: > On Thu, May 11, 2017 at 1:40 AM, Remi Colinet <remi.coli...@gmail.com> > wrote: > > This is version 2 of the new command name PROGRESS which I wrote in > order to > > monitor long running

Re: [HACKERS] [PATCH v2] Progress command to monitor progression of long running SQL queries

parameters such as the backend pid and a format specification for the output. Regards Remi 2017-05-10 21:52 GMT+02:00 David Fetter <da...@fetter.org>: > On Wed, May 10, 2017 at 06:40:31PM +0200, Remi Colinet wrote: > > Hello, > > > > This is version 2 of the new command

Re: [HACKERS] [PATCH] New command to monitor progression of long running queries

a function with parameters and a view created on the function is the solution. Regards Remi 2017-05-06 5:57 GMT+02:00 Jaime Casanova <jaime.casan...@2ndquadrant.com>: > On 5 May 2017 at 22:38, Vinayak Pokale <vinpok...@gmail.com> wrote: > > > > On Mon, Apr 17, 20

Re: [HACKERS] [PATCH] New command to monitor progression of long running queries

Do you have more details about the failed tests? Regards, Remi 2017-05-06 5:38 GMT+02:00 Vinayak Pokale <vinpok...@gmail.com>: > > On Mon, Apr 17, 2017 at 9:09 PM, Remi Colinet <remi.coli...@gmail.com> > wrote: > >> Hello, >> >> I've implement

Re: [HACKERS] [PATCH] New command to monitor progression of long running queries

2017-04-19 18:41 GMT+02:00 Maksim Milyutin <m.milyu...@postgrespro.ru>: > On 19.04.2017 17:13, Remi Colinet wrote: > >> Maksim, >> >> >> 2017-04-18 20:31 GMT+02:00 Maksim Milyutin <m.milyu...@postgrespro.ru >> <mailto:m.milyu...@postgrespro.ru>&

Re: [HACKERS] [PATCH] New command to monitor progression of long running queries

PLAN PROGRESS ---- Sample Scan on t_10m => rows 4031400/5793292 69% blks 75625/10 75% Sampling: system ('50'::real) (2 rows) Wed 19 Apr 2017 04:44:15 PM CEST (every 1s) PLAN PROGRESS (1 ro

Re: [HACKERS] [PATCH] New command to monitor progression of long running queries

Maksim, 2017-04-18 20:31 GMT+02:00 Maksim Milyutin <m.milyu...@postgrespro.ru>: > On 18.04.2017 17:39, Remi Colinet wrote: > >> Hello Maksim, >> >> The core implementation I suggested for the new PROGRESS command uses >> different functions from

Re: [HACKERS] [PATCH] New command to monitor progression of long running queries

> Hi! > > > On 17.04.2017 15:09, Remi Colinet wrote: > >> Hello, >> >> I've implemented a new command named PROGRESS to monitor progression of >> long running SQL queries in a backend process. >> >> >> Use case >> === >> >> A use ca