Re: Management of Concurrent Clients

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tino Wildenhain <tino(at)wildenhain(dot)de>
Cc: Hanan Bentaleb <Hanan(dot)Bentaleb(at)simplernetworks(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Management of Concurrent Clients
Date: 2006-02-26 20:23:22
Message-ID: 20725.1140985402@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Tino Wildenhain <tino(at)wildenhain(dot)de> writes:
> Hanan Bentaleb schrieb:
>> 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

> I wonder how they managed to lock the whole database.

I'd believe table-level locks; we used those in *really* old versions of
Postgres. (According to the release notes, MVCC was added in PG 6.5
released 1999-06-09.) I don't believe there ever was a facility that
would perform database-level locking at all.

Most PG hackers would call you certifiably insane if you were still
using a pre-MVCC version today. On data reliability grounds alone,
anything older than 7.2 is simply unsafe because of the XID wraparound
problem (let alone plain old bugs, of which there were many). If
you check the release history you will notice that 7.2.* was the first
release series that we continued to update after the initial release
of the next series. This is not coincidental: it reflects community
judgment that 7.2 was the first release series you'd really want to use
for long-term production purposes.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Neil Conway 2006-02-26 20:24:21 Re: Wish: remove ancient constructs from Postgres
Previous Message Wes 2006-02-26 20:14:56 Re: ECPG and COPY and PQputCopyData - don't get errors