Re: Simplifying the interface of UpdateMinRecoveryPoint

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Simplifying the interface of UpdateMinRecoveryPoint
Date: 2016-07-13 11:27:48
Message-ID: CAA4eK1Kx0eab6DWO3A9s0VXKGFTGGArKuvX740_cSufqzg_i-g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 13, 2016 at 9:19 AM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> Hi all,
>
> As of now UpdateMinRecoveryPoint() is using two arguments:
> - lsn, to check if the minimum recovery point should be updated to that
> - force, a boolean flag to decide if the update should be enforced or not.
> However those two arguments are correlated. If lsn is
> InvalidXlogRecPtr, the minimum recovery point update will be enforced.

Right.

> Hence why not simplifying its interface and remove the force flag?

One point to note is that the signature and usage of
UpdateMinRecoveryPoint() is same as it was when it got introduced in
commit-cdd46c76. Now the only reasons that come to my mind for
introducing the force parameter was (a) it looks cleaner that way to
committer (b) they have some usecase for the same in mind (c) it got
have overlooked. Now, if it got introduced due to (c), then your
patch does the right thing by removing it. Personally, I feel
overloading the parameter for multiple purposes makes code less
maintainable, so retaining as it is in HEAD has some merits.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2016-07-13 12:08:28 Re: pg_basebackup wish list
Previous Message Bjørnar Ness 2016-07-13 09:49:23 UPSERT/RETURNING -> ON CONFLICT SELECT?