On Fri, Jan 7, 2011 at 6:28 PM, Florian Pflug <f...@phlo.org> wrote:
> I forgot about sequences earlier. If we dump while someone deletes all
> rows and resets the sequence the dump might contain rows and still
> reset the sequence. This could cause duplicate key errors on restore.
> I haven't checked if this is really possible though - I guess it would
> depend on the exact order of these events...
To fix this, you'd need a lock that allowed getting values from the
sequence but prevented resetting it, and...
> I wonder how such locks would work. Would such locks prevent accessing
> these objects? Or just modifications? For example, if I locked a function,
> could someone else execute it while I held the lock?
...in fact we do very little locking of objects other than tables.
DROP takes an AccessExclusiveLock on whatever it's dropping, and
COMMENT and SECURITY LABEL take ShareUpdateExclusiveLocks to avoid
orphaning pg_{sh,}description or pg_seclabel entries in the face of a
concurrent drop, but most operations on non-table objects don't AFAIK
take any lock at all. We probably don't want to make too many changes
in this area, because there are already workloads where the
heavyweight lock manager can become a bottleneck, and one can easily
imagine that locking operators or namespaces could make that problem
much worse.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
