Nabble - PostgreSQL - docs

Re: [GENERAL] [HACKERS] Fwd: psql+krb5

2009-12-01T08:26:36Z

Except that he posted a month ago and got no answers...

On Tue, Dec 1, 2009 at 8:22 AM, Robert Haas <robertmhaas@...> wrote:

> 2009/11/30 rahimeh khodadadi <rahimeh.khodadadi@...>:
>>
>>
>> ---------- Forwarded message ----------
>> From: rahimeh khodadadi <rahimeh.khodadadi@...>
>> Date: 2009/11/29
>> Subject: Re: psql+krb5
>> To: Denis Feklushkin <denis.feklushkin@...>
>
> Please review the guidelines for reporting a problem, which you can find here:
>
> http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
>
> It seems to me that you've done the exact opposite of nearly
> everything suggested there, starting with cross-posting your email to
> four mailing lists at least three of which are irrelevant to the
> problem that you're attempting to solve.
>
> ...Robert
>
> --
> Sent via pgsql-general mailing list (pgsql-general@...)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

--
When fascism comes to America, it will be intolerance sold as diversity.

--
Sent via pgsql-docs mailing list (pgsql-docs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: vacuumdb clarification

2009-11-27T09:41:37Z

Peter Eisentraut wrote:
> On fre, 2009-11-13 at 14:49 -0500, Bruce Momjian wrote:
> > Here is a documentation patch I have applied to clarify that --analyze
> > does analyze during vacuum, not instead of vacuum.
>
> I don't see this committed, but I would vote against it, because the
> wording makes it sound like the statistics are for use by the optimizer
> during vacuum.

I agree with your analysis. I have applied a simpler wording
improvement that just adds the word "Also".

--
Bruce Momjian <bruce@...> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Index: doc/src/sgml/ref/vacuumdb.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/ref/vacuumdb.sgml,v
retrieving revision 1.44
diff -c -c -r1.44 vacuumdb.sgml
*** doc/src/sgml/ref/vacuumdb.sgml 26 Feb 2009 16:02:37 -0000 1.44
--- doc/src/sgml/ref/vacuumdb.sgml 27 Nov 2009 17:40:12 -0000
***************
*** 159,165 ****
<term><option>--analyze</option></term>
<listitem>
<para>
! Calculate statistics for use by the optimizer.
</para>
</listitem>
</varlistentry>
--- 159,165 ----
<term><option>--analyze</option></term>
<listitem>
<para>
! Also calculate statistics for use by the optimizer.
</para>
</listitem>
</varlistentry>

--
Sent via pgsql-docs mailing list (pgsql-docs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: extract('dow', ...) mention

2009-11-24T11:20:43Z

On sön, 2009-11-15 at 22:50 +0100, Erik Rijkers wrote:
> It seems to me this mention of extract()
> in the manual (chapter 9.8):
> extract('dow', ...)
>
> is better replaced with
> extract(dow from ...)
>
> ( 8.3, 8.4, HEAD )

Fix applied to those versions. Thanks.

--
Sent via pgsql-docs mailing list (pgsql-docs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: Possible to display Unicode symbols in our SGML docs?

2009-11-22T05:19:28Z

On lör, 2009-11-21 at 23:27 -0500, Tom Lane wrote:
> Greg Stark <gsstark@...> writes:
> > You could always write it out longhand "carriage return (code point 8269)"
>
> I don't think mentioning the numeric code point is going to do anything
> for anybody. If we can't actually show the symbol, then just saying
> "carriage return symbol" seems like the best bet. It might be worth
> making sure that the phrase exactly matches the Unicode standard's name
> for the glyph, but otherwise I won't sweat it.

8629 = U+21B5 = downwards arrow with corner leftwards
- may indicate a carriage return or new line
-> 23CE return symbol

8230 = U+2026 = horizontal ellipsis

--
Sent via pgsql-docs mailing list (pgsql-docs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: Possible to display Unicode symbols in our SGML docs?

2009-11-21T20:27:59Z

Greg Stark <gsstark@...> writes:
> On Sat, Nov 21, 2009 at 11:33 PM, Peter Eisentraut <peter_e@...> wrote:
>> I don't think there is a strong need to document this at all. Do we say
>> anywhere that columns are separated by vertical lines?

> I think it's not intuitively obvious which is which here. It would be
> nice to mention it.

If it were easy to do, I'd be for doing it.

>> DocBook SGML is limited to something like Latin 1. So delete it.

> You could always write it out longhand "carriage return (code point 8269)"

I don't think mentioning the numeric code point is going to do anything
for anybody. If we can't actually show the symbol, then just saying
"carriage return symbol" seems like the best bet. It might be worth
making sure that the phrase exactly matches the Unicode standard's name
for the glyph, but otherwise I won't sweat it.

regards, tom lane

--
Sent via pgsql-docs mailing list (pgsql-docs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: Possible to display Unicode symbols in our SGML docs?

2009-11-21T18:23:54Z

On Sat, Nov 21, 2009 at 11:33 PM, Peter Eisentraut <peter_e@...> wrote:

> On lör, 2009-11-21 at 17:05 -0500, Tom Lane wrote:
>> I'm currently looking at the latest psql-unicode-output patch, which
>> includes this bit of proposed documentation:
>>
>> + Newlines in data are shown using a carriage return symbol
>> + (<literal>↵</literal>) in the right-hand margin.
>> + Wrapped data uses an ellipsis symbol
>> + (<literal>…</literal>) in the right-hand margin of a
>> + wrapped line, and in the left-hand margin of the following
>> + continuation line.
>
> I don't think there is a strong need to document this at all. Do we say
> anywhere that columns are separated by vertical lines?

I think it's not intuitively obvious which is which here. It would be
nice to mention it.

>> Is there a way around that, or should I just delete the attempts
>> to show the specific symbols?
>
> DocBook SGML is limited to something like Latin 1. So delete it.

You could always write it out longhand "carriage return (code point 8269)"

--
greg

--
Sent via pgsql-docs mailing list (pgsql-docs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: Possible to display Unicode symbols in our SGML docs?

2009-11-21T15:33:24Z

On lör, 2009-11-21 at 17:05 -0500, Tom Lane wrote:
> I'm currently looking at the latest psql-unicode-output patch, which
> includes this bit of proposed documentation:
>
> + Newlines in data are shown using a carriage return symbol
> + (<literal>↵</literal>) in the right-hand margin.
> + Wrapped data uses an ellipsis symbol
> + (<literal>…</literal>) in the right-hand margin of a
> + wrapped line, and in the left-hand margin of the following
> + continuation line.

I don't think there is a strong need to document this at all. Do we say
anywhere that columns are separated by vertical lines?

> Unfortunately this markup seems to be pure speculation on the author's
> part:
>
> openjade -wall -wno-unused-param -wno-empty -wfully-tagged -D . -D . -c /usr/share/sgml/docbook/dsssl-stylesheets/catalog -d stylesheet.dsl -t sgml -i output-html -V html-index postgres.sgml
> openjade:ref/psql-ref.sgml:1797:22:E: "8629" is not a character number in the document character set
> openjade:ref/psql-ref.sgml:1799:22:E: "8230" is not a character number in the document character set
> make: *** [HTML.index] Error 1
>
> Is there a way around that, or should I just delete the attempts
> to show the specific symbols?

DocBook SGML is limited to something like Latin 1. So delete it.

--
Sent via pgsql-docs mailing list (pgsql-docs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Possible to display Unicode symbols in our SGML docs?

2009-11-21T14:05:08Z

I'm currently looking at the latest psql-unicode-output patch, which
includes this bit of proposed documentation:

+ Newlines in data are shown using a carriage return symbol
+ (<literal>↵</literal>) in the right-hand margin.
+ Wrapped data uses an ellipsis symbol
+ (<literal>…</literal>) in the right-hand margin of a
+ wrapped line, and in the left-hand margin of the following
+ continuation line.

Unfortunately this markup seems to be pure speculation on the author's
part:

openjade -wall -wno-unused-param -wno-empty -wfully-tagged -D . -D . -c /usr/share/sgml/docbook/dsssl-stylesheets/catalog -d stylesheet.dsl -t sgml -i output-html -V html-index postgres.sgml
openjade:ref/psql-ref.sgml:1797:22:E: "8629" is not a character number in the document character set
openjade:ref/psql-ref.sgml:1799:22:E: "8230" is not a character number in the document character set
make: *** [HTML.index] Error 1

Is there a way around that, or should I just delete the attempts
to show the specific symbols?

Note that this is in psql's reference page, which means that anything
we want to do here also has to translate to man-page output. That
might kill the idea even if it would work otherwise.

regards, tom lane

--
Sent via pgsql-docs mailing list (pgsql-docs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: vacuumdb clarification

2009-11-20T05:58:09Z

On fre, 2009-11-13 at 14:49 -0500, Bruce Momjian wrote:
> Here is a documentation patch I have applied to clarify that --analyze
> does analyze during vacuum, not instead of vacuum.

I don't see this committed, but I would vote against it, because the
wording makes it sound like the statistics are for use by the optimizer
during vacuum.

diff -c -c -r1.44 vacuumdb.sgml
*** doc/src/sgml/ref/vacuumdb.sgml 26 Feb 2009 16:02:37 -0000
1.44
--- doc/src/sgml/ref/vacuumdb.sgml 13 Nov 2009 19:46:37 -0000
***************
*** 159,165 ****
<term><option>--analyze</option></term>
<listitem>
<para>
! Calculate statistics for use by the optimizer.
</para>
</listitem>
</varlistentry>
--- 159,165 ----
<term><option>--analyze</option></term>
<listitem>
<para>
! Calculate statistics for use by the optimizer during vacuum.
</para>
</listitem>
</varlistentry>

--
Sent via pgsql-docs mailing list (pgsql-docs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: [GENERAL] Postgresql Database Lock Problem

2009-11-18T00:17:06Z

The statement that creates lock and waiting is in following. This is from pg_stats and pg_stat_activity view.
Here AD_Sequence is a table that maintains sequence number for all database objects. It automatically generates primary key value for all table insert. I think it also generates transaction related ID. For that reason it needs to update next sequence value for transaction ID.

Statment:
======================
SELECT CurrentNext, CurrentNextSys, IncrementNo, Prefix, Suffix, DecimalPattern, AD_Sequence_ID FROM AD_Sequence WHERE Name = $1 AND AD_Client_ID = $2 AND IsActive='Y' AND IsTableID='N' AND IsAutoSequence='Y' ORDER BY AD_Client_ID DESC FOR UPDATE OF AD_Sequence

AD_Sequence Table Definition
=====================

adempiere=# \d ad_sequence
Table "adempiere.ad_sequence"
Column | Type | Modifiers
----------------+-----------------------------+------------------------------
ad_sequence_id | numeric(10,0) | not null
ad_client_id | numeric(10,0) | not null
ad_org_id | numeric(10,0) | not null
isactive | character(1) | default 'Y'::bpchar
created | timestamp without time zone | not null default now()
createdby | numeric(10,0) | not null
updated | timestamp without time zone | not null default now()
updatedby | numeric(10,0) | not null
name | character varying(60) | not null
description | character varying(255) |
vformat | character varying(40) |
isautosequence | character(1) | not null default 'Y'::bpchar
incrementno | numeric(10,0) | not null
startno | numeric(10,0) | not null
currentnext | numeric(10,0) | not null
currentnextsys | numeric(10,0) | not null
isaudited | character(1) | default 'N'::bpchar
istableid | character(1) | default 'N'::bpchar
prefix | character varying(255) |
suffix | character varying(255) |
startnewyear | character(1) | default 'N'::bpchar
datecolumn | character varying(60) |
decimalpattern | character varying(40) |
Indexes:
"ad_sequence_pkey" PRIMARY KEY, btree (ad_sequence_id)
"ad_sequence_name" UNIQUE, btree (ad_client_id, name)
Check constraints:
"ad_sequence_isactive_check" CHECK (isactive = ANY (ARRAY['Y'::bpchar, 'N'::bpchar]))
"ad_sequence_isaudited_check" CHECK (isaudited = ANY (ARRAY['Y'::bpchar, 'N'::bpchar]))
"ad_sequence_isautosequence_check" CHECK (isautosequence = ANY (ARRAY['Y'::bpchar, 'N'::bpchar]))
"ad_sequence_istableid_check" CHECK (istableid = ANY (ARRAY['Y'::bpchar, 'N'::bpchar]))
"ad_sequence_startnewyear_check" CHECK (startnewyear = ANY (ARRAY['Y'::bpchar, 'N'::bpchar]))
Foreign-key constraints:
"sequenceclient" FOREIGN KEY (ad_client_id) REFERENCES ad_client(ad_client_id) DEFERRABLE INITIALLY DEFERRED
"sequenceorg" FOREIGN KEY (ad_org_id) REFERENCES ad_org(ad_org_id) DEFERRABLE INITIALLY DEFERRED

With Thanks & Regards:
---------------------
Shohorab Hossain

----- Original Message ----
From: Scott Marlowe <scott.marlowe@...>
To: shohorab hossain <shohorab23@...>
Cc: pgsql-admin@...; pgsql-docs@...; pgsql-general@...
Sent: Wednesday, November 18, 2009 2:55:25
Subject: Re: [GENERAL] Postgresql Database Lock Problem

Next time this is happening join the pg_lock table to the
pg_stat_activity table to see which query is holding the lock for a
bazillion milliseconds, while it's happening. That query / statement
may give you some clue what's wrong.

Get your preferred Email name!
Now you can @ymail.com and @rocketmail.com.
http://mail.promotions.yahoo.com/newdomains/aa/

--
Sent via pgsql-docs mailing list (pgsql-docs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: [GENERAL] Postgresql Database Lock Problem

2009-11-17T12:55:25Z

Next time this is happening join the pg_lock table to the
pg_stat_activity table to see which query is holding the lock for a
bazillion milliseconds, while it's happening. That query / statement
may give you some clue what's wrong.

--
Sent via pgsql-docs mailing list (pgsql-docs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Postgresql Database Lock Problem

2009-11-17T11:25:51Z

Problem: Database Lock
----------------------------------

Dear
all
I
am working as a database administrator in a company. Our Database
system is Postgresql-8.3.5 and Application server is Jboss used for
our Adempiere ERP system. This is a web based ERP system. All
servers are running on RHEL.

Now
our system is going to on-line and users are entering old data. So
transactions are occurring very frequently.

Now
I am facing the problem is the application server just hangs at busy
hour and it does not accept any new connection. When I restart the
server (Adempiere, Jboss) it works fine for a few hours and problem
occurs again. When this problem occurs the database server shows the
following log

LOG: process 19181 still waiting for ShareLock on transaction 18025221
after 1002.251 ms
STATEMENT: SELECT CurrentNext, CurrentNextSys, IncrementNo, Prefix, Suffix,
DecimalPattern, AD_Sequence_ID FROM AD_Sequence WHERE Name = $1 AND
AD_Client_ID = $2 AND IsActive='Y' AND IsTableID='N' AND
IsAutoSequence='Y' ORDER BY AD_Client_ID DESC FOR UPDATE OF
AD_Sequence

LOG: process 19181 acquired ShareLock on transaction 18025221 after
1298870.572 ms
STATEMENT: SELECT CurrentNext, CurrentNextSys, IncrementNo, Prefix, Suffix,
DecimalPattern, AD_Sequence_ID FROM AD_Sequence WHERE Name = $1 AND
AD_Client_ID = $2 AND IsActive='Y' AND IsTableID='N' AND
IsAutoSequence='Y' ORDER BY AD_Client_ID DESC FOR UPDATE OF
AD_Sequence

and
the lock table informations are as following:
adempiere=#
select * from pg_locks where granted = 'y' and mode =
'ExclusiveLock';
locktype |
database | relation | page | tuple | virtualxid | transactionid |
classid | objid | objsubid | virtualtransaction | pid | mode | granted
---------------+----------+----------+------+-------+------------+---------------+---------+-------+----------+--------------------+-------+---------------+---------
transactionid | | | | | | 18386552 |
| | | 39/1733 | 19196 | ExclusiveLock | t
virtualxid | | | | | 24/1586 | |
| | | 24/1586 | 19181 | ExclusiveLock | t
transactionid | | | | | | 18386856 |
| | | 24/1586 | 19181 | ExclusiveLock | t
virtualxid | | | | | 39/1733 | |
| | | 39/1733 | 19196 | ExclusiveLock | t
transactionid | | | | | | 18386574 |
| | | 39/1733 | 19196 | ExclusiveLock | t
transactionid | | | | | | 18386563 |
| | | 39/1733 | 19196 | ExclusiveLock | t
transactionid | | | | | | 18386869 |
| | | 24/1586 | 19181 | ExclusiveLock | t
virtualxid | | | | | 50/20 | |
| | | 50/20 | 19217 | ExclusiveLock | t
transactionid | | | | | | 18386846 |
| | | 24/1586 | 19181 | ExclusiveLock | t
tuple |
250427 | 251989 | 209 | 7 | | | | | | 24/1586 | 19181 | ExclusiveLock |
t
(10
rows)

adempiere=#
select * from pg_locks where granted = 'f';
locktype |
database | relation | page | tuple | virtualxid | transactionid |
classid | objid | objsubid | virtualtransaction | pid | mode |
granted
---------------+----------+----------+------+-------+------------+---------------+---------+-------+----------+--------------------+-------+-----------+---------
transactionid | | | | | | 18386574 |
| | | 24/1586 | 19181 | ShareLock | f
(1
row)

*** Here
you can see that process 19196 have ExclusiveLock on transaction
18386574 and process 19181 is waiting for ShareLock to the same
transaction.

When
I monitor the Application server sessions from Jboss console normally
I can see one of three stats R-Ready, K-Keep Alive and S-Service.
When the application server hangs all sessions goes to Service mode.

Please give me your appropriate and valuable solution in this regard. I am eagerly looking forward for your quick reply.
Thanks in advance: --------------------------- Shohorab Hossain

Send instant messages to your online friends http://uk.messenger.yahoo.com

--
Sent via pgsql-docs mailing list (pgsql-docs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

extract('dow', ...) mention

2009-11-15T13:50:15Z

Hi,

It seems to me this mention of extract()
in the manual (chapter 9.8):
extract('dow', ...)

is better replaced with
extract(dow from ...)

( 8.3, 8.4, HEAD )

hth

Erik Rijkers

--- doc/src/sgml/func.sgml.orig 2009-11-15 21:58:02.000000000 +0100
+++ doc/src/sgml/func.sgml 2009-11-15 21:59:16.000000000 +0100
@@ -5274,9 +5274,9 @@
<listitem>
<para>
<function>to_char(..., 'ID')</function>'s day of the week numbering
- matches the <function>extract('isodow', ...)</function> function, but
+ matches the <function>extract(isodow from ...)</function> function, but
<function>to_char(..., 'D')</function>'s does not match
- <function>extract('dow', ...)</function>'s day numbering.
+ <function>extract(dow from ...)</function>'s day numbering.
</para>
</listitem>

--
Sent via pgsql-docs mailing list (pgsql-docs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

vacuumdb clarification

2009-11-13T11:49:20Z

Here is a documentation patch I have applied to clarify that --analyze
does analyze during vacuum, not instead of vacuum.

--
Bruce Momjian <bruce@...> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Index: doc/src/sgml/ref/vacuumdb.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/ref/vacuumdb.sgml,v
retrieving revision 1.44
diff -c -c -r1.44 vacuumdb.sgml
*** doc/src/sgml/ref/vacuumdb.sgml 26 Feb 2009 16:02:37 -0000 1.44
--- doc/src/sgml/ref/vacuumdb.sgml 13 Nov 2009 19:46:37 -0000
***************
*** 159,165 ****
<term><option>--analyze</option></term>
<listitem>
<para>
! Calculate statistics for use by the optimizer.
</para>
</listitem>
</varlistentry>
--- 159,165 ----
<term><option>--analyze</option></term>
<listitem>
<para>
! Calculate statistics for use by the optimizer during vacuum.
</para>
</listitem>
</varlistentry>

--
Sent via pgsql-docs mailing list (pgsql-docs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: New member - where to begin

2009-10-23T14:05:02Z

Greg Smith wrote:
> On Fri, 23 Oct 2009, Roderick A. Anderson wrote:
>
>> * What format? DocBook was mentioned.
>
> http://developer.postgresql.org/pgdocs/postgres/docguide.html is the
> main intro to this area and the latest docs available. You'll need to
> check out the current release from CVS or git to generate patches; see
> http://wiki.postgresql.org/wiki/Development_information for guides to
> both of those.

Thanks Greg.

>
>> I prefer vim so what are your preferences for plugins-wise?
>> * Any Vim+DocBook or DocBook howtos/tutorials that you would recommend?
>
> For the most part simple changes are easy enough to make; just mimic the
> style of similar markup and confirm the docs still build after your
> change. I'd recommend using a version control system where you can
> track your diffs easier and commit in stages, particularly when getting
> started. That makes it easier to figure out what broke after a bad
> change and you can incrementally save successful changes until you get
> more comfortable.

Sounds good.

> If you have the full vim set (vim-enhanced on Fedora/RHEL, vim-full on
> Debian/Ubuntu), there is some assistance the editor can provide.
> There's a quick intro to helpful features to toggle at
> http://docs.fedoraproject.org/documentation-guide/en_US/ch-vim.html and
> a much longer discussion of macros at
> http://www.linuxjournal.com/article/7737 ; you really don't need
> anything beyond simple customizations in most cases though, simple tool
> assistance and cut/paste example copying is plenty if you're not
> authoring a serious docbook work from scratch.

I found both of these so will do a more in depth reading.

> One helpful thing you might do right off the bat is update section I.4
> "Documentation Authoring" with a section covering vim, to match the one
> already there for emacs, to include whatever you find works here.
> Getting documentation updates from patch authors is always hard to do,
> and some better information to help them accomplish that would be valuable.

This will be the first thing I work on.

\\||/
Rod
--
> --
> * Greg Smith gsmith@... http://www.gregsmith.com Baltimore, MD
>

--
Sent via pgsql-docs mailing list (pgsql-docs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: New member - where to begin

2009-10-23T13:54:38Z

On Fri, 23 Oct 2009, Roderick A. Anderson wrote:

> * What format? DocBook was mentioned.

http://developer.postgresql.org/pgdocs/postgres/docguide.html is the main
intro to this area and the latest docs available. You'll need to check
out the current release from CVS or git to generate patches; see
http://wiki.postgresql.org/wiki/Development_information for guides to both
of those.

> I prefer vim so what are your preferences for plugins-wise?
> * Any Vim+DocBook or DocBook howtos/tutorials that you would recommend?

For the most part simple changes are easy enough to make; just mimic the
style of similar markup and confirm the docs still build after your
change. I'd recommend using a version control system where you can track
your diffs easier and commit in stages, particularly when getting started.
That makes it easier to figure out what broke after a bad change and you
can incrementally save successful changes until you get more comfortable.

If you have the full vim set (vim-enhanced on Fedora/RHEL, vim-full on
Debian/Ubuntu), there is some assistance the editor can provide. There's
a quick intro to helpful features to toggle at
http://docs.fedoraproject.org/documentation-guide/en_US/ch-vim.html and a
much longer discussion of macros at
http://www.linuxjournal.com/article/7737 ; you really don't need anything
beyond simple customizations in most cases though, simple tool assistance
and cut/paste example copying is plenty if you're not authoring a serious
docbook work from scratch.

One helpful thing you might do right off the bat is update section I.4
"Documentation Authoring" with a section covering vim, to match the one
already there for emacs, to include whatever you find works here.
Getting documentation updates from patch authors is always hard to do, and
some better information to help them accomplish that would be valuable.

--
* Greg Smith gsmith@... http://www.gregsmith.com Baltimore, MD

--
Sent via pgsql-docs mailing list (pgsql-docs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

New member - where to begin

2009-10-23T13:12:55Z

While at PgConf West 2009 JD mentioned there is a need to review and
possibly update the Pg documentation.

I'm here and wondering where to start. :-)

A few questions that come to mind:

* Is there an area that needs the most attention?

* Is flavor-rite topics alright or what most do?

* What format? DocBook was mentioned.
I prefer vim so what are your preferences for plugins-wise?

* Any Vim+DocBook or DocBook howtos/tutorials that you would recommend?

\\||/
Rod
--

--
Sent via pgsql-docs mailing list (pgsql-docs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

[PATCH] clarify username mapping in Kerberos and GSSAPI

2009-10-23T12:43:50Z

[PATCH] clarify username mapping in Kerberos and GSSAPI

Hello all,

I noticed what appears to be an ambiguity in this area, so I prepared a patch. It is included below. The issue is that the documentation does not make it crystal clear exactly what string is used for username mapping when authenticating with GSSAPI or Kerberos. It’s possible that this issue also applies to the SSPI documentation, though I didn’t check.

Cheers,

--Ian Turner

Senior UNIX Systems Engineer

D. E. Shaw & Co.

--- postgresql-8.4-8.4.1/doc/src/sgml/client-auth.sgml 2009-06-24 14:46:32.000000000 +0100

+++ postgresql-8.4-8.4.1-docfix/doc/src/sgml/client-auth.sgml 2009-10-23 20:41:28.000000000 +0100

@@ -801,23 +801,28 @@

The following configuration options are supported for <productname>GSSAPI</productname>:

- <term><literal>map</literal></term>

+ <term><literal>include_realm</literal></term>

<para>

- Allows for mapping between system and database usernames. See

- <xref linkend="auth-username-maps"> for details.

+ If set to <literal>1</>, the realm name from the authenticated user

+ principal is included in the system user name that's passed through

+ username mapping (<xref linkend="auth-username-maps">). This is

+ useful for handling users from multiple realms.

</para>

</listitem>

</varlistentry>

- <term><literal>include_realm</literal></term>

+ <term><literal>map</literal></term>

<para>

- If set to <literal>1</>, the realm name from the authenticated user

- principal is included in the system user name that's passed through

- username mapping (<xref linkend="auth-username-maps">). This is

- useful for handling users from multiple realms.

+ Allows for mapping between system and database usernames. See

+ <xref linkend="auth-username-maps"> for details. For a Kerboros

+ principal <literal>username/hostbased@...</literal>, the

+ username used for mapping is <literal>username/hostbased</literal>

+ if <literal>include_realm</literal> is disabled, and

+ <literal>username/hostbased@...</literal> if

+ <literal>include_realm</literal> is enabled.

</para>

</listitem>

</varlistentry>

@@ -1003,10 +1008,10 @@

<para>

When connecting to the database make sure you have a ticket for a

principal matching the requested database user name. For example, for

- database user name <literal>fred</>, both principal

- <literal>fred@...</> and

- <literal>fred/users.example.com@...</> could be used to

- authenticate to the database server.

+ database user name <literal>fred</>, principal

+ <literal>fred@...</> would be able to connect. To also allow

+ principle <literal>fred/users.example.com@...</>, use a username

+ map, as described in <xref linkend="auth-username-maps">.

</para>

<para>

Re: Shared memory usage calculations

2009-10-10T13:15:22Z

Thom Brown <thombrown@...> writes:
> My mistake. I've never seen that before. Running it on mine returns the
> following:

> ------ Shared Memory Segments --------
> key shmid owner perms bytes nattch status

> 0x0052e2c1 491520 postgres 600 235511808 4

Okay, so your actual shmem size is 235MB, of which 196 is shared_buffers
and 8 is wal_buffers, and the rest is related to max_connections and
various third-order parameters. I'm not sure how precise the values
given in the docs are, but last I checked they weren't hugely wrong.

regards, tom lane

--
Sent via pgsql-docs mailing list (pgsql-docs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: Shared memory usage calculations

2009-10-10T11:45:45Z

2009/10/10 Tom Lane <tgl@...>

There is no "default value", we are talking about the actual size of an
actual memory object. Which you find out with ipcs, not sysctl.
For instance

$ ipcs -a

------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x00530201 3080195 tgl 600 37904384 4

------ Semaphore Arrays --------
key semid owner perms nsems
0x00530201 20873216 tgl 600 17
0x00530202 20905985 tgl 600 17
0x00530203 20938754 tgl 600 17
0x00530204 20971523 tgl 600 17
0x00530205 21004292 tgl 600 17
0x00530206 21037061 tgl 600 17
0x00530207 21069830 tgl 600 17

------ Message Queues --------
key msqid owner perms used-bytes messages

(I'm running this postmaster as "tgl", not the more usual "postgres".
On some platforms you might need to be the postgres user or root to see
shared objects belonging to postgres.)

regards, tom lane

My mistake. I've never seen that before. Running it on mine returns the following:

------ Shared Memory Segments --------

key shmid owner perms bytes nattch status

0x0052e2c1 491520 postgres 600 235511808 4

------ Semaphore Arrays --------

key semid owner perms nsems

0x0052e2c1 8585218 postgres 600 17

0x0052e2c2 8617987 postgres 600 17

0x0052e2c3 8650756 postgres 600 17

0x0052e2c4 8683525 postgres 600 17

0x0052e2c5 8716294 postgres 600 17

0x0052e2c6 8749063 postgres 600 17

0x0052e2c7 8781832 postgres 600 17

0x0052e2c8 8814601 postgres 600 17

0x0052e2c9 8847370 postgres 600 17

0x0052e2ca 8880139 postgres 600 17

0x0052e2cb 8912908 postgres 600 17

0x0052e2cc 8945677 postgres 600 17

0x0052e2cd 8978446 postgres 600 17

0x0052e2ce 9011215 postgres 600 17

0x0052e2cf 9043984 postgres 600 17

0x0052e2d0 9076753 postgres 600 17

0x0052e2d1 9109522 postgres 600 17

0x0052e2d2 9142291 postgres 600 17

0x0052e2d3 9175060 postgres 600 17

0x0052e2d4 9207829 postgres 600 17

0x0052e2d5 9240598 postgres 600 17

0x0052e2d6 9273367 postgres 600 17

0x0052e2d7 9306136 postgres 600 17

0x0052e2d8 9338905 postgres 600 17

0x0052e2d9 9371674 postgres 600 17

0x0052e2da 9404443 postgres 600 17

0x0052e2db 9437212 postgres 600 17

0x0052e2dc 9469981 postgres 600 17

0x0052e2dd 9502750 postgres 600 17

0x0052e2de 9535519 postgres 600 17

0x0052e2df 9568288 postgres 600 17

0x0052e2e0 9601057 postgres 600 17

0x0052e2e1 9633826 postgres 600 17

0x0052e2e2 9666595 postgres 600 17

0x0052e2e3 9699364 postgres 600 17

0x0052e2e4 9732133 postgres 600 17

0x0052e2e5 9764902 postgres 600 17

0x0052e2e6 9797671 postgres 600 17

0x0052e2e7 9830440 postgres 600 17

0x0052e2e8 9863209 postgres 600 17

0x0052e2e9 9895978 postgres 600 17

0x0052e2ea 9928747 postgres 600 17

0x0052e2eb 9961516 postgres 600 17

0x0052e2ec 9994285 postgres 600 17

0x0052e2ed 10027054 postgres 600 17

0x0052e2ee 10059823 postgres 600 17

0x0052e2ef 10092592 postgres 600 17

0x0052e2f0 10125361 postgres 600 17

0x0052e2f1 10158130 postgres 600 17

0x0052e2f2 10190899 postgres 600 17

0x0052e2f3 10223668 postgres 600 17

0x0052e2f4 10256437 postgres 600 17

0x0052e2f5 10289206 postgres 600 17

0x0052e2f6 10321975 postgres 600 17

0x0052e2f7 10354744 postgres 600 17

0x0052e2f8 10387513 postgres 600 17

0x0052e2f9 10420282 postgres 600 17

0x0052e2fa 10453051 postgres 600 17

0x0052e2fb 10485820 postgres 600 17

0x0052e2fc 10518589 postgres 600 17

------ Message Queues --------

key msqid owner perms used-bytes messages

In any case, I gather that the documentation isn't inaccurate, rather my interpretation is. And having put my number of connections right up to 1500, Postgres still starts fine, so I'm not sure why I thought it would cause the shared memory limit to be reached so easily.

Thanks

Thom

Re: Shared memory usage calculations

2009-10-10T11:39:38Z

Thom Brown <thombrown@...> writes:
> 2009/10/10 Tom Lane <tgl@...>
>> Clearly wrong compared to what --- ie, what's the actual size of your
>> shared memory segment? (See ipcs)

> I don't actually know the size of my shared memory segment. "sysctl -a |
> grep -i shmseg" doesn't return anything as it hasn't been set, and not sure
> how to find out the default value.

There is no "default value", we are talking about the actual size of an
actual memory object. Which you find out with ipcs, not sysctl.
For instance

$ ipcs -a

------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x00530201 3080195 tgl 600 37904384 4

------ Semaphore Arrays --------
key semid owner perms nsems
0x00530201 20873216 tgl 600 17
0x00530202 20905985 tgl 600 17
0x00530203 20938754 tgl 600 17
0x00530204 20971523 tgl 600 17
0x00530205 21004292 tgl 600 17
0x00530206 21037061 tgl 600 17
0x00530207 21069830 tgl 600 17

------ Message Queues --------
key msqid owner perms used-bytes messages

(I'm running this postmaster as "tgl", not the more usual "postgres".
On some platforms you might need to be the postgres user or root to see
shared objects belonging to postgres.)

regards, tom lane

--
Sent via pgsql-docs mailing list (pgsql-docs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: Shared memory usage calculations

2009-10-10T07:29:31Z

2009/10/10 Tom Lane <tgl@...>

Thom Brown <thombrown@...> writes:
> I've had a look at the documentation for how much shared memory (in bytes)
> Postgres uses:
> http://www.postgresql.org/docs/8.4/static/kernel-resources.html#SHARED-MEMORY-PARAMETERS
> However, after using these calculations to work out the shared memory usage
> for my own setup, the numbers I came up with are clearly wrong.

Clearly wrong compared to what --- ie, what's the actual size of your
shared memory segment? (See ipcs)

I don't actually know the size of my shared memory segment. "sysctl -a | grep -i shmseg" doesn't return anything as it hasn't been set, and not sure how to find out the default value. I didn't see that mentioned in the calculations so I didn't take it into account anywhere. But 1.7TB shared memory can't be right as the entire system memory is only 720MB.

> If I convert the sizes to kilobytes instead of bytes, it shows a total value
> of 47 megabytes, which, while not extreme, looks too low. And I am
> surprised that max_connections has relatively little bearing on the shared
> memory requirements. Is this right, or should is it more a case of it
> affecting semaphores? I was under the impression that the maximum number of
> connections played a large role in deciding shared memory limits.

No, it doesn't really ... shared_buffers is the first-order component.
Also, I'm not sure whether you realize that the native unit for these
numbers is mostly *not* bytes.

> shared_buffers = 196000000 (196MB)
> wal_buffers = 8000000 (8MB)

Neither of those parenthetical remarks are correct if that's exactly
what you wrote in postgresql.conf. It might be worth checking the
way these values are displayed in pg_settings.

The parenthesised values are what I have in postgresql.conf. I take it these are supposed to be mebibytes then? When I check the value in pg_settings, it's set at 25088 with the unit set at 8kB is 196 mebibytes. It also shows wal_buffers at 1024 with 8kB units, which would be 8 mebibytes.

I gather I'm calculating the final value wrong though. :/

Thom

Re: Shared memory usage calculations

2009-10-10T06:57:33Z

Thom Brown <thombrown@...> writes:
> I've had a look at the documentation for how much shared memory (in bytes)
> Postgres uses:
> http://www.postgresql.org/docs/8.4/static/kernel-resources.html#SHARED-MEMORY-PARAMETERS
> However, after using these calculations to work out the shared memory usage
> for my own setup, the numbers I came up with are clearly wrong.

Clearly wrong compared to what --- ie, what's the actual size of your
shared memory segment? (See ipcs)

> If I convert the sizes to kilobytes instead of bytes, it shows a total value
> of 47 megabytes, which, while not extreme, looks too low. And I am
> surprised that max_connections has relatively little bearing on the shared
> memory requirements. Is this right, or should is it more a case of it
> affecting semaphores? I was under the impression that the maximum number of
> connections played a large role in deciding shared memory limits.

No, it doesn't really ... shared_buffers is the first-order component.
Also, I'm not sure whether you realize that the native unit for these
numbers is mostly *not* bytes.

> shared_buffers = 196000000 (196MB)
> wal_buffers = 8000000 (8MB)

Neither of those parenthetical remarks are correct if that's exactly
what you wrote in postgresql.conf. It might be worth checking the
way these values are displayed in pg_settings.

regards, tom lane

--
Sent via pgsql-docs mailing list (pgsql-docs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Shared memory usage calculations

2009-10-10T05:52:04Z

I've had a look at the documentation for how much shared memory (in bytes) Postgres uses: http://www.postgresql.org/docs/8.4/static/kernel-resources.html#SHARED-MEMORY-PARAMETERS

However, after using these calculations to work out the shared memory usage for my own setup, the numbers I came up with are clearly wrong. Here's what I put my values down as:

max_locks_per_transaction = 64

max_connections = 220

autovacuum_max_workers = 3

max_prepared_transactions = 0

block_size = 8192

shared_buffers = 196000000 (196MB)

wal_block_size = 8192

wal_buffers = 8000000 (8MB)

Using the calculations on that page, it puts my shared memory requirements up to 1.7 terabytes, but my server is running along fine with these settings.

If I convert the sizes to kilobytes instead of bytes, it shows a total value of 47 megabytes, which, while not extreme, looks too low. And I am surprised that max_connections has relatively little bearing on the shared memory requirements. Is this right, or should is it more a case of it affecting semaphores? I was under the impression that the maximum number of connections played a large role in deciding shared memory limits.

My SHMMAX is currently set at 268435456, which I thought was just enough to cover my config settings.

Is the documentation flawed, or am I using the wrong units?

Thanks

Thom

pg_restore listing

2009-09-29T02:01:57Z

Hello, pgsql-docs.

I think it would be nice to update the listing file example (and
explanation of listing) at
http://www.postgresql.org/docs/8.4/static/app-pgrestore.html

Now it looks like:

;
; Archive created at Fri Jul 28 22:28:36 2000
; dbname: mydb
; TOC Entries: 74
; Compression: 0
; Dump Version: 1.4-0
; Format: CUSTOM
;
;
; Selected TOC Entries:
;
2; 145344 TABLE species postgres
3; 145344 ACL species
...

But modern utilities output looks a bit different:

;
; Archive created at Mon Sep 14 13:55:39 2009
; dbname: DBDEMOS
; TOC Entries: 81
; Compression: 9
; Dump Version: 1.10-0
; Format: CUSTOM
; Integer: 4 bytes
; Offset: 8 bytes
; Dumped from database version: 8.3.5
; Dumped by pg_dump version: 8.3.8
;
;
; Selected TOC Entries:
;
3; 2615 2200 SCHEMA - public pasha
1861; 0 0 COMMENT - SCHEMA public pasha
1862; 0 0 ACL - public pasha
317; 1247 17715 TYPE public composite pasha
319; 1247 25899 DOMAIN public domain0 pasha

--
With best wishes,
Pavel mailto:pavel@...

--
Sent via pgsql-docs mailing list (pgsql-docs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: functions-formatting.html

2009-09-14T13:03:28Z

david@... writes:
> Was reading the docs and stumbled across what I believe is a mistake.
> There is a mistake in Table 9-25
> the result of to_char(148.5,'999D999') should be ' 148.500',
> the docs list it as ' 148,500'

The example in the docs presumes a locale where comma is the radix point
(eg, fr_FR). Perhaps that should be clarified, but changing the example
so that D appears to act the same as . doesn't seem to me to be an
improvement.

regards, tom lane

--
Sent via pgsql-docs mailing list (pgsql-docs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

functions-formatting.html

2009-09-14T12:24:53Z

Was reading the docs and stumbled across what I believe is a mistake.

There is a mistake in Table 9-25
the result of to_char(148.5,'999D999') should be ' 148.500',
the docs list it as ' 148,500'

http://www.postgresql.org/docs/8.4/interactive/functions-formatting.html
and
http://developer.postgresql.org/pgdocs/postgres/functions-formatting.html

--
Sent via pgsql-docs mailing list (pgsql-docs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: Doc 8.4 Part 2 - Cap 6 : Data Manipulation ( about Triggers and Rewrite Rules )

2009-09-11T05:53:48Z

On Fri, 2009-08-21 at 08:53 -0300, Bruno Guimarães Carneiro wrote:
> http://www.postgresql.org/docs/8.4/interactive/dml.html
>
> In this chapter we find:
> We also introduce ways to effect automatic data changes when
> certain events occur: triggers and rewrite rules.
>
> But i didnt find anything about triggers and rewrite rules.

Indeed. I have removed the claim.

--
Sent via pgsql-docs mailing list (pgsql-docs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: [GENERAL] What happens when syslog gets blocked?

2009-09-10T08:05:39Z

Alvaro Herrera wrote:

> decibel wrote:
> > On Aug 6, 2009, at 2:00 PM, Bill Moran wrote:
>
> > >Well ... "life better" really depends on which failure scenario you're
> > >more comfortable with ... personally, I'd rather lose log messages
> > >than
> > >have the DB system go down. Of course, if auditing is critical to
> > >your
> > >scenario, then your priorities are different ...
> >
> > Bingo. I'm thinking we should make mention of this in the docs...
>
> I propose the following patch.

Committed (on HEAD)

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

--
Sent via pgsql-docs mailing list (pgsql-docs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: no refentry in acronyms.sgml?

2009-09-07T10:28:11Z

Alvaro Herrera <alvherre@...> writes:
> I have not fooled with these files lately so I have zero idea where the
> bogus postgres.xml came from.

The dependencies in doc/src/sgml/Makefile have moved around a bit
lately, so maybe things got confused. Still, a 'make clean' should
have fixed it right up.

regards, tom lane

--
Sent via pgsql-docs mailing list (pgsql-docs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: no refentry in acronyms.sgml?

2009-09-07T09:33:12Z

Alvaro Herrera wrote:

> osx:/pgsql/source/00head/doc/src/sgml/acronyms.sgml:3:0:E: prolog can't be omitted unless CONCUR NO and LINK EXPLICIT NO and either IMPLYDEF ELEMENT YES or IMPLYDEF DOCTYPE YES
> osx:/pgsql/source/00head/doc/src/sgml/acronyms.sgml:3:0:E: no document type declaration; will parse without validation
> Erro: no refentry: No refentry elements found in "Acronyms". Acronyms
>
> I have no idea how to fix this.

After looking at this, I noticed that for some unknown reason,
postgres.xml only contained the output generated from acronyms.sgml.
After removing it, it got regenerated from the whole set of files and
"make man" started behaving normally.

I have not fooled with these files lately so I have zero idea where the
bogus postgres.xml came from.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

--
Sent via pgsql-docs mailing list (pgsql-docs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

no refentry in acronyms.sgml?

2009-09-07T07:05:13Z

Hi,

I just got this weird error while doing "make distprep" (doc build being
previously enabled):

osx:/pgsql/source/00head/doc/src/sgml/acronyms.sgml:3:0:E: prolog can't be omitted unless CONCUR NO and LINK EXPLICIT NO and either IMPLYDEF ELEMENT YES or IMPLYDEF DOCTYPE YES
osx:/pgsql/source/00head/doc/src/sgml/acronyms.sgml:3:0:E: no document type declaration; will parse without validation
Erro: no refentry: No refentry elements found in "Acronyms". Acronyms

I have no idea how to fix this.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

--
Sent via pgsql-docs mailing list (pgsql-docs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

8.4: suppress_redundant_updates trigger vs. "Upsert" logic

2009-09-04T08:15:36Z

Hello,

It might be helpful to point out that the "suppress_redundant_updates" trigger will cause trouble with the normal approach to doing an UPSERT, for example that specified by the "merge_db" function in example 38-2 here:
http://www.postgresql.org/docs/current/static/plpgsql-control-structures.html#PLPGSQL-UPSERT-EXAMPLE

If you happen to submit a redundant update against a table with the suppress_redundant_updates trigger, using the merge_db function, you'll end up in an infinite loop.

It'll similarly break any code where a result of "UPDATE 0" is assumed to indicate that the record does not exist.

Suggested changes:
1. Add to http://www.postgresql.org/docs/8.4/static/functions-trigger.html the following copy, or something nicer :)
Note that the suppress_redundant_updates trigger invalidates any logic that assumes that the number of rows affected by an UPDATE indicates the existence or non-existence of the associated rows. Specifically, in the case of the merge_db function, any redundant updates performed by this function will cause an infinite loop.

2. Add to http://www.postgresql.org/docs/8.4/static/plpgsql-control-structures.html#PLPGSQL-UPSERT-EXAMPLE the following copy
Warning: Using this function or similar logic is incompatible with the suppress_redundant_updates trigger, since it is assumed that if zero rows are updated, the row does not exist.

Alternatively, the example merge_db function could be reworked to be compatible with the trigger by attempting the insert first, for example:

CREATE FUNCTION merge_db(key INT, data TEXT) RETURNS VOID AS

$$
BEGIN
    BEGIN
        -- first try to insert the row
        INSERT INTO db(a,b) VALUES (key, data);
    EXCEPTION WHEN unique_violation THEN
        -- key already existed, try updating the row

        UPDATE db SET b = data WHERE a = key;
    END;
END;
$$
LANGUAGE plpgsql;

The above is not as robust as the original, since it doesn't retry, and it's a bit of a foot-gun if you don't actually have a unique constraint... Maybe someone else can come up with a version that's strictly better than the old one, and still plays nice with suppress_redundant_updates.

Thanks!

Mark

Re: [GENERAL] What happens when syslog gets blocked?

2009-09-03T15:04:44Z

decibel wrote:
> On Aug 6, 2009, at 2:00 PM, Bill Moran wrote:

> >Well ... "life better" really depends on which failure scenario you're
> >more comfortable with ... personally, I'd rather lose log messages
> >than
> >have the DB system go down. Of course, if auditing is critical to
> >your
> >scenario, then your priorities are different ...
>
> Bingo. I'm thinking we should make mention of this in the docs...

I propose the following patch.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Index: doc/src/sgml/config.sgml =================================================================== RCS file: /home/alvherre/Code/cvs/pgsql/doc/src/sgml/config.sgml,v retrieving revision 1.224 diff -c -p -r1.224 config.sgml *** doc/src/sgml/config.sgml 24 Aug 2009 20:08:31 -0000 1.224 --- doc/src/sgml/config.sgml 3 Sep 2009 22:03:00 -0000 *************** local0.* /var/log/postgresql *** 2408,2413 **** --- 2408,2426 ---- is dynamic-linker failure messages). This parameter can only be set at server start. </para> + + <note> + <para> + The logging collector is designed to never lose messages. This means + that in case of extremely high load, server processes could be + blocked due to trying to send additional log messages when the + collector has fallen behind. In contrast, <application>syslog</> + prefers to drop messages if it cannot write them, which means it's + less reliable in those cases but it will not block the rest of the + system. + </para> + </note> + </listitem> </varlistentry>

--
Sent via pgsql-docs mailing list (pgsql-docs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: Postgres Sql7.3 Update

2009-09-03T11:32:10Z

On Wed, Sep 2, 2009 at 7:09 AM,
kunwarpal.rawat<kunwarpal.rawat@...> wrote:
>
> 2. The list of feature that’s updating in each new version of the
> software.
>

http://www.postgresql.org/about/featurematrix

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157

--
Sent via pgsql-docs mailing list (pgsql-docs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs