Re: Reports on obsolete Postgres versions

On 3/15/24 3:17 AM, Daniel Gustafsson wrote: >> On 14 Mar 2024, at 16:48, Peter Eisentraut wrote: >> On 13.03.24 18:12, Bruce Momjian wrote: > >>> I think "minor" is a better term since it contrasts with "major". We >>> don't actually supply patches to upgrade minor versions. >> >> There are

Re: Reports on obsolete Postgres versions

> On Mar 13, 2024, at 11:39 AM, Tom Lane wrote: > > Jeremy Schneider writes: >>> On 3/13/24 11:21 AM, Tom Lane wrote: >>> Agreed, we would probably add confusion not reduce it if we were to >>> change our longstanding nomenclature for this. > >>

Re: Reports on obsolete Postgres versions

On 3/13/24 11:21 AM, Tom Lane wrote: > Robert Treat writes: >> On Wed, Mar 13, 2024 at 1:12 PM Bruce Momjian wrote: >>> On Wed, Mar 13, 2024 at 09:21:27AM -0700, Jeremy Schneider wrote: >>>> In my view, the best thing would be to move toward consistently using &g

Re: Reports on obsolete Postgres versions

On 3/12/24 3:56 AM, Daniel Gustafsson wrote: >>> but that is far down the page. Do we need to improve this? > >> I liked the statement from Laurenz a while ago on his blog >> (paraphrased): "Upgrading to the latest patch release does not require >> application testing or recertification". I am

Re: Built-in CTYPE provider

On 1/9/24 2:31 PM, Jeff Davis wrote: > On Tue, 2024-01-09 at 14:17 -0800, Jeremy Schneider wrote: >> I think we missed something in psql, pretty sure I applied all the >> patches but I see this error: >> >> =# \l >> ERROR:  42703: column d.datlocale does n

Re: Built-in CTYPE provider

On 12/28/23 6:57 PM, Jeff Davis wrote: > On Wed, 2023-12-27 at 17:26 -0800, Jeff Davis wrote: > Attached a more complete version that fixes a few bugs, stabilizes the > tests, and improves the documentation. I optimized the performance, too > -- now it's beating both libc's "C.utf8" and ICU

Re: Built-in CTYPE provider

On 12/28/23 6:57 PM, Jeff Davis wrote: > > Attached a more complete version that fixes a few bugs, stabilizes the > tests, and improves the documentation. I optimized the performance, too > -- now it's beating both libc's "C.utf8" and ICU "en-US-x-icu" for both > collation and case mapping

Re: Set log_lock_waits=on by default

On 12/21/23 6:58 AM, Nikolay Samokhvalov wrote: > On Thu, Dec 21, 2023 at 05:29 Laurenz Albe > wrote: > > Here is a patch to implement this. > Being stuck behind a lock for more than a second is almost > always a problem, so it is reasonable to turn

Re: Built-in CTYPE provider

On 12/20/23 4:04 PM, Jeremy Schneider wrote: > On 12/20/23 3:47 PM, Jeremy Schneider wrote: >> On 12/5/23 3:46 PM, Jeff Davis wrote: >>> CTYPE, which handles character classification and upper/lowercasing >>> behavior, may be simpler than it first appears. We may be abl

Re: Built-in CTYPE provider

On 12/20/23 3:47 PM, Jeremy Schneider wrote: > On 12/5/23 3:46 PM, Jeff Davis wrote: >> CTYPE, which handles character classification and upper/lowercasing >> behavior, may be simpler than it first appears. We may be able to get >> a net decrease in complexity by just buildin

Re: Built-in CTYPE provider

On 12/5/23 3:46 PM, Jeff Davis wrote: > CTYPE, which handles character classification and upper/lowercasing > behavior, may be simpler than it first appears. We may be able to get > a net decrease in complexity by just building in most (or perhaps all) > of the functionality. > > === Character

Re: encoding affects ICU regex character classification

On 12/14/23 7:12 AM, Jeff Davis wrote: > The concern over unassigned code points is misplaced. The application > may be aware of newly-assigned code points, and there's no way they > will be mapped correctly in Postgres if the provider is not aware of > those code points. The user can either

Re: Built-in CTYPE provider

On 12/13/23 5:28 AM, Jeff Davis wrote: > On Tue, 2023-12-12 at 13:14 -0800, Jeremy Schneider wrote: >> My biggest concern is around maintenance. Every year Unicode is >> assigning new characters to existing code points, and those existing >> code points can of course alr

