Thread: pgsql: Add isolation tests for DROP INDEX CONCURRENTLY.
Add isolation tests for DROP INDEX CONCURRENTLY. Backpatch to 9.2 to ensure bugs are fixed. Abhijit Menon-Sen Branch ------ REL9_2_STABLE Details ------- http://git.postgresql.org/pg/commitdiff/d4412fa0e543fa1608c3bb9b6651d247ce59983f Modified Files -------------- .../expected/drop-index-concurrently-1.out | 36 ++++++++++++++++++++ .../expected/drop-index-concurrently-2.out | 24 +++++++++++++ src/test/isolation/isolation_schedule | 2 + .../isolation/specs/drop-index-concurrently-1.spec | 33 ++++++++++++++++++ .../isolation/specs/drop-index-concurrently-2.spec | 21 +++++++++++ 5 files changed, 116 insertions(+), 0 deletions(-)
Simon Riggs <simon@2ndQuadrant.com> writes:
> Add isolation tests for DROP INDEX CONCURRENTLY.
WTF? You just turned the whole buildfarm red. Didn't you read
Abhijit's statement that the code fails these tests currently?
Didn't you run the test before committing?
Please revert, until we have patches in place that make these
tests pass.
regards, tom lane
On 18 October 2012 14:49, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Simon Riggs <simon@2ndQuadrant.com> writes: >> Add isolation tests for DROP INDEX CONCURRENTLY. > > WTF? You just turned the whole buildfarm red. Didn't you read > Abhijit's statement that the code fails these tests currently? > Didn't you run the test before committing? Yes, but I was expecting it to fail. > Please revert, until we have patches in place that make these > tests pass. This was supposed to be two patches in quick succession, one to show the bug and one to fix it, but another problem delayed the second commit. At your request, I will revert and do this in one. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Simon Riggs <simon@2ndQuadrant.com> writes:
> On 18 October 2012 14:49, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Please revert, until we have patches in place that make these
>> tests pass.
> This was supposed to be two patches in quick succession, one to show
> the bug and one to fix it, but another problem delayed the second
> commit.
FWIW, a reasonable way to handle that would have been to make two
(or more) commits locally, but not push until the final state was good.
Pushing known-broken code is an extremely unfriendly thing to do.
regards, tom lane