Re: What is pg_stat_user_tables Showing NULL for last_autoanalyze & last_autovacuum

[Laurenz Albe]

On Wed, 2019-02-27 at 09:47 -0500, Fd Habash wrote:
> I have been able to locate four google search results with the same inquiry. 
> What’ve been able to understand is …
>  
> If auto-vaccum is working as expected, stats collector does not nullify these 
> values as part of a
> startup sequence or regular Maitenance. If a relation gets 
> auto[vacuumed|analyzed], the timestamps should remain.
> A database engine crash or restart with ‘immediate’ option will cause the 
> timestamps to nullify.
> Table never qualified for vacuuming based on auto-vacuum settings.
>  
> I can rule out all three scenarios above, but I still see null values. What 
> else could be at play here?

The obvious suspicion is that autovacuum starts, but cannot finish because it 
either
cannot keep up with the change rate or gives up because it is blocking a 
concurrent
session.

What is "n_live_tup" and "n_dead_tup" in "pg_stat_user_tables" for these tables?
Are there any autovacuum workers running currently?

Yours,
Laurenz Albe
-- 
Cybertec | https://www.cybertec-postgresql.com

How to get the content of Bind variables

[ROS Didier]

Hi
   In the log file of my PostgreSQL cluster, I find :
>>
Statement: update t_shared_liste_valeurs set deletion_date=$1, 
deletion_login=$2, modification_date=$3, modification_login=$4, 
administrable=$5, libelle=$6, niveau=$7 where code=$8
<<


è how to get the content of the bind variables ?

Thanks in advance

Best Regards
[cid:image002.png@01D14E0E.8515EB90]


Didier ROS
Expertise SGBD
EDF - DTEO - DSIT - IT DMA
Département Solutions Groupe
Groupe Performance Applicative
32 avenue Pablo Picasso
92000 NANTERRE

didier@edf.fr
Tél. : +33 6 49 51 11 88
[cid:image003.png@01D4BE20.1EAF68B0][cid:image004.png@01D4BE20.1EAF68B0]






Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à 
l'intention exclusive des destinataires et les informations qui y figurent sont 
strictement confidentielles. Toute utilisation de ce Message non conforme à sa 
destination, toute diffusion ou toute publication totale ou partielle, est 
interdite sauf autorisation expresse.

Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le 
copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si 
vous avez reçu ce Message par erreur, merci de le supprimer de votre système, 
ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support 
que ce soit. Nous vous remercions également d'en avertir immédiatement 
l'expéditeur par retour du message.

Il est impossible de garantir que les communications par messagerie 
électronique arrivent en temps utile, sont sécurisées ou dénuées de toute 
erreur ou virus.


This message and any attachments (the 'Message') are intended solely for the 
addressees. The information contained in this Message is confidential. Any use 
of information contained in this Message not in accord with its purpose, any 
dissemination or disclosure, either whole or partial, is prohibited except 
formal approval.

If you are not the addressee, you may not copy, forward, disclose or use any 
part of it. If you have received this message in error, please delete it and 
all copies from your system and notify the sender immediately by return message.

E-mail communication cannot be guaranteed to be timely secure, error or 
virus-free.

Re: How to get the content of Bind variables

[MichaelDBA]

If you set log_min_duration_statement low enough for your particular 
query, you will see another line below it showing what values are 
associated with each bind variable like this:


2019-02-28 00:07:55CST 2019-02-2800:02:09CST ihr2 10.86.42.184(43460) 
SELECT LOG:  duration: 26078.308 ms  execute : select 
pg_advisory_lock($1)


2019-02-28 00:07:55CST 2019-02-2800:02:09CST ihr2 10.86.42.184(43460) 
SELECT DETAIL:  parameters: $1 = '3428922050323511872'


Regards,
Michael Vitale

ROS Didier 
Thursday, February 28, 2019 7:21 AM

Hi

In the log file of my PostgreSQL cluster, I find :

>>

*Statement:*update t_shared_liste_valeurs set deletion_date=*$1*, 
deletion_login=*$2*, modification_date=*$3*, modification_login=*$4*, 
administrable=*$5*, libelle=*$6*, niveau=*$7* where code=*$8*


<<

èhow to get the content of the bind variables ?

Thanks in advance

Best Regards

cid:image002.png@01D14E0E.8515EB90



*
**Didier ROS*

*Expertise SGBD*

EDF - DTEO - DSIT - IT DMA

Département Solutions Groupe

Groupe Performance Applicative

32 avenue Pablo Picasso

