Code

Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#17213 closed Bug (wontfix)

Can't change TIME_ZONE after initial transaction in PostgreSQL

Reported by: calvinspealman Owned by: nobody
Component: Database layer (models, ORM) Version: master
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

The changeset from #3459 has SET TIME ZONE only executed for new connections, which breaks any code which changes settings.TIME_ZONE, such as live settings applications or per-request middleware implementations. The connection should allow other code to tell it "I'm changing things, re-do the settings statements on the next transaction.

Attachments (1)

17213.diff (4.1 KB) - added by calvinspealman 3 years ago.
Patch that adds a way to flag when the connection shoudl set once-only things again, and a test for it.

Download all attachments as: .zip

Change History (7)

Changed 3 years ago by calvinspealman

Patch that adds a way to flag when the connection shoudl set once-only things again, and a test for it.

comment:1 Changed 3 years ago by calvinspealman

  • Component changed from Uncategorized to Database layer (models, ORM)
  • Has patch set
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

I'm sure the way I've added control to set these flags on-demand might need changed, but its a proof-of-concept

comment:2 Changed 3 years ago by aaugustin

  • Resolution set to wontfix
  • Status changed from new to closed

You should never alter settings at runtime, and we won't add code to Django to support that.

See https://docs.djangoproject.com/en/dev/topics/settings/#altering-settings-at-runtime

Would time zone support resolve your problem? (see last comment on #2626)

Last edited 3 years ago by aaugustin (previous) (diff)

comment:3 Changed 3 years ago by calvinspealman

While I'm very happy to see #2626 moving forward, I don't think it will be helpful in the context I've seen #17213 needed, which are installations running more sites than can realistically be served with at least one process per site, and some sort of middleware is used before each request to load per-site settings. I understand the dislike of changing settings, and I agree with it. i only filed this ticket, because it seemed that #3459 had broken a previous behavior and I could not determine if this was intended or desirable. I'm not sure the best course of action for such setups in the future, but will give it some thought.

comment:4 Changed 3 years ago by aaugustin

In fact, you're looking a larger problem than just time zone settings. (Massive) multi-hosting isn't supported by Django at this time. While it sort of works (some third party libraries exist to support this use case), our current position is that changing settings at runtime may cause undefined behavior.

comment:5 Changed 3 years ago by anonymous

It would be possible to support changing the connection timezone for every cursor.execute() if it needs changing, using get_parameter_status (see #17266). Although I do agree with aaugustin: you should not change settings, except in testing using override_setting.

comment:6 Changed 3 years ago by aaugustin

The connection_created signal may be useful in you want to change the time zone on a per-request basis.

I think setting TIME_ZONE = None in the settings file and executing SET TIME ZONE in a signal receiver should work. That function will have to look up the time zone in a global (thread-local) variable.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.