Re: Commits 8de72b and 5457a1 (COPY FREEZE)
Simon Riggs <simon@2ndquadrant.com>
From: Simon Riggs <simon@2ndQuadrant.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: Andres Freund <andres@2ndquadrant.com>, Jeff Davis <pgsql@j-davis.com>, pgsql-hackers@postgresql.org
Date: 2012-12-06T18:16:00Z
Lists: pgsql-hackers
On 6 December 2012 17:02, Stephen Frost <sfrost@snowman.net> wrote: > * Simon Riggs (simon@2ndQuadrant.com) wrote: >> It's not a bug. Requesting a useful, but not critical optimisation is >> just a hint. The preconditions are not easy to understand, so I see no >> reason to punish people that misunderstand, or cause programs to fail >> in ways that need detailed understanding to make them work again. > > 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... -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
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