92000 NANTERRE

_didier*.r...@edf.fr* _

Tél. : +33 6 49 51 11 88

cid:image003.png@01D4BE20.1EAF68B0 
cid:image004.png@01D4BE20.1EAF68B0 




Ce message et toutes les pièces jointes (ci-après le 'Message') sont 
établis à l'intention exclusive des destinataires et les informations 
qui y figurent sont strictement confidentielles. Toute utilisation de 
ce Message non conforme à sa destination, toute diffusion ou toute 
publication totale ou partielle, est interdite sauf autorisation expresse.


Si vous n'êtes pas le destinataire de ce Message, il vous est interdit 
de le copier, de le faire suivre, de le divulguer ou d'en utiliser 
tout ou partie. Si vous avez reçu ce Message par erreur, merci de le 
supprimer de votre système, ainsi que toutes ses copies, et de n'en 
garder aucune trace sur quelque support que ce soit. Nous vous 
remercions également d'en avertir immédiatement l'expéditeur par 
retour du message.


Il est impossible de garantir que les communications par messagerie 
électronique arrivent en temps utile, sont sécurisées ou dénuées de 
toute erreur ou virus.



This message and any attachments (the 'Message') are intended solely 
for the addressees. The information contained in this Message is 
confidential. Any use of information contained in this Message not in 
accord with its purpose, any dissemination or disclosure, either whole 
or partial, is prohibited except formal approval.


If you are not the addressee, you may not copy, forward, disclose or 
use any part of it. If you have received this message in error, please 
delete it and all copies from your system and notify the sender 
immediately by return message.


E-mail communication cannot be guaranteed to be timely secure, error 
or virus-free.

RE: How to get the content of Bind variables

[ROS Didier]

Hi
   Thanks for the answer.

I have  in my postgresql.conf :
log_min_duration_statement=0
and the content of bind variables is not showed in the log file.
What can I do to get the content of the bind variables ?

Best Regard
[cid:image002.png@01D14E0E.8515EB90]


Didier ROS
Expertise SGBD
EDF - DTEO - DSIT - IT DMA
Département Solutions Groupe
Groupe Performance Applicative
32 avenue Pablo Picasso
92000 NANTERRE

didier@edf.fr
Tél. : +33 6 49 51 11 88
[cid:image003.png@01D4BE20.1EAF68B0][cid:image004.png@01D4BE20.1EAF68B0]



De : michael...@sqlexec.com [mailto:michael...@sqlexec.com]
Envoyé : jeudi 28 février 2019 13:37
À : ROS Didier 
Cc : pgsql-performa...@postgresql.org
Objet : Re: How to get the content of Bind variables

If you set log_min_duration_statement low enough for your particular query, you 
will see another line below it showing what values are associated with each 
bind variable like this:
2019-02-28 00:07:55 CST 2019-02-28 00:02:09 CST ihr2 10.86.42.184(43460) SELECT 
LOG:  duration: 26078.308 ms  execute : select pg_advisory_lock($1)
2019-02-28 00:07:55 CST 2019-02-28 00:02:09 CST ihr2 10.86.42.184(43460) SELECT 
DETAIL:  parameters: $1 = '3428922050323511872'

Regards,
Michael Vitale

ROS Didier
Thursday, February 28, 2019 7:21 AM
Hi
   In the log file of my PostgreSQL cluster, I find :
>>
Statement: update t_shared_liste_valeurs set deletion_date=$1, 
deletion_login=$2, modification_date=$3, modification_login=$4, 
administrable=$5, libelle=$6, niveau=$7 where code=$8
<<


è how to get the content of the bind variables ?

Thanks in advance

Best Regards
[cid:image002.png@01D14E0E.8515EB90]


Didier ROS
Expertise SGBD
EDF - DTEO - DSIT - IT DMA
Département Solutions Groupe
Groupe Performance Applicative
32 avenue Pablo Picasso
92000 NANTERRE

didier@edf.fr
Tél. : +33 6 49 51 11 88
[cid:image003.png@01D4BE20.1EAF68B0][cid:image004.png@01D4BE20.1EAF68B0]




Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à 
l'intention exclusive des destinataires et les informations qui y figurent sont 
strictement confidentielles. Toute utilisation de ce Message non conforme à sa 
destination, toute diffusion ou toute publication totale ou partielle, est 
interdite sauf autorisation expresse.

Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le 
copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si 
vous avez reçu ce Message par erreur, merci de le supprimer de votre système, 
ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support 
que ce soit. Nous vous remercions également d'en avertir immédiatement 
l'expéditeur par retour du message.

Il est impossible de garantir que les communications par messagerie 
électronique arrivent en temps utile, sont sécurisées ou dénuées de toute 
erreur ou virus.


This message and any attachments (the 'Message') are intended solely for the 
addressees. The information contained in this Message is confidential. Any use 
of information contained in this Message not in accord with its purpose, any 
dissemination or disclosure, either whole or partial, is prohibited except 
formal approval.

If you are not the addressee, you may not copy, forward, disclose or use any 
part of it. If you have received this message in error, please delete it and 
all copies from your system and notify the sender immediately by return message.

E-mail communication cannot be guaranteed to be timely secure, error or 
virus-free.




Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à 
l'intention exclusive des destinataires et les informations qui y figurent sont 
strictement confidentielles. Toute utilisation de ce Message non conforme à sa 
destination, toute diffusion ou toute publication totale ou partielle, est 
interdite sauf autorisation expresse.

Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le 
copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si 
vous avez reçu ce Message par erreur, merci de le supprimer de votre système, 
ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support 
que ce soit. Nous vous remercions également d'en avertir immédiatement 
l'expéditeur par retour du message.

Il est impossible de garantir que les communications par messagerie 
électronique arrivent en temps utile, sont sécurisées ou dénuées de toute 
erreur ou virus.


This message and any attachments (the 'Message') are intended solely for the 
addressees. The information contained in this Message is confidential. Any use 
of information contained in this Message not in accord with its purpose, any 
dissemination or disclosure, either 

pgsql-performance@lists.postgresql.org

[Fd Habash]

Thank you …

Are the calculations for triggering autovacuum dependent upon statistics 
generated by auto-anaylyze. In other words, if autoanalyze does not run at all, 
will autovac be able to run its math for threshold (updates & deletes) & scale 
factor (table rows) to do its thing?

My understanding from the documentation is that it does not need autoanalyze 
stats.

Thanks 


Thank you

From: Justin Pryzby
Sent: Wednesday, February 27, 2019 11:15 AM
To: Fd Habash
Cc: pgsql-performa...@postgresql.org
Subject: Re: What is pg_stat_user_tables Showing NULL for last_autoanalyze 
&last_autovacuum

On Wed, Feb 27, 2019 at 09:47:13AM -0500, Fd Habash wrote:
> I have been able to locate four google search results with the same inquiry. 
> What’ve been able to understand is …
> 
> 1. If auto-vaccum is working as expected, stats collector does not nullify 
> these values as part of a startup sequence or regular Maitenance. If a 
> relation gets auto[vacuumed|analyzed], the timestamps should remain.
> 2. A database engine crash or restart with ‘immediate’ option will cause the 
> timestamps to nullify. 
> 3. Table never qualified for vacuuming based on auto-vacuum settings. 

Can you give an example ?

If it's an empty inheritence parent (relkind=r), then it won't trigger
autovacuum/analyze thresholds (but you should analyze it manually).

Note that relkind=p "partitioned" tables don't have entries at all.
https://www.postgresql.org/message-id/flat/20180503141430.GA28019%40telsasoft.com

If it's never DELETEd from, then it won't trigger autovacuum (but may trigger
autoanalyze).

Justin

Re: How to get the content of Bind variables

[Laurenz Albe]

ROS Didier wrote:
>In the log file of my PostgreSQL cluster, I find :
> >> 
> Statement: update t_shared_liste_valeurs set deletion_date=$1, 
> deletion_login=$2, modification_date=$3, modification_login=$4, 
> administrable=$5, libelle=$6, niveau=$7 where code=$8
> << 
>  
> how to get the content of the bind variables ?

Can we see the whole log entry and the following one?

Perhaps there was a syntax error or similar, and the statement was never 
executed.

Yours,
Laurenz Albe
-- 
Cybertec | https://www.cybertec-postgresql.com

RE: How to get the content of Bind variables

[ROS Didier]

Hi Laurent

Here is a biggest part of my log file :

>>
 2019-02-27 14:41:28 CET [16239]: [5696-1] [10086] 
user=pgbd_preint_sg2,db=pgbd_preint_sg2,client=localhost.localdomainLOG:  
duration: 1.604 ms
2019-02-27 14:41:28 CET [16239]: [5697-1] [10086] 
user=pgbd_preint_sg2,db=pgbd_preint_sg2,client=localhost.localdomainLOG:  
duration: 0.084 ms  parse : update t_shared_liste_valeurs set 
deletion_date=$1, deletion_login=$2, modification_date=$3, 
modification_login=$4, administrable=$5, libelle=$6, niveau=$7 where code=$8
2019-02-27 14:41:28 CET [16239]: [5698-1] [10086] 
user=pgbd_preint_sg2,db=pgbd_preint_sg2,client=localhost.localdomainLOG:  plan:
2019-02-27 14:41:28 CET [16239]: [5699-1] [10086] 
user=pgbd_preint_sg2,db=pgbd_preint_sg2,client=localhost.localdomainSTATEMENT:  
update t_shared_liste_valeurs set deletion_date=$1, deletion_login=$2, 
modification_date=$3, modification_login=$4, administrable=$5, libelle=$6, 
niveau=$7 where code=$8
2019-02-27 14:41:28 CET [16239]: [5700-1] [10086] 
user=pgbd_preint_sg2,db=pgbd_preint_sg2,client=localhost.localdomainLOG:  
duration: 0.288 ms  bind : update t_shared_liste_valeurs set 
deletion_date=$1, deletion_login=$2, modification_date=$3, 
modification_login=$4, administrable=$5, libelle=$6, niveau=$7 where code=$8
2019-02-27 14:41:28 CET [16239]: [5701-1] [10086] 
user=pgbd_preint_sg2,db=pgbd_preint_sg2,client=localhost.localdomainLOG:  
execute : update t_shared_liste_valeurs set deletion_date=$1, 
deletion_login=$2, modification_date=$3, modification_login=$4, 
administrable=$5, libelle=$6, niveau=$7 where code=$8
<<
The statement has been executed
It is the same problem for all the statements.
I can not get the content of the bind variables.


Didier ROS
Expertise SGBD
EDF - DTEO - DSIT - IT DMA
Département Solutions Groupe
Groupe Performance Applicative
32 avenue Pablo Picasso
92000 NANTERRE
 
didier@edf.fr
Tél. : +33 6 49 51 11 88


-Message d'origine-
De : laurenz.a...@cybertec.at [mailto:laurenz.a...@cybertec.at] 
Envoyé : jeudi 28 février 2019 17:01
À : ROS Didier ; pgsql-performa...@postgresql.org
Objet : Re: How to get the content of Bind variables

ROS Didier wrote:
>In the log file of my PostgreSQL cluster, I find :
> >> 
> Statement: update t_shared_liste_valeurs set deletion_date=$1, 
> deletion_login=$2, modification_date=$3, modification_login=$4, 
> administrable=$5, libelle=$6, niveau=$7 where code=$8 <<
>  
> how to get the content of the bind variables ?

Can we see the whole log entry and the following one?

Perhaps there was a syntax error or similar, and the statement was never 
executed.

Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com




Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à 
l'intention exclusive des destinataires et les informations qui y figurent sont 
strictement confidentielles. Toute utilisation de ce Message non conforme à sa 
destination, toute diffusion ou toute publication totale ou partielle, est 
interdite sauf autorisation expresse.

Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le 
copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si 
vous avez reçu ce Message par erreur, merci de le supprimer de votre système, 
ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support 
que ce soit. Nous vous remercions également d'en avertir immédiatement 
l'expéditeur par retour du message.

Il est impossible de garantir que les communications par messagerie 
électronique arrivent en temps utile, sont sécurisées ou dénuées de toute 
erreur ou virus.


This message and any attachments (the 'Message') are intended solely for the 
addressees. The information contained in this Message is confidential. Any use 
of information contained in this Message not in accord with its purpose, any 
dissemination or disclosure, either whole or partial, is prohibited except 
formal approval.

If you are not the addressee, you may not copy, forward, disclose or use any 
part of it. If you have received this message in error, please delete it and 
all copies from your system and notify the sender immediately by return message.

E-mail communication cannot be guaranteed to be timely secure, error or 
virus-free.

Re: How to get the content of Bind variables

[Justin Pryzby]

On Thu, Feb 28, 2019 at 12:21:56PM +, ROS Didier wrote:
> Statement: update t_shared_liste_valeurs set deletion_date=$1, 
> deletion_login=$2, modification_date=$3, modification_login=$4, 
> administrable=$5, libelle=$6, niveau=$7 where code=$8
> 
> è how to get the content of the bind variables ?

What is your setting of log_error_verbosity ?
https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-ERROR-VERBOSITY

Also, I recommend using CSV logs, since they're easier to import into the DB
and then easier to parse.
https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-ERROR-VERBOSITY

Also, note that you can either set log_min_duration_statement=0, which logs all
statement durations, and associated statements (if they haven't been previously
logged).

Or, you can set log_statement=all, which logs all statements (but duration is
only logged according to log_min_duration_statement).

Justin

Re: Performance regressions found using sqlfuzz

[Jung, Jinho]

Hi Andres:

Could you please share your thoughts on QUERY 3?

The performance impact of this regression increases *linearly* on larger 
databases. We concur with Andrew in that this is related to the lack of a 
Materialize node and mis-costing of the Nested Loop Anti-Join.

We found more than 20 regressions related to this commit. We have shared two 
illustrative examples (QUERIES 3A and 3B) below.

- Commit: 77cd477 (Enable parallel query by default.)

- Summary: Execution Time (milliseconds)

When we increased the scale-factor of TPC-C to 300 (~30 GB), this query ran 
three times slower on v11 (24 seconds) in comparison to v9.5 (7 seconds). We 
also found more than 15 regressions related to the same commit and share a 
couple of them below.

+---++-+-+---+
|   | scale1 | scale10 | scale50 | scale 300 |
+---++-+-+---+
| Query 3 (v9.5)| 28 | 248 |1231 |  7265 |
| Query 3 (v11) | 74 | 677 |3345 | 24581 |
+---++-+-+---+
| Query 3A (v9.5)   | 88 | 937 |4721 | 27241 |
| Query 3A (v11)|288 |2822 |   13838 | 85081 |
+---++-+-+---+
| Query 3B (v9.5)   |101 | 934 |4824 | 29363 |
| Query 3B (v11)|200 |2331 |   12327 | 74110 |
+---++-+-+---+


## QUERY 3:

select
 cast(ref_1.ol_i_id as int4) as c0
from
 public.stock as ref_0
   left join public.order_line as ref_1
   on (ref_1.ol_number is not null)
where ref_1.ol_number is null


## QUERY 3A:

select
  ref_0.ol_delivery_d as c1
from
  public.order_line as ref_0
where EXISTS (
  select
ref_1.i_im_id as c0
from
public.item as ref_1
where ref_0.ol_d_id <=  ref_1.i_im_id
  )

 Execution plan:

[OLD version]
Nested Loop Semi Join  (cost=0.00..90020417940.08 rows=30005835 width=8) 
(actual time=0.034..24981.895 rows=90017507 loops=1)
  Join Filter: (ref_0.ol_d_id <= ref_1.i_im_id)
  ->  Seq Scan on order_line ref_0  (cost=0.00..2011503.04 rows=90017504 
width=12) (actual time=0.022..7145.811 rows=90017507 loops=1)
  ->  Materialize  (cost=0.00..2771.00 rows=10 width=4) (actual 
time=0.000..0.000 rows=1 loops=90017507)
->  Seq Scan on item ref_1  (cost=0.00..2271.00 rows=10 width=4) 
(actual time=0.006..0.006 rows=1 loops=1)

Planning time: 0.290 ms
Execution time: 27241.239 ms

[NEW version]
Gather  (cost=1000.00..88047487498.82 rows=30005835 width=8) (actual 
time=0.265..82355.289 rows=90017507 loops=1)
  Workers Planned: 2
  Workers Launched: 2
  ->  Nested Loop Semi Join  (cost=0.00..88044485915.32 rows=12502431 width=8) 
(actual time=0.033..68529.259 rows=30005836 loops=3)
Join Filter: (ref_0.ol_d_id <= ref_1.i_im_id)
->  Parallel Seq Scan on order_line ref_0  (cost=0.00..1486400.93 
rows=37507293 width=12) (actual time=0.023..2789.901 rows=30005836 loops=3)
->  Seq Scan on item ref_1  (cost=0.00..2271.00 rows=10 width=4) 
(actual time=0.001..0.001 rows=1 loops=90017507)

Planning Time: 0.319 ms
Execution Time: 85081.158 ms


## QUERY 3B:


select
  ref_0.ol_i_id as c0
from
  public.order_line as ref_0
where EXISTS (
  select
ref_0.ol_delivery_d as c0
from
public.order_line as ref_1
where ref_1.ol_d_id <= cast(nullif(ref_1.ol_o_id, ref_0.ol_i_id) as int4))

Execution plan:

[OLD version]
Nested Loop Semi Join  (cost=0.00..115638730740936.53 rows=30005835 width=4) 
(actual time=0.017..27009.302 rows=90017507 loops=1)
  Join Filter: (ref_1.ol_d_id <= NULLIF(ref_1.ol_o_id, ref_0.ol_i_id))
  Rows Removed by Join Filter: 11557
  ->  Seq Scan on order_line ref_0  (cost=0.00..2011503.04 rows=90017504 
width=4) (actual time=0.009..7199.540 rows=90017507 loops=1)
  ->  Materialize  (cost=0.00..2813221.56 rows=90017504 width=8) (actual 
time=0.000..0.000 rows=1 loops=90017507)
->  Seq Scan on order_line ref_1  (cost=0.00..2011503.04 rows=90017504 
width=8) (actual time=0.001..0.002 rows=14 loops=1)

Planning time: 0.252 ms
Execution time: 29363.737 ms

[NEW version]
Gather  (cost=1000.00..84060490326155.39 rows=30005835 width=4) (actual 
time=0.272..71712.491 rows=90017507 loops=1)
  Workers Planned: 2
  Workers Launched: 2
  ->  Nested Loop Semi Join  (cost=0.00..84060487324571.89 rows=12502431 
width=4) (actual time=0.046..60153.472 rows=30005836 loops=3)
Join Filter: (ref_1.ol_d_id <= NULLIF(ref_1.ol_o_id, ref_0.ol_i_id))
Rows Removed by Join Filter: 1717
->  Parallel Seq Scan on order_line ref_0  (cost=0.00..1486400.93 
rows=37507293 width=4) (actual time=0.023..2819.361 rows=30005836 loops=3)
->  Seq Scan on order_line ref_1  (cost=0.00..2011503.04 rows=90017504 
width=8) (actual time=0.001..0.001 rows=1 loops=90017507)

Planning

RE: How to get the content of Bind variables

[ROS Didier]

Hi
Here is the information :

postgres=# show log_error_verbosity ;
 log_error_verbosity
-
 default
(1 row)


postgres=# show log_statement ;
 log_statement
---
 none
(1 row) 

I am trying now to set up log_statement :
log_statement=all ;
log_min_duration_statement=250;


Didier ROS
Expertise SGBD
EDF - DTEO - DSIT - IT DMA
Département Solutions Groupe
Groupe Performance Applicative
32 avenue Pablo Picasso
92000 NANTERRE
 
didier@edf.fr
Tél. : +33 6 49 51 11 88




-Message d'origine-
De : pry...@telsasoft.com [mailto:pry...@telsasoft.com] 
Envoyé : jeudi 28 février 2019 17:19
À : ROS Didier 
Cc : pgsql-performa...@postgresql.org
Objet : Re: How to get the content of Bind variables

On Thu, Feb 28, 2019 at 12:21:56PM +, ROS Didier wrote:
> Statement: update t_shared_liste_valeurs set deletion_date=$1, 
> deletion_login=$2, modification_date=$3, modification_login=$4, 
> administrable=$5, libelle=$6, niveau=$7 where code=$8
> 
> è how to get the content of the bind variables ?

What is your setting of log_error_verbosity ?
https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-ERROR-VERBOSITY

Also, I recommend using CSV logs, since they're easier to import into the DB 
and then easier to parse.
https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-ERROR-VERBOSITY

Also, note that you can either set log_min_duration_statement=0, which logs all 
statement durations, and associated statements (if they haven't been previously 
logged).

Or, you can set log_statement=all, which logs all statements (but duration is 
only logged according to log_min_duration_statement).

Justin



Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à 
l'intention exclusive des destinataires et les informations qui y figurent sont 
strictement confidentielles. Toute utilisation de ce Message non conforme à sa 
destination, toute diffusion ou toute publication totale ou partielle, est 
interdite sauf autorisation expresse.

Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le 
copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si 
vous avez reçu ce Message par erreur, merci de le supprimer de votre système, 
ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support 
que ce soit. Nous vous remercions également d'en avertir immédiatement 
l'expéditeur par retour du message.

Il est impossible de garantir que les communications par messagerie 
électronique arrivent en temps utile, sont sécurisées ou dénuées de toute 
erreur ou virus.


This message and any attachments (the 'Message') are intended solely for the 
addressees. The information contained in this Message is confidential. Any use 
of information contained in this Message not in accord with its purpose, any 
dissemination or disclosure, either whole or partial, is prohibited except 
formal approval.

If you are not the addressee, you may not copy, forward, disclose or use any 
part of it. If you have received this message in error, please delete it and 
all copies from your system and notify the sender immediately by return message.

E-mail communication cannot be guaranteed to be timely secure, error or 
virus-free.