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:
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.
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 ):
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.
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?
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.
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)
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.
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.
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.
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’ .
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
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.