On Sat, 10 Jul 2004, Bruce Momjian wrote:
> Oracle can use SAVEPOINTS all the time because it knows it is always in
> a transaction, but PostgreSQL is not always.
PostgreSQL is also alsways in a transaction. If some use autocommit and go
SAVEPOINT foo;
RELEASE foo;
The first will work and
On Sat, Jul 10, 2004 at 09:18:28PM -0700, elein wrote:
> The new plperl returns sets by having
> the function return an array.
>
> This requires that the entire array be
> built before anything is returned.
>
> It seems to me that that does not scale
> very well. The technique of RETURN NEXT;
>
On Sat, Jul 10, 2004 at 08:25:16PM -0400, Bruce Momjian wrote:
> Do we want to allow BEGIN NESTED to start a main transaction?
I have a better question: do we allow SAVEPOINT (i.e. to establish a
savepoint, i.e. to open a nested transaction) within an aborted
transaction block?
This is allowed i
The new plperl returns sets by having
the function return an array.
This requires that the entire array be
built before anything is returned.
It seems to me that that does not scale
very well. The technique of RETURN NEXT;
scales much better.
For example, you maybe selecting rows,
doing a litt
Christopher Kings-Lynne wrote:
> > Part of the problem is that PREPARE has no provision to overwrite an
> > existing plan (CREATE OR REPLACE). I run into this all the time because
> > I make heavy use of prepared statements to emulate an ISAM file system.
> > I have to jump through hoops to keep t
I have added to TODO:
* Allow moving system tables to other tablespaces, where
possible
---
Tom Lane wrote:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > With our new tablespace set up, is it
What was the conclusion for PREPARE done inside transactions?
---
Tom Lane wrote:
> "Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> > I think we're talking at cross purposes here... If the client doesn't use
> > explici
If you get full control of PostgreSQL, you can dictate what will happen.
Until then, I will follow the community consensus, which may or may not
match your opinion.
---
Marc G. Fournier wrote:
> On Sat, 10 Jul 2004, Bruce Mo
On Sat, 10 Jul 2004, Bruce Momjian wrote:
My point is that it isn't the patch submitters we are waiting on
anymore. It is the backlog of patches that need review/adjustment.
"Of course, many of the patches I kept need some adjustment to get applied
..." ... to me, that indicates that even after r
My point is that it isn't the patch submitters we are waiting on
anymore. It is the backlog of patches that need review/adjustment.
---
Marc G. Fournier wrote:
> On Sat, 10 Jul 2004, Bruce Momjian wrote:
>
> > I am still g
On Sat, 10 Jul 2004, Bruce Momjian wrote:
I am still going through my mailbox, trying to address all the open
patches so we can move toward beta. Of course, many of the patches I
kept need some adjustment to get applied (e.g. configuration file
location) so it is slow going.
However, we still have
Added to TODO:
* Allow changing of already-created database and schema
tablespaces
---
Christopher Kings-Lynne wrote:
> > Tom already mentioned this just after committing tablespaces: 'Minor DROP
> > TABLE
I am still going through my mailbox, trying to address all the open
patches so we can move toward beta. Of course, many of the patches I
kept need some adjustment to get applied (e.g. configuration file
location) so it is slow going.
However, we still have PITR unapplied, autovacuum unapplied, and
On Sat, 2004-07-10 at 15:21, Josh Berkus wrote:
> Bruce,
>
> > They have no way of reporting a failed query back to the user? How do
> > people program in those environments? Right now any failed query aborts
> > the transaction so it seems it would be pretty easy.
>
> Believe it or not, PHP4 d
Josh Berkus wrote:
> > Well, that involves either creating a conditional capability in the
> > backend, or in psql, neither of which will happen for 7.5. The best we
> > can do is allow COMMIT NESTED INGORE ERROR (or COMMIT NESTED INGORE
> > ROLLBACK) and just let the script keep going. I am think
Added to TODO, just so we don't forget later:
* Use a phantom command counter for nested subtransactions to reduce
tuple overhead
---
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Hmm .
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > It seems anonymous savepoints really don't buy us anything. They
> > don't match the Oracle behavior, and don't do anything more than
> > nested transactions. I agree we want them, but I don't see the value
> > they add value right now.
>
> The v
I wrote:
> I was initially thinking that probing a large number of test times
> would be expensive, but on second thought I don't see that it would
> be a problem. On nearly all the entries in the TZ database, we'd
> reject on the first or second probe time anyway; only very near
> matches such as
Bruce Momjian wrote:
elein wrote:
FYI: I'm agreeing w/Tom who is agreeing with me.
The tag change should be good. I do hope people are
not relying on seeing COMMIT when the transaction
rolled back. It does not seem that in this case
they would.
If it is a problem, hopefully we will hear about it
Josh Berkus wrote:
3) We adopt a slightly mutated form of the SQL3 SAVEPOINT syntax. This would
have the twin benefit of both allowing us to improve our standards compliance
and make savepoints completely compliant in the next version, as well as
helping those wishing to migrate from Oracle to
Bruce,
> It seems anonymous savepoints really don't buy us anything. They don't
> match the Oracle behavior, and don't do anything more than nested
> transactions. I agree we want them, but I don't see the value they add
> value right now.
Anonymous Savepoints == Nested Transactions
This issue
Bruce Momjian wrote:
> It seems anonymous savepoints really don't buy us anything. They
> don't match the Oracle behavior, and don't do anything more than
> nested transactions. I agree we want them, but I don't see the value
> they add value right now.
The value they add is that they follow the
Bruce Momjian wrote:
The syntax was for support of script languages that don't have
conditional constructs, like psql scripts, where you want the subxact to
commit but if it fails, you don't want that to affect the outer
transaction. Are you saying there are very few cases where you don't
care if
Josh Berkus wrote:
> But the ability to detect an abort state *from the SQL command line*
> (or a database port connection) has not been addressed.
This has existed since 7.4. If some interfaces don't expose it, fix
those interfaces.
---(end of broadcast)-
Josh Berkus wrote:
> Bruce,
>
> > They have no way of reporting a failed query back to the user? How do
> > people program in those environments? Right now any failed query aborts
> > the transaction so it seems it would be pretty easy.
>
> Believe it or not, PHP4 doesn't. This is one of the
Josh Berkus wrote:
> Dennis,
>
> > The non-standard part I was talking about was the savepoints without
> > names, and that is what we should support for ever if we introduce them.
>
> I don't have a problem with that idea.Anonymous Savepoints should be easy
> to support if we are supportin
Dennis,
> The non-standard part I was talking about was the savepoints without
> names, and that is what we should support for ever if we introduce them.
I don't have a problem with that idea.Anonymous Savepoints should be easy
to support if we are supporting Named (spec) Savepoints. And t
Bruce,
> They have no way of reporting a failed query back to the user? How do
> people program in those environments? Right now any failed query aborts
> the transaction so it seems it would be pretty easy.
Believe it or not, PHP4 doesn't. This is one of the reasons why coders in
other lang
On Sat, 2004-07-10 at 15:17, Jan Wieck wrote:
> On 7/6/2004 3:58 PM, Simon Riggs wrote:
>
> > On Tue, 2004-07-06 at 08:38, Zeugswetter Andreas SB SD wrote:
> >> > - by time - but the time stamp on each xlog record only specifies to the
> >> > second, which could easily be 10 or more commits (we h
FYI: I'm agreeing w/Tom who is agreeing with me.
The tag change should be good. I do hope people are
not relying on seeing COMMIT when the transaction
rolled back. It does not seem that in this case
they would.
elein
On Sat, Jul 10, 2004 at 04:13:49PM -0400, Tom Lane wrote:
> Bruce Momjian <[E
elein wrote:
> FYI: I'm agreeing w/Tom who is agreeing with me.
>
> The tag change should be good. I do hope people are
> not relying on seeing COMMIT when the transaction
> rolled back. It does not seem that in this case
> they would.
If it is a problem, hopefully we will hear about it during
Josh Berkus wrote:
> Bruce,
>
> > Well, Oracle doesn't suppor RELEASE, so we are matching the standard but
> > perhaps not allowing easy migration from Oracle.
>
> Well, that's Oracle's problem. Considering the amount of influence they had
> over the standard, there's no excuse for their syntax
Bruce,
> Well, Oracle doesn't suppor RELEASE, so we are matching the standard but
> perhaps not allowing easy migration from Oracle.
Well, that's Oracle's problem. Considering the amount of influence they had
over the standard, there's no excuse for their syntax. Also, if someone
converts
I just posted a clarification. It isn't a problem.
---
Josh Berkus wrote:
> Dennis, Bruce,
>
> > Just to clarify, this is to allow rolling back to the same savepoint
> > multiple times. If we named savepoints, the new sav
On Sat, 10 Jul 2004, Bruce Momjian wrote:
> > > > SAVEPOINT == BEGIN NESTED
> > > > RELEASE SAVEPOINT == COMMIT NESTED
> > > > ROLLBACK TO SAVEPOINT == ROLLBACK NESTED
> > >
> > > Here it should be:
> > >
> > > ROLLBACK TO SAVEPOINT == ROLLBACK NESTED; SAVEPOINT;
> >
Bruce Momjian wrote:
> Dennis Bjorklund wrote:
> > On Sat, 10 Jul 2004, Josh Berkus wrote:
> >
> > > In other words:
> > > SAVEPOINT == BEGIN NESTED
> > > RELEASE SAVEPOINT == COMMIT NESTED
> > > ROLLBACK TO SAVEPOINT == ROLLBACK NESTED
> >
> > Here it should be:
> >
> > ROLLBACK TO SA
Dennis, Bruce,
> Just to clarify, this is to allow rolling back to the same savepoint
> multiple times. If we named savepoints, the new savepoint would be the
> same name as the one we just rolled back.
Hmmm ... yeah, it would be nice to find a way around this so that we don't
have non-standard
I am still going through my mailbox, trying to address all the open
patches so we can move toward beta. Of course, many of the patches I
kept need some adjustment to get applied (e.g. configuration file
location) so it is slow going.
However, we still have PITR unapplied, autovacuum unapplied, an
Dennis Bjorklund wrote:
> On Sat, 10 Jul 2004, Josh Berkus wrote:
>
> > In other words:
> > SAVEPOINT == BEGIN NESTED
> > RELEASE SAVEPOINT == COMMIT NESTED
> > ROLLBACK TO SAVEPOINT == ROLLBACK NESTED
>
> Here it should be:
>
> ROLLBACK TO SAVEPOINT == ROLLBACK NESTED; SAVEPOINT
Josh Berkus wrote:
> If you couldn't tell, I favor option 3) b)This syntax would look like:
>
> BEGIN TRANSACTION; --begin main
> do stuff;
> SAVEPOINT; -- begin "nested transaction 1"
> do more stuff;
> SAVEPOINT; -- begin "nested transaction 2" inside
Bruce Momjian <[EMAIL PROTECTED]> writes:
> As I remember, the big issue was how often applications are looking and
> comparing these tags to take actions. I think we should return ROLLBACK
> on COMMIT failure and we can see if we get any problem reports during
> beta.
Good enough; I'll make it h
On Sat, 10 Jul 2004, Josh Berkus wrote:
> In other words:
> SAVEPOINT == BEGIN NESTED
> RELEASE SAVEPOINT == COMMIT NESTED
> ROLLBACK TO SAVEPOINT == ROLLBACK NESTED
Here it should be:
ROLLBACK TO SAVEPOINT == ROLLBACK NESTED; SAVEPOINT;
And just to clearify, this is an ex
On 7/10/2004 3:21 PM, Simon Riggs wrote:
On Sat, 2004-07-10 at 15:04, Jan Wieck wrote:
> ...Nobody is shouting YES, so its a dodo...
No way!
Sorry...I meant "this idea is dead, just like the extinct Dodo bird".-
I've been trying to be succinct, but that has led to information loss.
I know, "preser
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> MOVE, FETCH, EXECUTE ...
>
> > Ah, yes, I remember we changed EXECUTE recently to return the tag of
> > what we executed. How do we modify MOVE/FETCH tags? I can't remember.
>
> I was just looking to see what c
On Sat, Jul 10, 2004 at 09:46:00PM +0200, Dennis Bjorklund wrote:
> One can have many different semantics, here are 3 versions:
>
> 1) You release savepoints in any order
> 2) You release savepoints in reverse order
> 3) You release any savepoints and later ones then the
> one you released
People,
Are we perhaps getting away from the issues here? The reason for this
discussion was to determine the user-level syntax for Alvaro's nested
transactions. We can discuss all we want about how he should have maybe
implemented some things differently, but we're supposed to start beta-t
On Sat, 10 Jul 2004, Alvaro Herrera wrote:
> That's why it's absurd. Why allow an operation which isn't really an
> operation?
Same reason why you allow an addition with 0. One can say that it's
not really an operation either.
One can have many different semantics, here are 3 versions:
1) Yo
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> MOVE, FETCH, EXECUTE ...
> Ah, yes, I remember we changed EXECUTE recently to return the tag of
> what we executed. How do we modify MOVE/FETCH tags? I can't remember.
I was just looking to see what cases ProcessUtility allowed to c
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Do we change tags in any other commands?
>
> MOVE, FETCH, EXECUTE ...
Ah, yes, I remember we changed EXECUTE recently to return the tag of
what we executed. How do we modify MOVE/FETCH tags? I can't remember.
--
Bruce Momjian
Bruce Momjian <[EMAIL PROTECTED]> writes:
>>> I am not excited about changing the command tag.
>>
>> I was not either to start with, but the more I think about it, the more
>> I think it would be a good idea.
> What tag would we use? ABORT?
No, ROLLBACK, which is what you get when you give the
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Do we change tags in any other commands?
MOVE, FETCH, EXECUTE ...
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Sat, Jul 10, 2004 at 12:40:21PM -0400, Tom Lane wrote:
>> Perhaps, rather than just probing a few selected years, we had better
>> check every year since 1970 ...
> What if we tell the user what the detected timezone is at some point,
> and tell them
Both patches withdrawn by author.
---
Nikola Milutinovic wrote:
> Hi guys.
>
> I have just had some problems resolved while building PostgreSQL 7.4.2
> on Tru64 UNIX 5.1B.
>
> File "./src/backend/utils/adt/float.c" uses "
On Sat, 2004-07-10 at 15:04, Jan Wieck wrote:
> On 7/5/2004 6:16 PM, Simon Riggs wrote:
>
> > On Mon, 2004-07-05 at 22:30, Tom Lane wrote:
> >> Simon Riggs <[EMAIL PROTECTED]> writes:
> >> > ...While recovering, it is very straightforward to simply ignore every
> >> > record associated with one (o
On Fri, Jul 09, 2004 at 08:03:36PM +0100, Simon Riggs wrote:
> On Fri, 2004-07-09 at 16:47, Alvaro Herrera wrote:
> > So this is another reason why we should use COMMIT to close a nested
> > transaction: it may refer to a transaction that is already closed
> > because the user got confused.
Sorry
On Sat, Jul 10, 2004 at 06:22:00PM +0200, Dennis Bjorklund wrote:
> On the other hand, it's not hard to implement the other behaviour either
> if that is what one wants (and we don't). It would only forget the name of
> the earlier savepoint. The corresponding transaction in itself have to
> stay.
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Christopher Kings-Lynne wrote:
>> It seems to me that we have mixed up two concepts: the tablespaces
>> that a database is IN and the default tablespaces for any schemas
>> created in that tablespace. This will probably cause trouble further
>> down
On Sat, Jul 10, 2004 at 12:40:21PM -0400, Tom Lane wrote:
> Perhaps, rather than just probing a few selected years, we had better
> check every year since 1970 ...
What if we tell the user what the detected timezone is at some point,
and tell them that it's only a heuristic? So if somebody gets
On Wednesday 07 July 2004 08:21, [EMAIL PROTECTED] wrote:
> Hi,
>
> while playing around with the tablespace stuff I noticed that on can't see
> the tablespace a table is in when querying the pg_tables view.
> I think the tablespace a table is in is a valuable information and should
> be shown ther
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >>> Do we want to add this to TODO:
> >>> * Issue an extra message when COMMIT completes a failed transaction
> >>
> >> No --- it's (a) wordy and (b) not responsive to
Ian Burrell <[EMAIL PROTECTED]> writes:
> We have user-defined aggregates written in C running inside the server.
> We are running into some memory management issues and wondering what
> is the best way to solve the problem.
> The state of the aggregates is a structure with a pointer to alloca
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Bruce Momjian <[EMAIL PROTECTED]> writes:
>>> Do we want to add this to TODO:
>>> * Issue an extra message when COMMIT completes a failed transaction
>>
>> No --- it's (a) wordy and (b) not responsive to the original complaint,
>> whi
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Attached is the startup log. I should point out that the Casey
> Antarctic base is in the Australian Antarctic Territory and it is in the
> same time zone as Perth, Western Australia for me:
Looking in the data files,
Zone Antarctica/Casey
On Sat, 10 Jul 2004, Tom Lane wrote:
> Nonsense. Invalidating an older savepoint must invalidate everything
> after it as well. The fact that the savepoint syntax allows you to
> express conceptually-ridiculous operations (like that one) is not a
> point in its favor IMHO.
Luckily the standard
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> On Fri, 9 Jul 2004, Mike Rylander wrote:
>> Nested transactions and savepoints serve two different purposes. They have
>> some overlap, but for the most part solve two distinct problems.
> Then show some examples that illustrait the difference. So fa
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
>>> You haven't shown us the patch, have you?
>
> this leads me to the first question I asked... do you want me to pull
> the latest cvs and patch it... or distribute my patch for 7.4.3?
Well, we will not be applying any such patch to 7.4.*, so if you
On Sat, 10 Jul 2004, Mike Rylander wrote:
> They do, if only to make particular constructs easier to write. This is an
> opinion, but for example an EXCEPTION framework for plpgsql would be easier
> to implement and use if it used the nested transactions rather than
> savepoint syntax:
>
> CREAT
On 7/10/2004 9:05 AM, Andrew Dunstan wrote:
If trusted, the function is located inside a perl Safe container, a
mechanism designed for just this purpose. Try doing something forbidden
inside a trusted function (like opening a file) and you will see the error.
As if I would know perl :-)
But yes,
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Do we want to add this to TODO:
> > * Issue an extra message when COMMIT completes a failed transaction
>
> No --- it's (a) wordy and (b) not responsive to the original complaint,
> which was that a client that examines command c
On 7/6/2004 3:58 PM, Simon Riggs wrote:
On Tue, 2004-07-06 at 08:38, Zeugswetter Andreas SB SD wrote:
> - by time - but the time stamp on each xlog record only specifies to the
> second, which could easily be 10 or more commits (we hope)
>
> Should we use a different datatype than time_t for
On 7/5/2004 6:16 PM, Simon Riggs wrote:
On Mon, 2004-07-05 at 22:30, Tom Lane wrote:
Simon Riggs <[EMAIL PROTECTED]> writes:
> ...While recovering, it is very straightforward to simply ignore every
> record associated with one (or more) transactions. That gives us the
> ability to recover "all apar
If trusted, the function is located inside a perl Safe container, a
mechanism designed for just this purpose. Try doing something forbidden
inside a trusted function (like opening a file) and you will see the error.
cheers
andrew
Jan Wieck wrote:
while playing with the OSCON CD's, I noticed that
while playing with the OSCON CD's, I noticed that the current version of
plperl installs the same function handler for both, plperl and plperlu.
I was wondering how it implements the important security difference or,
in case it is not handled and both are in fact the same, who ignored
this IMHO
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> this leads me to the first question I asked... do you want me to pull
> the latest cvs and patch it... or distribute my patch for 7.4.3?
Latest CVS, no question. It would be going into 7.6 (or whatever) T
the earliest...
-Doug
---
Alvaro Herrera wrote:
On Sat, Jul 10, 2004 at 09:46:56AM +1200, Oliver Jowett wrote:
Alvaro Herrera wrote:
We can't actually release anything (commit the subtransactions), because
they may be savepoints established after that point, and they are
logically "inside" the previously established ones.
Christopher Kings-Lynne wrote:
It seems to me that we have mixed up two concepts: the tablespaces
that a database is IN and the default tablespaces for any schemas
created in that tablespace. This will probably cause trouble further
down the track :(
As long as we interpret schema and databa
You tell us ... what's your real timezone, and what do you get from
pushing up the log level to DEBUG4 during postmaster start?
OK, I have log level set to debug4 and australian_timezones set to true.
The system time zone is set to WST.
Attached is the startup log. I should point out that the
The latter is relatively trivial as long as you interpret it as just
changing the default TS for tables created later in that schema.
(On the other hand, you can fake that with a simple UPDATE to
pg_namespace, so I'm not sure it qualifies as a "must have".)
The former is a real mess since it would
Bruce Momjian wrote:
Interesting Oracle doesn't support RELEASE or savepoint levels:
T271, SavepointsOracle supports this feature, except:
* Oracle does not support RELEASE SAVEPOINT.
Yes, and IMHO it's just some housekeeping stuff, informing the backend
that you'll never want to rol
Simon Riggs wrote:
BEGIN
display one screen to user - book the flight
INSERT INTO ...
INSERT INTO ...
UPDATE ...
SAVEPOINT
display another related screen - book the hotel
INSERT INTO
DELETE
UPDAT
On Sat, 10 Jul 2004, Gavin Sherry wrote:
> "3) The savepoint identified by S and all savepoints established in the
> current savepoint level subsequent to the establishment of S are
> destroyed."
So the standard savepoints are even more like the subtransactions that
alvaro have implemented then I
81 matches
Mail list logo
