Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Hmm ... but that "close" can't unregister the snapshot immediately,
>> because you'd lose if the 2nd savepoint gets rolled back, no? Is the
>> handling of this case even correct at the moment?
> No, CLOSE is not rolled back:
> ...
>
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Shouldn't UnregisterSnapshot insist that s_level be equal to current
> >> xact nest level?
>
> > It can't check that; consider
>
> > begin;
> > savepoint foo;
> > declare cur cursor for select (1), (2), (3);
> >
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Shouldn't UnregisterSnapshot insist that s_level be equal to current
>> xact nest level?
> It can't check that; consider
> begin;
> savepoint foo;
> declare cur cursor for select (1), (2), (3);
> savepoint bar;
> close cur;
> commit;
Tom Lane wrote:
I'm revising the patch; this comment is flawed though:
> Shouldn't UnregisterSnapshot insist that s_level be equal to current
> xact nest level?
It can't check that; consider
begin;
savepoint foo;
declare cur cursor for select (1), (2), (3);
savepoint bar;
close cur;
commit;
Th
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> I am sending enhanced version of original patch.
Hmm ... this patch seems to have been generated against something
significantly different from HEAD ... was that intentional?
patching file plpgsql.sgml
Hunk #1 succeeded at 2102 (offset -82 lines).
Hun
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Also, I think that the whole snapshot-sharing mechanism is not working
>> as intended except for the serializable case; otherwise sequences
>> like
>> x = RegisterSnapshot(GetTransactionSnapshot());
>> y = RegisterSnapshot(GetTransacti
Nikhils <[EMAIL PROTECTED]> writes:
> ... One minor thing that myself and Alex discussed was
> the usage of "child tables" in tablecmds.c, especially in error messages.
> Again English is not my native language, but shouldn't that be worded as
> "children tables"? Admittedly even this does not soun
On Sat, May 10, 2008 at 11:02 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> Where are we on this?
I haven't had time to do any work since the original patch. That patch
was fairly basic - it just ran install / uninstall scripts and created
catalog entries, and introduced some slightly exotic sy
On Sun, May 11, 2008 at 04:30:47AM -0700, daveg wrote:
>
> Attached is a patch to add a commandline option to pg_dump to limit how long
> pg_dump will wait for locks during startup.
Ooops, really attached this time.
-dg
--
David Gould [EMAIL PROTECTED] 510 536 1443510 282 0869
Attached is a patch to add a commandline option to pg_dump to limit how long
pg_dump will wait for locks during startup.
The intent of this patch is to allow pg_dump to fail if a table lock cannot
be taken in a reasonable time. This allows the caller of pg_dump to retry or
otherwise correct the s
Hi,
On Sat, May 10, 2008 at 6:11 AM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> On Fri, May 9, 2008 at 5:37 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> >> [ patch to change inherited-check-constraint behavior ]
> >
> > Applied after rather heavy editor
11 matches
Mail list logo
