Re: Small refactoring around vacuum_open_relation

From: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Kirill Reshke <reshkekirill(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Small refactoring around vacuum_open_relation
Date: 2025-01-10 04:37:40
Message-ID: CAExHW5uJtbgKdn1nRQ3GP+uei-4ETLtcZpPRP9e8VAZh3v1UHg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Thu, Jan 9, 2025 at 5:30 PM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>
> > On 9 Jan 2025, at 11:45, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>
> > Dunno what others think, this seems useless churn to me.
>
> I agree, I don't see this providing enough value to warrant the changes.
>

I agree about most of the changes however

>
> > I found some more
> > static const struct
> > {
> > LOCKMODE hwlock;
> > int lockstatus;
> > int updstatus;
> > }
> >
> > tupleLockExtraInfo[MaxLockTupleMode + 1] =
> >
> > hwlock should be hwlockmode?

this one looks useful. Variable name hwlock indicates some kind of
lock (object) not a mode in which it should be locked. This is
especially so when the next variable is named lockstatus indicating
status of the lock.

--
Best Wishes,
Ashutosh Bapat

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2025-01-10 04:46:53 Re: WAL-logging facility for pgstats kinds
Previous Message David Rowley 2025-01-10 04:06:26 Re: Some ExecSeqScan optimizations