doc patch for savepoints

Joseph Shraibman <jks@selectacast.net> writes:

+   <para>
+    Savepoints use shared memory.  If you use many savepoints without 
releasing them, you
+    will run out of shared memory and you may see an error like this in 
your log:

I do not see the point of this. Shall we put equivalent disclaimers
into every single construct that consumes shared memory? There is no
such paragraph under LOCK TABLE, for example.

regards, tom lane

On Mon, 2006-11-27 at 17:48 -0500, Tom Lane wrote:

Joseph Shraibman <jks@selectacast.net> writes:

+   <para>
+    Savepoints use shared memory.  If you use many savepoints without 
releasing them, you
+    will run out of shared memory and you may see an error like this in 
your log:

I do not see the point of this. Shall we put equivalent disclaimers
into every single construct that consumes shared memory?

Stating that it uses shared memory? Absolutely. Stating that you may run
out? No, that is implicit in that shared memory is a static value made
available to the operating system (well dynamic, but statically
configured).

Joshua D. Drake

There is no
such paragraph under LOCK TABLE, for example.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

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

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

"Joshua D. Drake" <jd@commandprompt.com> writes:

On Mon, 2006-11-27 at 17:48 -0500, Tom Lane wrote:

I do not see the point of this. Shall we put equivalent disclaimers
into every single construct that consumes shared memory?

Stating that it uses shared memory? Absolutely. Stating that you may run
out? No, ...

Well, the fact that it uses shared memory is an uninteresting
implementation detail --- at least, it's uninteresting until you run
out. When/if that happens, ISTM the error message and HINT are plenty
good enough to tell you what to do about it. If we tried to document
every possible error message and appropriate corrective action for same
the docs would become bloated to the point of unreadability. So to me
the question is why this particular case deserves a paragraph of its own.

regards, tom lane

On Mon, 2006-11-27 at 17:58 -0500, Tom Lane wrote:

"Joshua D. Drake" <jd@commandprompt.com> writes:

On Mon, 2006-11-27 at 17:48 -0500, Tom Lane wrote:

I do not see the point of this. Shall we put equivalent disclaimers
into every single construct that consumes shared memory?

Stating that it uses shared memory? Absolutely. Stating that you may run
out? No, ...

Well, the fact that it uses shared memory is an uninteresting
implementation detail --- at least, it's uninteresting until you run
out. When/if that happens, ISTM the error message and HINT are plenty
good enough to tell you what to do about it. If we tried to document
every possible error message and appropriate corrective action for same
the docs would become bloated to the point of unreadability. So to me
the question is why this particular case deserves a paragraph of its own.

I would agree that it likely does not need a paragraph on its own.

Hmm... but a shared memory reference page? Something that says, "What
uses shared memory with PostgreSQL?" That might be useful.

Sincerely,

Joshua D. Drake

regards, tom lane

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

Tom Lane wrote:

Joseph Shraibman <jks@selectacast.net> writes:

+   <para>
+    Savepoints use shared memory.  If you use many savepoints without 
releasing them, you
+    will run out of shared memory and you may see an error like this in 
your log:

I do not see the point of this. Shall we put equivalent disclaimers
into every single construct that consumes shared memory? There is no
such paragraph under LOCK TABLE, for example.

Because one is unlikely to lock so many tables that they run out of
shared memory. On the other hand if someone does like I did, which is
in a loop:

SAVEPOINT ;
UPDATE;

and does not realize that SAVEPOINT uses shared memory they can get
themselves in trouble.

You don't have to have the error message example, but I really think
some sort of message is needed. Right now it is not clear that
savepoints use shared memory at all. A user might assume they just
exist on the disk somehow, or in regular nonshared memory.

Tom Lane wrote:

"Joshua D. Drake" <jd@commandprompt.com> writes:

On Mon, 2006-11-27 at 17:48 -0500, Tom Lane wrote:

I do not see the point of this. Shall we put equivalent disclaimers
into every single construct that consumes shared memory?

Stating that it uses shared memory? Absolutely. Stating that you may run
out? No, ...

Well, the fact that it uses shared memory is an uninteresting
implementation detail --- at least, it's uninteresting until you run
out. When/if that happens, ISTM the error message and HINT are plenty
good enough to tell you what to do about it.

No, when you run out it is not obvious that your unreleased savepoints
are causing the problem.

To further help diagnose shared memory problems maybe in pg_locks there
should be the sql that caused the lock to come into existence, like
current_query in pg_stat_activity.