On Mon, Jun 17, 2024 at 10:07 PM Markus Winand wrote:
> > On 17.06.2024, at 08:20, Amit Langote wrote:
> >>> 2. EMPTY [ARRAY|OBJECT] ON ERROR implies ERROR ON EMPTY
> >>>
> >>> 17beta1=# SELECT JSON_QUERY('[]', '$[*]' EMPTY ARRAY ON ERROR) a;
> >>>a
> >>>
> >>>[]
> >>> (1 row)
On Thu, Jun 13, 2024 at 5:04 PM Amit Langote wrote:
> On Thu, Jun 6, 2024 at 6:20 PM Amit Langote wrote:
> >
> > Hi,
> >
> > Alvaro reported off-list that the following should really fail,
> > because the jsonpath expression refers to a PASSING variable that
> > doesn't exist:
> >
> > select json
> On Jun 18, 2024, at 20:42, Melanie Plageman wrote:
>
> External Email
>
> On Mon, Jun 17, 2024 at 9:12 PM Li, Yong wrote:
>>
>> As a newcomer, when I was walking through the code looking for WAL replay
>> related code, it was relatively easy for me to find them for the B-Tree
>> access m
On Tue, Jun 11, 2024 at 3:12 PM Ashutosh Bapat
wrote:
>
> On Sat, Jun 8, 2024 at 3:52 PM Amit Kapila wrote:
>>
>> On Fri, Jun 7, 2024 at 5:39 PM Ashutosh Bapat
>> wrote:
>> >
>> > On Thu, Jun 6, 2024 at 5:16 PM Nisha Moond
>> > wrote:
>> >>
>> >> >
>> >>
>> >> Here are more use cases of the "e
On Tuesday, June 18, 2024, Tom Lane wrote:
> Yugo NAGATA writes:
> > On Tue, 18 Jun 2024 20:56:58 -0700
> > "David G. Johnston" wrote:
> >> But it is neither a keyword nor an identifier.
>
> The lexer would be quite surprised by your claim that NULL isn't
> a keyword. Per src/include/parser/kw
On Tue, Jun 18, 2024 at 7:44 AM Zhijie Hou (Fujitsu)
wrote:
>
> On Thursday, June 13, 2024 2:11 PM Masahiko Sawada
> wrote:
>
> Hi,
>
> > On Wed, Jun 5, 2024 at 3:32 PM Zhijie Hou (Fujitsu)
> > wrote:
> > >
> > > This time at PGconf.dev[1], we had some discussions regarding this
> > > project.
Yugo NAGATA writes:
> On Tue, 18 Jun 2024 20:56:58 -0700
> "David G. Johnston" wrote:
>> But it is neither a keyword nor an identifier.
The lexer would be quite surprised by your claim that NULL isn't
a keyword. Per src/include/parser/kwlist.h, NULL is a keyword,
and a fully reserved one at tha
On Tue, Jun 11, 2024 at 4:21 AM John H wrote:
>
> Building on bf279ddd1c, this patch introduces a GUC
> 'standby_slot_names_from_syncrep' which allows logical failover slots
> to wait for changes to have been synchronously replicated before sending
> the decoded changes to logical subscribers.
>
>
On Tue, 18 Jun 2024 20:56:58 -0700
"David G. Johnston" wrote:
> On Tue, Jun 18, 2024 at 8:34 PM Yugo NAGATA wrote:
>
> >
> > It may be a trivial thing but I am not sure we need to mention case
> > insensitivity
> > here, because all keywords and unquoted identifiers are case-insensitive in
> >
Dear Horiguchi-san,
Thanks for sharing the patch! I agree this approach (ensure WAL records are
flushed)
Is more proper than others.
I have an unclear point. According to the comment atop GetInsertRecPtr(), it
just
returns the approximated value - the position of the last full WAL page [1].
If
Richard Guo writes:
> On Mon, Jun 17, 2024 at 10:51 PM Alexander Pyhalov
> wrote:
>> ERROR: could not find commutator for operator XXX
> It seems to me that the new operator is somewhat artificial, since it is
> designed to support a mergejoin but lacks a valid commutator. So before
> we proce
On Wed, Jun 19, 2024 at 6:46 AM Peter Smith wrote:
>
> On Tue, Jun 18, 2024 at 9:40 PM Amit Kapila wrote:
> >
> > On Tue, Jun 18, 2024 at 12:11 PM Peter Smith wrote:
> > >
> > > While reviewing another thread that proposes to include "generated
> > > columns" support for logical replication [1]
On Mon, Jun 17, 2024 at 10:51 PM Alexander Pyhalov
wrote:
> There's the following inconsistency between try_mergejoin_path() and
> create_mergejoin_plan().
> When clause operator has no commutator, we can end up with mergejoin
> path.
> Later create_mergejoin_plan() will call get_switched_clauses(
On Tue, Jun 18, 2024 at 8:34 PM Yugo NAGATA wrote:
>
> It may be a trivial thing but I am not sure we need to mention case
> insensitivity
> here, because all keywords and unquoted identifiers are case-insensitive in
> PostgreSQL and it is not specific to NULL.
>
But it is neither a keyword nor
On Tue, Jun 18, 2024 at 12:13 PM Peter Eisentraut wrote:
>
> On 18.06.24 05:59, Amit Kapila wrote:
> >> 1. After promotion, the pre-existing replication objects should be
> >> removed (either optionally or always), otherwise, it can lead to a new
> >> subscriber not being able to restart or gettin
On Tue, Jun 18, 2024 at 12:41 PM Euler Taveira wrote:
>
> On Tue, Jun 18, 2024, at 12:59 AM, Amit Kapila wrote:
>
> On Mon, May 20, 2024 at 12:12 PM Amit Kapila wrote:
> >
> > On Sun, May 19, 2024 at 11:20 PM Euler Taveira wrote:
> > >
> > > On Sun, May 19, 2024, at 2:30 PM, Tom Lane wrote:
> >
On Sat, 11 May 2024 08:33:27 -0700
"David G. Johnston" wrote:
> On Fri, May 3, 2024 at 9:00 AM David G. Johnston
> wrote:
>
> > On Fri, May 3, 2024 at 8:44 AM Tom Lane wrote:
> >
> >> Having said that, I reiterate my proposal that we make it a new
> >>
> > under DDL, before 5.2 Default Values
Hi,
On Wed, Jun 19, 2024 at 6:06 AM John H wrote:
>
> Hi Ashutosh,
>
> Thanks for clarifying.
>
> > not standalone functions created independently
>
> I'm wondering why we wouldn't want to extend that functionality so
> that if users (including superusers) do want to automatically
> configure sea
Hi,
On 2024-06-18 12:00:13 -0700, Andres Freund wrote:
> On 2024-06-18 10:10:17 -0700, Noah Misch wrote:
> > > 1) Sometimes hangs hard on windows if started processes have not been shut
> > >down before script exits. I've mostly encountered this via the
> > > buildfarm /
> > >CI, so I ne
Richard Guo 于2024年6月18日周二 17:24写道：
> On Tue, Jun 4, 2024 at 6:51 PM Tender Wang wrote:
> > Yeah, Richard commented the v1 patch about JOIN_UNIQUE_INNER in [1]
> >
> > * I think we should not consider materializing the cheapest inner path
> > if we're doing JOIN_UNIQUE_INNER, because in this case
If I am reading your patch correctly, we have lost the behavior of least
surprise in which the first "meta" argument overrides all others:
$ bin/postgres --version --boot --extrastuff
postgres (PostgreSQL) 16.2
What about just inlining --version and --help e.g.
else if (strcmp(argv[i], "--versio
On Tue, Jun 18, 2024 at 4:14 PM Pavel Borisov wrote:
>> Controls if the query planner will produce a plan which will provide
>> GROUP BY keys presorted in the order of keys of a child
>> node of the plan, such as an index scan. When disabled, the query planner
>> will produce a plan with GROUP
On Tue, Jun 18, 2024 at 8:49 PM Masahiko Sawada wrote:
> > At least I couldn't find anywhere in the docs where we have
> > described the relationship between these columns before. Thoughts?
>
> It would be a good idea to improve the documentation, but I think that
> we cannot simply compare these
On Tue, Jun 18, 2024 at 9:40 PM Amit Kapila wrote:
>
> On Tue, Jun 18, 2024 at 12:11 PM Peter Smith wrote:
> >
> > While reviewing another thread that proposes to include "generated
> > columns" support for logical replication [1] I was looking for any
> > existing PostgreSQL documentation on thi
On Sat, Jun 15, 2024 at 8:47 PM Robert Treat wrote:
>
> On Thu, Jun 13, 2024 at 9:22 PM Masahiko Sawada wrote:
> > On Fri, Jun 14, 2024 at 9:57 AM Masahiko Sawada
> > wrote:
> > > On Fri, Jun 14, 2024 at 9:41 AM Michael Paquier
> > > wrote:
> > > > On Thu, Jun 13, 2024 at 08:38:05PM -0400, To
On Tue, Jun 18, 2024 at 02:33:31PM -0700, Andres Freund wrote:
> Another one:
>
> Have a general cap of 64, but additionally limit it to something like
> max(1, min(WORKER_CAP, max_connections / 4))
>
> so that cases like tap tests don't end up allocating vastly more worker slots
> than actu
Hi Ashutosh,
Thanks for clarifying.
> not standalone functions created independently
I'm wondering why we wouldn't want to extend that functionality so
that if users (including superusers) do want to automatically
configure search_path
when they're creating functions it's available.
> The diff
On 03/06/2024 21:21, David E. Wheeler wrote:
On Jun 3, 2024, at 14:58, Andres Freund wrote:
Hi,
Hello Andres.
Are there notes for the session?
Yes, but not posted yet. Here’s what Andreas 'ads' Scherbaum sent me for that
bit of the conversation:
* Core is focused on core ABI stability
On Tue, 18 Jun 2024 at 15:14, Richard Guo wrote:
>
> On Tue, Jun 18, 2024 at 10:53 AM David Rowley wrote:
> > I think the best solution is to apply the attached. I didn't test,
> > but it should fix the issue you reported and also ensure that
> > MemoizePath.calls is never zero, which would also
Hi,
On 2024-06-18 16:09:09 -0500, Nathan Bossart wrote:
> On Tue, Jun 18, 2024 at 01:43:34PM -0700, Andres Freund wrote:
> > I just don't see much point in reserving 256 worker "possibilities", tbh. I
> > can't think of any practical system where it makes sense to use this much
> > (nor
> > do I
Hi,
On 2024-06-18 08:36:57 -0500, Justin Pryzby wrote:
> On Fri, Jun 14, 2024 at 08:34:37AM -0700, Andres Freund wrote:
> > Hm. There actually already is the mingw ccache installed. The images for
> > mingw and msvc used to be separate (for startup performance when using
> > containers), but we
On Tue, Jun 18, 2024 at 01:32:38PM -0700, Andres Freund wrote:
> On 2024-06-18 13:50:46 -0500, Nathan Bossart wrote:
>> Have we ruled out further adjustments to the cost parameters as a first
>> step?
>
> I'm not against that, but I it doesn't address the issue that with the current
> logic one se
On Tue, Jun 18, 2024 at 01:43:34PM -0700, Andres Freund wrote:
> I just don't see much point in reserving 256 worker "possibilities", tbh. I
> can't think of any practical system where it makes sense to use this much (nor
> do I think it's going to be reasonable in the next 10 years) and it's just
Andres Freund writes:
> I wonder if there's an argument the "persistent" TopTransactionContext should
> live under a different name outside of transactions, to avoid references to it
> working in a context where it's not valid? It's probably not worth it, but
> not sure.
Hm. We could stash the
Hi,
On 2024-06-18 14:00:00 -0500, Nathan Bossart wrote:
> On Mon, Jun 03, 2024 at 04:24:27PM -0700, Andres Freund wrote:
> > On 2024-06-03 14:28:13 -0500, Nathan Bossart wrote:
> >> On Mon, Jun 03, 2024 at 12:08:52PM -0700, Andres Freund wrote:
> >> > Why do we think that increasing the number of
On 2024-06-18 Tu 3:00 PM, Andres Freund wrote:
Hi,
On 2024-06-18 10:10:17 -0700, Noah Misch wrote:
On Mon, Jun 17, 2024 at 11:11:17AM -0700, Andres Freund wrote:
On 2024-06-15 16:48:24 -0700, Noah Misch wrote:
On Sat, Jun 15, 2024 at 01:26:57PM -0400, Robert Haas wrote:
The one
thing I know
Hi,
On 2024-06-18 13:50:46 -0500, Nathan Bossart wrote:
> Have we ruled out further adjustments to the cost parameters as a first
> step?
I'm not against that, but I it doesn't address the issue that with the current
logic one set of values just isn't going to fit a 60MB that's allowed to burst
t
Hi,
On 2024-06-18 15:28:03 -0400, Tom Lane wrote:
> After awhile I had an epiphany: what we should do is make
> CommitTransactionCommand restore the memory context that was active
> before StartTransactionCommand. That's what we want in every place
> that was cognizant of this issue, and it seems
> On 18 Jun 2024, at 21:50, Nathan Bossart wrote:
>
> I noticed that the "check" variable, which is used for "pg_upgrade
> --check", is commented as follows:
>
> bool check; /* true -> ask user for permission to make
> * changes */
>
> This comment was first added when pg_upgrade was introduced
I noticed that the "check" variable, which is used for "pg_upgrade
--check", is commented as follows:
boolcheck; /* true -> ask user for
permission to make
* changes */
This comment was first ad
David Rowley writes:
> On Tue, 18 Jun 2024 at 16:53, Tom Lane wrote:
>> I'll poke at this tomorrow, unless you're hot to try it right now.
> Please go ahead. I was just in suggestion mode here.
So I tried that, and while it kind of worked, certain parts of the
system (notably logical replicatio
Hi,
On 2024-06-18 10:10:17 -0700, Noah Misch wrote:
> On Mon, Jun 17, 2024 at 11:11:17AM -0700, Andres Freund wrote:
> > On 2024-06-15 16:48:24 -0700, Noah Misch wrote:
> > > On Sat, Jun 15, 2024 at 01:26:57PM -0400, Robert Haas wrote:
> > > > The one
> > > > thing I know about that *I* think is a
On Mon, Jun 03, 2024 at 04:24:27PM -0700, Andres Freund wrote:
> On 2024-06-03 14:28:13 -0500, Nathan Bossart wrote:
>> On Mon, Jun 03, 2024 at 12:08:52PM -0700, Andres Freund wrote:
>> > Why do we think that increasing the number of PGPROC slots, heavyweight
>> > locks
>> > etc by 256 isn't going
On Mon, Jun 17, 2024 at 03:39:27PM -0400, Robert Haas wrote:
> I think we might able to get fairly far by observing that if the
> number of running autovacuum workers is equal to the maximum allowable
> number of running autovacuum workers, that may be a sign of trouble,
> and the longer that situa
On Tue, Jun 18, 2024 at 08:23:49AM -0700, Noah Misch wrote:
> On Mon, Jun 17, 2024 at 06:57:30PM -0700, Andres Freund wrote:
> > On 2024-06-17 16:58:54 -0700, Noah Misch wrote:
> > > On Sat, Jun 15, 2024 at 03:37:18PM -0700, Noah Misch wrote:
> > > > On Wed, May 22, 2024 at 05:05:48PM -0700, Noah M
On Tue, Jun 18, 2024 at 01:20:50PM -0400, Bruce Momjian wrote:
> On Tue, Jun 18, 2024 at 05:14:08PM +, Amonson, Paul D wrote:
> > > And this bit doesn't look good. The LICENSE file says:
> > ...
> > > > //* Redistributions in binary form must reproduce the above
> > > > // copyright notice
On Tue, Jun 18, 2024 at 05:14:08PM +, Amonson, Paul D wrote:
> > And this bit doesn't look good. The LICENSE file says:
> ...
> > > //* Redistributions in binary form must reproduce the above
> > > // copyright notice, this list of conditions and the following
> > > disclaimer // in the do
> Hmm, I wonder if the "(c) 2024 Intel" line is going to bring us trouble.
> (I bet it's not really necessary anyway.)
Our lawyer agrees, copyright is covered by the "PostgreSQL Global Development
Group" copyright line as a contributor.
> And this bit doesn't look good. The LICENSE file says:
.
On Mon, Jun 17, 2024 at 11:11:17AM -0700, Andres Freund wrote:
> On 2024-06-15 16:48:24 -0700, Noah Misch wrote:
> > On Sat, Jun 15, 2024 at 01:26:57PM -0400, Robert Haas wrote:
> > > The one
> > > thing I know about that *I* think is a pretty big problem about Perl
> > > is that IPC::Run is not re
On Mon, Jun 17, 2024 at 02:10:22PM -0400, Robert Haas wrote:
> On Thu, Jun 13, 2024 at 3:48â¯PM Nathan Bossart
> wrote:
>> I think we could improve matters by abandoning the table and instead
>> documenting these roles more like we document GUCs, i.e., each one has a
>> section below it where we
On Mon, 2024-06-17 at 16:40 -0500, Justin Pryzby wrote:
> > The feature will become much less useful if unique voilations keep getting
> > logged.
>
> Uh, to be clear, your patch is changing the *defaults*, which I found
> surprising, even after reaading the thread. Evidently, the current
> beha
Hi.
Now when planner finds suitable pathkeys in
generate_orderedappend_paths(), it uses them, even if explicit sort of
the cheapest child path could be more efficient.
We encountered this issue on partitioned table with two indexes, where
one is suitable for sorting, and another is good for
On Tue, Jun 18, 2024 at 12:10:50PM -0400, Jonathan Katz wrote:
>
> Hi,
>
> PostgreSQL 17 Beta 2 is planned to be release on June 27, 2024. Please
> continue your hard work on closing out open items[1] ahead of the release
> and have the fixes targeted for the release committed by June 22, 2024.
Hi,
PostgreSQL 17 Beta 2 is planned to be release on June 27, 2024. Please
continue your hard work on closing out open items[1] ahead of the
release and have the fixes targeted for the release committed by June
22, 2024.
Thanks!
Jonathan
[1] https://wiki.postgresql.org/wiki/PostgreSQL_17_
Hi,
On 2024-06-18 15:54:27 +0100, Dave Page wrote:
> On Tue, 18 Jun 2024 at 15:38, Andres Freund wrote:
> > Do you have logs for those failures?
> >
>
> Sure - https://developer.pgadmin.org/~dpage/build-logs.zip. Those are all
> without any modifications to %LIB% or %INCLUDE%.
Thanks.
> > I t
On Tue, Jun 18, 2024 at 10:29 AM Maxim Orlov wrote:
> Maybe, I'm too bold, but looks like a kinda bug to me. At least, I don't
> understand why we do not check the HEAP_XMAX_INVALID flag.
> My guess is nobody noticed, that MultiXactIdIsValid call does not check the
> mentioned flag in the "firs
Hi,
On Tue, Jun 18, 2024 at 8:25 PM Tom Lane wrote:
>
> Ashutosh Sharma writes:
> > On Tue, Jun 18, 2024 at 7:50 PM Tom Lane wrote:
> >> I think the assertion you noticed is there because the code path gets
> >> traversed during REINDEX, which is an operation we do support on
> >> system catalo
On Mon, Jun 17, 2024 at 06:57:30PM -0700, Andres Freund wrote:
> On 2024-06-17 16:58:54 -0700, Noah Misch wrote:
> > On Sat, Jun 15, 2024 at 03:37:18PM -0700, Noah Misch wrote:
> > > On Wed, May 22, 2024 at 05:05:48PM -0700, Noah Misch wrote:
> > > > https://postgr.es/m/20240512232923.aa.nmi...@goo
Hi Robert, Andres, Tom,
Thank you for sharing your thoughts.
On Tue, Jun 18, 2024 at 8:02 PM Andres Freund wrote:
>
> Hi,
>
> On 2024-06-18 19:58:26 +0530, Ashutosh Sharma wrote:
> > On Tue, Jun 18, 2024 at 7:50 PM Tom Lane wrote:
> > >
> > > Robert Haas writes:
> > > > On Tue, Jun 18, 2024 at
I plan to send patch to pg_test_timing in a day or two
the underlying time precision on modern linux seems to be
2 ns for some Intel CPUs
10 ns for Zen4
40 ns for ARM (Ampere)
---
Hannu
|
On Tue, Jun 18, 2024 at 7:48 AM Andrey M. Borodin
wrote:
>
>
> > On 19 Mar 2024, at 13:28, Peter Ei
Hi,
+many for doing this in principle
> -const char *EAN13_range[][2] = {
> +static const char *EAN13_range[][2] = {
> {"000", "019"}, /* GS1 US */
> {"020", "029"}, /* Restricted distribution (MO
> defined) */
> {"030", "039"},
Ashutosh Sharma writes:
> On Tue, Jun 18, 2024 at 7:50 PM Tom Lane wrote:
>> I think the assertion you noticed is there because the code path gets
>> traversed during REINDEX, which is an operation we do support on
>> system catalogs. I have zero interest in making truncate work
>> on them.
> I
Hi
On Tue, 18 Jun 2024 at 15:38, Andres Freund wrote:
> Hi,
>
> On 2024-06-18 14:53:53 +0100, Dave Page wrote:
> > My next task was to extend that to support PostgreSQL 17 and beyond,
> which
> > is where I started to run into problems. I've attempted builds using
> Meson
> > with each of the de
Hi,
On 2024-06-18 14:53:53 +0100, Dave Page wrote:
> My next task was to extend that to support PostgreSQL 17 and beyond, which
> is where I started to run into problems. I've attempted builds using Meson
> with each of the dependencies defined in the old-style config.pl, both with
> and without m
On Fri, Jun 14, 2024 at 8:49 AM Tom Lane wrote:
> I think that's an oversimplified analysis. Sure, the languages are
> both Turing-complete, but for our purposes here they are both simply
> glue languages around some set of testing facilities. Some of those
> facilities will be provided by the b
(slowly catching up from the weekend email backlog)
On Fri, Jun 14, 2024 at 5:10 AM Robert Haas wrote:
> I mean, both Perl and Python are Turing-complete.
Tom responded to this better than I could have, but I don't think this
is a helpful statement. In fact I opened the unconference session with
Hi,
On 2024-06-18 19:58:26 +0530, Ashutosh Sharma wrote:
> On Tue, Jun 18, 2024 at 7:50 PM Tom Lane wrote:
> >
> > Robert Haas writes:
> > > On Tue, Jun 18, 2024 at 8:10 AM Ashutosh Sharma
> > > wrote:
> > >> Executing below commands:
> > >> -- set allow_system_table_mods TO on;
> > >> -- trun
11.01.2024 19:58, Yura Sokolov пишет:
Good day, hackers.
Here I am to suggest two small improvements to Point In Time Recovery.
First is ability to recover recovery-target-time with timestamp stored
in XLOG_RESTORE_POINT. Looks like historically this ability did exist
and were removed uninten
Hi,
On 2024-06-18 09:27:02 +0200, Peter Eisentraut wrote:
> The CompilerWarnings task on Cirrus CI does not catch warnings in C++ code.
> It tries to make warnings fatal by passing COPT='-Werror', but that does not
> apply to C++ compilations.
>
> I suggest that we just add COPT to CXXFLAGS as we
Hi!
Maybe, I'm too bold, but looks like a kinda bug to me. At least, I don't
understand why we do not check the HEAP_XMAX_INVALID flag.
My guess is nobody noticed, that MultiXactIdIsValid call does not check the
mentioned flag in the "first" condition, but it's all my speculation.
Does anyone kno
Hi,
On Tue, Jun 18, 2024 at 7:50 PM Tom Lane wrote:
>
> Robert Haas writes:
> > On Tue, Jun 18, 2024 at 8:10 AM Ashutosh Sharma
> > wrote:
> >> Executing below commands:
> >> -- set allow_system_table_mods TO on;
> >> -- truncate table pg_type;
>
> > If the operation isn't allowed without turn
On 18.06.24 16:08, Tom Lane wrote:
Peter Eisentraut writes:
The CompilerWarnings task on Cirrus CI does not catch warnings in C++
code. It tries to make warnings fatal by passing COPT='-Werror', but
that does not apply to C++ compilations.
I suggest that we just add COPT to CXXFLAGS as well.
On 18.06.24 04:35, Andres Freund wrote:
On 2024-06-17 23:52:54 +0200, Daniel Gustafsson wrote:
Since sqlca is, according to our docs, present in other database systems we
should probably keep it a 5-char array for portability reasons. Adding a
padding character should be fine though.
How abou
Robert Haas writes:
> On Tue, Jun 18, 2024 at 8:10 AM Ashutosh Sharma wrote:
>> Executing below commands:
>> -- set allow_system_table_mods TO on;
>> -- truncate table pg_type;
> If the operation isn't allowed without turning on
> allow_system_table_mods, that means that doing it is probably a b
On Tue, Jun 18, 2024 at 8:10 AM Ashutosh Sharma wrote:
> I've noticed that truncating mapped catalogs causes the server to
> crash due to an assertion failure. Here are the details:
>
> Executing below commands:
>
> -- set allow_system_table_mods TO on;
> -- truncate table pg_type;
If the operati
Hi,
On 2024-06-17 22:42:41 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2024-06-17 23:52:54 +0200, Daniel Gustafsson wrote:
> >> Since sqlca is, according to our docs, present in other database systems we
> >> should probably keep it a 5-char array for portability reasons. Adding a
> >>
Peter Eisentraut writes:
> The CompilerWarnings task on Cirrus CI does not catch warnings in C++
> code. It tries to make warnings fatal by passing COPT='-Werror', but
> that does not apply to C++ compilations.
> I suggest that we just add COPT to CXXFLAGS as well. I think passing
> -Werror i
Hi
Further to my previous report [1] about zlib detection not working with
Meson on Windows, I found it's similarly or entirely broken for the
majority of other dependencies, none of which are tested on the buildfarm
as far as I can see.
For convenience, I've put together a number of Github actio
On 06/18/24 08:30, Peter Eisentraut wrote:
> Are you saying we shouldn't allow .boolean() to be called on a JSON number?
>
> I would concur that that's what the spec says.
Or, if we want to extend the spec and allow .boolean() on a JSON number,
should it just check that the number is nonzero or z
On Fri, Jun 14, 2024 at 08:34:37AM -0700, Andres Freund wrote:
> Hm. There actually already is the mingw ccache installed. The images for
> mingw and msvc used to be separate (for startup performance when using
> containers), but we just merged them. So it might be easiest to just
> explicitly
>
> Controls if the query planner will produce a plan which will provide
> GROUP BY keys presorted in the order of keys of a child
> node of the plan, such as an index scan. When disabled, the query planner
> will produce a plan with GROUP BY keys only reordered to
> match
> the ORDER BY clause, if
> On 17 Jun 2024, at 19:38, Andres Freund wrote:
> Note the second to last paragraph: Because we use SSL_OP_NO_TICKET we trigger
> use of stateful tickets. Which afaict are never going to be useful, because we
> don't share the necessary state.
Nice catch, I learned something new today. I was u
Hi, Alexander!
On Tue, 18 Jun 2024 at 16:13, Alexander Korotkov
wrote:
> On Tue, Jun 18, 2024 at 9:14 AM Andrei Lepikhov wrote:
> > On 6/18/24 09:32, Bruce Momjian wrote:
> > > This commit added enable_group_by_reordering:
> > >
> > > commit 0452b461bc4
> > > Author: Alexander Korot
On Mon, Jun 17, 2024 at 9:12 PM Li, Yong wrote:
>
> As a newcomer, when I was walking through the code looking for WAL replay
> related code, it was relatively easy for me to find them for the B-Tree
> access method because of the “xlog” hint in the file names. It took me a
> while to find the
On 18.06.24 04:17, Chapman Flack wrote:
On 06/17/24 19:17, David E. Wheeler wrote:
[1]:
https://github.com/postgres/postgres/blob/82ed67a/src/backend/utils/adt/jsonpath_exec.c#L2058-L2059
Huh, I just saw something peculiar, skimming through the code:
https://github.com/postgres/postgres/blob
On Tue, Jun 18, 2024 at 9:14 AM Andrei Lepikhov wrote:
> On 6/18/24 09:32, Bruce Momjian wrote:
> > This commit added enable_group_by_reordering:
> >
> > commit 0452b461bc4
> > Author: Alexander Korotkov
> > Date: Sun Jan 21 22:21:36 2024 +0200
> > It mentions it was added as
Hi everyone,
I've noticed that truncating mapped catalogs causes the server to
crash due to an assertion failure. Here are the details:
Executing below commands:
-- set allow_system_table_mods TO on;
-- truncate table pg_type;
Results into a server crash with below backtrace:
...
#2 0x557
Sorry, I've just noticed that the letter is shown incorrectly. I rewrote
it below.
As I understand it, you talked about speeding up SeqScan by faster
re-searching through the use of a hash table. At the same time, we have
to build it before that, when there was the initial lookup tuples, right
I have this patch series that fixes up the types of the new incremental
JSON API a bit. Specifically, it uses "const" throughout so that the
top-level entry points such as pg_parse_json_incremental() can declare
their arguments as const char * instead of just char *. This just
works, it doesn
Em ter., 18 de jun. de 2024 às 04:18, Peter Eisentraut
escreveu:
> Under the topic of getting rid of thread-unsafe functions in the backend
> [0], here is a patch series to deal with strtok().
>
> Of course, strtok() is famously not thread-safe and can be replaced by
> strtok_r(). But it also ha
On Tue, Jun 18, 2024 at 12:11 PM Peter Smith wrote:
>
> While reviewing another thread that proposes to include "generated
> columns" support for logical replication [1] I was looking for any
> existing PostgreSQL documentation on this topic.
>
> But, I found almost nothing about it at all -- I on
On Tue, Jun 18, 2024 at 7:30 AM Masahiko Sawada wrote:
>
> On Fri, Jun 14, 2024 at 4:04 PM Amit Kapila wrote:
> >
> > On Thu, Jun 13, 2024 at 6:14 PM Masahiko Sawada
> > wrote:
> > >
> >
> > > >
> > > > Now, say we don't want to maintain the state of sequences for initial
> > > > sync at all th
Le 18/06/2024 à 05:06, Nathan Bossart a écrit :
I didn't see a commitfest entry for this, so I created one to make sure we
don't lose track of this:
https://commitfest.postgresql.org/48/5046/
OK thanks!
By the way, I wonder if there were any off-list discussions after
Robert's co
Hi! Unfortunately,Iwas notableto fullyunderstandyourmessage.Couldyou
explainit to meplease?
On 09.04.2024 16:20, Andrei Lepikhov wrote:
Moreover, it helps even SeqScan: attempting to find a value in the
hashed array is much faster than cycling a long-expression on each
incoming tuple.
AsIu
On Tue, Jun 18, 2024 at 11:34 AM Dilip Kumar wrote:
>
> On Tue, Jun 18, 2024 at 10:17 AM Dilip Kumar wrote:
> >
> > On Mon, Jun 17, 2024 at 3:23 PM Amit Kapila wrote:
> > >
> > > On Wed, Jun 12, 2024 at 10:03 AM Dilip Kumar
> > > wrote:
> > > >
> > > > On Tue, Jun 11, 2024 at 7:44 PM Tomas Von
On Mon, Jun 17, 2024 at 5:50 PM Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> Hi,
>
> While looking at the commit
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=29d0a77fa6606f9c01ba17311fc452dabd3f793d
> ,
> I noticed that get_old_cluster_logical_slot
On Tue, Jun 4, 2024 at 6:51 PM Tender Wang wrote:
> Yeah, Richard commented the v1 patch about JOIN_UNIQUE_INNER in [1]
>
> * I think we should not consider materializing the cheapest inner path
> if we're doing JOIN_UNIQUE_INNER, because in this case we have to
> unique-ify the inner path.
>
> We
On Tue, 18 Jun 2024 at 09:32, Sven Klemm wrote:
>
> On Mon, Jun 17, 2024 at 10:25 PM Matthias van de Meent
> wrote:
>
> > I think you're solving the wrong problem here, as I can't think of a
> > place where both virtual tuple slots and tuple locking are allowed at
> > the same time in core code.
On Tue, Jun 4, 2024 at 7:03 PM Amit Langote wrote:
> On Tue, Jun 4, 2024 at 2:20 AM Tom Lane wrote:
> > Peter Eisentraut writes:
> > > On 02.06.24 21:46, Tom Lane wrote:
> > >> If you don't
> > >> like our current behavior, then either you have to say that RETURNING
> > >> with a length-limited
Hi Gayatri,
On Sun, Jun 16, 2024 at 4:39 AM Gayatri Singh
wrote:
> Hi Team,
>
> Greetings of the day!!
>
> We are planning to partition tables using pg_partman. Like we are planning
> for their backup and restoration process.
>
> Got a few URLs where pg_dump had issues while restoring some data
1 - 100 of 111 matches
Mail list logo
