seems a new and good idea for me, is
the first time i heard about SELECT FOR UPDATE.
Another question !, can i combine SELECT FOR UPDATE and LOCK command on
different tables at the same transaction ?
Alan Acosta
On Tue, Mar 1, 2011 at 9:33 AM, Andrew Sullivan wrote:
> On Tue, Mar 01, 2011
to changes.
Meanwhile, i reduce my lock level and even the CPU load is now lower LOL, is
fantastic, thanks for your help, clients are now working better and faster
than before ^_^, i still have a lot of to read about postgres.
Alan Acosta
On Mon, Feb 28, 2011 at 8:13 PM, David Johnston wrote:
>
need to lock
in some way in order to check if seat number X was already sold or is free !
Alan Acosta
On Mon, Feb 28, 2011 at 5:21 PM, Andrew Sullivan wrote:
> On Mon, Feb 28, 2011 at 05:13:11PM -0500, Alan Acosta wrote:
> > I really appreciate your help Andrew, and yep, i already
I really appreciate your help Andrew, and yep, i already starto to feel some
pain lol. I suppose is true but is better to ask, SELECT FOR UPDATE is
faster than LOCK ?
Thanks for the recommendations, i will check them ^_^
Cheers,
Alan Acosta
On Mon, Feb 28, 2011 at 4:28 PM, Andrew Sullivan
E don't, or i'm reading
bad the table ? I need only one process insert or update my tables in my
transaction, no matter how many i have.
How can i know which mode is better to block in which case ?
Cheers,
Alan Acosta
On Mon, Feb 28, 2011 at 3:44 PM, Andrew Sullivan wrote:
> On Mon
cting lock modes*. Meanwhile i understand well which mode to use
in which case i reduce my lock level to EXCLUSIVE, which lock against itself
but let SELECT to do his job !
Cheers,
Alan Acosta
On Mon, Feb 28, 2011 at 1:10 PM, Andrew Sullivan wrote:
> On Mon, Feb 28, 2011 at 12:43:58PM -0500
ed in an open transaction
will be read it by another threads or this new rows are invisible no matter
the mode of the transaction.
Any help is very welcome ^_^
Cheers,
Alan Acosta
