Re: Correction to documentation at https://www.postgresql.org/docs/12/kernel-resources.html
Thanks Thomas. Looks like I misread that.
On Wednesday, 6 October, 2021, 04:56:42 am IST, Thomas Munro
wrote:
On Wed, Oct 6, 2021 at 3:48 AM Tom Lane wrote:
> PG Doc comments form writes:
> > On https://www.postgresql.org/docs/12/kernel-resources.html, the command to
> > calculate memory allocated to postgres is not correct. Following is the
> > command as shown in 18.4.5. Linux Huge Pages.
> > pmap 4170 | awk '/rw-s/ && /zero/ {print $2}', this command does not return
> > any results with correct pid. Probably /zero/ needs to be updated with
> > /anon_hugepage/
>
> The example seems to work as-given for me (testing on a RHEL8 system).
> It's of course not guaranteed to work on every flavor of Linux.
I think the pattern as given will show you the size if you are not
already using huge pages. For example, this line matches on my system
when I have /proc/sys/vm/nr_hugepages == 0:
7f2932eb6000 145360K rw-s- zero (deleted)
If you are already using huge pages, it doesn't match anything,
because the relevant line looks like:
7f6814e0 145408K rw-s- anon_hugepage (deleted)
Re: small patch
On Thu, Oct 07, 2021 at 07:58:47AM +0200, Laurenz Albe wrote: > On Wed, 2021-10-06 at 23:39 -0400, rir wrote: > > On Mon, Oct 04, 2021 at 08:18:22AM +0200, Laurenz Albe wrote: > > > On Fri, 2021-10-01 at 21:06 -0400, rir wrote: > > > > Minor changes to move.sgml and fetch.sgml. > > > However, I don't think that is an improvement: > > > > > > - the comments pointing from MOVE to FETCH and vice versa are > > > helpful for people who edit the documentation like you did > > > - we should retain "empty or one of", otherwise the following syntax > > > would be undocumented: > > > > > > FETCH FROM c; > > > > Your view is completely reasonable, but it suggests that > > many of the synopses are leaving syntax undocumented. > > The 'empty or one of:' is only used in these two synopses. > Can you think of a way to modify the syntax diagram so that it > expresses that and still remains comprehensible? For myself, 'FETCH [ [ FROM | IN ] ] ' clearly indicates that 'direction' is optional. Rob
Re: small patch
On 2021-Oct-07, rir wrote: > For myself, >'FETCH [ [ FROM | IN ] ] ' > clearly indicates that 'direction' is optional. Hmm, aren't you misreading the scope of the outer square brackets? If is optional independently of [FROM|IN], then the synopsis should be FETCH [ ] [ FROM | IN ] and I think that's correct, since all forms omitting any of these are accepted: alvherre=# begin; BEGIN alvherre=*# declare c scroll cursor with hold for select 1 ; DECLARE CURSOR alvherre=*# commit; COMMIT alvherre=# fetch forward from c; ?column? -- 1 (1 fila) alvherre=# fetch from c; ?column? -- (0 filas) alvherre=# fetch BACKWARD c; ?column? -- 1 (1 fila) alvherre=# fetch c; ?column? -- (0 filas) -- Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/
Re: small patch
rir writes: > On Thu, Oct 07, 2021 at 07:58:47AM +0200, Laurenz Albe wrote: >> Can you think of a way to modify the syntax diagram so that it >> expresses that and still remains comprehensible? > For myself, >'FETCH [ [ FROM | IN ] ] ' > clearly indicates that 'direction' is optional. Right, but if we don't say that can be empty, then this diagram disallows FETCH FROM cursor_name which in fact is legal. I think however that we could make it read FETCH [ ] [ FROM | IN ] ' and have a correct description without requiring to be allowed to be empty. BTW, as it stands, the diagram is ambiguous because there are two ways to parse FETCH cursor_name ... is present but empty, or omitted altogether? regards, tom lane