Re: encoding affects ICU regex character classification

On 12/12/23 1:39 PM, Jeff Davis wrote: > On Sun, 2023-12-10 at 10:39 +1300, Thomas Munro wrote: >> Unless you also >> implement built-in case mapping, you'd still have to call libc or ICU >> for that, right? > > We can do built-in case mapping, see: > >

Re: Built-in CTYPE provider

On 12/5/23 3:46 PM, Jeff Davis wrote: > === Character Classification === > > Character classification is used for regexes, e.g. whether a character > is a member of the "[[:digit:]]" ("\d") or "[[:punct:]]" > class. Unicode defines what character properties map into these > classes in TR #18 [1],

Re: proposal: change behavior on collation version mismatch

On 11/28/23 2:12 AM, Daniel Verite wrote: > Jeremy Schneider wrote: >> 1) "collation changes are uncommon" (which is relatively correct) >> 2) "most users would rather have ease-of-use than 100% safety, since >> it's uncommon" >> >> An

Re: proposal: change behavior on collation version mismatch

ort rules for japanese, chinese, arabic, cyrilic, nepalese, and all kinds of strings with nonsensical combinations of all these characters.  After some years of ICU and PG, I'm just coming to a conclusion that the right thing to do is stay safe and don't change ICU versions (or glibc versions) for existing

proposal: change behavior on collation version mismatch

ufFS-4-6%3DO3L%2BqG9iFT8tm6BvtZXNnSm1dkJ8GciCkA%40mail.gmail.com#beefde2f9e54dcee813a8f731993247d 2: https://github.com/ardentperf/glibc-unicode-sorting/ 3: https://ardentperf.com/2023/03/26/did-postgres-lose-my-data/ -- Jeremy Schneider Database and Performance Engineer Amazon Web Services

Re: Configurable FP_LOCK_SLOTS_PER_BACKEND

research ticket. Maybe it doesn't actually help. Anyway Alexander Pyhalov's email about LWLock optimization and NUM_LOCK_PARTITIONS is out there, and I wondered about this. -Jeremy -- Jeremy Schneider Performance Engineer Amazon Web Services

Re: Let's make PostgreSQL multi-threaded

On 6/7/23 2:39 PM, Thomas Kellerer wrote: > Tomas Vondra schrieb am 07.06.2023 um 21:20: >> Also, which other projects did this transition? Is there something we >> could learn from them? Were they restricted to much smaller list of >> platforms? > > Not open source, but Oracle was historically

Re: Let's make PostgreSQL multi-threaded

On 6/5/23 2:07 PM, Jonah H. Harris wrote: > On Mon, Jun 5, 2023 at 8:18 AM Tom Lane > wrote: > > For the record, I think this will be a disaster.  There is far too much > code that will get broken, largely silently, and much of it is not > under our

collation settings table in v16 docs

Looking at the "collation settings" table in the v16 docs, I think some readers may have a little difficulty understanding what each row means. https://www.postgresql.org/docs/devel/collation.html#ICU-COLLATION-SETTINGS The "Key" column isn't meaningful and it's a bit arduous to read the whole

Re: Collation version tracking for macOS

On 11/28/22 6:54 PM, Jeff Davis wrote: > > =# select * from pg_icu_collation_versions('en_US') order by > icu_version; > icu_version | uca_version | collator_version > -+-+-- > ... > 67.1| 13.0| 153.14 > 68.2| 13.0|

Re: Collation version tracking for macOS

  > On Jun 14, 2022, at 19:06, Thomas Munro wrote: > One difference would be the effect if ICU ever ships a minor library > version update that changes the reported collversion. If I’m reading it correctly, ICU would not change collation in major versions, as an explicit matter of policy

Re: Collation version tracking for macOS

