"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Fri, 2006-11-10 at 18:55 -0500, Tom Lane wrote:
>> One thought that comes to mind is to require hash to do an smgrextend()
>> addressing the last block it intends to use whenever it allocates a new
>> batch of blocks, whereupon md.c could adopt a saner
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
Just wanted to let you know that working with Teodor I beleive we have
now found the cause for this bug, and I have a workaround that passes
your tests. I'm unsure if it's safe on != win32, so I'm deferring to
Teodor to come up with the final fix.
It's also possible that I spotted another problem
