[DOCS] doc change request (7.4.6, reference section, grant)
Hi doc keepers, while I was looking for which privilege is to be granted to a user so the user can lock tables, I found that information missing in the manual. Therefore I tried to add it to the sgml doc sources: postgresql-7.4.6/doc/src/sgml/ref/grant.sgml 134c134,135
Re: [DOCS] doc change request (7.4.6, reference section, grant)
Ralph Graulich wrote: > while I was looking for which privilege is to be granted to a user so > the user can lock tables, I found that information missing in the > manual. It's on the reference page of LOCK, where it belongs. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [DOCS] doc change request (7.4.6, reference section, grant)
Hi Peter, It's on the reference page of LOCK, where it belongs. That's where I finally found it. Comparing the notes on different SQL commands and the reference page for GRANT, I still consider it's worth mentioning it there, as it is not that obvious like SELECT, INSERT or DELETE privileges. The way the question occured while creating a user allowed to pg_dump certain databases, but not allowed to do anything else. That way I only granted SELECT privileges on the tables to that user, but that didn't work, as pg_dump wants to lock the table. But anyway, thanks to all the folks writing the documentation, in nearly a hundred percent of the time the docs are really helpful. Best regards ... Ralph ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [DOCS] doc change request (7.4.6, reference section, grant)
On Mon, Jan 31, 2005 at 09:16:11PM +0100, Peter Eisentraut wrote: > Ralph Graulich wrote: > > while I was looking for which privilege is to be granted to a user so > > the user can lock tables, I found that information missing in the > > manual. > > It's on the reference page of LOCK, where it belongs. It's useful (and consistent) to have a mention on the GRANT page. Else, the list in GRANT should be a plain list of available privileges, without the text that currently follows each. -- Alvaro Herrera (<[EMAIL PROTECTED]>) "El destino baraja y nosotros jugamos" (A. Schopenhauer) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [DOCS] doc change request (7.4.6, reference section, grant)
Alvaro Herrera wrote: > It's useful (and consistent) to have a mention on the GRANT page. > Else, the list in GRANT should be a plain list of available > privileges, without the text that currently follows each. In any case, his proposed change was wrong because the required privileges depend on the lock type. Then you start duplicating all that information and it's going to become a mess to maintain. The existing list gives a basic idea of what each privilege is for and explicitly states that details are to be found on the reference page of each command. Note that the "basic ideas" are fairly static: the SELECT privilege is always going to allow SELECT. But I will resist the demand to duplicate the privilege rules of each command and function on the GRANT reference page. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [DOCS] doc change request (7.4.6, reference section, grant)
Ralph Graulich <[EMAIL PROTECTED]> writes: > The way the question occured while creating a user allowed to pg_dump > certain databases, but not allowed to do anything else. That way I only > granted SELECT privileges on the tables to that user, but that didn't > work, as pg_dump wants to lock the table. Huh? pg_dump only takes ACCESS SHARE lock, which requires only SELECT privileges. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[DOCS] Instructions for FreeBSD ipc config showing age
A recent mailing on the -perf list highlighted that the docs concerning ipc configuration are a bit out for date for FreeBSD. The attached patch separates out FreeBSD from Open/NetBSD, and shows how to change settings via sysctl w/o a kernel rebuild. Any thoughts? BTW I suspect that both Open and NetBSD are in need of an update too, however I don't have any installations of such to experiment on. regards Mark --- runtime.sgml.orig Sat Jan 29 18:30:50 2005 +++ runtime.sgmlMon Jan 31 22:30:35 2005 @@ -4350,10 +4350,8 @@ - FreeBSD NetBSD OpenBSD - FreeBSDIPC configuration NetBSDIPC configuration OpenBSDIPC configuration @@ -4364,25 +4362,66 @@ the option SHMMAXPGS (in pages). The following shows an example of how to set the various parameters: -options SYSVSHM -options SHMMAXPGS=4096 -options SHMSEG=256 +option SYSVSHM +option SHMMAXPGS=4096 +option SHMSEG=256 -options SYSVSEM -options SEMMNI=256 -options SEMMNS=512 -options SEMMNU=256 -options SEMMAP=256 +option SYSVSEM +option SEMMNI=256 +option SEMMNS=512 +option SEMMNU=256 +option SEMMAP=256 -(On NetBSD and OpenBSD the key word is actually -option singular.) You might also want to configure your kernel to lock shared memory into RAM and prevent it from being paged out to swap. Use the sysctl setting kern.ipc.shm_use_phys. + + + + + + + FreeBSD + FreeBSDIPC configuration + + +The default settings are only suitable for small installations +(default SHMMAX is 32 MB). Changes can be made via +the sysctl or loader interfaces. +Firstly the ones that are settable using sysctl: + +$ systcl -w kern.ipc.shmall=32768 +$ systcl -w kern.ipc.shmmax=134217728 +$ systcl -w kern.ipc.semmap=256 + +These to be saved between reboots in /etc/sysctl.conf. + + +The remaining sempahore settings are read only as far as +sysctl is concerned, but can be changed before boot +using the loader prompt: + +(loader) set kern.ipc.semmni=256 +(loader) set kern.ipc.semmns=512 +(loader) set kern.ipc.semmnu=256 + +Similarly these can be saved between reboots in +/boot/loader.conf. + + +You might also want to configure your kernel to lock shared +memory into RAM and prevent it from being paged out to swap. +Use the sysctl setting +kern.ipc.shm_use_phys. + + +Versions before 4.0 will require a kernel rebuild, see the +NetBSD and OpenBSD instructions above, however the key word is +options (plural) in this case. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [DOCS] Instructions for FreeBSD ipc config showing age
Mark Kirkwood <[EMAIL PROTECTED]> writes: > A recent mailing on the -perf list highlighted that the docs concerning > ipc configuration are a bit out for date for FreeBSD. > The attached patch separates out FreeBSD from Open/NetBSD, and shows how > to change settings via sysctl w/o a kernel rebuild. Any thoughts? This seems a bit awkwardly phrased: > + > +Versions before 4.0 will require a kernel rebuild, see the > +NetBSD and +class="osname">OpenBSD instructions above, however the key word > is > +options (plural) in this case. > Perhaps FreeBSD versions before 4.0 work like NetBSD and OpenBSD (see above), except that the configuration file uses the key word "options" instead of "option". Also, alphabetization would suggest putting the FreeBSD entry before the other two, not after, so maybe that should be "see below". regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [DOCS] Instructions for FreeBSD ipc config showing age
Tom Lane wrote: This seems a bit awkwardly phrased: + +Versions before 4.0 will require a kernel rebuild, see the +NetBSD and +class="osname">OpenBSD instructions above, however the key word is +options (plural) in this case. Perhaps FreeBSD versions before 4.0 work like NetBSD and OpenBSD (see above), except that the configuration file uses the key word "options" instead of "option". Yeah - much nicer. Also, alphabetization would suggest putting the FreeBSD entry before the other two, not after, so maybe that should be "see below". Thanks - had not considered that! Amended patch attached. regards Mark --- runtime.sgml.orig Sat Jan 29 18:30:50 2005 +++ runtime.sgmlTue Feb 1 14:25:53 2005 @@ -4351,9 +4351,51 @@ FreeBSD + FreeBSDIPC configuration + + +The default settings are only suitable for small installations +(default SHMMAX is 32 MB). Changes can be made via +the sysctl or loader interfaces. +Firstly the ones that are settable using sysctl: + +$ systcl -w kern.ipc.shmall=32768 +$ systcl -w kern.ipc.shmmax=134217728 +$ systcl -w kern.ipc.semmap=256 + +These to be saved between reboots in /etc/sysctl.conf. + + +The remaining sempahore settings are read only as far as +sysctl is concerned, but can be changed before boot +using the loader prompt: + +(loader) set kern.ipc.semmni=256 +(loader) set kern.ipc.semmns=512 +(loader) set kern.ipc.semmnu=256 + +Similarly these can be saved between reboots in +/boot/loader.conf. + + +You might also want to configure your kernel to lock shared +memory into RAM and prevent it from being paged out to swap. +Use the sysctl setting +kern.ipc.shm_use_phys. + + +FreeBSD versions before 4.0 work like +NetBSD and +OpenBSD (see below), except that the configuration file uses the +key word "options" instead of "option". + + + + + + NetBSD OpenBSD - FreeBSDIPC configuration NetBSDIPC configuration OpenBSDIPC configuration @@ -4364,19 +4406,16 @@ the option SHMMAXPGS (in pages). The following shows an example of how to set the various parameters: -options SYSVSHM -options SHMMAXPGS=4096 -options SHMSEG=256 +option SYSVSHM +option SHMMAXPGS=4096 +option SHMSEG=256 -options SYSVSEM -options SEMMNI=256 -options SEMMNS=512 -options SEMMNU=256 -options SEMMAP=256 +option SYSVSEM +option SEMMNI=256 +option SEMMNS=512 +option SEMMNU=256 +option SEMMAP=256 -(On NetBSD and OpenBSD the key word is actually -option singular.) You might also want to configure your kernel to lock shared ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[DOCS] "that" missing in "12.2. Transaction Isolation"
Hi everyone, I don't know if this is the right place for this, but the documentation of Postgresql 8.1Devel has a statement in the section "12.2. Transaction Isolation" that is lacking "that": Since the cost of redoing complex transactions may be significant, this mode is recommended only when updating transactions contain logic sufficiently complex that they may give wrong answers in Read Committed mode. Thanks, Hashem Masoud __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [DOCS] "that" missing in "12.2. Transaction Isolation"
Hashem Masoud <[EMAIL PROTECTED]> writes: > I don't know if this is the right place for this, but > the documentation of Postgresql 8.1Devel has a > statement > in the section "12.2. Transaction Isolation" that is > lacking "that": > Since the cost of redoing complex transactions may be > significant, this mode is recommended only when > updating transactions contain logic sufficiently > complex that they may give wrong answers in Read > Committed mode. I'm confused --- that seems like perfectly OK English grammar to me. What change are you suggesting exactly? regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[DOCS] FAQ 4.11.* numbering is off
The numbering in the FAQ table of contents doesn't always agree with the numbering in the body. For example, the table of contents has this: 4.11.0) How do I create a serial/auto-incrementing field? 4.11.1) How do I get the value of a SERIAL insert? 4.11.2) Doesn't currval() lead to a race condition with other users? 4.11.3) Why aren't my sequence numbers reused on transaction abort? but the body has this: 4.11.1) How do I create a serial/auto-incrementing field? 4.11.2) How do I get the value of a SERIAL insert? 4.11.3) Doesn't currval() lead to a race condition with other users? 4.11.4) Why aren't my sequence numbers reused on transaction abort? -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
