Re: Refactor UnpinBuffer()

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Zhang Mingli <zmlpostgres(at)gmail(dot)com>
Subject: Re: Refactor UnpinBuffer()
Date: 2022-09-30 06:59:04
Message-ID: YzaTuHB4cw3dNGpZ@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 29, 2022 at 10:35:20AM -0700, Nathan Bossart wrote:
> I've marked this one as ready-for-committer.

UnpinBuffer() is local to bufmgr.c, so it would not be an issue for
external code, and that's 10 callers that don't need to worry about
that anymore. 2d115e4 is from 2015, and nobody has used this option
since, additionally.

Anyway, per the rule of consistency with the surroundings (see
ReleaseBuffer() and ReleaseAndReadBuffer()), it seems to me that there
is a good case for keeping the adjustment of CurrentResourceOwner
before any refcount checks. I have also kept a mention to
CurrentResourceOwner in the top comment of the function, and applied
that.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Benjamin Coutu 2022-09-30 07:09:30 Re: disfavoring unparameterized nested loops
Previous Message Benjamin Coutu 2022-09-30 06:44:46 Re: disfavoring unparameterized nested loops