Re: [HACKERS] Assertion failure when the non-exclusive pg_stop_backup aborted.

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Assertion failure when the non-exclusive pg_stop_backup aborted.
Date: 2017-12-08 09:13:02
Message-ID: CAB7nPqSVN7eSns0yVgdRWYbdkjNiewNtA2pHrPeysbXu+viM-w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Dec 8, 2017 at 5:38 PM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> After off-discussion with Fujii-san, I've updated the comment of why
> we should disallow interrupts before setting/cleanup the session-level
> lock. Please review it.

+ /*
+ * Set session-level lock. If we allow interrupts before setting
+ * session-level lock, we could call callbacks with an inconsistent
+ * state. To avoid calling CHECK_FOR_INTERRUPTS by LWLockReleaseClearVar
+ * which is called by WALInsertLockRelease before changing the backup
+ * state we change it while holding the WAL insert lock.
+ */
So you are just adding the reference to WALInsertLockRelease.. Instead
of writing the function names for LWLocks, I would just write "To
avoid calling CHECK_FOR_INTERRUPTS which can happen when releasing a
LWLock" and be done with it. There is no point to list a full function
dependency list, which could change in the future with static routines
of lwlock.c.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bernd Helmle 2017-12-08 09:19:44 Re: PostgreSQL crashes with SIGSEGV
Previous Message Bernd Helmle 2017-12-08 09:13:00 Re: PostgreSQL crashes with SIGSEGV