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 по дате отправления: