Forum: Ruby on Rails ActiveRecord 1.13.2 -> 1.14.0 breaks Postgres connectivity

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Pistos C. (Guest)
on 2006-03-30 23:42
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 H. (Guest)
on 2006-03-31 12:32
(Received via mailing list)
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
Jeroen H. (Guest)
on 2006-03-31 12:38
(Received via mailing list)
Jeroen H. 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
Joe (Guest)
on 2006-03-31 15:20
I'm using Rails 1.1 and Postgres 8.0 and haven't had any connectivity
problems.

Only problems with default = current_timestamp...

Joe
Jeroen H. (Guest)
on 2006-03-31 15:46
(Received via mailing list)
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 H. (Guest)
on 2006-03-31 16:01
(Received via mailing list)
Jeroen H. wrote:
> Jeroen H. 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
Pistos C. (Guest)
on 2006-04-01 01:02
Jeroen H. wrote:
> Jeroen H. 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
Joe (Guest)
on 2006-04-01 01:41
Jeroen H. 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
Jeroen H. (Guest)
on 2006-04-01 11:26
(Received via mailing list)
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
Joe (Guest)
on 2006-04-01 11:37
Jeroen H. 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
Jeroen H. (Guest)
on 2006-04-01 11:42
(Received via mailing list)
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
Joe (Guest)
on 2006-04-01 11:51
Jeroen H. 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
Jeroen H. (Guest)
on 2006-04-01 11:57
(Received via mailing list)
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
Joe (Guest)
on 2006-04-01 12:09
Jeroen H. 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
Jeroen H. (Guest)
on 2006-04-01 12:15
(Received via mailing list)
Joe wrote:
>> 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
Raphael B. (Guest)
on 2006-04-01 12:58
(Received via mailing list)
On 4/1/06, Jeroen H. <removed_email_address@domain.invalid> wrote:
> >> What kind of defaults were you using then, because having defaults with
> 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
This topic is locked and can not be replied to.