log_timezone = UTC (charm default) is invalid on xenial
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
PostgreSQL Charm |
High
|
Stuart Bishop | |||
postgresql (Ubuntu) |
Undecided
|
Unassigned |
Bug Description
the log_timezone = UTC which worked on precise/trusty causes an error...
http://
it is in /usr/share/
either way I set it to GMT which worked fine.
my workaround
ubuntu@
listen_
ssl=true
log_checkpoints
log_connections
log_disconnecti
log_autovacuum_
log_line_prefix='%t [%p]: [%l-1] db=%d,user=%u '
archive_mode=on
archive_
hot_standby=true
max_wal_senders=80
# max_wal_
# wal_level=
# shared_
# effective_
default_
from_collapse_
join_collapse_
wal_buffers=-1
checkpoint_
password_
max_connections=100
log_timezone = GMT"
tags: | added: oil |
Changed in postgresql-charm: | |
status: | New → Triaged |
importance: | Undecided → High |
Greg Lutostanski (lutostag) wrote : | #1 |
Stuart Bishop (stub) wrote : | #2 |
I cannot reproduce this locally. I have reproduced it on OpenStack.
Stuart Bishop (stub) wrote : | #3 |
postgres=# select * from pg_timezone_
ERROR: time zone abbreviation "novst" is not used in time zone "Asia/Novosibirsk"
Querying the pg_timezone_names table works fine.
Looks like the ubuntu packages have bad integration with the system timezone database.
tags: | added: regression |
Stuart Bishop (stub) wrote : | #4 |
Worked around in the charm by removing the log_timezone default from the charm config.
Changed in postgresql-charm: | |
status: | Triaged → Fix Released |
assignee: | nobody → Stuart Bishop (stub) |
Launchpad Janitor (janitor) wrote : | #5 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in postgresql (Ubuntu): | |
status: | New → Confirmed |
Martin Pitt (pitti) wrote : | #6 |
I'm 99% sure that this is due to the cloud-init bug which messed up "UTC", in bug 1543025. Marking as a duplicate. If this still happens with current cloud images, please undup again.
Yep, its the symlink thing..., dunno why postgres can't deal with them, seems very strange.
precise/trusty
GMT -> Greenwich
Zulu -> UTC
xenial
Greenwich -> GMT
UTC -> Zulu
So there is neither default which will work across the series... bummer.
http://<email address hidden> says it should default to UTC if not specified, but that's for internal db timestamps, not sure for logging.
http:// stackoverflow. com/questions/ 26049242/ postgresql- error-timezone- directory- stack-overflow also mentions to check whether it was compiled with the --with- system- tzdata flag, but dunno what the debbuild does.