Обсуждение: log timestamp since daylight saving time
Hi all -
Ever since daylight savings time, I've noticed that the timestamp in the
log files on 2 of our many postgres servers (version 8.4.5) did not
update. It's still 1 hour behind. The settings are all default (see
below) on all the servers.
# - Locale and Formatting -
datestyle = 'iso, mdy'
#intervalstyle = 'postgres'
#timezone = unknown # actually, defaults to TZ
environment
# setting
#timezone_abbreviations = 'Default' # Select the set of available
time zone
# abbreviations. Currently,
there are
# Default
# Australia
# India
# You can create your own file in
# share/timezonesets/.
#extra_float_digits = 0 # min -15, max 2
#client_encoding = sql_ascii # actually, defaults to database
# encoding
I've also checked the timezone through psql - for the 2 incorrect
servers I get
postgres=# show timezone;
TimeZone
----------
EST5EDT
(1 row)
For the correct servers, I get.....
postgres=# show timezone;
TimeZone
------------
US/Eastern
(1 row)
postgres=#
How do you go about correcting this??
thanks!
Maria Wilson
NASA/Langley Research Center
Hampton, Virginia 23681
On Tue, Mar 15, 2011 at 6:50 AM, Maria L. Wilson <Maria.L.Wilson-1@nasa.gov> wrote: > Hi all - > > Ever since daylight savings time, I've noticed that the timestamp in the log > files on 2 of our many postgres servers (version 8.4.5) did not update. > It's still 1 hour behind. The settings are all default (see below) on all > the servers. Have you tried updating postgresql and / or the tz data for the servers?
On Tue, Mar 15, 2011 at 12:12 PM, Maria L. Wilson <Maria.L.Wilson-1@nasa.gov> wrote: > when you say updating postgres - do you mean the server software? How do > you update the tz data? Yes updating the pg software. The OS has tzdata as well, and you can update that. But postgresql includes its own tzdata so I'm guessing that updating pg would fix it. > I'm just a little concerned why only 2 of our machines (they are all > supposed to be the same) are having this problem. Are they all running the same pg version?
On Tue, Mar 15, 2011 at 12:17 PM, Scott Marlowe <scott.marlowe@gmail.com> wrote: > On Tue, Mar 15, 2011 at 12:12 PM, Maria L. Wilson > <Maria.L.Wilson-1@nasa.gov> wrote: >> when you say updating postgres - do you mean the server software? How do >> you update the tz data? > > Yes updating the pg software. The OS has tzdata as well, and you can > update that. But postgresql includes its own tzdata so I'm guessing > that updating pg would fix it. > >> I'm just a little concerned why only 2 of our machines (they are all >> supposed to be the same) are having this problem. > > Are they all running the same pg version? Also are all the machines set to the same time zone?
yes they are all running the same postgres version. - 8.4.5 just as a test this morning - on one of the problem machines, we installed another postgres installation - same version - just pointed it to different paths - copied over the conf files and brought the server up. This time it was the correct timeszone - US/Eastern. The other postgres is set to EST5EDT. When I try to set it to US/Eastern, I get an error... postgres=# set timezone = 'US/Eastern'; ERROR: unrecognized time zone name: "US/Eastern" postgres=# On 3/15/11 2:18 PM, Scott Marlowe wrote: > On Tue, Mar 15, 2011 at 12:17 PM, Scott Marlowe<scott.marlowe@gmail.com> wrote: >> On Tue, Mar 15, 2011 at 12:12 PM, Maria L. Wilson >> <Maria.L.Wilson-1@nasa.gov> wrote: >>> when you say updating postgres - do you mean the server software? How do >>> you update the tz data? >> Yes updating the pg software. The OS has tzdata as well, and you can >> update that. But postgresql includes its own tzdata so I'm guessing >> that updating pg would fix it. >> >>> I'm just a little concerned why only 2 of our machines (they are all >>> supposed to be the same) are having this problem. >> Are they all running the same pg version? > Also are all the machines set to the same time zone?
it also looks like the view pg_timezone_names is empty in the problem installation. What loads this view? psql (8.4.5) Type "help" for help. postgres=# select * from pg_timezone_names; name | abbrev | utc_offset | is_dst ------+--------+------------+-------- (0 rows) postgres=# On 3/15/11 2:18 PM, Scott Marlowe wrote: > On Tue, Mar 15, 2011 at 12:17 PM, Scott Marlowe<scott.marlowe@gmail.com> wrote: >> On Tue, Mar 15, 2011 at 12:12 PM, Maria L. Wilson >> <Maria.L.Wilson-1@nasa.gov> wrote: >>> when you say updating postgres - do you mean the server software? How do >>> you update the tz data? >> Yes updating the pg software. The OS has tzdata as well, and you can >> update that. But postgresql includes its own tzdata so I'm guessing >> that updating pg would fix it. >> >>> I'm just a little concerned why only 2 of our machines (they are all >>> supposed to be the same) are having this problem. >> Are they all running the same pg version? > Also are all the machines set to the same time zone?
when you say updating postgres - do you mean the server software? How do you update the tz data? I'm just a little concerned why only 2 of our machines (they are all supposed to be the same) are having this problem. On 3/15/11 2:08 PM, Scott Marlowe wrote: > On Tue, Mar 15, 2011 at 6:50 AM, Maria L. Wilson > <Maria.L.Wilson-1@nasa.gov> wrote: >> Hi all - >> >> Ever since daylight savings time, I've noticed that the timestamp in the log >> files on 2 of our many postgres servers (version 8.4.5) did not update. >> It's still 1 hour behind. The settings are all default (see below) on all >> the servers. > Have you tried updating postgresql and / or the tz data for the servers?
"Maria L. Wilson" <Maria.L.Wilson-1@nasa.gov> writes:
> yes they are all running the same postgres version. - 8.4.5
> just as a test this morning - on one of the problem machines, we
> installed another postgres installation - same version - just pointed it
> to different paths - copied over the conf files and brought the server
> up. This time it was the correct timeszone - US/Eastern. The other
> postgres is set to EST5EDT. When I try to set it to US/Eastern, I get
> an error...
> postgres=# set timezone = 'US/Eastern';
> ERROR: unrecognized time zone name: "US/Eastern"
Huh. That should most certainly work in a standard Postgres
installation. You're apparently missing that timezone file.
There are two possibilities:
1. If Postgres was built to use its own timezone database (the default),
then $INSTALLPREFIX/share/timezone/US/Eastern is missing. Which means
you've got an incomplete PG installation.
2. If Postgres was built with --with-system-tzdata=SOMETHING, then
SOMETHING/US/Eastern is missing, which means either an incomplete
system timezone database or whoever did the build used the wrong
value of SOMETHING for your platform.
I'd imagine that the EST5EDT setting you're seeing is some kind of
fallback behavior upon not finding the proper timezone file. It's
hard to be sure about where that came from without knowing exactly
what's missing.
regards, tom lane
I would have thought the same thing too - but, the file system looks correct.....(below...) [postgres@catalogdata share]$ cd timezone /scratch/postgresql-8.4.5/share/timezone [postgres@catalogdata timezone]$ ls -al total 268 drwxr-xr-x 19 root staff 4096 Nov 1 09:08 ./ drwxr-xr-x 9 root staff 4096 Nov 1 09:20 ../ drwxr-xr-x 2 root staff 4096 Nov 1 09:08 Africa/ drwxr-xr-x 6 root staff 4096 Nov 1 09:08 America/ drwxr-xr-x 2 root staff 4096 Nov 1 09:08 Antarctica/ . . . -rw------- 6 root staff 118 Nov 1 09:08 Universal drwxr-xr-x 2 root staff 4096 Nov 1 09:08 US/ -rw------- 6 root staff 118 Nov 1 09:08 UTC -rw------- 1 root staff 1873 Nov 1 09:08 WET -rw------- 2 root staff 2194 Nov 1 09:08 W-SU -rw------- 6 root staff 118 Nov 1 09:08 Zulu [postgres@catalogdata timezone]$ pwd /scratch/postgresql-8.4.5/share/timezone /scratch/postgresql-8.4.5/share/timezone [postgres@catalogdata timezone]$ cd US /scratch/postgresql-8.4.5/share/timezone/US [postgres@catalogdata US]$ ls -al total 60 drwxr-xr-x 2 root staff 4096 Nov 1 09:08 ./ drwxr-xr-x 19 root staff 4096 Nov 1 09:08 ../ -rw------- 2 root staff 2358 Nov 1 09:08 Alaska -rw------- 3 root staff 2353 Nov 1 09:08 Aleutian -rw------- 2 root staff 327 Nov 1 09:08 Arizona -rw------- 2 root staff 3543 Nov 1 09:08 Central -rw------- 3 root staff 3519 Nov 1 09:08 Eastern -rw------- 4 root staff 1649 Nov 1 09:08 East-Indiana -rw------- 2 root staff 312 Nov 1 09:08 Hawaii -rw------- 3 root staff 2395 Nov 1 09:08 Indiana-Starke -rw------- 2 root staff 2202 Nov 1 09:08 Michigan -rw------- 4 root staff 2427 Nov 1 09:08 Mountain -rw------- 3 root staff 2819 Nov 1 09:08 Pacific -rw------- 3 root staff 2819 Nov 1 09:08 Pacific-New -rw------- 3 root staff 290 Nov 1 09:08 Samoa [postgres@catalogdata US]$ I'm just wondering if something happened in the installation that did NOT load the data into the timezone view - pg_timezone_names - because when I query that it comes up empty. On 3/15/11 3:50 PM, Tom Lane wrote: > "Maria L. Wilson"<Maria.L.Wilson-1@nasa.gov> writes: >> yes they are all running the same postgres version. - 8.4.5 >> just as a test this morning - on one of the problem machines, we >> installed another postgres installation - same version - just pointed it >> to different paths - copied over the conf files and brought the server >> up. This time it was the correct timeszone - US/Eastern. The other >> postgres is set to EST5EDT. When I try to set it to US/Eastern, I get >> an error... >> postgres=# set timezone = 'US/Eastern'; >> ERROR: unrecognized time zone name: "US/Eastern" > Huh. That should most certainly work in a standard Postgres > installation. You're apparently missing that timezone file. > There are two possibilities: > > 1. If Postgres was built to use its own timezone database (the default), > then $INSTALLPREFIX/share/timezone/US/Eastern is missing. Which means > you've got an incomplete PG installation. > > 2. If Postgres was built with --with-system-tzdata=SOMETHING, then > SOMETHING/US/Eastern is missing, which means either an incomplete > system timezone database or whoever did the build used the wrong > value of SOMETHING for your platform. > > I'd imagine that the EST5EDT setting you're seeing is some kind of > fallback behavior upon not finding the proper timezone file. It's > hard to be sure about where that came from without knowing exactly > what's missing. > > regards, tom lane
"Maria L. Wilson" <Maria.L.Wilson-1@nasa.gov> writes:
> I would have thought the same thing too - but, the file system looks
> correct.....(below...)
> -rw------- 3 root staff 3519 Nov 1 09:08 Eastern
Well ... correct other than lacking read permissions for anybody but
root ...
regards, tom lane
good grief! - thanks for seeing that..... ok, next question. so I change these permissions (to the correct read perms :) then how does postgres "load" these timezone? I'm really hoping that this doesn't require a re-install. thanks again!! Maria Wilson On 3/15/11 4:12 PM, Tom Lane wrote: > "Maria L. Wilson"<Maria.L.Wilson-1@nasa.gov> writes: >> I would have thought the same thing too - but, the file system looks >> correct.....(below...) >> -rw------- 3 root staff 3519 Nov 1 09:08 Eastern > Well ... correct other than lacking read permissions for anybody but > root ... > > regards, tom lane
Maria L. Wilson wrote: > good grief! - thanks for seeing that..... > > ok, next question. so I change these permissions (to the correct read > perms :) > then how does postgres "load" these timezone? I'm really hoping that > this doesn't require a re-install. Restarting the server will fix it. I don't know if a simple configuration file reload will fix it. --------------------------------------------------------------------------- > > thanks again!! Maria Wilson > > On 3/15/11 4:12 PM, Tom Lane wrote: > > "Maria L. Wilson"<Maria.L.Wilson-1@nasa.gov> writes: > >> I would have thought the same thing too - but, the file system looks > >> correct.....(below...) > >> -rw------- 3 root staff 3519 Nov 1 09:08 Eastern > > Well ... correct other than lacking read permissions for anybody but > > root ... > > > > regards, tom lane > > -- > Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-admin -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +