| From: | "Kuroda, Hayato" <kuroda(dot)hayato(at)jp(dot)fujitsu(dot)com> |
|---|---|
| To: | 'David Steele' <david(at)pgmasters(dot)net>, Adrien NAYRAT <adrien(dot)nayrat(at)anayrat(dot)info> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, "'pgsql-hackers(at)lists(dot)postgresql(dot)org'" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | RE: Re: Log a sample of transactions |
| Date: | 2019-03-26 00:54:48 |
| Message-ID: | 1F66B161998C704BABF8989B8A2AC0A31CDD2C@G01JPEXMBYT05 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Dear David,
I have a will and already read the patch, but I thought it's not my turn.
Sorry.
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 check_log_duration()):
> https://coverage.postgresql.org/src/backend/tcop/postgres.c.gcov.html
I understand the unnecessarily of some test case. It's OK.
Finally, how do you think about the deviation of randomness?
If this parameter is set very low, nobody may be output because of the deviation.
we can avoid this phenomenon by counting up internal parameter for each transactions and output to log file if the parameter becomes more than 1.
After consideration for this case and rebasing, I think this patch is enough.
Do I have to measure the change of throughput?
Best Regards,
Hayato Kuroda
Fujitsu LIMITED
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tatsuro Yamada | 2019-03-26 01:04:48 | Re: [HACKERS] CLUSTER command progress monitor |
| Previous Message | Andres Freund | 2019-03-26 00:44:42 | setLastTid() and currtid() |