On Fri, 21 Apr 2023 at 01:49, Robert Haas wrote:
>
> On Thu, Apr 20, 2023 at 1:08 AM Amit Kapila wrote:
> > Pushed. I noticed that we didn't display this new subscription option
> > 'password_required' in \dRs+:
> >
> > postgres=# \dRs+
> >
> > List of subscriptions
> > Name | Owner | E
Hi!
This limitation applies not only to wide tables - it also applies to tables
where TOASTed values
are updated very often. You would soon be out of available TOAST value ID
because in case of
high frequency updates autovacuum cleanup rate won't keep up with the
updates. It is discussed
in [1].
Hi,
After catching up with this thread, where pending bugs are listed and discussed,
I wonder if the current patches trying to lower the HashJoin memory explosion[1]
could be added to the "Older bugs affecting stable branches" list of
https://wiki.postgresql.org/wiki/PostgreSQL_16_Open_Items as I
There was discussion in [1] about improvements to list manipulation in
several places. But since the discussion is not related to the topic in
that thread, fork a new thread here and attach a patch to show my
thoughts.
Some are just cosmetic changes by using macros. The others should have
perfor
> In my opinion, PQconnectPoll and PQgetCancel should use the same
> parsing function or PQconnectPoll should set parsed values, making
> unnecessary for PQgetCancel to parse the same parameter
> again.
Yes, I totally agree. So I think patch 0002 looks fine.
> Additionally, PQgetCancel should set
On Fri, Apr 21, 2023 at 5:43 AM David Rowley wrote:
> On Thu, 20 Apr 2023 at 18:46, Richard Guo wrote:
> > I searched the codes and found some other places where the manipulation
> > of lists can be improved in a similar way.
> I'd be happy to discuss our thought about List inefficiencies, but I
> On 18 Apr 2023, at 14:32, Daniel Gustafsson wrote:
>
>> On 17 Apr 2023, at 18:20, Jacob Champion wrote:
>
>> Note that it won't fix the
>> (completely different) misleading error message for OpenSSL 3.0, but
>> since that's an *actively* unhelpful error message coming back from
>> OpenSSL, I
Now that the PG16 feature freeze happened I think it's time to bump
this thread again. As far as I remember everyone that responded (even
previously silent people) were themselves proponents of being more
strict around pgindent.
I think there's two things needed to actually start doing this:
1. We
Hi Michael
thank you for your explanation.
actually, some location can be tricky to add.
it looks like CREATE, but it’s actually ALTER, should call
InvokeObjectPostAlterHook instead of InvokeObjectPostCreateHook?
eg.,CREATE OR REPLACE, CREATE TYPE(perfecting shell type)
Thank you
-
Okay, I rebased again. Indeed 983ec23007b gave the most problems.
On Fri, 7 Apr 2023 at 10:02, Denis Laxalde wrote:
>
> The patch set does not apply any more.
>
> I tried to rebase locally; even leaving out 1 ("libpq: Run pgindent
> after a9e9a9f32b3"), patch 4 ("Start using new libpq cancel APIs
> On 21 Apr 2023, at 07:02, Gurjeet Singh wrote:
> On Thu, Apr 20, 2023 at 9:31 PM Tom Lane wrote:
libpq_append_conn_error(conn, "invalid require_auth method: \"%s\"",
method);
>>
>> Yup, this one did not get the memo.
I've pushed this, with the change to use the common "invalid %s v
On Thu, Apr 20, 2023 at 9:41 PM Kumar, Sachin wrote:
>
> I am working on a prototype with above discussed idea, I think I will send it
> for initial review by Monday.
>
Okay, but which idea are you referring to? pg_subscription_remote_rel
+ worker_pid idea Amit proposed?
Regards,
--
Masahiko
On Thu, Apr 20, 2023 at 8:16 PM Amit Kapila wrote:
>
> On Mon, Apr 17, 2023 at 9:12 AM Masahiko Sawada wrote:
> >
> > On Fri, Apr 7, 2023 at 6:37 PM Amit Kapila wrote:
> > >
> > > On Thu, Apr 6, 2023 at 6:57 PM Masahiko Sawada
> > > wrote:
> > > >
> > > >
> > > > While writing a PoC patch, I f
> On 21 Apr 2023, at 01:32, Nathan Bossart wrote:
>
> On Wed, Mar 15, 2023 at 10:38:34AM +0100, Daniel Gustafsson wrote:
>> While here, I wonder if we should document what BGW_MAXLEN is defined as in
>> bgworker.sgml?
>
> I am -0.5 for this. If you are writing a new background worker, it's
> pr
On Fri, Apr 21, 2023 at 2:40 AM Tom Lane wrote:
>
> The Core Team would like to extend our congratulations to
> Nathan Bossart, Amit Langote, and Masahiko Sawada, who have
> accepted invitations to become our newest Postgres committers.
>
> Please join me in wishing them much success and few rever
Many congratulations to all.
On Thursday, April 20, 2023, Tom Lane wrote:
> The Core Team would like to extend our congratulations to
> Nathan Bossart, Amit Langote, and Masahiko Sawada, who have
> accepted invitations to become our newest Postgres committers.
>
> Please join me in wishing them
Hi David,
21.04.2023 01:49, David Rowley wrote:
On Wed, 19 Apr 2023 at 07:00, Alexander Lakhin wrote:
please look at the similar list for v15+ (596b5af1d..HEAD).
I've now pushed most of these but didn't include the following ones:
Thank you!
3. BufFileOpenShared -> BufFileOpenFileSet // s
On Thu, Apr 20, 2023 at 6:09 PM shveta malik wrote:
>
>
> Few more comments, mainly for event_trigger.c in the patch dated April17:
>
> 1)EventTriggerCommonSetup()
> +pub_funcoid = LookupFuncName(pubfuncname, 0, NULL, true);
>
> This is the code where we have special handling for ddl-triggers
LGTM I guess this was an unintended leftover from me reordering the tests a
bit in the final stages of getting these patches in.
On Fri, 21 Apr 2023 at 08:38, Gurjeet Singh wrote:
> On Thu, Apr 20, 2023 at 11:00 PM Gurjeet Singh wrote:
> >
> > Commit 7f5b198 introduced TAP tests that use string
Hi.
We've found that in cases like the one attached, when we insert into
foreign partition with batch_size set, buffer refcount leak is detected.
The above example we see a dozen of similar messages:
repro_small.sql:31: WARNING: buffer refcount leak: [14621]
(rel=base/16718/16732, blockNum=
On Fri, Apr 21, 2023 at 01:07:03PM +0300, Alexander Pyhalov wrote:
> We've found that in cases like the one attached, when we insert into foreign
> partition with batch_size set, buffer refcount leak is detected.
>
> The above example we see a dozen of similar messages:
>
> repro_small.sql:31: WA
Hello, hackers,
we have a duplicate line, declaration of default_multirange_selectivity() in
src/backend/utils/adt/multirangetypes_selfuncs.c:
static double default_multirange_selectivity(Oid operator);
static double default_multirange_selectivity(Oid operator);
Affected branches: REL_14_STABLE
> On 21 Apr 2023, at 12:32, Anton Voloshin wrote:
> we have a duplicate line, declaration of default_multirange_selectivity() in
> src/backend/utils/adt/multirangetypes_selfuncs.c:
>
> static double default_multirange_selectivity(Oid operator);
> static double default_multirange_selectivity(Oid
Hi!
On Fri, 21 Apr 2023 at 14:34, Daniel Gustafsson wrote:
>
> > On 21 Apr 2023, at 12:32, Anton Voloshin wrote:
>
> > we have a duplicate line, declaration of default_multirange_selectivity() in
> > src/backend/utils/adt/multirangetypes_selfuncs.c:
> >
> > static double default_multirange_selec
> On 21 Apr 2023, at 08:38, Gurjeet Singh wrote:
>
> On Thu, Apr 20, 2023 at 11:00 PM Gurjeet Singh wrote:
>>
>> Commit 7f5b198 introduced TAP tests that use string literals to mark
>> the presence of a query in server logs. For no explicable reason, the
>> tests with the marker 'connect2' occu
On 21/04/2023 13:45, Pavel Borisov wrote:
The patch is attached. Anyone to commit?
Speaking of duplicates, I just found another one:
>break;
>break;
in src/interfaces/ecpg/preproc/variable.c
(in all stable branches).
Sorry for missing it in the p
On Fri, Apr 21, 2023 at 17:52 Masahiko Sawada wrote:
> On Fri, Apr 21, 2023 at 2:40 AM Tom Lane wrote:
> >
> > The Core Team would like to extend our congratulations to
> > Nathan Bossart, Amit Langote, and Masahiko Sawada, who have
> > accepted invitations to become our newest Postgres committe
> On 21 Apr 2023, at 12:58, Anton Voloshin wrote:
>
> On 21/04/2023 13:45, Pavel Borisov wrote:
>> The patch is attached. Anyone to commit?
>
> Speaking of duplicates, I just found another one:
> >break;
> >break;
> in src/interfaces/ecpg/preproc/v
Em sex., 21 de abr. de 2023 às 04:34, Richard Guo
escreveu:
> There was discussion in [1] about improvements to list manipulation in
> several places. But since the discussion is not related to the topic in
> that thread, fork a new thread here and attach a patch to show my
> thoughts.
>
> Some
Hi!
On Fri, 21 Apr 2023 at 15:14, Daniel Gustafsson wrote:
>
> > On 21 Apr 2023, at 12:58, Anton Voloshin wrote:
> >
> > On 21/04/2023 13:45, Pavel Borisov wrote:
> >> The patch is attached. Anyone to commit?
> >
> > Speaking of duplicates, I just found another one:
> > >
Hi Tom,
Thanks a lot for your possible approach for a solution.
I have implemented the approach by splitting the hash table into two parts.
Please find the attached patch for the same.
Thanks & Best Regards,
Ajit
On Wed, Apr 19, 2023 at 10:13 PM Tom Lane wrote:
> Ajit Awekar writes:
> > Plea
On Wed, 19 Apr 2023 at 14:58, Tom Lane wrote:
>
> Thom Brown writes:
> > I've attached a patch that removes some now redundant messaging about
> > unsupported versions.
>
> If we want to make that a policy, I think a lot more could be done
> --- I remember noticing a documentation comment about s
On Fri, 21 Apr 2023 at 23:16, Ranier Vilela wrote:
> Perhaps list_delete_nth_cell needs to check NIL too?
> + if (list == NIL)
> + return NIL;
Which cell would you be deleting from an empty list?
David
On Fri, Apr 21, 2023 at 12:30 PM vignesh C wrote:
>
> On Fri, 21 Apr 2023 at 01:49, Robert Haas wrote:
> >
> > On Thu, Apr 20, 2023 at 1:08 AM Amit Kapila wrote:
> > > Pushed. I noticed that we didn't display this new subscription option
> > > 'password_required' in \dRs+:
> > >
> > > postgres=#
On 21/04/2023 14:14, Daniel Gustafsson wrote:
I'll take care of these in a bit (unless someone finds more, or objects)
backpatching them to their respective origins branches
Thanks!
I went through master with
find . -name "*.[ch]" -exec bash -c 'echo {}; uniq -d {}' \;|sed -E
'/^[[:space:]*]*
> On 21 Apr 2023, at 07:29, Gurjeet Singh wrote:
>
> Commit [1] implements Fisher-Yates shuffling algorithm to shuffle
> connection addresses, in two places.
>
> The attached patch moves the duplicated code to a function, and calls
> it in those 2 places.
The reason I left it like this when rev
On Fri, Apr 21, 2023 at 8:19 AM Amit Kapila wrote:
> LGTM. Let's see if Robert or others have any comments, otherwise, I'll
> push this early next week.
LGTM too.
--
Robert Haas
EDB: http://www.enterprisedb.com
Hi hackers,
Following my previous mail about adding stats on parallelism[1], this
patch introduces the log_parallel_worker_draught parameter, which
controls whether a log message is produced when a backend attempts to
spawn a parallel worker but fails due to insufficient worker slots. The
sho
Hi,
Apologies if this has already been discussed someplace, but I couldn't
find a previous discussion. It seems to me that base backups are
broken in the face of a concurrent truncation that reduces the number
of segments in a relation.
Suppose we have a relation that is 1.5GB in size, so that we
Jehan-Guillaume de Rorthais writes:
> After catching up with this thread, where pending bugs are listed and
> discussed,
> I wonder if the current patches trying to lower the HashJoin memory
> explosion[1]
> could be added to the "Older bugs affecting stable branches" list of
> https://wiki.post
Hi,
I recently noticed the following in the work_mem [1] documentation:
“Note that for a complex query, several sort or hash operations might be
running in parallel;”
The use of “parallel” here is misleading as this has nothing to do with
parallel query, but
rather several operations in a plan
On Fri, Apr 21, 2023 at 8:25 AM Daniel Gustafsson wrote:
> The reason I left it like this when reviewing and committing is that I think
> it
> makes for more readable code. The amount of lines saved is pretty small, and
> "shuffle" isn't an exact term so by reading the code it isn't immediate cl
Hi,
Just a quick observation:
> basebackup.c's theory about relation truncation is that it doesn't
> really matter because WAL replay will fix things up. But in this case,
> I don't think it will, because WAL replay relies on the above
> invariant holding.
Assuming this is the case perhaps we ca
Hi again,
> Assuming this is the case perhaps we can reduce the scenario and
> consider this simpler one:
>
> 1. The table is truncated
> 2. The DBMS is killed before making a checkpoint
> 3. We are in recovery and presumably see a pair of 0.5 Gb segments
>
> Or can't we?
Oh, I see. If the proces
On Fri, Apr 21, 2023 at 10:56 AM Aleksander Alekseev
wrote:
> > Assuming this is the case perhaps we can reduce the scenario and
> > consider this simpler one:
> >
> > 1. The table is truncated
> > 2. The DBMS is killed before making a checkpoint
> > 3. We are in recovery and presumably see a pair
A couple of days ago, our PostGIS PG16 bots started failing with order
changes in text.
We have our tests set to locale=c
It seems since April 20th, our tests that rely on sorting characters
changed.
As noted in this ticket:
https://trac.osgeo.org/postgis/ticket/5375
I'm assuming it's result of
"Regina Obe" writes:
> A couple of days ago, our PostGIS PG16 bots started failing with order
> changes in text.
> We have our tests set to locale=c
> It seems since April 20th, our tests that rely on sorting characters
> changed.
> As noted in this ticket:
> https://trac.osgeo.org/postgis/ticke
Em sex, 21 de abr de 2023 9:10 AM, David Rowley
escreveu:
> On Fri, 21 Apr 2023 at 23:16, Ranier Vilela wrote:
> > Perhaps list_delete_nth_cell needs to check NIL too?
> > + if (list == NIL)
> > + return NIL;
>
> Which cell would you be deleting from an empty list?
>
None.
But list_delete_nth_ce
On Fri, 2023-04-21 at 11:27 -0400, Regina Obe wrote:
> A couple of days ago, our PostGIS PG16 bots started failing with
> order
> changes in text.
> We have our tests set to locale=c
Are you sure it's still using the C locale? The results seem to be
explainable if the locale switched from "C" to "
On Fri, Apr 21, 2023 at 7:47 AM Robert Haas wrote:
>
> On Fri, Apr 21, 2023 at 8:25 AM Daniel Gustafsson wrote:
> > The reason I left it like this when reviewing and committing is that I
> > think it
> > makes for more readable code. The amount of lines saved is pretty small,
> > and
> > "shuf
On 20.04.23 17:33, Andres Freund wrote:
Peter, it's unlikely given the timeframe, but do you happen to remember why
you specified -x when stripping static libs? This seems to be all the way back
from
commit 563673e15db995b6f531b44be7bb162330ac157a
Author: Peter Eisentraut
Date: 2002-04-10 16:4
On 21.04.23 18:41, Peter Eisentraut wrote:
On 20.04.23 17:33, Andres Freund wrote:
Peter, it's unlikely given the timeframe, but do you happen to
remember why
you specified -x when stripping static libs? This seems to be all the
way back
from
commit 563673e15db995b6f531b44be7bb162330ac157a
Au
On Fri, Apr 21, 2023 at 9:50 AM Tom Lane wrote:
>
> Jehan-Guillaume de Rorthais writes:
> > After catching up with this thread, where pending bugs are listed and
> > discussed,
> > I wonder if the current patches trying to lower the HashJoin memory
> > explosion[1]
> > could be added to the "Ol
On 21.04.23 09:34, Richard Guo wrote:
There was discussion in [1] about improvements to list manipulation in
several places. But since the discussion is not related to the topic in
that thread, fork a new thread here and attach a patch to show my
thoughts.
Some are just cosmetic changes by usin
On Fri, Apr 21, 2023 at 12:55 AM Daniel Gustafsson wrote:
> This has been done and the open item marked as completed.
Thanks! Now that the weirdness is handled by the tests, I think we can
remove the Cirrus workaround. Something like the attached, which
passes the macOS Meson suite for me.
--Jac
On 21.04.23 16:28, Imseih (AWS), Sami wrote:
I recently noticed the following in the work_mem [1] documentation:
“Note that for a complex query, several sort or hash operations might be
running in parallel;”
The use of “parallel” here is misleading as this has nothing to do with
parallel que
Peter Eisentraut writes:
> On 20.04.23 17:33, Andres Freund wrote:
>> Peter, it's unlikely given the timeframe, but do you happen to remember why
>> you specified -x when stripping static libs?
> I suspect this was copied from GNU Libtool. Libtool still has that but
> later changed the strippin
On Fri, Apr 21, 2023 at 11:48:51AM -0400, Tom Lane wrote:
> "Regina Obe" writes:
>
> > https://trac.osgeo.org/postgis/ticket/5375
>
> If they actually are using locale C, I would say this is a bug.
> That should designate memcmp sorting and nothing else.
Sounds like a bug to me. This is happeni
On 19.04.23 14:37, Thom Brown wrote:
I've attached a patch that removes some now redundant messaging about
unsupported versions.
The text in pg_basebackup.sgml describes behavior that still exists in
pg_basebackup. As long as that behavior exists, we should document it
accurately.
On 21.04.23 19:00, Tom Lane wrote:
Peter Eisentraut writes:
On 20.04.23 17:33, Andres Freund wrote:
Peter, it's unlikely given the timeframe, but do you happen to remember why
you specified -x when stripping static libs?
I suspect this was copied from GNU Libtool. Libtool still has that bu
On Fri, Apr 21, 2023 at 12:49 PM Melanie Plageman
wrote:
> If using a separate memory context solely for the purpose of accounting
> is considered an anti-pattern, ...
This thread isn't the right place to argue about the merits of that
patch, at least IMHO, but I don't think that's an anti-patter
On 21.04.23 19:09, Sandro Santilli wrote:
On Fri, Apr 21, 2023 at 11:48:51AM -0400, Tom Lane wrote:
"Regina Obe" writes:
https://trac.osgeo.org/postgis/ticket/5375
If they actually are using locale C, I would say this is a bug.
That should designate memcmp sorting and nothing else.
Sounds
Peter Eisentraut writes:
> On 21.04.23 16:28, Imseih (AWS), Sami wrote:
>> I suggest a small doc fix:
>> “Note that for a complex query, several sort or hash operations might be
>> running simultaneously;”
> Here is a discussion of these terms:
> https://takuti.me/note/parallel-vs-concurrent/
On Fri, 2023-04-21 at 19:09 +0200, Sandro Santilli wrote:
> =# select version();
> PostgreSQL 16devel on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu
> 11.3.0-1ubuntu1~22.04) 11.3.0, 64-bit
> =# show lc_collate;
> C
> =# select '+' < '-';
> f
What is the result of:
select datlocprov
Peter Eisentraut writes:
> If the database is created with locale provider ICU, then lc_collate
> does not apply here, so the result might be correct (depending on what
> locale you have set).
FWIW, an installation created under LANG=C defaults to ICU locale
en-US-u-va-posix for me (see psql \l
Peter Eisentraut writes:
> On 21.04.23 19:00, Tom Lane wrote:
>> If you use both -x and -S, you get the same file sizes as with -x
>> alone. Not sure why we should change anything here.
> The complaint was that -x doesn't work correctly, no?
The complaint was that it doesn't work correctly if y
> Peter Eisentraut writes:
> > If the database is created with locale provider ICU, then lc_collate
> > does not apply here, so the result might be correct (depending on what
> > locale you have set).
>
> FWIW, an installation created under LANG=C defaults to ICU locale en-US-u-
> va-posix for me
On Fri, Apr 21, 2023 at 10:15 AM Tom Lane wrote:
>
> Peter Eisentraut writes:
> > On 21.04.23 16:28, Imseih (AWS), Sami wrote:
> >> I suggest a small doc fix:
> >> “Note that for a complex query, several sort or hash operations might be
> >> running simultaneously;”
>
> > Here is a discussion of
Robert Haas writes:
> On Fri, Apr 21, 2023 at 12:49 PM Melanie Plageman
> wrote:
>> If using a separate memory context solely for the purpose of accounting
>> is considered an anti-pattern, ...
> This thread isn't the right place to argue about the merits of that
> patch, at least IMHO, but I do
"Regina Obe" writes:
> On my mingw64 setup, I built a test database on PG16 (built with icu
> support) and PG15 (no icu support)
> CREATE DATABASE test TEMPLATE=template0 ENCODING = 'UTF8' LC_COLLATE = 'C'
> LC_CTYPE = 'C';
As has been pointed out already, setting LC_COLLATE/LC_CTYPE is
meaningl
> > CREATE DATABASE test TEMPLATE=template0 ENCODING = 'UTF8'
> LC_COLLATE = 'C'
> > LC_CTYPE = 'C';
>
> As has been pointed out already, setting LC_COLLATE/LC_CTYPE is
> meaningless when the locale provider is ICU. You need to look at what ICU
> locale is being chosen, or force it with LOCALE =
"Regina Obe" writes:
> Okay got it was on IRC with RhodiumToad and he suggested:
> CREATE DATABASE test2 TEMPLATE=template0 ENCODING = 'UTF8' LC_COLLATE = 'C'
> LC_CTYPE = 'C' ICU_LOCALE='C';
> Which gives expected result:
> SELECT '+' < '-' ; -- true
> but gives me a notice:
> NOTICE: usi
> "Peter" == Peter Eisentraut writes:
Peter> If the database is created with locale provider ICU, then
Peter> lc_collate does not apply here,
Having lc_collate return a value which is silently being ignored seems
to me rather hugely confusing.
Also, somewhere along the line someone broke
Andrew Gierth writes:
> "Peter" == Peter Eisentraut writes:
> Peter> If the database is created with locale provider ICU, then
> Peter> lc_collate does not apply here,
> Having lc_collate return a value which is silently being ignored seems
> to me rather hugely confusing.
It's not *completel
> Yeah. My recommendation is just LOCALE:
>
> regression=# CREATE DATABASE test1 TEMPLATE=template0 ENCODING =
> 'UTF8' LOCALE = 'C'; CREATE DATABASE regression=# CREATE DATABASE test2
> TEMPLATE=template0 ENCODING = 'UTF8' ICU_LOCALE = 'C';
> NOTICE: using standard form "en-US-u-va-posix" for l
"Regina Obe" writes:
> CREATE DATABASE test1 TEMPLATE=template0 ENCODING = 'UTF8' LOCALE = 'C';
> Doesn't seem to work at least not under mingw64 anyway.
Hmm, doesn't work for me either:
$ LANG=en_US.utf8 initdb
The files belonging to this database system will be owned by user "postgres".
This u
On Fri, Apr 21, 2023 at 07:14:13PM +0200, Peter Eisentraut wrote:
> On 21.04.23 19:09, Sandro Santilli wrote:
> > On Fri, Apr 21, 2023 at 11:48:51AM -0400, Tom Lane wrote:
> > > "Regina Obe" writes:
> > >
> > > > https://trac.osgeo.org/postgis/ticket/5375
> > >
> > > If they actually are using l
> "Tom" == Tom Lane writes:
>> Also, somewhere along the line someone broke initdb --no-locale,
>> which should result in C locale being the default everywhere, but
>> when I just tested it it picked 'en' for an ICU locale, which is not
>> the right thing.
Tom> Confirmed:
Tom> $ LANG=
On Fri, Apr 21, 2023 at 10:27:49AM -0700, Jeff Davis wrote:
> On Fri, 2023-04-21 at 19:09 +0200, Sandro Santilli wrote:
> > =# select version();
> > PostgreSQL 16devel on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu
> > 11.3.0-1ubuntu1~22.04) 11.3.0, 64-bit
> > =# show lc_collate;
> > C
> >
On 21.04.2023 1:51 AM, Melanie Plageman wrote:
On Thu, Apr 20, 2023 at 12:42 PM Konstantin Knizhnik wrote:
On 11.04.2023 8:14 PM, Jehan-Guillaume de Rorthais wrote:
On Sat, 8 Apr 2023 02:01:19 +0200
Jehan-Guillaume de Rorthais wrote:
On Fri, 31 Mar 2023 14:06:11 +0200
Jehan-Guillaume de R
On Fri, 2023-04-21 at 14:23 -0400, Tom Lane wrote:
> postgres=# CREATE DATABASE test1 TEMPLATE=template0 ENCODING = 'UTF8'
> LOCALE = 'C';
...
> test1 | postgres | UTF8 | icu | C |
> C | en-US | |
> (4 rows)
>
> Looks like the "pick en-US ev
I checked the commit log.
About 001_basic.pl, it had been added at 2017 once but been reverted soon
[1][2].
322bec added the file again at 2022[3], so I chose 2022.
About 002_pg_upgrade.pl, it has been added at the same time[3].
Definitively it should be 2022.
It is great to make sure each
Jeff Davis writes:
> I have a couple ideas:
> 1. Introduce a "none" provider to separate the concept of C/POSIX
> locales from the libc provider. It's not really using a provider
> anyway, it's just using memcmp(), and I think it causes confusion to
> combine them. Saying "LOCALE_PROVIDER=none" i
On Fri, 2023-04-21 at 21:14 +0200, Sandro Santilli wrote:
> And then runs:
>
> createdb --encoding=UTF-8 --template=template0 --lc-collate=C
>
> Should we tweak anything else to make the results predictable ?
You can specify --locale-provider=libc
Regards,
Jeff Davis
On Fri, 2023-04-21 at 13:28 -0400, Tom Lane wrote:
> I am wondering however whether this doesn't mean that all our
> carefully
> coded fast paths for C locale just went down the drain.
The code still exists. You can test it by using the built-in collation
"C" which is correctly specified with coll
On Fri, Apr 21, 2023 at 08:10:56PM +0900, Amit Langote wrote:
> On Fri, Apr 21, 2023 at 17:52 Masahiko Sawada wrote:
>> Thank you and everyone for the wishes! Congratulations to the other
>> new committers.
>
> +1, thank you core team for the opportunity.
>
> Thank you all for the wishes.
Than
On Fri, Apr 21, 2023 at 01:50:34PM +0700, John Naylor wrote:
> On Wed, Mar 8, 2023 at 7:25 AM Nathan Bossart
> wrote:
>> was mostly a fun weekend project, and I don't presently have any concrete
>> examples of workloads where this might help.
>
> It seems like that should be demonstrated before s
On Fri, Apr 21, 2023 at 3:25 PM Jeff Davis wrote:
> I am also having second thoughts about accepting "C" or "POSIX" as an
> ICU locale and transforming it to "en-US-u-va-posix" in v16. It's not
> terribly useful (why not just use memcmp()?), it's not fast in my
> measurements (en-US is faster), so
On Fri, Apr 21, 2023 at 10:49:48AM +0200, Daniel Gustafsson wrote:
> On 21 Apr 2023, at 01:32, Nathan Bossart wrote:
>> I am -0.5 for this. If you are writing a new background worker, it's
>> probably reasonable to expect that you can locate the definition of
>> BGW_MAXLEN.
>
> Of course. The
On Fri, Apr 7, 2023 at 8:01 PM Jehan-Guillaume de Rorthais
wrote:
>
> On Fri, 31 Mar 2023 14:06:11 +0200
> Jehan-Guillaume de Rorthais wrote:
>
> > > [...]
> > > >> Hmmm, not sure is WARNING is a good approach, but I don't have a better
> > > >> idea at the moment.
> > > >
> > > > I stepped it do
On Fri, 2023-04-21 at 19:00 +0100, Andrew Gierth wrote:
> > > > >
> Also, somewhere along the line someone broke initdb --no-locale,
> which
> should result in C locale being the default everywhere, but when I
> just
> tested it it picked 'en' for an ICU locale, which is not the right
> thing.
Fi
On Fri, 2023-04-21 at 16:00 -0400, Tom Lane wrote:
> Maybe this means we are not ready to do ICU-by-default in v16.
> It certainly feels like there might be more here than we want to
> start designing post-feature-freeze.
I don't see how punting to the next release helps. If the CREATE
DATABASE sy
> "Jeff" == Jeff Davis writes:
>> Also, somewhere along the line someone broke initdb --no-locale,
>> which should result in C locale being the default everywhere, but
>> when I just tested it it picked 'en' for an ICU locale, which is not
>> the right thing.
Jeff> Fixed, thank you.
Is
Hi,
> > Oh, I see. If the process will be killed this perhaps is not going to
> > happen. Whether this can happen if we pull the plug from the machine
> > is probably a design implementation of the particular filesystem and
> > whether it's journaled.
>
> Right. I mentioned that scenario in the or
On Fri, 2023-04-21 at 22:08 +0100, Andrew Gierth wrote:
> > > > >
> Is that the right fix, though? (It forces --locale-provider=libc for
> the
> cluster default, which might not be desirable?)
For the "no locale" behavior (memcmp()-based) the provider needs to be
libc. Do you see an alternative?
> "Jeff" == Jeff Davis writes:
>> Is that the right fix, though? (It forces --locale-provider=libc for
>> the cluster default, which might not be desirable?)
Jeff> For the "no locale" behavior (memcmp()-based) the provider needs
Jeff> to be libc. Do you see an alternative?
Can lc_collat
On Fri, 2023-04-21 at 16:33 -0400, Robert Haas wrote:
> My opinion is that the switch to using ICU by default is ill-advised
> and should be reverted.
Most of the complaints seem to be complaints about v15 as well, and
while those complaints may be a reason to not make ICU the default,
they are a
Hi,
I find the inclusion of the un-parenthesized syntax for VACUUM, ANALYZE,
and EXPLAIN in the docs makes it harder to understand the preferred,
parenthesized syntax (see [1] as an example).
Over in [2], it was suggested that moving the un-parenthesized syntax to
the "Compatibility" section of t
> > My opinion is that the switch to using ICU by default is ill-advised
> > and should be reverted.
>
> Most of the complaints seem to be complaints about v15 as well, and while
> those complaints may be a reason to not make ICU the default, they are also
> an argument that we should continue to
On Fri, Apr 21, 2023 at 06:29:16PM -0400, Melanie Plageman wrote:
> Over in [2], it was suggested that moving the un-parenthesized syntax to
> the "Compatibility" section of their respective docs pages would be
> okay. Patch attached.
I think that's reasonable.
> I left out CLUSTER since that syn
1 - 100 of 109 matches
Mail list logo
