Обсуждение: Code comment change

There is some language in a code comment that has been bothering me for
several years now.  After pointing it out in a conversation off-list
recently, I figured it was past time to do something about it.

Patch attached.
-- 
Vik Fearing                                          +33 6 46 75 15 36
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support

On Sun, Jun 23, 2019 at 9:21 PM Vik Fearing <vik.fearing@2ndquadrant.com> wrote:
> There is some language in a code comment that has been bothering me for
> several years now.  After pointing it out in a conversation off-list
> recently, I figured it was past time to do something about it.
>
> Patch attached.

Pushed.  Thanks!

--
Thomas Munro
https://enterprisedb.com

On 23/06/2019 12:35, Thomas Munro wrote:
> On Sun, Jun 23, 2019 at 9:21 PM Vik Fearing <vik.fearing@2ndquadrant.com> wrote:
>> There is some language in a code comment that has been bothering me for
>> several years now.  After pointing it out in a conversation off-list
>> recently, I figured it was past time to do something about it.
>>
>> Patch attached.
> 
> Pushed.  Thanks!

Thank you!
-- 
Vik Fearing                                          +33 6 46 75 15 36
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support

On Sun, Jun 23, 2019 at 3:36 AM Thomas Munro <thomas.munro@gmail.com> wrote:
> Pushed.  Thanks!

I wonder what the comment is supposed to mean.

I think that it's addressing the situation prior to commit 70508ba7aed
in 2003, which was the point when the "fast" root concept was
introduced. Prior to that commit, there was only what we would now
call a true root, and _bt_getroot() had to loop to make sure that it
reliably found it without deadlocking, while dealing with concurrent
splits. This was necessary because the old design also involved
maintaining a pointer to each page's parent in each page, which sounds
like a seriously bad approach to me.

I think that the whole sentence about "the standard class of race
conditions" should go. There is no more dance. Nothing in
_bt_getroot() is surprising to me. The other comments explain things
comprehensively.

-- 
Peter Geoghegan

Peter Geoghegan <pg@bowt.ie> writes:
> On Sun, Jun 23, 2019 at 3:36 AM Thomas Munro <thomas.munro@gmail.com> wrote:
>> Pushed.  Thanks!

> I wonder what the comment is supposed to mean.
> I think that it's addressing the situation prior to commit 70508ba7aed
> in 2003, which was the point when the "fast" root concept was
> introduced.

Yeah.  I did some research into the provenance of that comment when
Thomas pushed the change.  It's *old*.  The whole para exists verbatim
in Postgres v4r2, src/backend/access/nbtree/nbtpage.c dated 1993-12-10
(in my copy of that tarball).  The only change since then has been to
change the whitespace for 4-space tabs.

Even more interesting, the same para also exists verbatim in
v4r2's src/backend/access/nobtree/nobtpage.c, which is dated 1991-10-29
in the same tarball.  (If you're wondering, "nobtree" seems to stand
for "no-overwrite btree"; so I suppose it went the way of all flesh
when Stonebraker lost interest in write-once mass storage.)  So presumably
this comment dates back to some common ancestor of the mainline btree code
and the no-overwrite code, which must have been even older than the 1991
date.

This is only marginally relevant to what we should do about it today,
but I think it's reasonable to conclude that the current locking
considerations are nearly unrelated to what they were when the comment
was written.

> I think that the whole sentence about "the standard class of race
> conditions" should go. There is no more dance. Nothing in
> _bt_getroot() is surprising to me. The other comments explain things
> comprehensively.

+1

            regards, tom lane

On Mon, Jul 1, 2019 at 7:28 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Even more interesting, the same para also exists verbatim in
> v4r2's src/backend/access/nobtree/nobtpage.c, which is dated 1991-10-29
> in the same tarball.  (If you're wondering, "nobtree" seems to stand
> for "no-overwrite btree"; so I suppose it went the way of all flesh
> when Stonebraker lost interest in write-once mass storage.)  So presumably
> this comment dates back to some common ancestor of the mainline btree code
> and the no-overwrite code, which must have been even older than the 1991
> date.

"no-overwrite btree" is described here, if you're interested:

https://pdfs.semanticscholar.org/a0de/438d5efd96e8af51bc7595aa1c30d0497a57.pdf

This is a link to the B-Tree focused paper "An Index Implementation
Supporting Fast Recovery for the POSTGRES Storage System". I found
that the paper provided me with some interesting historic context. I
am pretty sure that the authors were involved in early work on the
Postgres B-Tree code. It references Lanin and Shasha, even though the
nbtree code that is influenced by L&S first appears in the same 2003
commit of yours that I mentioned.

> > I think that the whole sentence about "the standard class of race
> > conditions" should go. There is no more dance. Nothing in
> > _bt_getroot() is surprising to me. The other comments explain things
> > comprehensively.
>
> +1

I'll take care of it soon.

-- 
Peter Geoghegan