Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> ... Did we explicitly decide
>> to do this differently from spec, and if so why?
> Yeah, we did. I think the rationale was what happens when you have
> another savepoint in the middle, say
> SAVEPOINT foo;
> SAVEPOINT bar;
> SAVEPOI
Tom Lane wrote:
> Actually, I'd say the dubious behavior here is that
>
> SAVEPOINT foo;
> SAVEPOINT foo;
> SAVEPOINT foo;
>
> creates three nested savepoints ... it might be better if it
> automatically released any existing savepoint of the same name.
> I notice that the SAVE
Tom Lane wrote:
Joseph Shraibman writes:
See example below. At the very least the documentation needs to tell
users that savepoints use shared memory, and the cofusing HINT string
needs to be changed to something more useful.
Which part of "You may need to increase max_locks_per_transactio
Joseph Shraibman writes:
> See example below. At the very least the documentation needs to tell
> users that savepoints use shared memory, and the cofusing HINT string
> needs to be changed to something more useful.
Which part of "You may need to increase max_locks_per_transaction" do
you find
See example below. At the very least the documentation needs to tell
users that savepoints use shared memory, and the cofusing HINT string
needs to be changed to something more useful.
When run on a machine running 8.2b3
version: PostgreSQL 8.2beta3 on i686-pc-linux-gnu, compiled by GCC gcc
