On Tue, 6 Jul 2004, Alvaro Herrera wrote:
We can later implement savepoints, which will have SAVEPOINT foo and
ROLLBACK TO foo as interface. (Note that a subtransaction is slightly
different from a savepoint, so we can't use ROLLBACK TO foo in
subtransactions because that has a different
Its questionable if these are to be interpreted as just changing the
default tablespace for subsequent creates, or also moving all objects
that were created using the previous tablespace. Since it's
indistinguishable whether an object was created using the default from
schema/database or given
Christopher Kings-Lynne wrote:
The other thing we need are these two commands:
ALTER DATABASE foo SET TABLESPACE spc;
ALTER SCHEMA foo SET TABLESPACE spc;
I think these should not be considered new features but essential
functionality left out of the original patch.
Its questionable if these are
On Sat, Jul 03, 2004 at 11:03:33AM -0400, Tom Lane wrote:
than begin/commit for subxacts? What about savepoints?) Also, what about
exposing this functionality in plpgsql? Seems like we need some kind of
exception handling syntax to make this useful. What does Oracle do?
Oracle uses
Dennis Bjorklund wrote:
On Tue, 6 Jul 2004, Alvaro Herrera wrote:
We can later implement savepoints, which will have SAVEPOINT foo and
ROLLBACK TO foo as interface. (Note that a subtransaction is slightly
different from a savepoint, so we can't use ROLLBACK TO foo in
subtransactions because that
Christopher Kings-Lynne wrote:
Its questionable if these are to be interpreted as just changing the
default tablespace for subsequent creates, or also moving all objects
that were created using the previous tablespace. Since it's
indistinguishable whether an object was created using the default
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Well, my opinion is that cursors and other resources should at least be
usable from a inner subtransaction in its parent -- because if that
can't be done we are wasting some of the benefits, because we can't just
stick everything in a
On Wed, 7 Jul 2004, Oliver Jowett wrote:
Savepoint ROLLBACK TO foo doesn't invalidate 'foo'. If SAVEPOINT foo
is 'start new subtransaction foo', ROLLBACK TO foo must be 'roll back
subtransaction foo and all children; start new subtransaction foo'.
If that is all there is, I much rather see
On Wed, 7 Jul 2004, Oliver Jowett wrote:
So how do you propose supporting simple rollback of a subtransaction? It
seems like an extension regardless of how it's done.
If I understand you correctly what you want is a ROLLBACK TO SAVEPOINT
foo; followed by a RELEASE SAVEPOINT foo;
--
/Dennis
Dennis Bjorklund wrote:
On Wed, 7 Jul 2004, Oliver Jowett wrote:
So how do you propose supporting simple rollback of a subtransaction? It
seems like an extension regardless of how it's done.
If I understand you correctly what you want is a ROLLBACK TO SAVEPOINT
foo; followed by a RELEASE
On Wed, 7 Jul 2004, Oliver Jowett wrote:
If I understand you correctly what you want is a ROLLBACK TO SAVEPOINT
foo; followed by a RELEASE SAVEPOINT foo;
Ugh.. nasty syntax and an extra empty transaction.
If you translate it directly using only the primitives of the current
Yannick Lecaillez wrote:
Thanks a lot for all people which answer.
I have this clustering on SAN problem today and i think it could be
less harder to implement this today than it was for Oracle in 1993
(since i can find a lot of work in opensource which could be interesting
in this project
Well, Tom does seem to have something with regard to StartUpIds. I feel
it is easier to force a new timeline by adding a very large number to
the LogId IF, and only if, we have performed an archive recovery. That
way, we do not change at all the behaviour of the system for people that
choose
Tom Lane wrote:
Recovering when you get an error is probably the trickiest part of this.
OK, I have a setup that instead of refusing to load trusted functions if
the Safe version is not up to date, forces them to error out by calling
elog(ERROR...), thus:
andrew=# select tval();
ERROR:
On Tue, 2004-07-06 at 23:36, Greg Stark wrote:
Scott Marlowe [EMAIL PROTECTED] writes:
Why not rollback all or commit all?
I really really don't like subbegin and subcommit. I get the feeling
they'll cause more problems we haven't foreseen yet, but I can't put my
finger on it.
On Wed, 2004-07-07 at 00:16, Dennis Bjorklund wrote:
On Tue, 6 Jul 2004, Alvaro Herrera wrote:
We can later implement savepoints, which will have SAVEPOINT foo and
ROLLBACK TO foo as interface. (Note that a subtransaction is slightly
different from a savepoint, so we can't use ROLLBACK
On Wed, 2004-07-07 at 06:39, Yannick Lecaillez wrote:
I have this clustering on SAN problem today and
snip
Me thinks you've fallen into the trap of proprietary vendors. Your
problem isn't that you need clustering on SAN, your problem is you
want some form of high availability solution for your
Few days old snapshot produces an error when making tsearch2 module:
dict_ispell.o(.text+0x31b):dict_ispell.c: undefined reference to
`pg_strcasecmp'
dict_ispell.o(.text+0x420):dict_ispell.c: undefined reference to
`pg_strcasecmp'
dict_ispell.o(.text+0x500):dict_ispell.c: undefined reference to
Scott Marlowe wrote:
On Tue, 2004-07-06 at 23:36, Greg Stark wrote:
Scott Marlowe [EMAIL PROTECTED] writes:
Why not rollback all or commit all?
I really really don't like subbegin and subcommit. I get the feeling
they'll cause more problems we haven't foreseen yet, but I can't put my
On Wed, 2004-07-07 at 02:04, Justin Clift wrote:
Simon Riggs wrote:
snip
External tool is one thing, but the loadable personality seems like a
very good idea and worth discussing further.
Would an interesting, and maybe slightly different way of viewing a
loadable personality, be as a
On Wed, 2004-07-07 at 14:17, Zeugswetter Andreas SB SD wrote:
Well, Tom does seem to have something with regard to StartUpIds. I feel
it is easier to force a new timeline by adding a very large number to
the LogId IF, and only if, we have performed an archive recovery. That
way, we do not
21 matches
Mail list logo
