Thread
Commits
-
Fix typo and outdated information in README.barrier
- 943bda157eca 9.6.23 landed
- e71219ca11fa 10.18 landed
- a399755ba2fc 11.13 landed
- 898c62951e80 12.8 landed
- 010429eb1f77 13.4 landed
- 2ded19fa3a4d 14.0 landed
-
Typo in README.barrier
Tatsuo Ishii <ishii@sraoss.co.jp> — 2021-05-16T12:11:33Z
I think there is a typo in src/backend/storage/lmgr/README.barrier. Attached patch should fix it. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
-
Re: Typo in README.barrier
David Rowley <dgrowleyml@gmail.com> — 2021-05-16T12:51:50Z
On Mon, 17 May 2021 at 00:11, Tatsuo Ishii <ishii@sraoss.co.jp> wrote: > I think there is a typo in src/backend/storage/lmgr/README.barrier. > Attached patch should fix it. Yeah looks like a typo to me. I wonder if we also need to fix this part: > either one does their writes. Eventually we might be able to use an atomic > fetch-and-add instruction for this specific case on architectures that support > it, but we can't rely on that being available everywhere, and we currently > have no support for it at all. Use a lock. That seems to have been written at a time before we got atomics. The following also might want to mention atomics too: > 2. Eight-byte loads and stores aren't necessarily atomic. We assume in > various places in the source code that an aligned four-byte load or store is > atomic, and that other processes therefore won't see a half-set value. > Sadly, the same can't be said for eight-byte value: on some platforms, an > aligned eight-byte load or store will generate two four-byte operations. If > you need an atomic eight-byte read or write, you must make it atomic with a > lock. David
-
Re: Typo in README.barrier
Tatsuo Ishii <ishii@sraoss.co.jp> — 2021-05-16T13:29:30Z
> Yeah looks like a typo to me. Ok. > I wonder if we also need to fix this part: > >> either one does their writes. Eventually we might be able to use an atomic >> fetch-and-add instruction for this specific case on architectures that support >> it, but we can't rely on that being available everywhere, and we currently >> have no support for it at all. Use a lock. > > That seems to have been written at a time before we got atomics. > > The following also might want to mention atomics too: > >> 2. Eight-byte loads and stores aren't necessarily atomic. We assume in >> various places in the source code that an aligned four-byte load or store is >> atomic, and that other processes therefore won't see a half-set value. >> Sadly, the same can't be said for eight-byte value: on some platforms, an >> aligned eight-byte load or store will generate two four-byte operations. If >> you need an atomic eight-byte read or write, you must make it atomic with a >> lock. Yes, we'd better to fix them. Attached is a propsal for these. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
-
Re: Typo in README.barrier
David Rowley <dgrowleyml@gmail.com> — 2021-05-17T00:19:41Z
On Mon, 17 May 2021 at 01:29, Tatsuo Ishii <ishii@sraoss.co.jp> wrote: > Yes, we'd better to fix them. Attached is a propsal for these. Thanks for working on that. I had a look and wondered if it might be better to go into slightly less details about the exact atomic function to use. The wording there might lead you to believe you can just call the atomic function on the non-atomic variable. It might be best just to leave the details about how exactly to use atomics by just referencing port/atomics.h. Maybe something like the attached? I'm also a bit on the fence if this should be backpatched or not. The reasons though maybe not is that it seems unlikely maybe people would not be working in master if they're developing something new. On the other side of the argument, 0ccebe779, which adjusts another README was backpatched. I'm leaning towards backpatching. David
-
Re: Typo in README.barrier
Tatsuo Ishii <ishii@sraoss.co.jp> — 2021-05-17T00:33:27Z
> Thanks for working on that. I had a look and wondered if it might be > better to go into slightly less details about the exact atomic > function to use. The wording there might lead you to believe you can > just call the atomic function on the non-atomic variable. > > It might be best just to leave the details about how exactly to use > atomics by just referencing port/atomics.h. > > Maybe something like the attached? Thanks. Agreed and your patch looks good to me. > I'm also a bit on the fence if this should be backpatched or not. The > reasons though maybe not is that it seems unlikely maybe people would > not be working in master if they're developing something new. On the > other side of the argument, 0ccebe779, which adjusts another README > was backpatched. I'm leaning towards backpatching. Me too. Let's backpatch. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
-
Re: Typo in README.barrier
Tatsuo Ishii <ishii@sraoss.co.jp> — 2021-05-17T04:45:09Z
David, >> Thanks for working on that. I had a look and wondered if it might be >> better to go into slightly less details about the exact atomic >> function to use. The wording there might lead you to believe you can >> just call the atomic function on the non-atomic variable. >> >> It might be best just to leave the details about how exactly to use >> atomics by just referencing port/atomics.h. >> >> Maybe something like the attached? > > Thanks. Agreed and your patch looks good to me. > >> I'm also a bit on the fence if this should be backpatched or not. The >> reasons though maybe not is that it seems unlikely maybe people would >> not be working in master if they're developing something new. On the >> other side of the argument, 0ccebe779, which adjusts another README >> was backpatched. I'm leaning towards backpatching. > > Me too. Let's backpatch. Would you like to push the patch? -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
-
Re: Typo in README.barrier
David Rowley <dgrowleyml@gmail.com> — 2021-05-17T04:46:29Z
On Mon, 17 May 2021 at 16:45, Tatsuo Ishii <ishii@sraoss.co.jp> wrote: > Would you like to push the patch? Yeah, I can. I was just letting it sit for a while to see if anyone else had an opinion about backpatching. David
-
Re: Typo in README.barrier
Tatsuo Ishii <ishii@sraoss.co.jp> — 2021-05-17T04:48:31Z
> On Mon, 17 May 2021 at 16:45, Tatsuo Ishii <ishii@sraoss.co.jp> wrote: >> Would you like to push the patch? > > Yeah, I can. I was just letting it sit for a while to see if anyone > else had an opinion about backpatching. Ok. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
-
Re: Typo in README.barrier
Michael Paquier <michael@paquier.xyz> — 2021-05-17T04:52:54Z
On Mon, May 17, 2021 at 09:33:27AM +0900, Tatsuo Ishii wrote: > Me too. Let's backpatch. A README is not directly user-facing, it is here for developers, so I would not really bother with a backpatch. Now it is not a big deal to do so either, so that's not a -1 from me, more a +0, for "please feel free to do what you think is most adapted". You may want to hold on until 14beta1 is tagged, though. -- Michael
-
Re: Typo in README.barrier
Tatsuo Ishii <ishii@sraoss.co.jp> — 2021-05-17T05:18:41Z
> On Mon, May 17, 2021 at 09:33:27AM +0900, Tatsuo Ishii wrote: >> Me too. Let's backpatch. > > A README is not directly user-facing, it is here for developers, so I > would not really bother with a backpatch. Now it is not a big deal to > do so either, so that's not a -1 from me, more a +0, for "please feel > free to do what you think is most adapted". I think README is similar to code comments. If a code comment is wrong, we usually fix to back branches. Why can't we do the same thing for README? > You may want to hold on until 14beta1 is tagged, though. Of course we can wait till that day but I wonder why. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
-
Re: Typo in README.barrier
David Rowley <dgrowleyml@gmail.com> — 2021-05-17T22:07:30Z
On Mon, 17 May 2021 at 17:18, Tatsuo Ishii <ishii@sraoss.co.jp> wrote: > > > On Mon, May 17, 2021 at 09:33:27AM +0900, Tatsuo Ishii wrote: > >> Me too. Let's backpatch. > > > > A README is not directly user-facing, it is here for developers, so I > > would not really bother with a backpatch. Now it is not a big deal to > > do so either, so that's not a -1 from me, more a +0, for "please feel > > free to do what you think is most adapted". > > I think README is similar to code comments. If a code comment is > wrong, we usually fix to back branches. Why can't we do the same thing > for README? Thanks for the votes. Since Michael was on the fence and I was just leaning over it and Ishii-san was pro-backpatch, I backpatched it. > > You may want to hold on until 14beta1 is tagged, though. > > Of course we can wait till that day but I wonder why. I imagined that would be a good idea for more risky patches so we don't break something before a good round of buildfarm testing. However, since this is just a README, I didn't think it would have mattered. Maybe there's another reason I'm overlooking? David
-
Re: Typo in README.barrier
Tom Lane <tgl@sss.pgh.pa.us> — 2021-05-17T22:37:56Z
David Rowley <dgrowleyml@gmail.com> writes: >>> You may want to hold on until 14beta1 is tagged, though. >> Of course we can wait till that day but I wonder why. > I imagined that would be a good idea for more risky patches so we > don't break something before a good round of buildfarm testing. > However, since this is just a README, I didn't think it would have > mattered. Maybe there's another reason I'm overlooking? Generally it's considered poor form to push any inessential patches during a release window (which I'd define roughly as 48 hours before the wrap till after the tag is applied). It complicates the picture for the final round of buildfarm testing, and if we have to do a re-wrap then we're faced with the question of whether to back out the patch. In this case, it being just a README, I agree there's no harm done. But we've been burnt by "low risk" patches before, so I'd tend to err on the side of caution during a release window. regards, tom lane
-
Re: Typo in README.barrier
Michael Paquier <michael@paquier.xyz> — 2021-05-18T00:04:11Z
On Mon, May 17, 2021 at 06:37:56PM -0400, Tom Lane wrote: > Generally it's considered poor form to push any inessential patches > during a release window (which I'd define roughly as 48 hours before > the wrap till after the tag is applied). It complicates the picture > for the final round of buildfarm testing, and if we have to do a > re-wrap then we're faced with the question of whether to back out > the patch. > > In this case, it being just a README, I agree there's no harm done. > But we've been burnt by "low risk" patches before, so I'd tend to > err on the side of caution during a release window. Yes, I've had this experience once in the past. So I tend to just wait until the tag is pushed as long as it is not critical for the release. -- Michael