From: | Tino Wildenhain <tino(at)wildenhain(dot)de> |
---|---|
To: | Hanan Bentaleb <Hanan(dot)Bentaleb(at)simplernetworks(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Management of Concurrent Clients |
Date: | 2006-02-26 19:30:32 |
Message-ID: | 440201D8.4090009@wildenhain.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hanan Bentaleb schrieb:
> Hi Tino,
>
> Thanks for your response! I did not provide more specific technical
> details because I just came in to the project. So, I will try to provide
> as much information as I can.
>
> Former versions of postgresql used in this project are postgresql
> (starting at 6). I will try to find out the exact revision number.
>
> It has been reported to me that the main problem encountered with former
> postgresql versions is that when a process performs an update (of a
> record in any table), the whole database was locked which prevents the
> other processes from accessing the database (to retrieve data for
> instance). In other words, the process performing the update operation
> had an exclusive access to the database. This had an important impact on
> the system performance and justified the fact that tables were spread
> into different databases.
>
> Usually, granularity on locks is at the row or table level but maybe
> there was a specific configuration that was used which made it so that
> the entire database was locked. Before starting any major database
> re-structuring, I want to make sure that are not specific cases where
> this situation occurs.
I wonder how they managed to lock the whole database. You can try
and lock a table but usually its virtually unlocked (thanks to
MVCC). And even 6.x had MVCC. You schould give us an example
what they do. Otherwise it sounds like a myth :)
Regards
Tino
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Browne | 2006-02-26 19:31:45 | Re: Postgre capability |
Previous Message | Hanan Bentaleb | 2006-02-26 19:20:41 | Re: Management of Concurrent Clients |