Thread
Commits
-
doc: Fix explanation related to pg_shmem_allocations
- d28a14d2d400 13.2 landed
- bce641a2af71 14.0 landed
-
pg_shmem_allocations & documentation
Benoit Lobréau <benoit.lobreau@gmail.com> — 2020-12-10T10:07:47Z
Hi, While reading the documentation of pg_shmem_allocations, I noticed that the off column is described as such : "The offset at which the allocation starts. NULL for anonymous allocations and unused memory." Whereas, the view returns a value for unused memory: [local]:5433 postgres@postgres=# SELECT * FROM pg_shmem_allocations WHERE name IS NULL; name | off | size | allocated_size ------+-----------+---------+---------------- ¤ | 178095232 | 1923968 | 1923968 (1 row) From what I understand, the doc is wrong. Am I right ? Benoit [1] https://www.postgresql.org/docs/13/view-pg-shmem-allocations.html [2] https://www.postgresql.org/message-id/flat/20140504114417.GM12715%40awork2.anarazel.de (original thread)
-
Re: pg_shmem_allocations & documentation
Kyotaro Horiguchi <horikyota.ntt@gmail.com> — 2020-12-11T02:00:58Z
At Thu, 10 Dec 2020 11:07:47 +0100, Benoit Lobréau <benoit.lobreau@gmail.com> wrote in > Hi, > > While reading the documentation of pg_shmem_allocations, I noticed that the > off column is described as such : > > "The offset at which the allocation starts. NULL for anonymous allocations > and unused memory." > > Whereas, the view returns a value for unused memory: > > [local]:5433 postgres@postgres=# SELECT * FROM pg_shmem_allocations WHERE > name IS NULL; > name | off | size | allocated_size > ------+-----------+---------+---------------- > ¤ | 178095232 | 1923968 | 1923968 > (1 row) > > From what I understand, the doc is wrong. > Am I right ? Good catch! I think you're right. It seems to me the conclusion in the discussion is to expose the offset for free memory. Although we could just rip some words off, I'd like to propose instead to add an explanation why it is not exposed for anonymous allocations, like the column allocated_size. > Benoit > > [1] https://www.postgresql.org/docs/13/view-pg-shmem-allocations.html > [2] > https://www.postgresql.org/message-id/flat/20140504114417.GM12715%40awork2.anarazel.de > (original thread) regards. ¤ -- Kyotaro Horiguchi NTT Open Source Software Center
-
Re: pg_shmem_allocations & documentation
Michael Paquier <michael@paquier.xyz> — 2020-12-11T05:42:45Z
On Fri, Dec 11, 2020 at 11:00:58AM +0900, Kyotaro Horiguchi wrote: > Although we could just rip some words off, I'd like to propose instead > to add an explanation why it is not exposed for anonymous allocations, > like the column allocated_size. Indeed, there is a hiccup between what the code does and what the docs tell: the offset is not NULL for unused memory. > - The offset at which the allocation starts. NULL for anonymous > - allocations and unused memory. > + The offset at which the allocation starts. For anonymous allocations, > + no information about individual allocations is available, so the column > + will be NULL in that case. I'd say: let's be simple and just remove "and unused memory" because anonymous allocations are... Anonymous so you cannot know details related to them. That's something easy to reason about, and the docs were written originally to remain simple. -- Michael
-
Re: pg_shmem_allocations & documentation
Kyotaro Horiguchi <horikyota.ntt@gmail.com> — 2020-12-11T08:29:54Z
At Fri, 11 Dec 2020 14:42:45 +0900, Michael Paquier <michael@paquier.xyz> wrote in > On Fri, Dec 11, 2020 at 11:00:58AM +0900, Kyotaro Horiguchi wrote: > > Although we could just rip some words off, I'd like to propose instead > > to add an explanation why it is not exposed for anonymous allocations, > > like the column allocated_size. > > Indeed, there is a hiccup between what the code does and what the docs > tell: the offset is not NULL for unused memory. > > > - The offset at which the allocation starts. NULL for anonymous > > - allocations and unused memory. > > + The offset at which the allocation starts. For anonymous allocations, > > + no information about individual allocations is available, so the column > > + will be NULL in that case. > > I'd say: let's be simple and just remove "and unused memory" because > anonymous allocations are... Anonymous so you cannot know details > related to them. That's something easy to reason about, and the docs > were written originally to remain simple. Hmm. I don't object to that. Howerver, isn't the description for allocated_size too verbose in that sense? regards. -- Kyotaro Horiguchi NTT Open Source Software Center
-
Re: pg_shmem_allocations & documentation
Benoit Lobréau <benoit.lobreau@gmail.com> — 2020-12-11T08:58:29Z
Would "NULL for anonymous allocations, since details related to them are not known." be ok ? Le ven. 11 déc. 2020 à 09:29, Kyotaro Horiguchi <horikyota.ntt@gmail.com> a écrit : > At Fri, 11 Dec 2020 14:42:45 +0900, Michael Paquier <michael@paquier.xyz> > wrote in > > On Fri, Dec 11, 2020 at 11:00:58AM +0900, Kyotaro Horiguchi wrote: > > > Although we could just rip some words off, I'd like to propose instead > > > to add an explanation why it is not exposed for anonymous allocations, > > > like the column allocated_size. > > > > Indeed, there is a hiccup between what the code does and what the docs > > tell: the offset is not NULL for unused memory. > > > > > - The offset at which the allocation starts. NULL for anonymous > > > - allocations and unused memory. > > > + The offset at which the allocation starts. For anonymous > allocations, > > > + no information about individual allocations is available, so > the column > > > + will be NULL in that case. > > > > I'd say: let's be simple and just remove "and unused memory" because > > anonymous allocations are... Anonymous so you cannot know details > > related to them. That's something easy to reason about, and the docs > > were written originally to remain simple. > > Hmm. I don't object to that. Howerver, isn't the description for > allocated_size too verbose in that sense? > > regards. > > -- > Kyotaro Horiguchi > NTT Open Source Software Center >
-
Re: pg_shmem_allocations & documentation
Benoit Lobréau <benoit.lobreau@gmail.com> — 2020-12-14T09:33:06Z
Here's a proposal patch. Le ven. 11 déc. 2020 à 09:58, Benoit Lobréau <benoit.lobreau@gmail.com> a écrit : > Would "NULL for anonymous allocations, since details related to them are > not known." be ok ? > > > Le ven. 11 déc. 2020 à 09:29, Kyotaro Horiguchi <horikyota.ntt@gmail.com> > a écrit : > >> At Fri, 11 Dec 2020 14:42:45 +0900, Michael Paquier <michael@paquier.xyz> >> wrote in >> > On Fri, Dec 11, 2020 at 11:00:58AM +0900, Kyotaro Horiguchi wrote: >> > > Although we could just rip some words off, I'd like to propose instead >> > > to add an explanation why it is not exposed for anonymous allocations, >> > > like the column allocated_size. >> > >> > Indeed, there is a hiccup between what the code does and what the docs >> > tell: the offset is not NULL for unused memory. >> > >> > > - The offset at which the allocation starts. NULL for anonymous >> > > - allocations and unused memory. >> > > + The offset at which the allocation starts. For anonymous >> allocations, >> > > + no information about individual allocations is available, so >> the column >> > > + will be NULL in that case. >> > >> > I'd say: let's be simple and just remove "and unused memory" because >> > anonymous allocations are... Anonymous so you cannot know details >> > related to them. That's something easy to reason about, and the docs >> > were written originally to remain simple. >> >> Hmm. I don't object to that. Howerver, isn't the description for >> allocated_size too verbose in that sense? >> >> regards. >> >> -- >> Kyotaro Horiguchi >> NTT Open Source Software Center >> >
-
Re: pg_shmem_allocations & documentation
Michael Paquier <michael@paquier.xyz> — 2020-12-15T01:09:35Z
On Mon, Dec 14, 2020 at 10:33:06AM +0100, Benoit Lobréau wrote: > </para> > <para> > The offset at which the allocation starts. NULL for anonymous > - allocations and unused memory. > + allocations, since details related to them are not known. > </para></entry> Both of you seem to agree about having more details about that, which is fine by me at the end. Horiguchi-san, do you have more thoughts to offer? Benoit's version is similar to yours, just simpler. -- Michael
-
Re: pg_shmem_allocations & documentation
Michael Paquier <michael@paquier.xyz> — 2020-12-16T01:40:43Z
On Tue, Dec 15, 2020 at 10:09:35AM +0900, Michael Paquier wrote: > Both of you seem to agree about having more details about that, which > is fine by me at the end. Horiguchi-san, do you have more thoughts to > offer? Benoit's version is similar to yours, just simpler. Okay, applied this one then. Thanks Benoit and Horigushi-san. -- Michael