Re: Statement timeout in pg_rewind

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Statement timeout in pg_rewind
Дата
Msg-id 20190827063534.GG7422@paquier.xyz
обсуждение исходный текст
Ответ на Re: Statement timeout in pg_rewind  (Alexander Kukushkin <cyberdemn@gmail.com>)
Ответы Re: Statement timeout in pg_rewind  (Alexander Kukushkin <cyberdemn@gmail.com>)
Список pgsql-hackers
On Mon, Aug 26, 2019 at 03:42:46PM +0200, Alexander Kukushkin wrote:
> Well, I was thinking about it and came to the conclusion that we are
> neither taking heavy locks nor explicitly opening a transaction and
> therefore we can avoid changing them.
> But maybe you are right, having them set to the safe value shouldn't
> hurt.

I'd rather be on the safe side and as we are looking at this at this
area..  Who knows if this logic is going to change in the future and
how it will change.

> I don't think we can use the same wrapper for run_simple_query() and
> for places where we call a SET, because PQresultStatus() returns
> PGRES_TUPLES_OK and PGRES_COMMAND_OK respectively.
> Passing expected ExecStatusType to the wrapper for comparison is
> looking a bit ugly to me.

Oops, I misread this part.  What about a simple wrapper
run_simple_command which checks after PGRES_COMMAND_OK, and frees the
result then?  This could be used for the temporary table creation and
when setting synchronous_commit.
--
Michael

Вложения

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: fix "Success" error messages
Следующее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: [HACKERS] WAL logging problem in 9.4.3?