Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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

pgsql-general by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group