Re: Commits 8de72b and 5457a1 (COPY FREEZE)
Stephen Frost <sfrost@snowman.net>
From: Stephen Frost <sfrost@snowman.net>
To: Simon Riggs <simon@2ndQuadrant.com>
Cc: Andres Freund <andres@2ndquadrant.com>, Jeff Davis <pgsql@j-davis.com>, pgsql-hackers@postgresql.org
Date: 2012-12-06T17:02:53Z
Lists: pgsql-hackers
* 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). Thanks, Stephen
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