Rails - Mar 2006 - ActiveRecord 1.13.2 -> 1.14.0 breaks Postgres connectivity

To Whom It May Concern:

I have an ActiveRecord-based application (non-Rails).  Life was grand 
until I upgraded ActiveRecord yesterday, after which point I was getting 
TONNES of these errors from my app and in PostgreSQL''s logs:

FATAL:  terminating connection due to administrator command

According to Google searching, this happens when an external process 
sends PostgreSQL SIGINT or SIGTERM.  Some threads suggested it might be 
Linux'' OOM killer or something similar.

Whatever it was, it rendered my application essentially unusable, 
because it couldn''t get through more than 5 to 15 DB hits before
getting
that error, and all subsequent DB hits would give "no connection to the 
server" errors.

Happily, I am able to use a specific AR version with:

require ''rubygems''
require_gem ''activerecord'', ''<= 1.13,2''

and that made the problem go away, so I''m content [for now].

I thought I''d mention my little adventure, so that Whomever Is In
Charge
would be informed.

Pistos

-- 
Posted via http://www.ruby-forum.com/.

Strange, I haven''t enabled very verbose logging but I don''t
seem to be
suffering from this. What version of PG are you running? I''m using
8.1.3

Cheers,

Jeroen

Pistos Christou wrote:
> To Whom It May Concern:
> 
> I have an ActiveRecord-based application (non-Rails).  Life was grand 
> until I upgraded ActiveRecord yesterday, after which point I was getting 
> TONNES of these errors from my app and in PostgreSQL''s logs:
> 
> FATAL:  terminating connection due to administrator command
> 
> According to Google searching, this happens when an external process 
> sends PostgreSQL SIGINT or SIGTERM.  Some threads suggested it might be 
> Linux'' OOM killer or something similar.
> 
> Whatever it was, it rendered my application essentially unusable, 
> because it couldn''t get through more than 5 to 15 DB hits before
getting
> that error, and all subsequent DB hits would give "no connection to
the
> server" errors.
> 
> Happily, I am able to use a specific AR version with:
> 
> require ''rubygems''
> require_gem ''activerecord'', ''<=
1.13,2''
> 
> and that made the problem go away, so I''m content [for now].
> 
> I thought I''d mention my little adventure, so that Whomever Is In
Charge
> would be informed.
> 
> Pistos
>

Jeroen Houben wrote:
> Strange, I haven''t enabled very verbose logging but I
don''t seem to be
> suffering from this. What version of PG are you running? I''m using
8.1.3
> 
I turned on verbose logging and I don''t see anything abnormal using pg 
8.1.3 and rails 1.1

Jeroen

I''m using Rails 1.1 and Postgres 8.0 and haven''t had any
connectivity
problems.

Only problems with default = current_timestamp...

Joe

-- 
Posted via http://www.ruby-forum.com/.

Joe wrote:
> I''m using Rails 1.1 and Postgres 8.0 and haven''t had any
connectivity
> problems.
> 
> Only problems with default = current_timestamp...
Yes this is a known issue. You don''t need now() you can just use 
created_at and updated_at which will act as automatic timestamps without 
writing any code for it. If you have any other columns you wish to 
default to now() you *do* need to set the value explicitly to Time.now() 
in ruby.

Jeroen

Jeroen Houben wrote:
> Jeroen Houben wrote:
>> Strange, I haven''t enabled very verbose logging but I
don''t seem to be
>> suffering from this. What version of PG are you running? I''m
using 8.1.3
>>
> 
> I turned on verbose logging and I don''t see anything abnormal
using pg
> 8.1.3 and rails 1.1
> 
That said, I *do* have a problem after restarting (start/stop) 
postgresql. The very first request yields an errors and after that 
everything is fine again.


here''s the error..

ActiveRecord::StatementInvalid (PGError: FATAL:  terminating connection 
due to administrator command
server closed the connection unexpectedly
         This probably means the server terminated abnormally
         before or while processing the request.
: SELECT count(*) AS count_all FROM matches ):


This does not happen on a graceful restart

Jeroen

Jeroen Houben wrote:
> Jeroen Houben wrote:
>> Strange, I haven''t enabled very verbose logging but I
don''t seem to be
>> suffering from this. What version of PG are you running? I''m
using 8.1.3
>> 
> 
> I turned on verbose logging and I don''t see anything abnormal
using pg
> 8.1.3 and rails 1.1
> 
> Jeroen
I''m running PostgreSQL 8.0.4.

I realized later that it could be because I stuffed all my model classes 
into a single file (because it was convenient at the time).  But anyway, 
I still think upgrading shouldn''t have broken this.  Either that, or
the
old version should have barfed the same way, telling me that I''m doing 
something wrong.

Here''s a question: Where should one''s establish_connection
call go,
exactly?  In the class?  In the initialize method?  Of which class?

Pistos

-- 
Posted via http://www.ruby-forum.com/.

Jeroen Houben wrote:
> Joe wrote:
>> I''m using Rails 1.1 and Postgres 8.0 and haven''t had
any connectivity
>> problems.
>> 
>> Only problems with default = current_timestamp...
> 
> Yes this is a known issue. You don''t need now() you can just use
> created_at and updated_at which will act as automatic timestamps without
> writing any code for it. If you have any other columns you wish to
> default to now() you *do* need to set the value explicitly to Time.now()
> in ruby.
> 
> Jeroen
Right. But this strikes me as a MAJOR backwards-compatibility violation. 
Seems like there was more harm in removing it rather than leaving it in, 
but I''m not privy to the developers'' reasons. It''s
gonna be a lot of
minor editing finding and fixing it in all my Rails apps.

Joe

-- 
Posted via http://www.ruby-forum.com/.

Joe wrote:
> Jeroen Houben wrote:
>> Joe wrote:
>>> I''m using Rails 1.1 and Postgres 8.0 and haven''t
had any connectivity
>>> problems.
>>>
>>> Only problems with default = current_timestamp...
>> Yes this is a known issue. You don''t need now() you can just
use
>> created_at and updated_at which will act as automatic timestamps
without
>> writing any code for it. If you have any other columns you wish to
>> default to now() you *do* need to set the value explicitly to
Time.now()
>> in ruby.
>>
>> Jeroen
> 
> Right. But this strikes me as a MAJOR backwards-compatibility violation. 
> Seems like there was more harm in removing it rather than leaving it in, 
> but I''m not privy to the developers'' reasons.
It''s gonna be a lot of
> minor editing finding and fixing it in all my Rails apps.
I''m pretty sure this same behaviour was also in 1.0
One important thing to note is that you do not notice this behaviour in 
development mode, so I only found out when I moved to production (on 1.0)

Jeroen

Jeroen Houben wrote:
> Joe wrote:
>>> in ruby.
>>>
>>> Jeroen
>> 
>> Right. But this strikes me as a MAJOR backwards-compatibility
violation.
>> Seems like there was more harm in removing it rather than leaving it
in,
>> but I''m not privy to the developers'' reasons.
It''s gonna be a lot of
>> minor editing finding and fixing it in all my Rails apps.
> 
> I''m pretty sure this same behaviour was also in 1.0
> One important thing to note is that you do not notice this behaviour in
> development mode, so I only found out when I moved to production (on 
> 1.0)
> 
> Jeroen
Nah, I never had this problem with 1.0 in production mode. The removal 
of the default code is in the 1.1 changelog for Activerecord.

Joe

-- 
Posted via http://www.ruby-forum.com/.

Joe wrote:
> Jeroen Houben wrote:
>> Joe wrote:
>>>> in ruby.
>>>>
>>>> Jeroen
>>> Right. But this strikes me as a MAJOR backwards-compatibility
violation.
>>> Seems like there was more harm in removing it rather than leaving
it in,
>>> but I''m not privy to the developers'' reasons.
It''s gonna be a lot of
>>> minor editing finding and fixing it in all my Rails apps.
>> I''m pretty sure this same behaviour was also in 1.0
>> One important thing to note is that you do not notice this behaviour in
>> development mode, so I only found out when I moved to production (on 
>> 1.0)
>>
>> Jeroen
> 
> Nah, I never had this problem with 1.0 in production mode. The removal 
> of the default code is in the 1.1 changelog for Activerecord.
What kind of defaults were you using then, because having defaults with 
pg functions in them for sure didn''t work properly in 1.0 (at least for
me)

Jeroen

