G'Day,
I was setting up a new machine today with an environment identical to the other developer machines and I installed postgreSQL using a debian package. After more than an hour's worth of troubleshooting I found that our application kept crashing on the new machine because it's datestyle value in postgresql.conf was set to 'ISO, MDY' whereas on the old machines it was 'ISO, DMY'. I checked the values of #LC_TIME# (in fact all locale values) and they're the same across the machines. Any idea what could've caused this difference in the setting?
Thanks!
Two points, first if you send dates to PostgreSQL in yyyy-mm-dd format, datestyle is irrelevant.
The initial value comes from the postgresql.conf which is set up by the installation of the package (initdb or the rpm/deb/etc). The best option here is to change it, but to correct your application to send dates to the db in yyyy-mm-dd format.
Related
I need to permanently change my postgreSQL db timezone from AEST to UTC, the instance is on AWS rds.
On my AWS RDS postgreSQL parameter group, the timezone shows UTC but when i run
show timezone; it returns my local time zone which is AEST
the sql SET TIMEZONE='UTC'; only change the session, so what's the right way to change the timezone to UTC permanently?
this link shows changing the parameter group value should work? https://aws.amazon.com/premiumsupport/knowledge-center/rds-change-time-zone/
thanks
A "source" of 'client' means that when your client connects, it sets the timezone it wants to use. This will override anything you do globally and permanently on the database side, as the client can always change their own setting for this.
If you tell us what your client is and how it is configured, someone may be able to help you change this behavior. For example if it is a libpq-based client, then having the PGTZ environment variable set will cause this behavior.
I'd like to know how to permanently change the timezone on postgresql -- using set timezone TO 'UTC' only changes it in current session, upon restarting it's back to my region timezone. If i change the postgresql.config file under data to:
datestyle = 'iso, dmy'
#intervalstyle = 'postgres'
timezone = 'UTC'
#timezone_abbreviations = 'Default'
Even if i stop the postgresql-x64-12 service, save the file, and restart service, it goes back to my region timezone afterwards.
Thank you!
The documentation says:
The TimeZone configuration parameter can be set in the file postgresql.conf, or in any of the other standard ways described in Chapter 19. There are also some special ways to set it:
The SQL command SET TIME ZONE sets the time zone for the session. This is an alternative spelling of SET TIMEZONE TO with a more SQL-spec-compatible syntax.
The PGTZ environment variable is used by libpq clients to send a SET TIME ZONE command to the server upon connection.
So either you changed the value in a wrong postgresql.conf, or you have the PGTZ environment variable set on the client side.
Another alternative is a SET TIME ZONE command in the .psqlrc file.
I have a postgresql database that I deploy scripts to using flyway. I use the maven flyway plugin to launch the database build against the target database. In that build I have scripts that do things like:
create table my_table(
my_date_time timestamp with time zone not null
);
insert into my_table(my_date_time)
select '2000-01-01';
The postgresql database timezone is set to UTC. My client machine (that runs the maven/flyway build) is running CEST (UTC+2:00).
When the scripts run, the database interprets the string literal above as '1999-12-31 22:00:00+00:00' and writes that to storage.
It seems that the jdbc client connection created by flyway is not setting its client timezone to UTC, but is taking the timstamp string and interpreting it as '2000-01-01 00:00:00+02:00'.
How can I set the client timezone on the jdbc connection created by flyway to UTC? Is there a setting that can be placed in my flyway.conf file?
If I change my local machine timezone to UTC the problem goes away, but I'd rather not do that on my development workstation.
A colleague suggested the following
mvn -Duser.timezone=UTC flyway:migrate
Instead of just giving it a date, which postgres has to interpret, it would be better to fully specify the timestamp:
insert into my_table(my_date_time)
select '2000-01-01T00:00:00+00';
If that is not possible, you could try running mvn with -Duser.timezone=UTC but fully specifying the timestamp is the better option as it leaves no room for misinterpretation or misconfiguration.
Another way is to set session timezone in migration script itself
SET timezone TO 'UTC';
i use flyway CLI in a script. so setting correct timezone to the corresponding environment variable before executing flyway command works for me:
export TZ=GMT
I have a timestamp column 'submitted_on' with default as now().
I have set the heroku TZ to my zone and added a php user ini with the same timezone.
But the database is still using UTC timezone. I see this when I ran this sql:
show timezone;
Is there a fix? Or this is how heroku databases work? Also I'm using free dynos.
Setting a TZ config var only affects the Dynos environment, as the database is located on a different machine, it has no effect.
Generally speaking, you should always keep servers clocks running on UTC, store all times in UTC, and perform any timezone/locale changes in your application framework.
The parameter timezone is determined when the database cluster is created.
You can either change the value in postgresql.conf, or you can use ALTER SYSTEM as a superuser to change the value.
I don't know if Heroku allows you either of these options.
I have Postgresql 9.5 installed on Ubuntu and need to use dblink. However I am using port 5433 (set in postgresql.conf) but dblink always defaults to port 5432. I know you can specify the port in the dblink parameters, but this is massive redundancy when I want to use the default port of my instance.
There is a way of telling dblink to use a specific port by default. I know this because I have successfully changed it in the past - but can't for the life of me remember how I did it. I have tried setting the PGPORT environment variable and rebooting. I have tried recreating the extension. I have tried reinstalling postgresql-contrib. None of this has made a difference. I have a feeling that there is some obscure file I edited but can't remember what, where or how.
Any suggestions of how to change the default connection parameters for dblink?
Got it!
It IS done by changing the environment variable, but this is not an environment variable in the sense that a Windows user would understand it (so changing /etc/environment does not work and neither does any other normal nix-style setting of global environment variables).
To change the default connection parameters for dblink you need to add PGPORT=5433 (in my case) to /etc/postgresql/9.5/main/environment. The annoying thing with Ubuntu install of Postgres is that I have at least three versions of all these sorts of files (including pg_HBA.conf and so on). The ones in /etc/... are mostly not read apart from in this case. It's the ones in my data directory (which for space reasons is in a non-default location). So, for anybody else having the same issue check /etc, /var, /your-data-directory.