Re: logging of Logical Decoding

Поиск
Список
Период
Сортировка
От Adrian Klaver
Тема Re: logging of Logical Decoding
Дата
Msg-id 549AF9A4.7000605@aklaver.com
обсуждение исходный текст
Ответ на Re: logging of Logical Decoding  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
On 12/24/2014 08:50 AM, Tom Lane wrote:
> Adrian Klaver <adrian.klaver@aklaver.com> writes:
>> On 12/24/2014 07:53 AM, Andrey Lizenko wrote:
>>> 2014-12-24 10:45:23 EST LOG:  starting logical decoding for slot
>>> "regression_slot"
>>> 2014-12-24 10:45:23 EST STATEMENT:  SELECT * FROM
>>> pg_logical_slot_get_changes('regression_slot', NULL, NULL);
>>> 2014-12-24 10:45:23 EST LOG:  logical decoding found consistent
>>> point at A/75000100
>>> 2014-12-24 10:45:23 EST STATEMENT:  SELECT * FROM
>>> pg_logical_slot_get_changes('regression_slot', NULL, NULL);
>
>> What you are looking for is to eliminate logging the statement entirely?
>> I would have though having log_statement = none would prevent that.
>
> No, this isn't logging any old statement that comes along, it's logging
> the statement that provoked the LOG message.  That's normal behavior.

Hmm, I missed the connection between starting logical decoding and
pg_logical_slot_get_changes. Time to do more reading on logical decoding.

>
> It is worth asking why these messages aren't DEBUG rather than LOG,
> but I don't see anything unexpected about the form of the output.
>
>             regards, tom lane
>


--
Adrian Klaver
adrian.klaver@aklaver.com


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: logging of Logical Decoding
Следующее
От: Andreas Ulbrich
Дата:
Сообщение: Check constraint on foreign table using SQL function