Re: Heap truncation without AccessExclusiveLock (9.4)
От | Robert Haas |
---|---|
Тема | Re: Heap truncation without AccessExclusiveLock (9.4) |
Дата | |
Msg-id | CA+TgmoaVgZxr3T1HdHQPqVuzbqfVV4H4ZpacnC6Fixo12HLeGg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Heap truncation without AccessExclusiveLock (9.4) (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Список | pgsql-hackers |
On Mon, May 20, 2013 at 10:19 AM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote: >> It shouldn't be difficult to restrict the set of backends that have to >> be signaled to those that have the relation open. You could have a >> special kind of catchup signal that means "catch yourself up, but >> don't chain" > > What does "chain" mean above? Normally, when sinval catchup is needed, we signal the backend that is furthest behind. After catching up, it signals the backend that is next-furthest behind, which in turns catches up and signals the next laggard, and so forth. > Hmm. The sinval message makes sure that when a backend locks a relation, it > will see the latest value, because of the AcceptInvalidationMessages call in > LockRelation. If there is no sinval message, you'd need to always check the > shared memory area when you lock a relation. The latest value of what? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: