Re: 'tuple concurrently updated' error for alter role ... set
От | Robert Haas |
---|---|
Тема | Re: 'tuple concurrently updated' error for alter role ... set |
Дата | |
Msg-id | BANLkTimXvwCcuywtConu8cDx6a_wV=c-JQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: 'tuple concurrently updated' error for alter role ... set (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: 'tuple concurrently updated' error for alter role ... set
|
Список | pgsql-hackers |
On Thu, May 12, 2011 at 6:59 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Thu, May 12, 2011 at 6:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> We're not likely to do that, first because it's randomly different from >>> the handling of every other system catalog update, > >> We have very robust locking of this type for table-related DDL >> operations and just about none for anything else. I don't consider >> the latter to be a feature. > > I didn't say it was ;-). What I *am* saying is that if we're going to > do anything about this sort of problem, there needs to be a > well-considered system-wide plan. Arbitrarily changing the locking > rules for individual operations is not going to make things better, > and taking exclusive locks on whole catalogs is definitely not going to > make things better. Yes; true. I'm inclined to say that this is a bug, but not one we're going to fix before 9.2. I think it might be about time to get serious about making an effort to sprinkle the code with a few more LockDatbaseObject() and LockSharedObject() calls. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: