Re: Statement timeout in pg_rewind
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Alexander Kukushkin <cyberdemn@gmail.com>
Cc: David Fetter <david@fetter.org>, Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-08-27T06:35:34Z
Lists: 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
Commits
-
Disable timeouts when running pg_rewind with online source cluster
- e9dcbc9c3fb6 9.5.20 landed
- d64789e97cf6 9.6.16 landed
- 19bfa15a8274 10.11 landed
- f51006ea9657 11.6 landed
- e96f524433db 12.0 landed
- be182e4f9e89 13.0 landed