Re: this is in plain text (row level locks)

From: Rod Taylor <rbt(at)rbt(dot)ca>
To: sailesh(at)cs(dot)berkeley(dot)edu
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Jenny - <nat_lazy(at)hotmail(dot)com>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: this is in plain text (row level locks)
Date: 2003-07-24 10:14:16
Message-ID: 1059041654.24535.13.camel@jester
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 2003-07-24 at 02:45, Sailesh Krishnamurthy wrote:
> >>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>
> Tom> That doesn't work, unless you insist that the first backend
> Tom> can't exit its transaction until all the other ones are done.
> Tom> Which introduces its own possibilities for deadlock --- but
> Tom> even worse, how does the first backend *know* that the other
> Tom> ones are done? You're right back where you started: it has
> Tom> to be possible to tell which backends have share-locked a
> Tom> particular row.
>
> Is a count a solution ?

Almost. Problem with a count is the difficulty decrementing the count
after a crash. You would also need to store a log of some kind so you
know what to reset while starting up in error recovery mode which would
add a large amount of overhead.

It may be best to have a locking manager run as a separate process.
That way it could store locks in ram or spill over to disk. Now the
problem is communication overhead. It probably isn't any worse than
writing them to disk for long queries (actual disk activity resulting),
but short queries are probably going to notice.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2003-07-24 12:42:59 Re: suggestions to improve postgresql suitability for
Previous Message Lee Kindness 2003-07-24 08:22:19 libpq_r