[jks@jks-work-desktop /tmp/tmp/postgresql-8.2rc1]$
src/tools/make_diff/difforig
../doc/src/sgml/ref/rollback_to.sgml
*** ./doc/src/sgml/ref/rollback_to.sgml.orig 2006-11-27
16:57:41.000000000 -0500
--- ./doc/src/sgml/ref/rollback_to.sgml 2006-11-27 17:02:43.000000000 -0500
***************
*** 69,74 ****
--- 69,80 ----
</para>

<para>
+ Rolling back a savepoint does not release it. It
+ will still be available for rolling back to, and it will still consume
+ shared memory until released.
+ </para>
+
+ <para>
Specifying a savepoint name that has not been established is an error.
</para>

../doc/src/sgml/ref/savepoint.sgml
*** ./doc/src/sgml/ref/savepoint.sgml.orig 2006-11-27
16:30:28.000000000 -0500
--- ./doc/src/sgml/ref/savepoint.sgml 2006-11-27 16:36:37.000000000 -0500
***************
*** 73,78 ****
--- 73,87 ----
Savepoints can only be established when inside a transaction block.
There can be multiple savepoints defined within a transaction.
</para>
+ <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:
+ <programlisting>
+ WARNING: out of shared memory
+ ERROR: out of shared memory
+ HINT: You may need to increase max_locks_per_transaction.
+ </programlisting>
+ </para>
</refsect1>

<refsect1>

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

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

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

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




---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

"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

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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




---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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.

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org