Re: Commits 8de72b and 5457a1 (COPY FREEZE)
Jeff Davis <pgsql@j-davis.com>
From: Jeff Davis <pgsql@j-davis.com>
To: Simon Riggs <simon@2ndQuadrant.com>
Cc: Stephen Frost <sfrost@snowman.net>, Andres Freund <andres@2ndquadrant.com>, pgsql-hackers@postgresql.org
Date: 2012-12-06T19:10:46Z
Lists: pgsql-hackers
On Thu, 2012-12-06 at 18:16 +0000, Simon Riggs wrote: > > I tend to agree with Andres on this one. This feels a bit like > > accepting a command but then not actually following-through on it > > if it turns out we can't actually do it. If it's truely an optimization > > (and I suspect my other email/question might provide insight into that), > > then it should be something we can 'just do' without needing to be asked > > to do it, along the same lines of not WAL'ing when the appropriate > > conditions are met (table created in this transaction, etc, etc). > > That depends whether its a command or a do-if-possible hint. Its > documented as the latter. > > Similar to the way VACUUM tries to truncate a relation, but gives up > if it can't. And on an even closer example, VACUUM FREEZE itself, > which doesn't guarantee that all rows are frozen at the end of it... Also, if the set of conditions changes in the future, we would have a problem if that caused new errors to appear. I think a WARNING might make more sense than a NOTICE, but I don't have a strong opinion about that. Regards, Jeff Davis
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Keep rd_newRelfilenodeSubid across overflow.
- ae9aba69a860 9.3.0 cited
-
Reduce scope of changes for COPY FREEZE.
- 5457a130d3a6 9.3.0 cited
-
COPY FREEZE and mark committed on fresh tables.
- 8de72b66a2ed 9.3.0 cited