Re: Statement timeout in pg_rewind

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Alexander Kukushkin <cyberdemn(at)gmail(dot)com>
Cc: David Fetter <david(at)fetter(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Statement timeout in pg_rewind
Date: 2019-08-27 06:35:34
Message-ID: 20190827063534.GG7422@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2019-08-27 06:49:32 Re: [HACKERS] WAL logging problem in 9.4.3?
Previous Message Michael Paquier 2019-08-27 06:27:26 Re: fix "Success" error messages