Hannu Krosing <ha...@2ndquadrant.com> writes:
> On Thu, 2009-09-17 at 12:18 -0400, Tom Lane wrote:
>> Or for an update without having to hold a transaction open. We have
>> recommended this type of technique in the past:
> If you need real locking, then just define a locked (or locked_by or
> locked_until) column and use that for concurrent edit control
That's pessimistic locking, and it sucks for any number of reasons,
most obviously if your client crashes or otherwise forgets to release
the lock. The method I was illustrating is specifically meant for
apps that would prefer optimistic locking.
>> Exactly. The application is typically going to throw a "concurrent
>> update" type of error when this happens, and we don't want magic
>> background operations to cause that.
> Would'nt current VACUUM FULL or CLUSTER cause much more grief in this
> situation ?
Sure, but neither of those are recommended for routine maintenance
during live database operations. (What you might do during maintenance
windows is a different discussion.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
