Thread: doc patch for savepoints
[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
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.