On Mon, Jun 24, 2024 at 11:30:53PM +0300, Heikki Linnakangas wrote:
> Given that, I think it is a good thing to fail the connection completely on
> receiving a V2 error.
>
> Attached is a patch to fix the other issue, with falling back from SSL to
> plaintext. And some tests and comment fixes I sp
Hello,
Can you briefly explain what’s the issues you are going through the patch?
On Tue, 16 Jul 2024 at 11:40 AM, 김명준 wrote:
> Hello,
>
> I have been considering adding a user script that performs pre-checks
> before executing the start, stop, and restart operations in pg_ctl. I
> believe it
Hello,
I have been considering adding a user script that performs pre-checks
before executing the start, stop, and restart operations in pg_ctl. I
believe it is necessary for pg_ctl to support an extension that can prevent
various issues that might occur when using start and stop. To this end, I
h
On Tue, Jul 16, 2024 at 9:29 AM Amit Kapila wrote:
>
> One related comment:
> @@ -1219,8 +1219,14 @@ AlterPublicationTables(AlterPublicationStmt
> *stmt, HeapTuple tup,
> oldrel = palloc(sizeof(PublicationRelInfo));
> oldrel->whereClause = NULL;
> oldrel->columns = NIL;
> +
> + /*
> + * Data
Hi Robert.
On Mon, Jul 15, 2024 at 11:15 PM Robert Haas wrote:
>
> On Mon, Jul 15, 2024 at 8:05 AM Ashutosh Sharma wrote:
> > I've added these changes to restrict users from explicitly setting the
> > $extension_schema in the search_path. This ensures that
> > $extension_schema can only be set i
Dear Amit, Hou,
Thanks for giving comments! PSA new versions.
What's new:
0001: included Hou's patch [1] not to overwrite slot options.
Some other comments were also addressed.
0002: not so changed, just rebased.
0003: Typo was fixed, s/Alter/After/.
[1]:
https://www.postgresql.org/messag
On Wed, May 22, 2024 at 8:22 PM jian he wrote:
> On Wed, May 22, 2024 at 7:14 PM Peter Eisentraut wrote:
> >
> > On 20.05.24 02:00, jian he wrote:
> > >> removing parentheses means we need to rephrase this sentence?
> > >> So I come up with the following rephrase:
> > >>
> > >> The context_item s
Hi,
On Mon, Jul 15, 2024 at 12:20:29PM -0500, Nathan Bossart wrote:
> On Fri, Jul 12, 2024 at 03:39:57PM -0500, Sami Imseih wrote:
> > but Bertrand found long drifts [2[ which I could not reproduce.
> > To safeguard the long drifts, continue to use the &remain time with an
> > additional safeguar
On Tue, Jul 16, 2024 at 3:19 PM Thomas Munro wrote:
> I've attached a new version like that. Let's see which runner machine
> gets it and how it turns out...
It failed[1] on pgx-m2-1: "Error: ShouldBeAtLeastOneLayer". So I
temporarily disabled that machine from the pool and click the re-run
but
On Wed, Jul 10, 2024 at 01:16:15PM +0900, Michael Paquier wrote:
> You mean with something that does a injection_point_cache_get()
> followed by a callback run if anything is found in the local cache?
> Why not. Based on what you have posted at [1], it looks like this had
> better check the conten
On Tue, Jul 16, 2024 at 12:48 AM Nitin Motiani wrote:
>
> A couple of questions on the latest patch :
>
> 1. I see there is this logic in PublicationDropSchemas to first check
> if there is a valid entry for the schema in pg_publication_namespace
>
> psid = GetSysCacheOid2(PUBLICAT
On Tue, Jul 16, 2024 at 10:48 AM Andres Freund wrote:
> WRT your patches:
> - I think we ought to switch to the -runner image, otherwise we'll just
> continue to get that "upgraded" warning
Right, let's try it.
> - With a fingerprint_script specified, we need to add
> reupload_on_changes: tr
On Mon, Jul 15, 2024 at 03:26:32PM +1200, Thomas Munro wrote:
> On Mon, Jul 8, 2024 at 2:49 AM Noah Misch wrote:
> > what is the scope of the review you seek?
>
> The patch "Refactor tidstore.c memory management." could definitely
> use some review.
That's reasonable. radixtree already forbids
On Fri, Jul 12, 2024 at 01:01:19PM +, Bertrand Drouvot wrote:
> Instead of removing the stat file, should we keep it around until the first
> call
> to pgstat_write_statsfile()?
Oops. You are right, I have somewhat missed the unlink() once we are
done reading the stats file with a correct re
On Sun, Jul 14, 2024 at 07:00:00PM +0300, Alexander Lakhin wrote:
> I've filed a bug report about the "WITH RECURSIVE" anomaly: [1], but what
> I wanted to understand when presenting different error kinds is what
> definition XX000 errors could have in principle?
Cool, thanks! I can see that Tom
On Monday, July 15, 2024, David Rowley wrote:
> On Tue, 16 Jul 2024 at 12:45, Richard Guo wrote:
> > As a workaround for this issue, I'm considering whether we can skip
> > checking functional dependency on primary keys for inheritance
> > parents, given that we cannot guarantee uniqueness on th
On Fri, Jul 12, 2024 at 03:44:26PM +0200, Dmitry Dolgov wrote:
> I think it's fine. Although this solution feels a bit uncomfortable,
> after thinking back and forth I don't see any significantly better
> option. Worth noting that since the main goal is to maintain uniqueness,
> fixing the kind IDs
On Mon, Jul 15, 2024 at 09:54:43AM +0900, Michael Paquier wrote:
> Thanks. I'll see about stressing the buildfarm tomorrow or so, after
> looking at how the CI reacts.
There were a few more things here:
1) The new test was missing from test_misc/meson.build.
2) With 1) fixed, the CI has been comp
On Tue, 16 Jul 2024 at 12:45, Richard Guo wrote:
> As a workaround for this issue, I'm considering whether we can skip
> checking functional dependency on primary keys for inheritance
> parents, given that we cannot guarantee uniqueness on the keys in this
> case. Maybe something like below.
>
>
On Mon, Jul 15, 2024 at 10:55:26AM +0300, Heikki Linnakangas wrote:
> Ok, committed this.
Okidoki. Thanks!
--
Michael
signature.asc
Description: PGP signature
I came across a query that returned incorrect results and I traced it
down to being caused by duplicate unique key values in an inheritance
table. As a simple example, consider
create table p (a int primary key, b int);
create table c () inherits (p);
insert into p select 1, 1;
insert into c sel
Hi,
I was reading back through this thread to find out how the proposed new
command for refreshing sequences, came about. The patch 0705 introduces a
new command syntax for ALTER SUBSCRIPTION ... REFRESH SEQUENCES
So now there are 2 forms of subscription refresh.
#1. ALTER SUBSCRIPTION name REF
On Sun, Jul 14, 2024 at 10:00 AM Thomas Munro wrote:
> On Fri, Jul 12, 2024 at 3:49 AM Dave Page wrote:
> > # doesn't match '(?^:pg_dump: error: connection to server .* failed:
> > FATAL: database "qqq" does not exist)'
>
> Does it help if you revert 29992a6?
FWIW I just happened to notice
On Tue, 16 Jul 2024 at 06:19, Robert Haas wrote:
> I'm not against what you're trying to do here, but I feel like you
> might be over-engineering it. I don't think there was anything really
> wrong with what Melih was doing, and I don't think there's anything
> really wrong with converting the pat
On Tue, Mar 5, 2024 at 4:12 PM David Zhang wrote:
> This is the third version patch for "Certificate status check using OCSP
> Stapling" with ssl regression test cases added.
Hi David,
Thanks again for working on this! So far I've taken a look at the
design and tests. I've only skimmed the callb
Thanks for the review!
On Mon, Jul 15, 2024 at 11:31 AM Nathan Bossart
wrote:
>
>I took a closer look at 0002.
>
>I'm curious why you aren't using float8_mul/float8_div here, i.e.,
>
>fresult = rint(float8_mul((float8) c, f));
>fresult = rint(float8_div((float8) c,
On Mon, 2024-07-15 at 16:04 -0400, Robert Haas wrote:
> Oh, I had the opposite idea: I wasn't proposing ignoring it. I was
> proposing making it work.
I meant: ignore $extension_schema if the search_path has nothing to do
with an extension. In other words, if it's in a search_path for the
session,
Hi,
On 2024-07-03 09:39:06 +1200, Thomas Munro wrote:
> On Thu, Jun 27, 2024 at 6:32 PM Thomas Munro wrote:
> > So I think we should request
> > ghcr.io/cirruslabs/macos-sonoma-base:latest. Personal github accounts
> > will use macos-runner:sonoma instead, but at least it's the same OS
> > relea
On Mon, Jul 8, 2024 at 2:25 PM Melanie Plageman
wrote:
> Attached v3 has one important additional component in the test -- I
> use pg_stat_progress_vacuum to confirm that we actually do more than
> one pass of index vacuuming. Otherwise, it would have been trivial for
> the test to incorrectly pas
Hi,
On 2024-07-15 14:35:14 -0700, Andres Freund wrote:
> Specifically, something like the attached.
>
> Due to the CI failure this is causing, I'm planning to apply this soon...
>
> Arguably we could backpatch this, the warning are present on older branches
> too. Except that they don't cause erro
> On 14 Jul 2024, at 14:03, Peter Eisentraut wrote:
>
> On 12.07.24 21:42, Daniel Gustafsson wrote:
>>> On 11 Jul 2024, at 23:22, Peter Eisentraut wrote:
>>> The 0001 patch removes the functions pgtls_init_library() and pgtls_init()
>>> but keeps the declarations in libpq-int.h. This should be
Hi,
On 2024-07-15 12:37:54 -0700, Andres Freund wrote:
> On 2024-07-15 11:30:59 -0700, Andres Freund wrote:
> > On 2024-07-15 09:43:26 -0700, Andres Freund wrote:
> > > I've now applied the guc fix to all branches and the CI changes to 15+.
> >
> > Ugh. I see that this fails on master, because of
@cfbot: rebased
>From bc92a05ba35115ba0df278d553a5c0e4e303fe23 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Tue, 21 Jun 2022 22:28:06 -0500
Subject: [PATCH] WIP: use BulkInsertState for toast tuples, too
DONE: ALTER, CLUSTER
TODO: copyto, copyfrom?
slot_getsomeattrs slot_deform_heap_tuple
On 2024-07-15 12:14:47 -0500, Nathan Bossart wrote:
> On Mon, Jul 15, 2024 at 09:41:55AM -0700, Andres Freund wrote:
> > On 2024-05-10 12:13:21 +0300, Nazir Bilal Yavuz wrote:
> >> The fix is attached. It cleanly applies from REL_15_STABLE to
> >> REL_12_STABLE, fixes the warnings and the tests pas
On Tue, Jul 16, 2024 at 1:47 AM Andrey M. Borodin
wrote:
>
>
> > On 15 Jul 2024, at 12:52, Stepan Neretin wrote:
> >
> >
> > I run benchmark with my patches:
> > ./pgbench -c 10 -j2 -t1000 -d postgres
> >
> > pgbench (18devel)
> > starting vacuum...end.
> > transaction type:
> > scaling factor:
On Mon, Jul 15, 2024 at 04:03:13PM -0400, Robert Haas wrote:
> On Mon, Jul 15, 2024 at 2:47 PM Nathan Bossart
> wrote:
>> My understanding is that the correctness of this GUC check hook depends on
>> wal_level being a PGC_POSTMASTER GUC. The check hook would always return
>> true during startup,
On Mon, Jul 15, 2024 at 2:33 PM Jeff Davis wrote:
> On Mon, 2024-07-15 at 13:44 -0400, Robert Haas wrote:
> > But ... why? I mean, what's the point of prohibiting that?
>
> Agreed. We ignore all kinds of stuff in search_path that doesn't make
> sense, like non-existent schemas. Simpler is better.
On Mon, Jul 15, 2024 at 2:47 PM Nathan Bossart wrote:
> My understanding is that the correctness of this GUC check hook depends on
> wal_level being a PGC_POSTMASTER GUC. The check hook would always return
> true during startup, and there'd be an additional cross-check in
> PostmasterMain() that
I agree with all your points as I encountered them myself, especially
ambiguity and error handling.
The introduced dependency between those functions also is for me a bad
idea but it seemed like the only way to support that use case, but turns
out my assumption that the array literal shouldn't
Andres Freund writes:
> On 2024-07-13 13:16:14 -0400, Tom Lane wrote:
>> Of course the main point is the hope that it will work at all with MSVC, but
>> I'm not in a position to test that.
> It does work with just your patches applied - very nice.
Thanks for testing!
> The only obvious thing th
Hi,
On 2024-07-15 11:30:59 -0700, Andres Freund wrote:
> On 2024-07-15 09:43:26 -0700, Andres Freund wrote:
> > I've now applied the guc fix to all branches and the CI changes to 15+.
>
> Ugh. I see that this fails on master, because of
>
> commit 0c3930d0768
> Author: Peter Eisentraut
> Date:
On 7/15/24 20:50, Julien Tachoires wrote:
> Hi,
>
> Le ven. 7 juin 2024 à 06:18, Julien Tachoires a écrit :
>>
>> Le ven. 7 juin 2024 à 05:59, Tomas Vondra
>> a écrit :
>>>
>>> On 6/6/24 12:58, Julien Tachoires wrote:
...
When compiled with LZ4 support (--with-lz4), this patch ena
On Mon, Jul 15, 2024 at 11:42 PM vignesh C wrote:
>
> On Mon, 15 Jul 2024 at 15:31, Amit Kapila wrote:
> >
> > On Thu, Jul 11, 2024 at 6:19 PM Nitin Motiani
> > wrote:
> > > I looked further into the scenario of adding the tables in schema to
> > > the publication. Since in that case, the entry
Arjan Marku writes:
> INSERT INTO item_2d_table VALUES(1, '(1,{{("inv a",42,1.99),("inv
> b",42,1.99)},{("inv c",42,1.99),("inv d",42,2)}})');
> The INSERT statement will fail due to how complex types are parsed, I
> have included a patch in this email to support this scenario.
The actual prob
On Mon, Jul 15, 2024 at 01:47:14PM -0500, Nathan Bossart wrote:
> On Mon, Jul 15, 2024 at 02:30:42PM -0400, Robert Haas wrote:
>> I guess I'm in the group of people who doesn't understand how this can
>> possibly work. There's no guarantee about the order in which GUC check
>> hooks are called, so
On Mon, Jul 15, 2024 at 02:30:42PM -0400, Robert Haas wrote:
> On Sun, Jul 14, 2024 at 10:56 PM Fujii Masao
> wrote:
>> I don't think it's a rare scenario since summarize_wal can be enabled
>> after starting the server with wal_level=minimal. Therefore, I believe
>> such a configuration should be
> On 15 Jul 2024, at 12:52, Stepan Neretin wrote:
>
>
> I run benchmark with my patches:
> ./pgbench -c 10 -j2 -t1000 -d postgres
>
> pgbench (18devel)
> starting vacuum...end.
> transaction type:
> scaling factor: 10
> query mode: simple
> number of clients: 10
> number of threads: 2
> max
On Mon, 2024-07-15 at 13:44 -0400, Robert Haas wrote:
> But ... why? I mean, what's the point of prohibiting that?
Agreed. We ignore all kinds of stuff in search_path that doesn't make
sense, like non-existent schemas. Simpler is better.
Regards,
Jeff Davis
Hi,
On 2024-07-15 09:43:26 -0700, Andres Freund wrote:
> I've now applied the guc fix to all branches and the CI changes to 15+.
Ugh. I see that this fails on master, because of
commit 0c3930d0768
Author: Peter Eisentraut
Date: 2024-07-01 07:30:38 +0200
Apply COPT to CXXFLAGS as well
I
On Sun, Jul 14, 2024 at 10:56 PM Fujii Masao
wrote:
> I don't think it's a rare scenario since summarize_wal can be enabled
> after starting the server with wal_level=minimal. Therefore, I believe
> such a configuration should be prohibited using a GUC check hook,
> as my patch does.
I guess I'm
On Mon, Jul 15, 2024 at 6:44 AM David Rowley wrote:
> Unfortunately, this wouldn't align with the goals of the patch. Going
> back to Melih's opening paragraph in the initial email, he mentions
> that there's currently no *reliable* way to determine the parent/child
> relationship in this view.
>
On Mon, 15 Jul 2024 at 15:31, Amit Kapila wrote:
>
> On Thu, Jul 11, 2024 at 6:19 PM Nitin Motiani wrote:
> >
> > On Wed, Jul 10, 2024 at 11:22 PM Nitin Motiani
> > wrote:
> > >
> > > On Wed, Jul 10, 2024 at 10:39 PM vignesh C wrote:
> > > >
> > > > On Wed, 10 Jul 2024 at 12:28, Amit Kapila
On Fri, Jul 12, 2024 at 6:33 PM Melih Mutlu wrote:
> I just ran the below to see if we have any context with the same level and
> name.
>
> postgres=# select level, name, count(*) from pg_backend_memory_contexts group
> by level, name having count(*)>1;
> level |name | count
> ---+
On Mon, Jul 15, 2024 at 8:05 AM Ashutosh Sharma wrote:
> I've added these changes to restrict users from explicitly setting the
> $extension_schema in the search_path. This ensures that
> $extension_schema can only be set implicitly for functions created by
> the extension when the "protected" fla
Hi,
On 2024-07-13 13:16:14 -0400, Tom Lane wrote:
> I wrote:
> > Per discussion elsewhere [1], I've been looking at $SUBJECT.
>
> Here's a finished patchset to perform this change.
Awesome!
> With gcc 8.5.0 I see the time drop from about 3 seconds to about 0.7. The
> win is less noticeable with
On Fri, Jul 12, 2024 at 03:39:57PM -0500, Sami Imseih wrote:
> but Bertrand found long drifts [2[ which I could not reproduce.
> To safeguard the long drifts, continue to use the &remain time with an
> additional safeguard to make sure the actual sleep does not exceed the
> requested sleep time.
On Mon, Jul 15, 2024 at 09:41:55AM -0700, Andres Freund wrote:
> On 2024-05-10 12:13:21 +0300, Nazir Bilal Yavuz wrote:
>> The fix is attached. It cleanly applies from REL_15_STABLE to
>> REL_12_STABLE, fixes the warnings and the tests pass.
>
> Thanks! I've applied it to all branches - while it's
Hi hackers,
I ran into an issue today when I was trying to insert a complex types
where one of its attributes is also an array of complex types,
As an example:
CREATE TYPE inventory_item AS
(
name text,
supplier_id integer,
price numeric
);
CREATE TYPE item_2d AS (id
Hi,
On 2024-05-24 10:30:00 -0700, Andres Freund wrote:
> On 2024-05-24 16:17:37 +0200, Peter Eisentraut wrote:
> > I'm not sure what the backpatching expectations of this kind of thing is.
> > The history of this CI setup is relatively short, so this hasn't been
> > stressed too much. I see that
Hi,
On 2024-05-10 12:13:21 +0300, Nazir Bilal Yavuz wrote:
> On Tue, 23 Apr 2024 at 19:59, Andres Freund wrote:
> >
> >
> > Which seems entirely legitimate. ISTM that guc_var_compare() ought to only
> > cast the pointers to the key type, i.e. char *. And incidentally that does
> > prevent the wa
I took a closer look at 0002.
+if (unlikely(isinf(f) || isnan(f)))
+ereport(ERROR,
+(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
+ errmsg("invalid float value")));
+
+fresult = rint(f * c);
+if (unlikely(f == 0.0))
+ereport(ERROR,
+
On Sat, 2024-06-29 at 07:01 +0200, Laurenz Albe wrote:
> I played around with incremental backup yesterday and tried $subject
>
> The WAL summarizer is running on the standby server, but when I try
> to take an incremental backup, I get an error that I understand to mean
> that WAL summarizing
On 07/15/24 10:46, Chapman Flack wrote:
> Ah, I may have mistaken which functions the patch meant to apply to.
> ...
> Any choice to use similar argument names in the regexp_* functions would
> be a matter of consistency with the analogous ISO functions, not anything
> mandated.
Or, looking back,
On 07/15/24 08:02, jian he wrote:
> also address Chapman Flack point:
> correct me if i am wrong, but i don't think the ISO standard mandates
> function argument names.
> So we can choose the best function argument name for our purpose?
Ah, I may have mistaken which functions the patch meant to ap
Hi,
Let me share my opinion on those questions ...
On 7/12/24 12:09, masahiro.ik...@nttdata.com wrote:
> Hi,
>
> Thanks for working the feature. As a user, I find it useful, and I'd like to
> use
> it in v18! Although I've just started start looking into it, I have a few
> questions.
>
>
>
On Jul 15, 2024, at 07:07, Stepan Neretin wrote:
> Hi! Looks good to me now! Please, register a patch in CF.
> Best regards, Stepan Neretin.
It’s here:
https://commitfest.postgresql.org/48/5017/
Best,
David
On 6/28/24 13:16, Tatsuro Yamada wrote:
> Hi Tomas and All,
>
> Attached file is a new patch including:
> 6) Add stats option to explain command
> 7) The patch really needs some docs (partly)
>
> >4) Add new node (resolve errors in cfbot and prepared statement)
>
> I tried adding a new
On 6/26/24 11:06, Tatsuro Yamada wrote:
> Hi Tomas!
>
> Thanks for the comments!
>
> 1) The patch is not added to the CF app, which I think is a mistake. Can
>> you please add it to the 2024-07 commitfest? Otherwise people may not be
>> aware of it, won't do reviews etc. It'll require posting
On Tue, 2 Jul 2024 at 02:23, David Rowley wrote:
>
> On Mon, 1 Jul 2024 at 23:42, Matthias van de Meent
> wrote:
> >
> > On Mon, 1 Jul 2024 at 12:49, David Rowley wrote:
> > >
> > > On Mon, 1 Jul 2024 at 22:07, Matthias van de Meent
> > > wrote:
> > > > One thing I'm slightly concerned about is
Hi Robert,
On Fri, Jul 12, 2024 at 9:02 PM Robert Haas wrote:
>
> On Mon, Jun 24, 2024 at 3:10 PM Jeff Davis wrote:
> > A special search_path variable "$extension_schema" would be a better
> > solution to this problem. We need something like that anyway, in case
> > the extension is relocated, s
On Thu, May 16, 2024 at 3:10 AM Tom Lane wrote:
>
> Robert Haas writes:
> > On Thu, Apr 4, 2024 at 9:55 AM jian he wrote:
> >> changing "N" to lower-case would be misleading for regexp_replace?
> >> so I choose "count".
>
> > I don't see why that would be confusing for regexp_replace
> > specifi
On Tue, Jul 9, 2024 at 6:23 PM Hayato Kuroda (Fujitsu)
wrote:
>
> Previous patch set could not be accepted due to the initialization miss.
> PSA new version.
>
Few minor comments:
=
0001-patch
1.
.git/rebase-apply/patch:253: space before tab in indent.
errmsg("slot_name and two_p
On Sat, 13 Jul 2024 at 10:12, Melih Mutlu wrote:
> I updated documentation for path and level columns and also fixed the tests
> as level starts from 1.
Thanks for updating.
+ The path column can be useful to build
+ parent/child relation between memory contexts. For example, the following
On Mon, Jul 8, 2024 at 11:09 PM David E. Wheeler
wrote:
> On Jun 27, 2024, at 04:17, Michael Paquier wrote:
>
> > The tests of jsonb_jsonpath.sql include a lot of patterns for @? and
> > jsonb_path_query with the lax and strict modes, so shouldn't these
> > additions be grouped closer to the exi
On Mon, Jul 15, 2024 at 4:24 AM Alexander Korotkov wrote:
> Thanks to Kyotaro for the review. And thanks to Ivan for the patch
> revision. I made another revision of the patch.
I've noticed failures on cfbot. The attached revision addressed docs
build failure. Also it adds some "quits" for ba
Hi Emanuel,
Changed implementation of the function Exec_UnlistenCommit . v2 of the path
contained a bug in the function Exec_UnlistenCommit (added a test case for
that) and also it was not implemented in natural to C form using pointers.
Now it looks fine and works as expected.
In the previous em
On Mon, Jul 15, 2024 at 4:52 PM Stepan Neretin wrote:
>
>
> On Mon, Jul 15, 2024 at 12:23 PM Антуан Виолин
> wrote:
>
>> Hello all.
>>>
>>> I have decided to explore more areas in which I can optimize and have
>>> added
>>> two new benchmarks. Do you have any thoughts on this?
>>>
>>> postgres=#
On Tue, 2 Jul 2024 at 11:18, Jim Jones wrote:
>
> When either minval or maxval exceeds int4 the function cannot be
> executed/found
>
> SELECT * FROM normal_rand_array(5, 10, 8, 42::bigint);
>
> ERROR: function normal_rand_array(integer, integer, integer, bigint)
> does not exist
> LINE 1: SELECT
On Sat, 13 Jul 2024 at 10:33, Melih Mutlu wrote:
> I've been also thinking if we should still have the parent column, as finding
> out the parent is also possible via looking into the path. What do you think?
I think we should probably consider removing it. Let's think about
that later. I don't
On Fri, 12 Jul 2024 at 08:09, Robert Haas wrote:
> Do we ever have contexts with the same name at the same level? Could
> we just make the path an array of strings, so that you could then say
> something like this...
>
> SELECT * FROM pg_backend_memory_contexts where path[2] = 'CacheMemoryContext'
On Thu, Jul 11, 2024 at 6:19 PM Nitin Motiani wrote:
>
> On Wed, Jul 10, 2024 at 11:22 PM Nitin Motiani
> wrote:
> >
> > On Wed, Jul 10, 2024 at 10:39 PM vignesh C wrote:
> > >
> > > On Wed, 10 Jul 2024 at 12:28, Amit Kapila wrote:
> > > > The patch missed to use the ShareRowExclusiveLock for
On Fri, May 17, 2024 at 4:26 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> Thanks, that's correct. I think the only thing left is to add a verifier
> pass, which everybody seems to be agreed is nice to have. The plan is to
> add it only to master without back-patching. I assume Thomas did not
>
On Mon, Jul 15, 2024 at 12:23 PM Антуан Виолин
wrote:
> Hello all.
>>
>> I have decided to explore more areas in which I can optimize and have
>> added
>> two new benchmarks. Do you have any thoughts on this?
>>
>> postgres=# select bench_int16_sort(100);
>> bench_int16_sort
>>
>>
>>
On Sat, 13 Jul 2024 at 14:21, Pavel Luzanov wrote:
>
> On 12.07.2024 12:22, Rafia Sabih wrote:
>
> Other thoughts came to my mind, should we have this column in \du+
> instead, maybe connection limit too.
> I know in the current version we have all this in \du itself, but then
> all clubbed in one
Hi,
> /*
> * Prevent spurious warning due to compiler not realizing
> * VARATT_IS_EXTERNAL_NON_EXPANDED() branch in assign_simple_var()
> isn't
> * reachable due to "found" being byvalue.
> */
> if (var->datatype->typlen != 1)
>
Hi,
I'm reviewing patches in Commitfest 2024-07 from top to bottom:
https://commitfest.postgresql.org/48/
This is the 3rd patch:
https://commitfest.postgresql.org/48/4583/
FYI: https://commitfest.postgresql.org/48/4681/ is my patch.
In
"Re: Wrong results with grouping sets" on Wed, 10 Jul 20
On 7/15/24 14:35, jian he wrote:
On Mon, Jul 15, 2024 at 2:08 PM Andrei Lepikhov wrote:
On 7/15/24 12:31, jian he wrote:
hi.
Here is the latest patch (v6),
I've made the following changes.
* disallow original Query->resultRelation participate in SJE.
for SELECT, nothing is changed. for UPDAT
On 10/07/2024 06:44, Michael Paquier wrote:
On Tue, Jul 09, 2024 at 12:12:04PM +0300, Heikki Linnakangas wrote:
I thought about it, but no. If the generation number doesn't match, there
are a few possibilities:
1. The entry was what we were looking for, but it was concurrently detached.
Return
On Mon, Jul 15, 2024 at 12:44 PM Антуан Виолин
wrote:
> On 2024-04-03 Wn 04:21, Andrew Dunstan
>
>> I don't think a cast that doesn't cater for all the forms json can take
>> is going to work very well. At the very least you would need to error out
>> in cases you didn't want to cover, and have t
On Mon, Jul 15, 2024 at 2:08 PM Andrei Lepikhov wrote:
>
> On 7/15/24 12:31, jian he wrote:
> > hi.
> > Here is the latest patch (v6),
> > I've made the following changes.
> >
> > * disallow original Query->resultRelation participate in SJE.
> > for SELECT, nothing is changed. for UPDATE/DELETE/ME
90 matches
Mail list logo