> On Jun 14, 2022, at 14:10, Peter Eisentraut > wrote: >  > Conversely, why are we looking at the ICU version instead of the collation > version. If we have recorded the collation as being version 1234, we need to > look through the available ICU versions (assuming we can load multiple

Re: Collation version tracking for macOS

> On Jun 8, 2022, at 22:40, Peter Geoghegan wrote: > > On Wed, Jun 8, 2022 at 10:24 PM Jeremy Schneider > wrote: >> Even if PG supports two versions of ICU, how does someone actually go about >> removing every dependency on the old version and replacing it with t

Re: Collation version tracking for macOS

> On Jun 8, 2022, at 03:19, Thomas Munro wrote: > > On Wed, Jun 8, 2022 at 12:23 PM Peter Geoghegan wrote: >> ISTM that there are two mostly-distinct questions here: >> >> 1. How do we link to multiple versions of ICU at the same time, in a >> way that is going to work smoothly on

Re: Collation version tracking for macOS

New emoji are getting added with some frequency, it’s a thing lately… New Unicode chars use existing but unassigned code points. All code points are able to be encoded, claimed or unclaimed. Someone on old glibc or ICU can still store the new characters. As long as there’s an input field. You

Re: Collation version tracking for macOS

On 6/7/22 1:51 PM, Peter Geoghegan wrote: > On Tue, Jun 7, 2022 at 1:24 PM Jeremy Schneider > wrote: >> This idea does seem to persist. It's not as frequent as timezones, but >> collation rules reflect local dialects and customs, and there are >> changes quite regularly

Re: Collation version tracking for macOS

On 6/7/22 12:53 PM, Peter Geoghegan wrote: > > Collations by their very nature are unlikely to change all that much. > Obviously they can and do change, but the details are presumably > pretty insignificant to a native speaker. This idea does seem to persist. It's not as frequent as timezones,

Re: Collation version tracking for macOS

> On Jun 6, 2022, at 17:10, Jim Nasby wrote: > Ignoring broken backups, segfaults and data corruption as a "rant" implies > that we simply throw in the towel and tell users to suck it up or switch > engines. Well now, let’s be clear, I was the one who called my email a “rant”.  And I do

Re: Collation version tracking for macOS

PG community, and that the seriousness of this issue is not fully understood. -Jeremy Schneider -- http://about.me/jeremy_schneider

Re: Sequence's value can be rollback after a crashed recovery.

On 11/23/21 05:49, Andy Fan wrote: > > > I think at this thread[1], which claimed to get this issue even after > > commit, I haven't tried it myself though. > > > > [1] > >

Re: Sequence's value can be rollback after a crashed recovery.

On 11/22/21 12:31, Tom Lane wrote: > "Bossart, Nathan" writes: >> I periodically hear rumblings about this behavior as well. At the >> very least, it certainly ought to be documented if it isn't yet. I >> wouldn't mind trying my hand at that. Perhaps we could also add a new >> configuration

Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns

On 10/10/21 23:27, Masahiko Sawada wrote: > > After more thought, given DDLs are not likely to happen than DML in > practice, ... I haven't looked closely at the patch, but I'd be careful about workloads where people create and drop "temporary tables". I've seen this pattern used a few times,

Re: pg_walinspect - a new extension to get raw WAL data and WAL stats

On 10/5/21 17:43, Bruce Momjian wrote: > On Tue, Oct 5, 2021 at 03:30:07PM -0700, Jeremy Schneider wrote: >> Specifically exposing pg_waldump functionality in SQL could speed up >> finding bugs in the PG logical replication code. We found and fixed a >> few over this past yea

Re: pg_walinspect - a new extension to get raw WAL data and WAL stats

On 10/5/21 15:07, Bruce Momjian wrote: > On Wed, Sep 8, 2021 at 07:18:08PM +0530, Bharath Rupireddy wrote: >> While working on one of the internal features, we found that it is a >> bit difficult to run pg_waldump for a normal user to know WAL info and >> stats of a running postgres database

Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query

> On Jun 20, 2018, at 12:30 AM, Haribabu Kommi wrote: > > Attached is a simple patch with implementation. Comments? Seems useful to me too! What are the odds we could have a column telling the timestamp when a particular query was last reset? Would that be complicated to add? -Jeremy

Re: [HACKERS] pg_upgrade to clusters with a different WAL segment size

On Mon, Nov 13, 2017 at 3:09 PM, Tom Lane wrote: >> On Tue, Nov 14, 2017 at 7:32 AM, Andres Freund wrote: >>> Even if that's the case, I fail to see why it'd be a good idea to have >>> any sort of pg_upgrade integration here. We should make pg_resetwal's

Re: [HACKERS] pg_upgrade to clusters with a different WAL segment size

On Fri, Nov 10, 2017 at 4:04 PM, Michael Paquier wrote: > On Sat, Nov 11, 2017 at 12:46 AM, Bossart, Nathan wrote: >> Allowing changes to the WAL segment size during pg_upgrade seems like a >> nice way to avoid needing a dump and load, so I would