Re: dblink regression failure in HEAD

I found regression test for dblink in HEAD was failed on my machine.
One buildfarm machine also reported the same failure.

http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=pangolin&dt=2010-07-12%2013:37:06

It seems to come from the recent fix for dropped column support,
but I'm not sure why other machines can pass the test.

================= pgsql.29332/contrib/dblink/regression.diffs
===================
*** /home/slux/buildfarm/HEAD/pgsql.29332/contrib/dblink/expected/dblink.out Mon
Jul 12 13:37:07 2010
--- /home/slux/buildfarm/HEAD/pgsql.29332/contrib/dblink/results/dblink.out Mon
Jul 12 13:51:40 2010
***************
*** 905,926 ****
ADD COLUMN col4 INT NOT NULL DEFAULT 42;
SELECT dblink_build_sql_insert('test_dropped', '2', 1,
ARRAY['1'::TEXT], ARRAY['2'::TEXT]);
! dblink_build_sql_insert
! ---------------------------------------------------------------------------
! INSERT INTO test_dropped(id,col2b,col3,col4) VALUES('2','113','foo','42')
! (1 row)
!
SELECT dblink_build_sql_update('test_dropped', '2', 1,
ARRAY['1'::TEXT], ARRAY['2'::TEXT]);
! dblink_build_sql_update
! -------------------------------------------------------------------------------------------
! UPDATE test_dropped SET id = '2', col2b = '113', col3 = 'foo', col4
= '42' WHERE id = '2'
! (1 row)
!
SELECT dblink_build_sql_delete('test_dropped', '2', 1,
ARRAY['2'::TEXT]);
! dblink_build_sql_delete
! -----------------------------------------
! DELETE FROM test_dropped WHERE id = '2'
(1 row)

--- 905,918 ----
ADD COLUMN col4 INT NOT NULL DEFAULT 42;
SELECT dblink_build_sql_insert('test_dropped', '2', 1,
ARRAY['1'::TEXT], ARRAY['2'::TEXT]);
! ERROR: source row not found
SELECT dblink_build_sql_update('test_dropped', '2', 1,
ARRAY['1'::TEXT], ARRAY['2'::TEXT]);
! ERROR: source row not found
SELECT dblink_build_sql_delete('test_dropped', '2', 1,
ARRAY['2'::TEXT]);
! dblink_build_sql_delete
! --------------------------------------------
! DELETE FROM test_dropped WHERE col2b = '2'
(1 row)

--
Itagaki Takahiro

Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> writes:
> I found regression test for dblink in HEAD was failed on my machine.
> One buildfarm machine also reported the same failure.

What this looks like to me is that dblink.c doesn't contain the fix
that the new regression test is checking for.

pangolin is pulling from the git mirror, which I still don't trust
further than I can throw it. How about you?

regards, tom lane

Excerpts from Tom Lane's message of lun jul 12 23:02:05 -0400 2010:

> pangolin is pulling from the git mirror, which I still don't trust
> further than I can throw it. How about you?

Easy enough to check -- just verify the $PostgreSQL$ tag in the file.

Oh wait ...

Tom Lane wrote:
> Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> writes:
>
>> I found regression test for dblink in HEAD was failed on my machine.
>> One buildfarm machine also reported the same failure.
>>
>
> What this looks like to me is that dblink.c doesn't contain the fix
> that the new regression test is checking for.
>
> pangolin is pulling from the git mirror, which I still don't trust
> further than I can throw it. How about you?
>
>
>

There is something very odd about that machine. It started failing 5
days ago. Then it stopped, then it started again.

As for the git mirror, I can only speak for the mirror I maintain, which
is validated on every live branch every day against CVS, so far without
a hiccup, and has four of my buildfarm members happily building against
it (and possibly others).

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Tom Lane wrote:
>> What this looks like to me is that dblink.c doesn't contain the fix
>> that the new regression test is checking for.
>>
>> pangolin is pulling from the git mirror, which I still don't trust
>> further than I can throw it. How about you?

> There is something very odd about that machine. It started failing 5
> days ago. Then it stopped, then it started again.

A few experiments later: I can reproduce the failure shown on pangolin
exactly if I revert the latest changes in sql/dblink.sql and
expected/dblink.out, while keeping dblink.c up to date. So I guessed
wrong on which file was out of sync, but I say confidently that this
is a repository sync problem.

regards, tom lane

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> A few experiments later: I can reproduce the failure shown on pangolin
> exactly if I revert the latest changes in sql/dblink.sql and
> expected/dblink.out, while keeping dblink.c up to date. So I guessed
> wrong on which file was out of sync, but I say confidently that this
> is a repository sync problem.

I'll check with Scott on this, sorry, but it might be an issue with the
machine and not the repository. That's the box that he's been doing the
performance-farm work on and it's entirely possible soemthing got
screwed up there. Of course, it could also be a repository problem,
I'll find out.

Thanks,

Stephen

Stephen Frost wrote:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>
>> A few experiments later: I can reproduce the failure shown on pangolin
>> exactly if I revert the latest changes in sql/dblink.sql and
>> expected/dblink.out, while keeping dblink.c up to date. So I guessed
>> wrong on which file was out of sync, but I say confidently that this
>> is a repository sync problem.
>>
>
> I'll check with Scott on this, sorry, but it might be an issue with the
> machine and not the repository. That's the box that he's been doing the
> performance-farm work on and it's entirely possible soemthing got
> screwed up there. Of course, it could also be a repository problem,
> I'll find out.
>
>
>

I just ran my validation script against the community git repo and it is
indeed broken in just this way :-(

cheers

andrew