pg/postgres/CI

Mike Gunderloy
Thu, 29 Jan 2009 12:09:34 -0000

I''m not convinced that
http://github.com/rails/rails/commit/feed7b4cfd860bdc9f5b4efc2ca2af76cb01d55d
  (simply replacing the postgres gem with the pg gem in the CI server
setup instructions) is the right resolution. We had a mystery build
break yesterday which pointed to the PostgreSQL AR tests; rebuilding
immediately made the break go away, and the commit didn''t touch AR at
all, so I reluctantly (very reluctantly) say "gremlins."

The problem with this fix, though, is that the AR driver for
PostgreSQL has code to detect which of the two gems is installed, and
to take different code - and test - paths depending on which one is
there. We''ve had failures in the past
(http://rails.lighthouseapp.com/projects/8994/tickets/1748
) that amounted to support of one or the other being broken.
Unfortunately, in the absence of any clear decision on which way to
go, the code is still trying to support both. By having only one or
the other on the CI server, we''re only testing some of the PG code -
and we have within the past several months seen breaks that affects pg
but not postgres AND breaks that affected postgres but not pg.

One possible resolution would be for us to have both gems available on
the CI server, and to increase the sophistication of the build script
to run the AR tests using each one in isolation - I know Chad Woolley
was looking into this. Another would be for us to declare the older
postgres gem as unsupported, and to just accept any breaks that happen
with it - that''s sort of what this swap in the CI setup does, but
without making any particular note of it. But I''m rather leery of
having code paths in AR that don''t get tested, especially given that
we''ve seen bugs in those code paths recently.

Mike