Re: Statement timeout in pg_rewind - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Statement timeout in pg_rewind
Date
Msg-id 20190827063534.GG7422@paquier.xyz
Whole thread Raw
In response to Re: Statement timeout in pg_rewind  (Alexander Kukushkin <cyberdemn@gmail.com>)
Responses Re: Statement timeout in pg_rewind  (Alexander Kukushkin <cyberdemn@gmail.com>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: fix "Success" error messages
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: [HACKERS] WAL logging problem in 9.4.3?