Re: foreign key locks, 2nd attempt
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2012-01-17T06:21:28Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Try to avoid running with a full fsync request queue.
- 7f242d880b5b 9.1.0 cited
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