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
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 |