Pushed, thanks.
I reviewed the test results and concluded that the comments were wrong
and the code was right, so I updated the comments to match reality.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training Services
--
Sent
On Sat, Jan 24, 2015 at 5:58 AM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Here's v0.5. (Why did you use that weird decimal versioning scheme? You
could just say v4 and save a couple of keystrokes). This patch makes
perfect sense to me now. I was ready to commit, but I checked the
Here's v0.5. (Why did you use that weird decimal versioning scheme? You
could just say v4 and save a couple of keystrokes). This patch makes
perfect sense to me now. I was ready to commit, but I checked the
regression test you added and noticed that you're only reading results
for the last set
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Even with the current approach of checking the stats after every
isolated case it's sometimes takes quite a little more than a glance
to verify correctness due to side-effects of rollback (ins/upd/del
counters are still updated), and the way
Alex Shulgin wrote:
OK, I think I have now all bases covered, though the updated patch is
not that pretty.
The problem is that we don't know in advance if the (sub)transaction is
going to succeed or abort, and in case of aborted truncate we need to
use the stats gathered prior to truncate.
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Alex Shulgin wrote:
OK, I think I have now all bases covered, though the updated patch is
not that pretty.
The problem is that we don't know in advance if the (sub)transaction is
going to succeed or abort, and in case of aborted truncate we
Jim Nasby jim.na...@bluetreble.com writes:
https://commitfest.postgresql.org/action/patch_view?id=1661 (apologies for
not replying to the thread; I can't find it in my inbox)
Patch applies and passes make check. Code formatting looks good.
Jim,
The regression test partially tests this. It
Alex Shulgin wrote:
Jim Nasby jim.na...@bluetreble.com writes:
The test also adds 2.5 seconds of forced pg_sleep. I think that's both
bad and unnecessary. When I removed the sleeps I still saw times of
less than 0.1 seconds.
Well, I never liked that part, but the stats don't get updated
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Another idea would be exposing pgstat_report_stat(true) at SQL level.
That would eleminate the need for explicit pg_sleep(=0.5), but we'll
still need the wait_for_... call to make sure the collector has picked
it up.
We already have a stats
Alex Shulgin wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Another idea would be exposing pgstat_report_stat(true) at SQL level.
That would eleminate the need for explicit pg_sleep(=0.5), but we'll
still need the wait_for_... call to make sure the collector has picked
it up.
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Alex Shulgin wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Another idea would be exposing pgstat_report_stat(true) at SQL level.
That would eleminate the need for explicit pg_sleep(=0.5), but we'll
still need the wait_for_...
https://commitfest.postgresql.org/action/patch_view?id=1661 (apologies for not
replying to the thread; I can't find it in my inbox)
Patch applies and passes make check. Code formatting looks good.
The regression test partially tests this. It does not cover 2PC, nor does it
test rolling back a
12 matches
Mail list logo
