Wed, Jun 16
May 10 2021
For a quick fix with a local installation, simply ALTER the schema for transcode and use TIMESTAMPTZ.
Dec 3 2020
The rationale laid out in this blog post makes sense but I am not sure it is feasible to stay on cURL 7.61 and below forever or backport changes from newer versions.
Nov 9 2020
Oct 6 2020
Sep 26 2020
Aug 16 2019
Thank you, the patches seem to fix the issue: the Active Users page is now working as intended on all my MediaWiki instances.
Aug 10 2019
Apologies for the delay, I somehow missed the e-mail notification completely. The 14-character fields are definitely not working as the format of the timestamps being inserted is full YYYY-MM-DD HH:MM:SS+TZ; TIMESTAMPTZ seems to work fine.
Jun 6 2019
Patch (removes EOR flag and uses PHP constants instead of hard-coded ones):
May 24 2019
By the way, I have another bug to report. This one I have not yet traced in the source (it is very hard to get it to actually happen and thus get a stack trace): unquoted column identifier for _pageID, once again.
May 23 2019
Update: this seems to trigger DB server overload. Deadlock detection has timeouts and this leads to PostgreSQL reaching its connection limit (my max_connections is set to 1024 and it gets exhausted during massive user influx).
May 9 2019
https://www.mediawiki.org/wiki/Special:ExtensionDistributor is broken again.
May 2 2019
Apr 20 2019
Note: this is still not fixed in 1.32.
Jan 10 2019
Pruning is broken for PostgreSQL:
Jul 17 2018
Perhaps there's a better way to detect these platform-specific constants?
Jul 1 2018
Jun 19 2018
@Ivor your patch fails in the first 4 chunks for REL_1.31 so I tried adapting it. Notably there is now an $ignore check which adds DO NOTHING to the query; I added a check for $set to avoid it if we already have an ON CONFLICT UPDATE added.
Jun 14 2018
Jan 26 2018
PostgreSQL user here, anything I could help with here? I have TMH installed and with the table/indexes added File pages seem to work so far.
Nov 8 2017
It most likely is a duplicate, my apologies — should have searched better prior to creating this one.
Oct 11 2017
Oops, missed T130634, please ignore.
Re: the first issue, I checked the documentation and seems like changing in page/WikiPage.php:
Oct 5 2017
File moving is still broken in 1.29.1:
@Ivor, I applied your patch 2 days ago and no errors so far, thank you. Benchmarks show database query time improvements of around 5% (probably thanks to no error logging going on any more, along with a better query plan).
Oct 4 2017
Side note: technically there are no problems that could lead to any kind of data loss or corruption (this happens inside a transaction), but I am not sure it is good practice to issue statements that lead to messages flooding the database server's error log.
Oct 3 2017
I would like to reiterate that this error appears in PostgreSQL error log with a severity of ERROR. Debug log is off at least in my case.
Sep 29 2017
Thank you. I guess this won't ever be fixed, then.