I also want to implement the same feature but for
ecpg. On INFORMIX there is the following syntax to control
timeouts:
SET LOCK MODE TO [WAIT [seconds] | NO
WAIT]
There is 2 possibilities:
- either the pre-processor implements execution of
the statement with the asynchronous functions. T
Michael Loftis wrote:
>
> Hiroshi Inoue wrote:
>
> >Tom Lane wrote:
> >
> >>Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> >>
> >>>I don't think this is *all* *should be* or *all
> >>>or nothing* kind of thing. If a SET variable has
> >>>its reason, it would behave in its own right.
> >>>
> >>Well,
Hiroshi Inoue wrote:
>Tom Lane wrote:
>
>>Hiroshi Inoue <[EMAIL PROTECTED]> writes:
>>
>>>I don't think this is *all* *should be* or *all
>>>or nothing* kind of thing. If a SET variable has
>>>its reason, it would behave in its own right.
>>>
>>Well, we could provide some kind of escape hatch t
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > I don't think this is *all* *should be* or *all
> > or nothing* kind of thing. If a SET variable has
> > its reason, it would behave in its own right.
>
> Well, we could provide some kind of escape hatch to let the behavior
> vary
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> I don't think this is *all* *should be* or *all
> or nothing* kind of thing. If a SET variable has
> its reason, it would behave in its own right.
Well, we could provide some kind of escape hatch to let the behavior
vary from one variable to the next.
Tom Lane wrote:
>
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I have updated the TODO to:
> > o Abort all or commit all SET changes made in an aborted transaction
> > I don't think our current behavior is defended by anyone.
>
> Hiroshi seems to like it ...
Probably I don't love it. Hone
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I have updated the TODO to:
> > o Abort all or commit all SET changes made in an aborted transaction
> > I don't think our current behavior is defended by anyone.
>
> Hiroshi seems to like it ...
>
> However, "commit SETs ev
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I have updated the TODO to:
> o Abort all or commit all SET changes made in an aborted transaction
> I don't think our current behavior is defended by anyone.
Hiroshi seems to like it ...
However, "commit SETs even after an error" is most certa
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I have added this to the TODO list, with a question mark. Hope this is
> > OK with everyone.
>
> > o Abort SET changes made in aborted transactions (?)
>
> Actually, I was planning to make only search_path act that way, bec
Hiroshi Inoue wrote:
> Michael Loftis wrote:
> >
> > Tom Lane wrote:
> >
> > >Bruce Momjian <[EMAIL PROTECTED]> writes:
> > >
> > >>I have added this to the TODO list, with a question mark. Hope this is
> > >>OK with everyone.
> > >>
> > >
> > >>o Abort SET changes made in aborted trans
Michael Loftis wrote:
>
> Tom Lane wrote:
>
> >Bruce Momjian <[EMAIL PROTECTED]> writes:
> >
> >>I have added this to the TODO list, with a question mark. Hope this is
> >>OK with everyone.
> >>
> >
> >>o Abort SET changes made in aborted transactions (?)
> >>
> >
> >Actually, I was plan
Tom Lane wrote:
>Bruce Momjian <[EMAIL PROTECTED]> writes:
>
>>I have added this to the TODO list, with a question mark. Hope this is
>>OK with everyone.
>>
>
>>o Abort SET changes made in aborted transactions (?)
>>
>
>Actually, I was planning to make only search_path act that way, be
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I have added this to the TODO list, with a question mark. Hope this is
> OK with everyone.
> o Abort SET changes made in aborted transactions (?)
Actually, I was planning to make only search_path act that way, because
of all the push-back I'd
I have added this to the TODO list, with a question mark. Hope this is
OK with everyone.
o Abort SET changes made in aborted transactions (?)
---
Tom Lane wrote:
> Thomas Lockhart <[EMAIL PROTECTED]> writes:
> > I
Thomas Lockhart writes:
> 1) All commands starting with "SET" must have the same transactional
> semantics. I'll agree that it might be nice for consistancy, but imho is
> not absolutely required.
This rule is already violated anyway. SET TRANSACTION ISOLATION, SET
CONSTRAINTS, SET SESSION AUTH
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> I do have a concern about how to implement some of the SET commands if
> we *do* respect transactional semantics. For example, SET TIME ZONE
> saves the current value of an environment variable (if available), and
> would need *at least* a "before tran
...
> Please note that even in those other databases, if one replaces the
> COMMIT with ROLLBACK in the above scenario, the effects of the INSERT
> *will* roll back. Transpose this into current Postgres, and replace
> INSERT with SET, and the effects do *not* roll back. How is that a
> good idea
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Actually, we could probably prevent transaction abort on syntax(yacc)
> errors, but the other errors like mistyped table names would be hard to
> prevent a rollback, so I guess we just roll back on any error.
I don't think that what we categorize as an
Bruce Momjian <[EMAIL PROTECTED]> writes:
> In the case of:
> BEGIN WORK;
> SET x=1;
> bad query that aborts transaction;
> SET x=2;
> COMMIT WORK;
> Only the first SET is done, so at the end, x = 1.
Perhaps even more to the point:
SET x=0;
BEGIN;
Bruce Momjian wrote:
>
> Hiroshi Inoue wrote:
> > > > ??? What do you mean by
> > > >o Some SETs are honored in an aborted transaction (current)
> > > > ?
> > > > Is the current state different from
> > > > o All SETs are honored in an aborted transaction
> > > > ?
> > >
> > > In the ca
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Take out a database other than PostgreSQL and do
>
> > BEGIN; -- or whatever they use; might be implicit
> > INSERT INTO existing_table ('legal value');
> > barf;
> > COMMIT;
>
> > The INSERT will most likely succeed. The reason
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Take out a database other than PostgreSQL and do
> BEGIN; -- or whatever they use; might be implicit
> INSERT INTO existing_table ('legal value');
> barf;
> COMMIT;
> The INSERT will most likely succeed. The reason is that "barf" does not
> modify
Hiroshi Inoue wrote:
> > > ??? What do you mean by
> > >o Some SETs are honored in an aborted transaction (current)
> > > ?
> > > Is the current state different from
> > > o All SETs are honored in an aborted transaction
> > > ?
> >
> > In the case of:
> >
> > BEGIN WORK;
> >
Hiroshi Inoue wrote:
> > > ??? What do you mean by
> > >o Some SETs are honored in an aborted transaction (current)
> > > ?
> > > Is the current state different from
> > > o All SETs are honored in an aborted transaction
> > > ?
> >
> > In the case of:
> >
> > BEGIN WORK;
> >
Bruce Momjian wrote:
>
> Hiroshi Inoue wrote:
> > Bruce Momjian wrote:
> > >
> > > Hiroshi Inoue wrote:
> > > > > > Oops does the first mean rolling back the variables on abort ?
> > > > > > If so I made a mistake. The current is better than the second.
> > > > >
> > > > > The second means all SET
Hiroshi Inoue wrote:
> Bruce Momjian wrote:
> >
> > Hiroshi Inoue wrote:
> > > > > Oops does the first mean rolling back the variables on abort ?
> > > > > If so I made a mistake. The current is better than the second.
> > > >
> > > > The second means all SET's are rolled back on abort.
> > >
> >
Bruce Momjian wrote:
>
> Hiroshi Inoue wrote:
> > > > Oops does the first mean rolling back the variables on abort ?
> > > > If so I made a mistake. The current is better than the second.
> > >
> > > The second means all SET's are rolled back on abort.
> >
> > I see.
> > BTW what varibles are roll
Hiroshi Inoue wrote:
> > > Oops does the first mean rolling back the variables on abort ?
> > > If so I made a mistake. The current is better than the second.
> >
> > The second means all SET's are rolled back on abort.
>
> I see.
> BTW what varibles are rolled back on abort currently ?
Current
Bruce Momjian wrote:
>
> Hiroshi Inoue wrote:
> > Hiroshi Inoue wrote:
> > >
> > > Bruce Momjian wrote:
> > > >
> > > > OK, we have three possibilities:
> > > >
> > > > o All SETs are honored in an aborted transaction
> > > > o No SETs are honored in an aborted transaction
> > >
Hiroshi Inoue wrote:
> Hiroshi Inoue wrote:
> >
> > Bruce Momjian wrote:
> > >
> > > OK, we have three possibilities:
> > >
> > > o All SETs are honored in an aborted transaction
> > > o No SETs are honored in an aborted transaction
> > > o Some SETs are honored in an a
Hiroshi Inoue wrote:
>
> Bruce Momjian wrote:
> >
> > OK, we have three possibilities:
> >
> > o All SETs are honored in an aborted transaction
> > o No SETs are honored in an aborted transaction
> > o Some SETs are honored in an aborted transaction (current)
> >
> > I t
Tom Lane wrote:
>
> Karel Zak <[EMAIL PROTECTED]> writes:
> > It's good point. Why not make it more transparent? You want
> > encapsulate it to standard and current SET statement, but if it's
> > something different why not use for it different statement?
>
> > SET SESSION search_path TO '
Bruce Momjian wrote:
>
> OK, we have three possibilities:
>
> o All SETs are honored in an aborted transaction
> o No SETs are honored in an aborted transaction
> o Some SETs are honored in an aborted transaction (current)
>
> I think the problem is our current behavio
Peter Eisentraut wrote:
> Michael Loftis writes:
>
> > I was under the impression that for a transaction either all commands
> > succeed or all commands fail, atleast according to everything I've ever
> > read.
>
> That's an urban legend.
>
> A transaction guarantees (among other things) that a
Michael Loftis writes:
> I was under the impression that for a transaction either all commands
> succeed or all commands fail, atleast according to everything I've ever
> read.
That's an urban legend.
A transaction guarantees (among other things) that all modifications to
the database with the
Karel Zak <[EMAIL PROTECTED]> writes:
> It's good point. Why not make it more transparent? You want
> encapsulate it to standard and current SET statement, but if it's
> something different why not use for it different statement?
> SET SESSION search_path TO 'something';
But a plain SET i
Heh pardon me but...
I was under the impression that for a transaction either all commands
succeed or all commands fail, atleast according to everything I've ever
read. So followign that all SETs done within the scope of a
BEGIN/COMMIT pair should only take effect if the whole set finishes, i
On Mon, Apr 08, 2002 at 01:03:41PM -0400, Tom Lane wrote:
> The search_path case is the main reason why I'm intent on changing
> the behavior of SET; without that, I'd just leave well enough alone.
Is there more variables like "search_path"? If not, I unsure if one
item is good consideration f
On Mon, Apr 08, 2002 at 12:28:18PM -0400, Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > OK, probably good time for summarization. First, consider this:
> >
> > BEGIN WORK;
> > SET something;
> > query fails;
> > SET something else;
> > COMMIT WORK;
> >
> > Under curre
Hiroshi Inoue wrote:
> > Yes, if you want multiple timeouts, you clearly could go in that
> > direction. Right now, we are considering only single-statement timing
> > and no one has asked for multiple timers.
>
> I don't ask multiple timers. ODBC driver would be able
> to handle multiple timeou
Bruce Momjian wrote:
>
> Hiroshi Inoue wrote:
> > Bruce Momjian wrote:
> > >
> > > Hiroshi Inoue wrote:
> > > > Bruce Momjian wrote:
> >
> > > > > > > They want the timeout for only the one statement, so they have to set it
> > > > > > > to non-zero before the statement, and to zero after the stat
Hiroshi Inoue wrote:
> Bruce Momjian wrote:
> >
> > Hiroshi Inoue wrote:
> > > Bruce Momjian wrote:
>
> > > > > > They want the timeout for only the one statement, so they have to set it
> > > > > > to non-zero before the statement, and to zero after the statement.
> > > > >
> > > > > Does setQu
Bruce Momjian wrote:
>
> Hiroshi Inoue wrote:
> > Bruce Momjian wrote:
> > > > > They want the timeout for only the one statement, so they have to set it
> > > > > to non-zero before the statement, and to zero after the statement.
> > > >
> > > > Does setQueryTimeout() issue a corresponding SET Q
Hiroshi Inoue wrote:
> Bruce Momjian wrote:
> >
> > Hiroshi Inoue wrote:
> > > > > Why should the SET query_timeout = 0 command be issued
> > > > > only when the query failed ? Is it a JDBC driver's requirement
> > > > > or some applications' requirements which uses the JDBC driver ?
> > > >
> >
Bruce Momjian wrote:
>
> Hiroshi Inoue wrote:
> > > > Why should the SET query_timeout = 0 command be issued
> > > > only when the query failed ? Is it a JDBC driver's requirement
> > > > or some applications' requirements which uses the JDBC driver ?
> > >
> > > They want the timeout for only the
Hiroshi Inoue wrote:
> > > Why should the SET query_timeout = 0 command be issued
> > > only when the query failed ? Is it a JDBC driver's requirement
> > > or some applications' requirements which uses the JDBC driver ?
> >
> > They want the timeout for only the one statement, so they have to se
Bruce Momjian wrote:
>
> Hiroshi Inoue wrote:
> > > -Original Message-
> > > From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> > > >
> > > > OK using your example, one by one
> > > >
> > > > BEGIN WORK;
> > > > SET query_timeout=20;
> > > > query fails;
> > > > SET query_tim
Hiroshi Inoue wrote:
> > -Original Message-
> > From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> > >
> > > OK using your example, one by one
> > >
> > > BEGIN WORK;
> > > SET query_timeout=20;
> > > query fails;
> > > SET query_timeout=0;
> > >
> > > For what the SET was
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> >
> > OK using your example, one by one
> >
> > BEGIN WORK;
> > SET query_timeout=20;
> > query fails;
> > SET query_timeout=0;
> >
> > For what the SET was issued ?
> > What command is issued if the
Hiroshi Inoue wrote:
> > -Original Message-
> > From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> >
> > Hiroshi Inoue wrote:
> > > > I am confused. Above you state you want SET QUERY_TIMEOUT to be
> > > > per-query. I assume you mean that the timeout applies for
> > only the next
> > > >
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
>
> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> > Sorry for my poor explanation. What I meant is that *Rollback*
> > is to
>> cancel the changes made to SQL-data or schemas
This line is a quote from SQL99 not my creation.
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
>
> Hiroshi Inoue wrote:
> > > I am confused. Above you state you want SET QUERY_TIMEOUT to be
> > > per-query. I assume you mean that the timeout applies for
> only the next
> > > query and is turned off after that.
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> But that is not a shortcoming of the SET command. The problem is that the
>> system does not accept any commands after one command has failed in a
>> transaction even though it could usefully do so.
In a situation where the reason for failure was a sy
Jan Wieck <[EMAIL PROTECTED]> writes:
> If namespace dropping allows for creation of objects that
> cannot be dropped afterwards any more, I would call that a
> bug or design flaw, which has to be fixed.
I will not require schema support to wait upon the existence of
dependency
"Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> Sorry for my poor explanation. What I meant is that *Rollback*
> is to cancel the changes made to SQL-data or schemas
> not to put back the variables which are local to the session.
Uh, why? Seems to me you are asserting as a given exactly the
point
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > OK, probably good time for summarization. First, consider this:
> >
> > BEGIN WORK;
> > SET something;
> > query fails;
> > SET something else;
> > COMMIT WORK;
> >
> > Under current behavior, the first SET is honored, whi
Bruce Momjian writes:
> OK, probably good time for summarization. First, consider this:
>
> BEGIN WORK;
> SET something;
> query fails;
> SET something else;
> COMMIT WORK;
>
> Under current behavior, the first SET is honored, while the second is
> ignored because t
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
>
> Hiroshi Inoue wrote:
> > > >
> > > > I feel we should just do it. Yeah, there might be some corner cases
> > > > where it's not the ideal behavior; but you haven't convinced me that
> > > > there are more cases wher
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > Is an invalid search path really that critical (read security
> > issue)?
>
> It's not a security issue (unless the OID counter wraps around soon
> enough to let someone else get assigned the same OID for a namespace).
> But it co
Hiroshi Inoue wrote:
> > > I vote against you. If a variable is local to the session, you
> > > can change it as you like without bothering any other user(session).
> > > Automatic resetting of the varibales is rather confusing to me.
> >
> > I don't see how this relates to other users. All SET c
Thomas Lockhart wrote:
> > > I consider SET variables metadata that are not affected by transactions.
> > Why? Again, the fact that historically they've not acted that way isn't
> > sufficient reason for me.
>
> Hmm. Historically, SET controls behaviors *out of band* with the normal
> transactio
> > I consider SET variables metadata that are not affected by transactions.
> Why? Again, the fact that historically they've not acted that way isn't
> sufficient reason for me.
Hmm. Historically, SET controls behaviors *out of band* with the normal
transaction mechanisms. There is strong prece
Jan Wieck wrote:
> > > Psql and libpq would simply issue the query according to the
> > > user's request as they currently do. What's pain with it ?
> >
> > If they wanted to place a timeout on all queries in a session, they
> > would need a SET for every query, which seems like a pain.
>
> E
Tom Lane wrote:
> This does not work as intended if the initial SET doesn't roll back
> upon transaction failure. Yeah, you can restructure it to
>
> SET enable_seqscan = false;
> BEGIN;
> some-queries-that-might-fail;
> END;
> SET enable_seqscan = true;
>
> but wh
Jan Wieck <[EMAIL PROTECTED]> writes:
> Is an invalid search path really that critical (read security
> issue)?
It's not a security issue (unless the OID counter wraps around soon
enough to let someone else get assigned the same OID for a namespace).
But it could be pretty annoying anyway
Tom Lane wrote:
> Karel Zak <[EMAIL PROTECTED]> writes:
> > Is there some problem implement "SET ... ON ROLLBACK UNSET" ?
>
> Yes. See my previous example concerning search_path: that variable
> MUST be rolled back at transaction abort, else we risk its value being
> invalid. We cannot offer th
Bruce Momjian wrote:
> > > > Sorry I couldn't understand your point.
> > > > It seems the simplest and the most certain way is to call
> > > > 'SET QUERY_TIMEOUT per query. The way dosen't require
> > > > RESET at all. Is the overhead an issue ?
> > >
> > > What about psql and libpq. Doing a tim
Karel Zak <[EMAIL PROTECTED]> writes:
> Is there some problem implement "SET ... ON ROLLBACK UNSET" ?
Yes. See my previous example concerning search_path: that variable
MUST be rolled back at transaction abort, else we risk its value being
invalid. We cannot offer the user a choice.
So far I
Karel Zak wrote:
> I agree with Peter. For example I have multi-encoding client program
> that changing client-encoding in the middle of transaction and this
> change not depend on transaction. And the other thing: I have DB
> driver in an program there is not possible do SQL query outsite
>
Hiroshi Inoue wrote:
> > I am confused. Above you state you want SET QUERY_TIMEOUT to be
> > per-query. I assume you mean that the timeout applies for only the next
> > query and is turned off after that.
>
> Hmm there seems a misunderstanding between you and I but I
> don't see what it is. Does
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
>
> Hiroshi Inoue wrote:
> > Bruce Momjian wrote:
> > >
> > > > > > Sorry I couldn't understand your point.
> > > > > > It seems the simplest and the most certain way is to call
> > > > > > 'SET QUERY_TIMEOUT per query
On Sun, Apr 07, 2002 at 01:01:07AM -0500, Peter Eisentraut wrote:
> Tom Lane writes:
>
> > I didn't say "transaction specific". I said that if you do a SET inside
> > a transaction block, and then the transaction is aborted, the effects of
> > the SET ought to roll back along with everything els
On Fri, Apr 05, 2002 at 02:13:26PM -0500, Tom Lane wrote:
> It seems clear to me that SET *should* roll back on abort. Just a
> matter of how important is it to fix.
I want control on this :-)
SET valname = 'vatdata' ON ROLLBACK UNSET;
or
SET valname = 'vatdata';
On Fri, Apr 05, 2002 at 08:32:47PM -0500, Bruce Momjian wrote:
> > Or, as I suggested above, extend the SELECT (and other querys?) syntax
> > seems reasonable. More so than the non-standard 'use this index, really'
> > types of extensions that other RDBMSs provide, that we've rightly avoided.
>
>
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
I guess it's a matter of definition: Do you consider SET variablesdatabase state or session metadata? I think some are this and some arethat. I'm not sure how to draw the line, but throwing
Hiroshi Inoue wrote:
> Bruce Momjian wrote:
> >
> > > > > Sorry I couldn't understand your point.
> > > > > It seems the simplest and the most certain way is to call
> > > > > 'SET QUERY_TIMEOUT per query. The way dosen't require
> > > > > RESET at all. Is the overhead an issue ?
> > > >
> > > >
Hiroshi Inoue wrote:
> Bruce Momjian wrote:
> >
> > > > I guess it's a matter of definition: Do you consider SET variables
> > > > database state or session metadata? I think some are this and some are
> > > > that. I'm not sure how to draw the line, but throwing everything from one
> > > > cat
Bruce Momjian wrote:
>
> > > > Sorry I couldn't understand your point.
> > > > It seems the simplest and the most certain way is to call
> > > > 'SET QUERY_TIMEOUT per query. The way dosen't require
> > > > RESET at all. Is the overhead an issue ?
> > >
> > > What about psql and libpq. Doing a t
Bruce Momjian wrote:
>
> > > I guess it's a matter of definition: Do you consider SET variables
> > > database state or session metadata? I think some are this and some are
> > > that. I'm not sure how to draw the line, but throwing everything from one
> > > category into the other isn't my favo
> > > Sorry I couldn't understand your point.
> > > It seems the simplest and the most certain way is to call
> > > 'SET QUERY_TIMEOUT per query. The way dosen't require
> > > RESET at all. Is the overhead an issue ?
> >
> > What about psql and libpq. Doing a timeout before every query is a
> >
Bruce Momjian wrote:
>
> > > > Probably I'm misunderstanding this thread.
> > > > Why must the query_timeout be reset particularly ?
> > > > What's wrong with simply issueing set query_timeout
> > > > command just before every query ?
> > >
> > > You could do that, but we also imagine cases where
> > I guess it's a matter of definition: Do you consider SET variables
> > database state or session metadata? I think some are this and some are
> > that. I'm not sure how to draw the line, but throwing everything from one
> > category into the other isn't my favorite solution.
>
> You seem to
> > > Probably I'm misunderstanding this thread.
> > > Why must the query_timeout be reset particularly ?
> > > What's wrong with simply issueing set query_timeout
> > > command just before every query ?
> >
> > You could do that, but we also imagine cases where people would want to
> > set a tim
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
>
> Hiroshi Inoue wrote:
> > > -Original Message-
> > > From: Tom Lane
> > >
> > > Jan Wieck <[EMAIL PROTECTED]> writes:
> > > > Could we get out of this by defining that "timeout" is
> > > > aut
> -Original Message-
> From: Peter Eisentraut [mailto:[EMAIL PROTECTED]]
>
>
> I guess it's a matter of definition: Do you consider SET variables
> database state or session metadata?
Session metadata IMHO. If there are(would be) database state
variables we should introduce another co
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I consider SET variables metadata that are not affected by transactions.
Why? Again, the fact that historically they've not acted that way isn't
sufficient reason for me.
> I should be able to change my mind about my session preferences in the
> mi
Tom Lane writes:
> I didn't say "transaction specific". I said that if you do a SET inside
> a transaction block, and then the transaction is aborted, the effects of
> the SET ought to roll back along with everything else you did inside
> that transaction block. I'm not seeing what the argument
Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> Can we all compromise on that?
> No.
Oh dear...
> I agree that there may be some variables that must be rolled back, or
> where automatic reset on transaction end may be desirable (note that these
> are two different things), but for some variable
Tom Lane writes:
> Note: I am now pretty well convinced that we *must* fix SET to roll back
> to start-of-transaction settings on transaction abort. If we do that,
> at least some of the difficulty disappears for JDBC to handle one-shot
> timeouts by issuing SETs before and after the target quer
Tom Lane wrote:
> Note: I am now pretty well convinced that we *must* fix SET to roll back
> to start-of-transaction settings on transaction abort. If we do that,
> at least some of the difficulty disappears for JDBC to handle one-shot
> timeouts by issuing SETs before and after the target query
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Ewe, I was hoping for something with zero overhead for the non-SET case.
>
> Well, a function call and immediate return if no SET has been executed
> in the current xact seems low enough overhead to me. We'll just keep
> a flag show
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Ewe, I was hoping for something with zero overhead for the non-SET case.
Well, a function call and immediate return if no SET has been executed
in the current xact seems low enough overhead to me. We'll just keep
a flag showing whether there's anything
Bruce Momjian <[EMAIL PROTECTED]> writes:
> We do have on_shmem_exit and on_proc_exit function call queues. Seems
> we will need SET to create a queue of function calls containing previous
> values of variables SEt in multi-statement transactions. If we execute
> the queue in last-in-first-out o
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > We do have on_shmem_exit and on_proc_exit function call queues. Seems
> > we will need SET to create a queue of function calls containing previous
> > values of variables SEt in multi-statement transactions. If we execute
> > the qu
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> One approach might be for the interface to take care of setting the query
> >> timeout before each query, and just ask the backend to handle timeouts
> >> per-query. So from the user's perspective, session-level timeouts would
> >> e
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> One approach might be for the interface to take care of setting the query
>> timeout before each query, and just ask the backend to handle timeouts
>> per-query. So from the user's perspective, session-level timeouts would
>> exist, but the backend woul
Jessica Perry Hekman wrote:
> On Sat, 6 Apr 2002, Bruce Momjian wrote:
>
> > > What's wrong with simply issueing set query_timeout
> > > command just before every query ?
> >
> > You could do that, but we also imagine cases where people would want to
> > set a timeout for each query in an entire
On Sat, 6 Apr 2002, Bruce Momjian wrote:
> > What's wrong with simply issueing set query_timeout
> > command just before every query ?
>
> You could do that, but we also imagine cases where people would want to
> set a timeout for each query in an entire session.
One approach might be for the i
Hiroshi Inoue wrote:
> > -Original Message-
> > From: Tom Lane
> >
> > Jan Wieck <[EMAIL PROTECTED]> writes:
> > > Could we get out of this by defining that "timeout" is
> > > automatically reset at next statement end?
> >
> > I was hoping to avoid that, because it seems l
> -Original Message-
> From: Tom Lane
>
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > Could we get out of this by defining that "timeout" is
> > automatically reset at next statement end?
>
> I was hoping to avoid that, because it seems like a wart. OTOH,
> it'd be less of a
1 - 100 of 158 matches
Mail list logo
