On Sat, 12 Jun 2004, Alvaro Herrera wrote:
> On Sat, Jun 12, 2004 at 10:27:15AM -0700, Stephan Szabo wrote:
>
> > As a question, what was the general assumption about what the following
> > should do (using a modification of the original test case)?
>
> [...]
>
> > Should the statement at (1) fai
On Thu, 10 Jun 2004, Alvaro Herrera wrote:
> On Wed, Jun 09, 2004 at 11:32:08PM -0700, Stephan Szabo wrote:
>
> > > Unfortunately, I've gotten it to fail, but I haven't looked in depth (I'm
> > > at work, so I'm doing it during compilations and such.)
>
> [...]
>
> > Okay - I think I see what's g
"Bort, Paul" <[EMAIL PROTECTED]> writes:
> Would it make more sense to specify at the time the optional subtransaction
> is committed that it is not critical to the completion of the outer
> transaction?
>
> BEGIN;
> BEGIN;
> DROP TABLE foo;
> COMMIT NON_CRITICAL;
> CREATE TABLE foo (i
On Wed, Jun 09, 2004 at 11:32:08PM -0700, Stephan Szabo wrote:
> > Unfortunately, I've gotten it to fail, but I haven't looked in depth (I'm
> > at work, so I'm doing it during compilations and such.)
[...]
> Okay - I think I see what's going on here.
>
> It looks like deferredTriggerInvokeEven
On Thu, Jun 10, 2004 at 03:39:14PM -0400, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > We are considering allowing COMMIT IGNORE ABORT for scripts that want to
> > do a subtransaction, but don't care if it fails, and because it is a
> > script, they can't test the return value to
Tom Lane wisely wrote:
> While we clearly want this functionality, I tend to agree with Barry
> that COMMIT IGNORE ABORT (and the other variants that have
> been floated)
> is a horrid, confusing name for it. I would suggest using
> END with some
> modifier, instead. Perhaps
>
> END [ WO
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Thu, Jun 10, 2004 at 03:39:14PM -0400, Tom Lane wrote:
>> END doesn't so directly imply that you are trying to commit a failed
>> transaction.
> The problem with END is how about executing it inside a PL/pgSQL
> function. Can we distinguish it from
Bruce Momjian <[EMAIL PROTECTED]> writes:
> We are considering allowing COMMIT IGNORE ABORT for scripts that want to
> do a subtransaction, but don't care if it fails, and because it is a
> script, they can't test the return value to send ROLLBACK:
While we clearly want this functionality, I tend
Well, the default behavior of COMMIT for an aborted subtransaction is
that it will abort the upper transaction too, so I think this is the
behavior you want.
We are considering allowing COMMIT IGNORE ABORT for scripts that want to
do a subtransaction, but don't care if it fails, and because it is
Am I the only one who has a hard time understanding why COMMIT in the
case of an error is allowed? Since nothing is actually committed, but
instead everything was actually rolled back. Isn't it misleading to
allow a commit under these circumstances?
Then to further extend the commit syntax wi
On Wed, 9 Jun 2004, Stephan Szabo wrote:
> On Wed, 9 Jun 2004, Alvaro Herrera wrote:
>
> > On Sun, May 30, 2004 at 04:07:27AM -0700, Stephan Szabo wrote:
> > > On Sat, 29 May 2004, Alvaro Herrera wrote:
> >
> > > > Ah, this seems to work. I'll implement it and I'll let you know how it
> > > > go
On Wed, 9 Jun 2004, Alvaro Herrera wrote:
> On Sun, May 30, 2004 at 04:07:27AM -0700, Stephan Szabo wrote:
> > On Sat, 29 May 2004, Alvaro Herrera wrote:
>
> > > Ah, this seems to work. I'll implement it and I'll let you know how it
> > > goes.
> >
> > Ugh... There's one further wrinkle I hadn't
Alvaro Herrera wrote:
> > One interesting idea would be for COMMIT to affect the outer
> > transaction, and END not affect the outer transaction. Of course that
> > kills the logic that COMMIT and END are the same, but it is an
> > interesting idea, and doesn't affect backward compatibility becaus
On Fri, May 28, 2004 at 04:05:40PM -0400, Bruce Momjian wrote:
Bruce,
> One interesting idea would be for COMMIT to affect the outer
> transaction, and END not affect the outer transaction. Of course that
> kills the logic that COMMIT and END are the same, but it is an
> interesting idea, and do
On Sun, May 30, 2004 at 04:07:27AM -0700, Stephan Szabo wrote:
> On Sat, 29 May 2004, Alvaro Herrera wrote:
> > Ah, this seems to work. I'll implement it and I'll let you know how it
> > goes.
>
> Ugh... There's one further wrinkle I hadn't thought about, imagine the
> following:
Ok Stephan, th
ra <[EMAIL PROTECTED]>
|
| cc: Tatsuo Ishii <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
|
| Subject: Re: [HACKERS] Nested xacts
On 5/28/2004 2:52 PM, Alvaro Herrera wrote:
On Fri, May 28, 2004 at 01:43:16PM -0400, Bruce Momjian wrote:
In this case, I want to try all of the inserts, but any of them can
fail, then I want the bottom part done.
I wonder where everyone eas when I asked this question a lot of time
ago. I said I
On Sat, 29 May 2004, Alvaro Herrera wrote:
> On Sat, May 29, 2004 at 08:25:27AM -0700, Stephan Szabo wrote:
>
> > BTW: For the deferred trigger stuff, I am guessing you haven't touched
> > that at all in the current patch?
> >
> > I wonder if the following would work assuming that we want deferred
On Fri, 28 May 2004, Alvaro Herrera wrote:
> On Fri, May 28, 2004 at 05:43:41PM -0700, Stephan Szabo wrote:
>
> > On Wed, 26 May 2004, Alvaro Herrera wrote:
> >
> > > I have tested it and it passes all regression tests (including ones I
> > > added), plus some more tests I threw at it mainly for c
On Sat, 29 May 2004, Alvaro Herrera wrote:
> On Sat, May 29, 2004 at 08:25:27AM -0700, Stephan Szabo wrote:
>
> > Also related, although START TRANSACTION (specifying isolation level or
> > read onlyness as part) is currently defined to act as if set transaction
> > was used, it seems really odd
On Sat, May 29, 2004 at 08:25:27AM -0700, Stephan Szabo wrote:
> Also related, although START TRANSACTION (specifying isolation level or
> read onlyness as part) is currently defined to act as if set transaction
> was used, it seems really odd that the settings would leak to the outer
> translatio
Alvaro Herrera wrote:
> On Fri, May 28, 2004 at 11:11:27PM -0400, Bruce Momjian wrote:
> > Alvaro Herrera wrote:
>
> > > I think this applies to all GUC variables, but I wonder if we want to
> > > save the value of each one at subtransaction start and recover it at
> > > abort? Things could easil
On Fri, May 28, 2004 at 11:11:27PM -0400, Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > I think this applies to all GUC variables, but I wonder if we want to
> > save the value of each one at subtransaction start and recover it at
> > abort? Things could easily get huge. Maybe only saving the
Alvaro Herrera wrote:
> On Fri, May 28, 2004 at 05:43:41PM -0700, Stephan Szabo wrote:
>
> > On Wed, 26 May 2004, Alvaro Herrera wrote:
> >
> > > I have tested it and it passes all regression tests (including ones I
> > > added), plus some more tests I threw at it mainly for concurrency.
> > > Ev
On Fri, May 28, 2004 at 05:43:41PM -0700, Stephan Szabo wrote:
> On Wed, 26 May 2004, Alvaro Herrera wrote:
>
> > I have tested it and it passes all regression tests (including ones I
> > added), plus some more tests I threw at it mainly for concurrency.
> > Everything behaves as expected. At th
On Wed, 26 May 2004, Alvaro Herrera wrote:
> I have tested it and it passes all regression tests (including ones I
> added), plus some more tests I threw at it mainly for concurrency.
> Everything behaves as expected. At this time I'd like to have it
> reviewed by the critic eye of the committer
Alvaro Herrera wrote:
> On Fri, May 28, 2004 at 01:43:16PM -0400, Bruce Momjian wrote:
>
> > In this case, I want to try all of the inserts, but any of them can
> > fail, then I want the bottom part done.
>
> I wonder where everyone eas when I asked this question a lot of time
> ago. I said I th
Alvaro Herrera wrote:
> On Fri, May 28, 2004 at 04:51:07PM +0900, Tatsuo Ishii wrote:
>
> > 2) certain behavior was different from what I expected (please correct me
> >if my expectation is wrong).
>
> Yes, the expected behavior is different: if an aborted subtransaction is
> closed with a C
On Fri, May 28, 2004 at 01:43:16PM -0400, Bruce Momjian wrote:
> In this case, I want to try all of the inserts, but any of them can
> fail, then I want the bottom part done.
I wonder where everyone eas when I asked this question a lot of time
ago. I said I thought the behavior should be like I
On Fri, May 28, 2004 at 04:05:40PM -0400, Bruce Momjian wrote:
Hm, you are right that there needs to be a more automatic way of doing
this.
> One interesting idea would be for COMMIT to affect the outer
> transaction, and END not affect the outer transaction. Of course that
> kills the logic tha
On Sat, May 29, 2004 at 12:27:39AM +0900, Tatsuo Ishii wrote:
> Can I ask you one more question?
>
> Is there any limit for nesting leveles of subtransactions?
In theory 2^16 I think, but I haven't tested it. It tried to 30 or so
only. Not sure if it's practical.
--
Alvaro Herrera ()
"Escucha
Can I ask you one more question?
Is there any limit for nesting leveles of subtransactions?
--
Tatsuo Ishii
> On Fri, May 28, 2004 at 04:51:07PM +0900, Tatsuo Ishii wrote:
>
> > 2) certain behavior was different from what I expected (please correct me
> >if my expectation is wrong).
>
> Ye
> On Fri, May 28, 2004 at 04:51:07PM +0900, Tatsuo Ishii wrote:
>
> > 2) certain behavior was different from what I expected (please correct me
> >if my expectation is wrong).
>
> Yes, the expected behavior is different: if an aborted subtransaction is
> closed with a COMMIT or END command,
On Fri, May 28, 2004 at 04:51:07PM +0900, Tatsuo Ishii wrote:
> 2) certain behavior was different from what I expected (please correct me
>if my expectation is wrong).
Yes, the expected behavior is different: if an aborted subtransaction is
closed with a COMMIT or END command, the parent tra
IL PROTECTED]>
|
| cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
|
| Subject: Re: [HACKERS] Nested xacts: looking for tes
EMAIL PROTECTED]
|
| Subject: Re: [HACKERS] Nested xacts: looking for tes
I have tested the patches with May 28 16:20 JST snapshot. Here is my
first impression:
1) errors, rules regression tests are failed (I'm not sure this is due
to your patches)
2) certain behavior was different from what I expected (please correct me
if my expectation is wrong).
test=# begi
On Thu, 27 May 2004, Alvaro Herrera wrote:
> On Wed, May 26, 2004 at 04:35:52PM -0700, Stephan Szabo wrote:
>
> > On Wed, 26 May 2004, Alvaro Herrera wrote:
> >
> > > I'm missing one item: deferred triggers. The problem with this is that
> > > the deftrig queue is not implemented using normal Lis
On Wed, May 26, 2004 at 04:35:52PM -0700, Stephan Szabo wrote:
> On Wed, 26 May 2004, Alvaro Herrera wrote:
>
> > I'm missing one item: deferred triggers. The problem with this is that
> > the deftrig queue is not implemented using normal Lists, so there's no
> > efficient way to reassign to the
On Wed, 26 May 2004, Alvaro Herrera wrote:
> I'm missing one item: deferred triggers. The problem with this is that
> the deftrig queue is not implemented using normal Lists, so there's no
> efficient way to reassign to the parent when the subtransaction commits.
> Also I'm not sure what should
40 matches
Mail list logo