Jeroen Houben wrote:
> Joe wrote:
>>> One important thing to note is that you do not notice this
behaviour in
>>> development mode, so I only found out when I moved to production
(on
>>> 1.0)
>>>
>>> Jeroen
>> 
>> Nah, I never had this problem with 1.0 in production mode. The removal 
>> of the default code is in the 1.1 changelog for Activerecord.
> 
> What kind of defaults were you using then, because having defaults with
> pg functions in them for sure didn''t work properly in 1.0 (at
least for
> me)
> 
> Jeroen
I just had timestamp columns with defaults of current_timestamp or 
now(). The default was used fine in 1.0, but after switching to 1.1 they 
caused errors.

Joe

-- 
Posted via http://www.ruby-forum.com/.

Joe wrote:
> Jeroen Houben wrote:
>> Joe wrote:
>>>> One important thing to note is that you do not notice this
behaviour in
>>>> development mode, so I only found out when I moved to
production (on
>>>> 1.0)
>>>>
>>>> Jeroen
>>> Nah, I never had this problem with 1.0 in production mode. The
removal
>>> of the default code is in the 1.1 changelog for Activerecord.
>> What kind of defaults were you using then, because having defaults with
>> pg functions in them for sure didn''t work properly in 1.0 (at
least for
>> me)
>>
>> Jeroen
> 
> I just had timestamp columns with defaults of current_timestamp or 
> now(). The default was used fine in 1.0, but after switching to 1.1 they 
> caused errors.
In my case, on 1.0, they would use *the same* timestamp value for each 
insert/update even if they were hours apart, because rails would cache 
those defaults somehow.

Jeroen

Jeroen Houben wrote:
> Joe wrote:
>>> pg functions in them for sure didn''t work properly in 1.0
(at least for
>>> me)
>>>
>>> Jeroen
>> 
>> I just had timestamp columns with defaults of current_timestamp or 
>> now(). The default was used fine in 1.0, but after switching to 1.1
they
>> caused errors.
> 
> In my case, on 1.0, they would use *the same* timestamp value for each
> insert/update even if they were hours apart, because rails would cache
> those defaults somehow.
> 
> Jeroen

Oh yeah, I saw that problem in the faults reports. But for me the 
current timestamp was always added as the default value correctly.

Joe

-- 
Posted via http://www.ruby-forum.com/.

Joe wrote:
> Jeroen Houben wrote:
>> Joe wrote:
>>>> pg functions in them for sure didn''t work properly in
1.0 (at least for
>>>> me)
>>>>
>>>> Jeroen
>>> I just had timestamp columns with defaults of current_timestamp or 
>>> now(). The default was used fine in 1.0, but after switching to 1.1
they
>>> caused errors.
>> In my case, on 1.0, they would use *the same* timestamp value for each
>> insert/update even if they were hours apart, because rails would cache
>> those defaults somehow.
>>
>> Jeroen
> 
> 
> Oh yeah, I saw that problem in the faults reports. But for me the 
> current timestamp was always added as the default value correctly.
Maybe it only occurred with the magic created_at / updated_at columns. I 
don''t think BC breakage is bad per se, as long as it''s clear
what the
breakage entails.

Jeroen

On 4/1/06, Jeroen Houben <jeroen@terena.nl> wrote:
> Joe wrote:
> > Jeroen Houben wrote:
> >> Joe wrote:
> >>>> One important thing to note is that you do not notice this
behaviour in
> >>>> development mode, so I only found out when I moved to
production (on
> >>>> 1.0)
> >>>>
> >>>> Jeroen
> >>> Nah, I never had this problem with 1.0 in production mode. The
removal
> >>> of the default code is in the 1.1 changelog for Activerecord.
> >> What kind of defaults were you using then, because having defaults
with
> >> pg functions in them for sure didn''t work properly in 1.0
(at least for
> >> me)
> >>
> >> Jeroen
> >
> > I just had timestamp columns with defaults of current_timestamp or
> > now(). The default was used fine in 1.0, but after switching to 1.1
they
> > caused errors.
>
> In my case, on 1.0, they would use *the same* timestamp value for each
> insert/update even if they were hours apart, because rails would cache
> those defaults somehow.
If have seen this in db/schema.rb. Rather than having a default value
of ''now'' or equivalent, you find a date, like
''2006-04-01 10:00:00'' .

Raph