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