I've attached two patches. 0001 adds a parenthesized CLUSTER syntax that
doesn't require a table name. 0002 is your patch with a couple of small
adjustments.
On Fri, Apr 21, 2023 at 07:29:59PM -0400, Melanie Plageman wrote:
> Attached v2 includes changes for CLUSTER syntax docs. I wasn't quite
> > especially since the next sentence uses "concurrently" to describe the
> > other case. I think we need a more thorough rewording, perhaps like
> >
> > - Note that for a complex query, several sort or hash operations
> > might be
> > - running in parallel; each operation will
On Fri, Apr 21, 2023 at 5:56 PM Jeff Davis wrote:
> 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 learn and try to
> fix those issues because they
Attached is a proof-of-concept/work-in-progress patch set that adds
functions for "vectors" repreѕented with one-dimensional float8 arrays.
These functions may be used in a variety of applications, but I am
proposing them with the AI/ML use-cases in mind. I am posting this early
in the v17 cycle
On Fri, Apr 21, 2023 at 07:29:59PM -0400, Melanie Plageman wrote:
> Attached v2 includes changes for CLUSTER syntax docs. I wasn't quite
> sure that we can move down CLUSTER [VERBOSE] syntax to the compatibility
> section since CLUSTER (VERBOSE) doesn't work. This seems like it should
> work
On Fri, Apr 21, 2023 at 6:55 PM Nathan Bossart wrote:
>
> 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
Ajit Awekar writes:
> I have implemented the approach by splitting the hash table into two parts.
> Please find the attached patch for the same.
I found a few things not to like about this:
* You didn't update the comment describing these hash tables.
* I wasn't really thrilled about renaming
On Wed, Mar 01, 2023 at 03:13:04PM -0800, Andres Freund wrote:
> On 2023-03-01 14:47:51 -0800, Nathan Bossart wrote:
>> Here is an attempt at adding a signal safe function for writing to STDERR.
>
> Cool.
I'm gently bumping this thread to see if anyone had additional feedback on
the proposed
On Fri, 2023-04-21 at 16:33 -0400, Robert Haas wrote:
> And the fact that "C" or "POSIX" gets transformed into
> "en-US-u-va-posix"
I already expressed, on reflection, that we should probably just not do
that. So I think we're in agreement on this point; patch attached.
Regards,
Jeff
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
> > 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
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
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
> "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
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?
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
> "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.
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
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.
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
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.
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),
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
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.
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
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
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 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
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
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
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
>
> "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> $
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
"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
> 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
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
> "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
"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:
> > 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:
> 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
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
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
> 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
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
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
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
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 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.
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
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
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 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
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
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
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.
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
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
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
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
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
> >
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
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
"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:
>
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
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
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
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
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
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
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
>
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
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
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
> 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
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
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+:
> > >
> > >
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 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
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:
> >
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:
> > >
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
> 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
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
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
> 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'
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
> 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
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:
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:
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,
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
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
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 //
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
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
> 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
>
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
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 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
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
1 - 100 of 113 matches
Mail list logo
