Re: foreign key locks, 2nd attempt
От | Heikki Linnakangas |
---|---|
Тема | Re: foreign key locks, 2nd attempt |
Дата | |
Msg-id | 4F151368.4020507@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: foreign key locks, 2nd attempt (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: foreign key locks, 2nd attempt
|
Список | pgsql-hackers |
On 16.01.2012 21:52, Alvaro Herrera wrote: > > Excerpts from Heikki Linnakangas's message of lun ene 16 16:17:42 -0300 2012: >> >> On 15.01.2012 06:49, Alvaro Herrera wrote: >>> - pg_upgrade bits are missing. >> >> I guess we'll need to rewrite pg_multixact contents in pg_upgrade. Is >> the page format backwards-compatible? > > It's not. > > I haven't worked out what pg_upgrade needs to do, honestly. I think we > should just not copy old pg_multixact files when upgrading across this > patch. Sorry, I meant whether the *data* page format is backwards-compatible? the multixact page format clearly isn't. > I was initially thinking that pg_multixact should return the > empty set if requested members of a multi that preceded the freeze > point. That way, I thought, we would just never try to access a page > originated in the older version (assuming the freeze point is set to > "current" whenever pg_upgrade runs). However, as things currently > stand, accessing an old multi raises an error. So maybe we need a > scheme a bit more complex to handle this. Hmm, could we create new multixact files filled with zeros, covering the range that was valid in the old cluster? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: