Re: Log a sample of transactions

Поиск
Список
Период
Сортировка
От Adrien NAYRAT
Тема Re: Log a sample of transactions
Дата
Msg-id 02704f8f-319c-6d52-a7ba-81659a74bfe6@anayrat.info
обсуждение исходный текст
Ответ на RE: Re: Log a sample of transactions  ("Kuroda, Hayato" <kuroda.hayato@jp.fujitsu.com>)
Ответы RE: Log a sample of transactions
Список pgsql-hackers
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 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
parameterbecomes  more than 1.
 

I don't understand what you want to do and I am afraid of the cost it 
could add.

There was a long discussion about random, maybe the thread could answer 
some of your questions?
https://www.postgresql.org/message-id/3859.1545849900%40sss.pgh.pa.us

Furthermore, I wonder if it is really necessary : the goal of this patch 
is to log a sample of transaction, not to perform precise stats 
computation. FIY we do not perform this kind of checks for 
log_statement_sample_rate.


> 
> After consideration for this case and rebasing, I think this patch is enough.
> Do I have to measure the change of throughput?
> 

I don't think it is necessary or maybe I am missing something. I already 
perform performance test for log_statement_sample_rate:
https://www.postgresql.org/message-id/8a608ccf-f78b-dfad-4c5f-8e6fd068c59c%40anayrat.info

It should be less expensive as we call random() for new transaction 
only. log_statement_sample_rate call it for each statement.

I don't know if there is cases where random() call could be slow?

There is still a point raised by Andres:


>> As far as I can tell xact_is_sampled is not properly reset in case of
>> errors?
>>
> 
> I am not sure if I should disable logging in case of errors. Actually we have:
> 
> postgres=# set log_transaction_sample_rate to 1;
> SET
> postgres=# set client_min_messages to 'LOG';
> LOG:  duration: 0.392 ms  statement: set client_min_messages to 'LOG';
> SET
> postgres=# begin;
> LOG:  duration: 0.345 ms  statement: begin;
> BEGIN
> postgres=# select 1;
> LOG:  duration: 0.479 ms  statement: select 1;
>  ?column?
> ----------
>         1
> (1 row)
> 
> postgres=# select * from missingtable;
> ERROR:  relation "missingtable" does not exist
> LINE 1: select * from missingtable;
>                       ^
> postgres=# select 1;
> ERROR:  current transaction is aborted, commands ignored until end of transaction block
> postgres=# rollback;
> LOG:  duration: 11390.295 ms  statement: rollback;
> ROLLBACK
> 
> If I reset xact_is_sampled (after the first error inside AbortTransaction if I am right), "rollback" statement will
notbe logged. I wonder if this "statement" should be logged?
 
> 
> If the answer is no, I will reset xact_is_sampled in AbortTransaction.


Thanks!


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alexander Korotkov
Дата:
Сообщение: Re: jsonpath
Следующее
От: "Imai, Yoshikazu"
Дата:
Сообщение: RE: speeding up planning with partitions