On Sun, Jan 31, 2010 at 7:25 AM, Craig Ringer <craig@xxxxxxxxxxxxxxxxxxxxx> wrote: >> However, here lies the problem: I need to use SERIALIZABLE transaction >> isolation level, and AFAIK it's not possible to make several database >> connections to share the same exact view of the database. > I've noticed some talk on -HACKERS of finding ways to make this possible. > It's needed for parallel pg_dump, among other things. Actually, I the program I'm writing behaves exactly like parallel pg_dump from PostgreSQL's point of view. I've found this discussion in -HACKERS: http://osdir.com/ml/pgsql-hackers/2009-11/msg00265.html It seems, it's exactly what I need to do. I might try to contribute a patch. Thanks for the pointer! > It's not clear if it'd work for non-read-only transactions; I didn't notice > that being discussed, and don't know enough about it to have an opinion of > my own. Still, it's worth looking into for the future. It should be possible to do this for read/write transactions as well. >> So, is there a way to somehow stop all mutating operations? > Take explicit locks on the resources of interest that are permissive enough > to be shared with other read transactions, but not to permit writes. I thought about it, but it's too deadlock-prone. I need to lock the whole database, and if I do this table-by-table then I'll almost certainly generate a deadlock. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
