No, not the pg data directory. The pg binaries. My problem was caused
by the timezone files installed under /usr/local/pgsql/share were not
world readable due the way I had the umask of root set when I did the
compile and install.
Erik Jones wrote:
What? Are you actually saying that a PG
Tom Lane wrote:
No, he's complaining that the share/timezone file tree wasn't
world-readable. I think that's plain old pilot error though.
The install script shouldn't be second-guessing the umask it's
given, any more than it second-guesses the file ownerships.
If binaries are made readable a
Erik Jones <[EMAIL PROTECTED]> writes:
> On Mar 26, 2008, at 12:26 PM, Joseph Shraibman wrote:
>> This is a IMHO a bug in the install script. All of the postgres
>> install should be world readable, regardless of the umask (or at
>> least provide a warning).
> What? Are you actually saying
On Mar 26, 2008, at 12:26 PM, Joseph Shraibman wrote:
After I sent my last email, a light bulb went off. I remembered a
similar problem I had a while ago with parts of postgres not having
read permission. Sure enough after I
[EMAIL PROTECTED] /usr/local/pgsql]# chmod -R a+r *
then restar
Sorry, I didn't realize what you were asking.
[local]:owl=# SHOW TimeZone;
TimeZone
--
EST5EDT
(1 row)
Tom Lane wrote:
Joseph S <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Works for me ... what have you got TimeZone set to?
/etc/localtime -> /usr/share/zoneinfo/US/Eastern
Yo
Joseph Shraibman <[EMAIL PROTECTED]> writes:
> Sorry, I didn't realize what you were asking.
> [local]:owl=# SHOW TimeZone;
> TimeZone
> --
> EST5EDT
> (1 row)
[ squint... ] That should certainly think that we're into DST;
it does here:
regression=# set timezone = 'EST5EDT';
SET
regr
After I sent my last email, a light bulb went off. I remembered a
similar problem I had a while ago with parts of postgres not having read
permission. Sure enough after I
[EMAIL PROTECTED] /usr/local/pgsql]# chmod -R a+r *
then restart postgres everything is fine.
This is a IMHO a bug in th
Joseph S <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Works for me ... what have you got TimeZone set to?
> /etc/localtime -> /usr/share/zoneinfo/US/Eastern
You didn't answer the question: what does "SHOW TimeZone" say?
regards, tom lane
--
Sent via pgsql-general
"Scott Marlowe" <[EMAIL PROTECTED]> writes:
> Weirdly, I'm getting the right offsets, but my timezone in pgsql is
> navajo... For the OS it's America/Denver like I set it. And there's
> no timezone set in postgresql.conf.
According to the TZ files, "Navajo" is just an alias for
"America/Denver":
On Tue, Mar 25, 2008 at 5:39 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Joseph S <[EMAIL PROTECTED]> writes:
> > Was there something wrong with the tzdata distributed in 8.2.7?
> > current_timestamp is still using EST, but the date command run from the
> > command line is correctly returning EDT
Tom Lane wrote:
Joseph S <[EMAIL PROTECTED]> writes:
Was there something wrong with the tzdata distributed in 8.2.7?
current_timestamp is still using EST, but the date command run from the
command line is correctly returning EDT
Works for me ... what have you got TimeZone set to?
Joseph S <[EMAIL PROTECTED]> writes:
> Was there something wrong with the tzdata distributed in 8.2.7?
> current_timestamp is still using EST, but the date command run from the
> command line is correctly returning EDT
Works for me ... what have you got TimeZone set to?
Was there something wrong with the tzdata distributed in 8.2.7?
current_timestamp is still using EST, but the date command run from the
command line is correctly returning EDT
[local]:owl=# select version(), current_timestamp;
version
13 matches
Mail list logo
