On Tue, 2008-01-22 at 20:53 +0100, Pavel Stehule wrote:
Agreed. I think Pavel Stehule was doing some experiments with them, I
don't know if he got anywhere.
I did only first research. Any hack is possible - you can stack
current transaction, but real implementation needs similar work
On Tue, 2008-01-22 at 20:53 +0100, Pavel Stehule wrote:
And there is most important question about data visibility - is
autonomous transaction independent on main transaction (isolation)?
From looking at how Oracle does them, autonomous transactions are
completely independent of the transaction
On 23/01/2008, Simon Riggs [EMAIL PROTECTED] wrote:
On Tue, 2008-01-22 at 20:53 +0100, Pavel Stehule wrote:
Agreed. I think Pavel Stehule was doing some experiments with them, I
don't know if he got anywhere.
I did only first research. Any hack is possible - you can stack
Neil Conway [EMAIL PROTECTED] writes:
On Tue, 2008-01-22 at 20:53 +0100, Pavel Stehule wrote:
And there is most important question about data visibility - is
autonomous transaction independent on main transaction (isolation)?
From looking at how Oracle does them, autonomous transactions are
On Tue, Jan 22, 2008 at 11:52:08AM +, cinu wrote:
Even though these errors are existing, at the end the
latest version is getting downloaded and when I do a
regression testing it goes through. Can anyone give me
Regression tests have to test error handling too, so some errors might
On Jan 22, 2008 11:37 PM, Guillaume Smet [EMAIL PROTECTED] wrote:
I can't drop/recreate the database at will because the customer is
also testing it but I'll try to find a moment to do it tomorrow.
I didn't reproduce the problem this time. I'll check after each
drop/recreate to see if I got
Tom Lane wrote:
Well, if there is any such problem then it could be triggered by two
independent plain-ol-REVOKE commands, so I still don't see an argument
why shdepDropOwned is more at risk than anything else. I think we
should just downgrade the lock.
Both issues fixed, thanks.
--
Alvaro Herrera wrote:
Hmm, unless revoking privileges concurrently, for two different users on
the same object could cause a problem? I don't see us grabbing a lock
on the object itself -- does this matter?
I tried a simple test: a process in a loop calling GRANT and REVOKE on random
users
As you said, 'gettimeofday' is occupying 40% of the execution time. But
without explain analyze(with just executor stats), i am not getting the time
duration at all. Is there any other way, i can get the timings without this
overhead?
Thanks,
Gokul.
On Jan 18, 2008 1:23 AM, Decibel! [EMAIL
On Wed, Jan 23, 2008 at 10:02:14PM +0530, Gokulakannan Somasundaram wrote:
As you said, 'gettimeofday' is occupying 40% of the execution time. But
without explain analyze(with just executor stats), i am not getting the time
duration at all. Is there any other way, i can get the timings without
On Jan 23, 2008 5:48 PM, Martijn van Oosterhout [EMAIL PROTECTED] wrote:
On Wed, Jan 23, 2008 at 10:02:14PM +0530, Gokulakannan Somasundaram wrote:
As you said, 'gettimeofday' is occupying 40% of the execution time. But
without explain analyze(with just executor stats), i am not getting the
I think the hard part would be error handling. You have to be able to
catch
any errors and resume the outer transaction.
I think this is not right. Autonomous transactions are used as soon as you
catch a error in order to log them. It can be used even for auditing. But
resuming the outer
On Wed, 2008-01-23 at 00:26 -0800, Neil Conway wrote:
On Tue, 2008-01-22 at 20:53 +0100, Pavel Stehule wrote:
And there is most important question about data visibility - is
autonomous transaction independent on main transaction (isolation)?
From looking at how Oracle does them, autonomous
Gokulakannan Somasundaram escribió:
The Audit transaction, which is a autonomous transaction need not catch any
error and resume the outer transaction.
What if the logging fails, say because you forgot to create the audit
table?
--
Alvaro Herrera
On Wed, 2008-01-23 at 09:30 +, Gregory Stark wrote:
I think the hard part would be error handling. You have to be able to catch
any errors and resume the outer transaction.
I agree that you'd need to do this, but I don't follow why it would be
particularly difficult. You essentially have a
Simon Riggs [EMAIL PROTECTED] writes:
From looking at how Oracle does them, autonomous transactions are
completely independent of the transaction that originates them -- they
take a new database snapshot. This means that uncommitted changes in the
originating transaction are not visible to the
On Jan 24, 2008 2:46 AM, Alvaro Herrera [EMAIL PROTECTED] wrote:
Gokulakannan Somasundaram escribió:
The Audit transaction, which is a autonomous transaction need not catch
any
error and resume the outer transaction.
What if the logging fails, say because you forgot to create the audit
On Jan 23, 2008 10:06 PM, Gokulakannan Somasundaram [EMAIL PROTECTED] wrote:
On Jan 24, 2008 2:46 AM, Alvaro Herrera [EMAIL PROTECTED] wrote:
The Audit transaction, which is a autonomous transaction need not catch
any
error and resume the outer transaction.
What if the logging fails,
18 matches
Mail list logo
