Lincoln Yeoh writes:
> At 06:04 PM 11/16/2005 +0100, Martijn van Oosterhout wrote:
>
> >On Thu, Nov 17, 2005 at 12:29:25AM +0800, Lincoln Yeoh wrote:
> > > My assumption is that pending transactions (e.g. locks and other metainfo)
> > > will take much less memory than database backends.
> >
> >T
At 06:04 PM 11/16/2005 +0100, Martijn van Oosterhout wrote:
On Thu, Nov 17, 2005 at 12:29:25AM +0800, Lincoln Yeoh wrote:
> My assumption is that pending transactions (e.g. locks and other metainfo)
> will take much less memory than database backends.
They make take less memory but they take ma
[EMAIL PROTECTED] wrote:
> I take it as a given that if suspended transactions were ever to
> appear people would expect a system table that let them list
> suspended transactions and how when they were suspended. Otherwise
> they just wouldn't be very manageable.
Regarding web applications,
"Guy Rouillier" <[EMAIL PROTECTED]> writes:
> Having worked with web-based, transaction-oriented applications for
> almost 10 years now, I don't see any justification for holding an actual
> database transaction open between HTTP requests. As Tom correctly
> points out, there is no guarantee wha
Greg Stark wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
>> Greg Stark <[EMAIL PROTECTED]> writes:
>>> Tom Lane <[EMAIL PROTECTED]> writes:
What this would actually be useful for is a fair question though
--- what's it do that you don't have now?
>>
>>> I think what they want to do is
Martijn van Oosterhout writes:
> They make take less memory but they take many more resources. Backend
> don't take locks by themselves, transactions do.
And backends have transactions implicitly. The point here is that if you're
going to suspend transactions by leaving idle backends around that
Tom Lane <[EMAIL PROTECTED]> writes:
> > This could be useful if you want to have X pending database transactions
> > and Y max concurrent database connections, where X is significantly greater
> > than Y (magnitudes higher?).
>
> I don't think the prepared-xacts facility has the performance t
On Thu, Nov 17, 2005 at 12:29:25AM +0800, Lincoln Yeoh wrote:
> MVCC-style transactions that are not limited by/to database connections.
>
> This could be useful if you want to have X pending database transactions
> and Y max concurrent database connections, where X is significantly greater
> th
Lincoln Yeoh writes:
> At 11:27 PM 11/15/2005 -0500, Tom Lane wrote:
>> That said, it seems to me that the prepared-xacts infrastructure could
>> possibly support a separate "suspend transaction" and "resume
>> transaction" facility, if anyone wants to do the legwork to make it
>> happen. What th
At 11:27 PM 11/15/2005 -0500, Tom Lane wrote:
That said, it seems to me that the prepared-xacts infrastructure could
possibly support a separate "suspend transaction" and "resume
transaction" facility, if anyone wants to do the legwork to make it
happen. What this would actually be useful for i
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > Tom Lane <[EMAIL PROTECTED]> writes:
> >> What this would actually be useful for is a fair question
> >> though --- what's it do that you don't have now?
>
> > I think what they want to do is make the database conce
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> What this would actually be useful for is a fair question
>> though --- what's it do that you don't have now?
> I think what they want to do is make the database concept of transactions
> match up 1-1 with their appli
Tom Lane <[EMAIL PROTECTED]> writes:
> Lincoln Yeoh writes:
> > Can we have a reconnect and "reopen prepared/saved transactions" feature?
> > Please? :)
>
> What this would actually be useful for is a fair question
> though --- what's it do that you don't have now?
I think what they want to do
Lincoln Yeoh writes:
> Can we have a reconnect and "reopen prepared/saved transactions" feature?
> Please? :)
No. A prepared transaction has already run its end-of-transaction
operations, eg at-commit triggers. Reopening it would be a fundamental
semantics violation.
That said, it seems to me
On Tue, 15 Nov 2005, Lincoln Yeoh wrote:
Can we have a reconnect and "reopen prepared/saved transactions" feature?
Please? :)
Note that this (transaction suspend/resume) is also required for a full
implementation of XA. Our current 2PC only supports the basics. There's
a bunch of other
Hi,
Can we have a reconnect and "reopen prepared/saved transactions" feature?
Please? :)
I'm sure there'll be uses for it. e.g. the stuff I mentioned.
Maybe we can also use it to help migrate queries to a different node.
At 11:54 AM 11/12/2005 +0800, Lincoln Yeoh wrote:
At 02:22 PM 11/11/20
At 02:22 PM 11/11/2005 +0100, Martijn van Oosterhout wrote:
But once you've prepared a transaction, you can't reopen it, all you
can do is either commit it or abort it. I don't see how prepared
transaction relate to webapps at all.
See also the docs:
http://www.postgresql.org/docs/8.1/static/sq
Martijn van Oosterhout writes:
> On Fri, Nov 11, 2005 at 05:45:28PM +0800, Lincoln Yeoh wrote:
>> Assuming the transactions don't explicitly do any locks ...
> Every transaction takes locks, on every table it accesses. Shared lock,
> but locks anyway. UPDATEs take stronger locks, so any UPDATE ma
On Fri, Nov 11, 2005 at 02:22:05PM +0100, Martijn van Oosterhout wrote:
> Every transaction takes locks, on every table it accesses. Shared lock,
> but locks anyway. UPDATEs take stronger locks, so any UPDATE may cause
> other queries to wait until you COMMIT or ABORT.
Note also, you don't want to
On Fri, Nov 11, 2005 at 05:45:28PM +0800, Lincoln Yeoh wrote:
> At 04:11 PM 11/10/2005 -0500, Tom Lane wrote:
> >A prepared transaction eats just about the same resources (other than an
> >active connection) as a live one. In particular it still holds its
> >locks, which makes leaving it around fo
At 04:11 PM 11/10/2005 -0500, Tom Lane wrote:
Lincoln Yeoh writes:
> Is it OK to use PREPARE TRANSACTION and COMMIT PREPARED in order to have
> transactions that last longer than just a single web request?
> Previously it was usually a bad idea to keep database connections alive
> just to keep
Lincoln Yeoh writes:
> Is it OK to use PREPARE TRANSACTION and COMMIT PREPARED in order to have
> transactions that last longer than just a single web request?
> Previously it was usually a bad idea to keep database connections alive
> just to keep a transaction pending.
A prepared transaction
Hi,
Is it OK to use PREPARE TRANSACTION and COMMIT PREPARED in order to have
transactions that last longer than just a single web request?
Previously it was usually a bad idea to keep database connections alive
just to keep a transaction pending.
Now I'm thinking that we could keep transact
23 matches
Mail list logo
