Re: pgsql: Resolve timing issue with logging locks for Hot Standby.
От | Robert Haas |
---|---|
Тема | Re: pgsql: Resolve timing issue with logging locks for Hot Standby. |
Дата | |
Msg-id | CA+TgmobUxd2PRh3mMpQg4piCLiCeQ-GYkg-HntPCdBRVO43mng@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pgsql: Resolve timing issue with logging locks for Hot Standby. (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: pgsql: Resolve timing issue with logging locks for Hot Standby.
|
Список | pgsql-committers |
On Mon, Jan 30, 2012 at 4:13 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > On Mon, Jan 30, 2012 at 12:30 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Simon Riggs <simon@2ndQuadrant.com> writes: >>> Resolve timing issue with logging locks for Hot Standby. >>> We log AccessExclusiveLocks for replay onto standby nodes, >>> but because of timing issues on ProcArray it is possible to >>> log a lock that is still held by a just committed transaction >>> that is very soon to be removed. To avoid any timing issue we >>> avoid applying locks made by transactions with InvalidXid. >> >>> Simon Riggs, bug report Tom Lane, diagnosis Pavan Deolasee >> >> I see this was only applied to HEAD. Wouldn't back-patching be in >> order? The problem is in 9.1 as well, no? > > Yes, it is. I prefer to give a little time before backpatching to > avoid mistakes (of my own making), especially since we're busy enough > not to want to divert energy to other releases right now. The patch > will make it in before next minor release. If it's going to go in before the next minor release, there's no real value in holding off, is there? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-committers по дате отправления: