> On 13 Mar 2024, at 05:23, Alexander Korotkov wrote:
>
> On Tue, Mar 12, 2024 at 10:28 AM Andrey M. Borodin
> wrote:
>>> On 11 Mar 2024, at 16:18, Alexander Korotkov wrote:
>>>
>>> I think if checking psql stderr is problematic, checking just logs is
>>> fine. Could we wait for the
On 12/3/2024 22:20, Alexander Korotkov wrote:
On Mon, Mar 11, 2024 at 2:43 PM Andrei Lepikhov
I think you are right. It is probably a better place than any other to
remove duplicates in an array. I just think we should sort and remove
duplicates from entry->consts in one pass. Thus, this
On Tue, Mar 12, 2024 at 06:55:41PM +0300, Teodor Sigaev wrote:
> Playing around I found one more place which could easily modified with
> hash_seq_init_with_hash_value() call.
I think that this patch should be split for clarity, as there are a
few things that are independently useful. I guess
FYI -- some more code has been pushed since this patch was last
updated. AFAICT perhaps you'll want to update this patch again for the
following new connection messages on HEAD:
- slotfuncs.c [1]
- slotsync.c [2]
--
[1]
On Wed, Mar 6, 2024 at 2:47 PM Bharath Rupireddy
wrote:
>
> On Wed, Mar 6, 2024 at 2:42 PM Bertrand Drouvot
> wrote:
> >
> > Hi,
> >
> > On Tue, Mar 05, 2024 at 01:44:43PM -0600, Nathan Bossart wrote:
> > > On Wed, Mar 06, 2024 at 12:50:38AM +0530, Bharath Rupireddy wrote:
> > > > On Mon, Mar 4,
On Tue Mar 12, 2024 at 6:56 PM CDT, Sutou Kouhei wrote:
Hi,
In
"Re: meson: Specify -Wformat as a common warning flag for extensions" on Fri,
08 Mar 2024 10:05:27 -0600,
"Tristan Partin" wrote:
> Ok, I figured this out. -Wall implies -Wformat=1. We set warning_level
> to 1 in the Meson
On Wed, Mar 13, 2024 at 08:08:42AM +0530, Bharath Rupireddy wrote:
> On Wed, Mar 13, 2024 at 5:16 AM Michael Paquier wrote:
>> The attached 0003 is what I had in mind:
>> - Simplification of the LOG generated with quotes applied around the
>> column name, don't see much need to add the relation
On Fri, Feb 16, 2024 at 11:42 PM torikoshia
wrote:
I'm not so sure about the implementation now, i.e. finding the next
node
to be executed from the planstate tree, but I'm going to try this
approach.
Attached a patch which takes this approach.
- I saw no way to find the next node to be
On Tue, Mar 12, 2024 at 8:46 PM Bharath Rupireddy
wrote:
>
> On Tue, Mar 12, 2024 at 6:05 PM Amit Kapila wrote:
> >
> > The patch looks mostly good to me. I have changed the comments and
> > commit message in the attached. I am planning to push this tomorrow
> > unless you or others have any
On Wednesday, March 13, 2024 11:49 AMvignesh C wrote:
> On Tue, 12 Mar 2024 at 09:34, Ajin Cherian wrote:
> >
> >
> >
> > On Tue, Mar 12, 2024 at 2:59 PM vignesh C wrote:
> >>
> >>
> >> Thanks, I have created the following Commitfest entry for this:
> >>
On Tue, 12 Mar 2024, 23:45 Anthonin Bonnefoy, <
anthonin.bonne...@datadoghq.com> wrote:
>
> > - I don't think it's a good idea to do memory allocations in the middle
> of a
> > PG_CATCH. If the error was due to out-of-memory, you'll throw another
> error.
> Good point. I was wondering what were
On Tue, Mar 12, 2024 at 10:10 PM Bharath Rupireddy
wrote:
>
> On Mon, Mar 11, 2024 at 3:44 PM Amit Kapila wrote:
> >
> > Yes, your understanding is correct. I wanted us to consider having new
> > parameters like 'inactive_replication_slot_timeout' to be at
> > slot-level instead of GUC. I think
On Tue, Mar 12, 2024 at 5:37 PM Amit Langote
wrote:
>
>
> SELECT JSON_EXISTS(jsonb '{"customer_name": "test", "salary":1000,
> "department_id":1}', '$ ? (@.department_id == $dept_id && @.salary ==
> $sal)' PASSING 1000 AS sal, 1 as dept_id);
> json_exists
> -
> t
> (1 row)
>
> Does
Andrew Dunstan writes:
> On 2024-03-12 Tu 18:59, Tom Lane wrote:
>> I wonder whether perlcritic has sufficiently deep understanding of
>> Perl code that it could find these hazards.
> Yeah, that was my thought too. I'd start with ProhibitComplexRegexes.pm
> as a template.
Oooh. Taking a quick
On Tue, Mar 12, 2024 at 9:11 PM Bertrand Drouvot
wrote:
>
> On Tue, Mar 12, 2024 at 05:51:43PM +0530, Amit Kapila wrote:
> > On Tue, Mar 12, 2024 at 1:24 PM Bertrand Drouvot
> > wrote:
>
> > so why to prevent it for
> > these new parameters? This will unnecessarily create inconsistency in
> >
On 2024-03-12 Tu 18:59, Tom Lane wrote:
Jeff Davis writes:
On Tue, 2024-03-12 at 18:53 +0100, Alvaro Herrera wrote:
I also tried grepping (for things
like qr{}, qr[], qr||, qr!!) and didn't find anything beyond what you
have ... but I only looked for the "qr" literal, not other ways to
get
Jelte Fennema-Nio writes:
> On Tue, 12 Mar 2024 at 19:28, Alvaro Herrera wrote:
>>> Hmm, buildfarm member kestrel (which uses
>>> -fsanitize=undefined,alignment) failed:
>> Hm, I tried using the same compile flags, couldn't reproduce.
> Okay, it passed now it seems so I guess this test is
On Tue, Mar 12, 2024 at 8:55 PM Bharath Rupireddy
wrote:
>
> On Mon, Mar 11, 2024 at 11:26 AM Amit Kapila wrote:
> >
> > > Hm. I get the concern. Are you okay with having inavlidation_reason
> > > separately for both logical and physical slots? In such a case,
> > > logical slots that got
On Tue, 12 Mar 2024 at 09:34, Ajin Cherian wrote:
>
>
>
> On Tue, Mar 12, 2024 at 2:59 PM vignesh C wrote:
>>
>>
>> Thanks, I have created the following Commitfest entry for this:
>> https://commitfest.postgresql.org/47/4816/
>>
>> Regards,
>> Vignesh
>
>
> Thanks for the patch, I have verified
I did some light editing to prepare this for commit.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 38c78bd92a7b4d4600e6f0dbe58283c21ea87d50 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 12 Mar 2024 22:04:25 -0500
Subject: [PATCH v10 1/1] Add
At Mon, 11 Mar 2024 16:43:32 +0900 (JST), Kyotaro Horiguchi
wrote in
> Oh, I once saw the fix work, but seems not to be working after some
> point. The new issue was a corruption of received WAL records on the
> first standby, and it may be related to the setting.
I identified the cause of the
On Wed, Mar 13, 2024 at 5:16 AM Michael Paquier wrote:
>
> On Tue, Mar 12, 2024 at 12:54:29PM +0530, Bharath Rupireddy wrote:
> > +1. But, do you want to add them now or later as a separate
> > patch/discussion altogether?
>
> The attached 0003 is what I had in mind:
> - Simplification of the LOG
On Wed, Mar 13, 2024 at 12:48 PM Masahiko Sawada wrote:
>
> On Wed, Mar 13, 2024 at 10:15 AM Peter Smith wrote:
> >
> > On Tue, Mar 12, 2024 at 4:23 PM Masahiko Sawada
> > wrote:
> > >
> > > On Fri, Mar 8, 2024 at 12:58 PM Peter Smith wrote:
> > > >
> > ...
> > > > > > 5.
> > > > > > + *
> >
On Wed, Mar 13, 2024 at 4:50 AM Maxim Orlov wrote:
> I looked at the changes and I liked them. Here are my thoughts:
Thanks for looking! Pushed.
On Wed, Mar 13, 2024 at 10:15 AM Peter Smith wrote:
>
> On Tue, Mar 12, 2024 at 4:23 PM Masahiko Sawada wrote:
> >
> > On Fri, Mar 8, 2024 at 12:58 PM Peter Smith wrote:
> > >
> ...
> > > > > 5.
> > > > > + *
> > > > > + * If 'indexed' is true, we create a hash table to track of each
> > > > >
On Tue, Mar 12, 2024 at 7:34 PM John Naylor wrote:
>
> On Mon, Mar 11, 2024 at 3:13 PM Masahiko Sawada wrote:
> >
> > On Mon, Mar 11, 2024 at 12:20 PM John Naylor
> > wrote:
> > >
> > > On Thu, Mar 7, 2024 at 10:35 PM Masahiko Sawada
> > > wrote:
>
> > > + ts->context = CurrentMemoryContext;
On Tue, Mar 12, 2024 at 4:23 PM Masahiko Sawada wrote:
>
> On Fri, Mar 8, 2024 at 12:58 PM Peter Smith wrote:
> >
...
> > > > 5.
> > > > + *
> > > > + * If 'indexed' is true, we create a hash table to track of each node's
> > > > + * index in the heap, enabling to perform some operations such as
On 2024-03-12 Tu 14:43, Jacob Champion wrote:
Hello,
Both the incremental JSON [1] and OAuth [2] patchsets would be
improved by json_errdetail(), which was removed from FRONTEND builds
in b44669b2ca:
The routine providing a detailed error message based on the error code
is made
On 2024-03-11 Mo 22:50, Thomas Munro wrote:
On Tue, Mar 12, 2024 at 2:56 PM Andrew Dunstan wrote:
On 2024-03-11 Mo 04:21, Oleg Tselebrovskiy wrote:
Greetings, everyone!
While running "installchecks" on databases with UTF-8 encoding the test
citext_utf8 fails because of Turkish dotted I
On Tue, Mar 12, 2024 at 10:28 AM Andrey M. Borodin wrote:
> > On 11 Mar 2024, at 16:18, Alexander Korotkov wrote:
> >
> > I think if checking psql stderr is problematic, checking just logs is
> > fine. Could we wait for the relevant log messages one by one with
> > $node->wait_for_log() just
On 2/29/24 16:55, Michael Paquier wrote:
On Thu, Feb 29, 2024 at 10:30:52AM +1300, David Steele wrote:
On 11/12/23 08:21, David Steele wrote:
As promised in [1], attached are some basic tests for the low-level
backup method.
Added to the 2024-03 CF.
There is already
> On Tue, Mar 12, 2024 at 10:40 PM Daniel Gustafsson wrote:
>
> > On 12 Mar 2024, at 14:38, Xing Guo wrote:
>
> > Would it be possible to add a new switch in the pgxs.mk framework to
> > allow users to disable this feature?
>
> Something like that doesn't seem unreasonable I think.
Thanks.
I
Hi,
In
"Re: meson: Specify -Wformat as a common warning flag for extensions" on Fri,
08 Mar 2024 10:05:27 -0600,
"Tristan Partin" wrote:
> Ok, I figured this out. -Wall implies -Wformat=1. We set warning_level
> to 1 in the Meson project() call, which implies -Wall, and set -Wall
> in
On Tue, Mar 12, 2024 at 12:54:29PM +0530, Bharath Rupireddy wrote:
> +1. But, do you want to add them now or later as a separate
> patch/discussion altogether?
The attached 0003 is what I had in mind:
- Simplification of the LOG generated with quotes applied around the
column name, don't see much
Jeff Davis writes:
> On Tue, 2024-03-12 at 18:53 +0100, Alvaro Herrera wrote:
>> I also tried grepping (for things
>> like qr{}, qr[], qr||, qr!!) and didn't find anything beyond what you
>> have ... but I only looked for the "qr" literal, not other ways to
>> get regexes.
> I think that's fine.
On Tue, 2024-03-12 at 18:53 +0100, Alvaro Herrera wrote:
> I suggest that pg_dump/t/002_pg_dump.pl could use a verification that
> the ->{regexp} thing is not empty.
I'm not sure how exactly to test for an empty pattern. The problem is,
we don't really want to test for an empty pattern, because
On Tue, 12 Mar 2024 at 19:28, Alvaro Herrera wrote:
>
> On 2024-Mar-12, Alvaro Herrera wrote:
>
> > Hmm, buildfarm member kestrel (which uses
> > -fsanitize=undefined,alignment) failed:
> >
> > # Running: libpq_pipeline -r 700 cancel port=49975 host=/tmp/dFh46H7YGc
> > dbname='postgres'
> > test
On Tue, Mar 12, 2024 at 12:00:00PM +0300, Alexander Lakhin wrote:
> Sorry for a bit off-topic, but I've remembered an anomaly with a similar
> assert:
> https://www.postgresql.org/message-id/17947-b9554521ad963c9c%40postgresql.org
Thanks for the reminder. The invalidation path with the stats
Hi,
Several animals are timing out while waiting for catchup,
sporadically. I don't know why. The oldest example I have found so
far by clicking around is:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink=2024-02-23%2015%3A44%3A35
So perhaps something was committed ~3 weeks ago
One more observation while I'm thinking about bulk_write.c... hmm, it
writes the data out and asks the checkpointer to fsync it, but doesn't
call smgrwriteback(). I assume that means that on Linux the physical
writeback sometimes won't happen until the checkpointer eventually
calls fsync()
David Rowley writes:
> So maybe the fix could be to set disable_cost to something like
> 1.0e110 and adjust compare_path_costs_fuzzily to not apply the
> fuzz_factor for paths >= disable_cost. However, I wonder if that
> risks the costs going infinite after a couple of cartesian joins.
On Thu, Mar 07, 2024 at 10:50:00AM -0600, Nathan Bossart wrote:
> Given all of this code was previously reviewed and committed, I am planning
> to forge ahead and commit this early next week, provided no objections or
> additional feedback materialize.
Jeff Davis and I spent some additional time
On Wed, 13 Mar 2024 at 08:55, Robert Haas wrote:
> But in the absence of that, we need some way to privilege the
> non-disabled paths over the disabled ones -- and I'd prefer to have
> something more principled than disable_cost, if we can work out the
> details.
The primary place I see issues
About 0002:
I think we should just drop it. Look at the changes it produces in the
plans for aliases XMLTABLE:
> @@ -1556,7 +1556,7 @@ SELECT f.* FROM xmldata, LATERAL
> xmltable('/ROWS/ROW[COUNTRY_NAME="Japan" or COU
> Output: f."COUNTRY_NAME", f."REGION_ID"
> -> Seq Scan on
On Wed, 13 Mar 2024 at 07:58, Cary Huang wrote:
> I noticed that the comment for declaring create_tidscan_paths() in
> src/include/optimizer/paths.h has a typo. The function is implemented in
> tidpath.c, not tidpath.h as stated, which does not exist.
Thank you. Pushed.
David
On Tue, Mar 12, 2024 at 3:36 PM Tom Lane wrote:
> Yeah. I keep thinking that the right solution is to not generate
> disabled paths in the first place if there are any other ways to
> produce the same relation. That has obvious order-of-operations
> problems though, and I've not been able to
Robert Haas writes:
> On Tue, Mar 12, 2024 at 1:32 PM Tom Lane wrote:
>> BTW, having written that paragraph, I wonder if we couldn't get
>> the same end result with a nearly one-line change that consists of
>> making disable_cost be IEEE infinity.
> I don't think so, because I think that what
Hello
I noticed that the comment for declaring create_tidscan_paths() in
src/include/optimizer/paths.h has a typo. The function is implemented in
tidpath.c, not tidpath.h as stated, which does not exist.
Made a small patch to correct it.
Thank you
Cary Huang
-
HighGo
While playing around with EXPLAIN and SubPlans, I noticed that there's
a bug in how this is handled for MERGE. For example:
drop table if exists src, tgt, ref;
create table src (a int, b text);
create table tgt (a int, b text);
create table ref (a int);
explain (verbose, costs off)
merge into
Hello,
Both the incremental JSON [1] and OAuth [2] patchsets would be
improved by json_errdetail(), which was removed from FRONTEND builds
in b44669b2ca:
>The routine providing a detailed error message based on the error code
>is made backend-only, the existing code being unsafe to use
On 2024-Mar-12, Alvaro Herrera wrote:
> Hmm, buildfarm member kestrel (which uses
> -fsanitize=undefined,alignment) failed:
>
> # Running: libpq_pipeline -r 700 cancel port=49975 host=/tmp/dFh46H7YGc
> dbname='postgres'
> test cancellations...
> libpq_pipeline:260: query did not fail when it
On Tue, Mar 12, 2024 at 1:32 PM Tom Lane wrote:
> BTW, having written that paragraph, I wonder if we couldn't get
> the same end result with a nearly one-line change that consists of
> making disable_cost be IEEE infinity. Years ago we didn't want
> to rely on IEEE float semantics in this area,
Hmm, buildfarm member kestrel (which uses
-fsanitize=undefined,alignment) failed:
# Running: libpq_pipeline -r 700 cancel port=49975 host=/tmp/dFh46H7YGc
dbname='postgres'
test cancellations...
libpq_pipeline:260: query did not fail when it was expected
On 2024-Mar-12, Jeff Davis wrote:
> Do not use perl empty patterns like // or qr// or s//.../, the behavior
> is too surprising for perl non-experts.
Yeah, nasty.
> There are a few such uses in
> our tests; patch attached. Unfortunately, there is no obvious way to
> automatically detect them so
Robert Haas writes:
> On Thu, Aug 3, 2023 at 5:22 AM Jian Guo wrote:
>> I have write an initial patch to retire the disable_cost GUC, which labeled
>> a flag on the Path struct instead of adding up a big cost which is hard to
>> estimate. Though it involved in tons of plan changes in
On Tue, 12 Mar 2024 at 18:18, Sergey Prokhorenko
wrote:
> Andrey and you simply did not read the RFC a little further down in the text:
You're totally right, sorry about that. Maybe it would be good to move
those subsections around a bit in the RFC though, so that anything
related to only one
Moved from discussion on -committers:
https://postgr.es/m/0ef325fa06e7a1605c4e119c4ecb637c67e5fb4e.ca...@j-davis.com
Summary:
Do not use perl empty patterns like // or qr// or s//.../, the behavior
is too surprising for perl non-experts. There are a few such uses in
our tests; patch attached.
On Mon, Mar 11, 2024 at 4:09 PM Amit Kapila wrote:
>
> I don't see how it will be easier for the user to choose the default
> value of 'max_slot_xid_age' compared to 'max_slot_wal_keep_size'. But,
> I agree similar to 'max_slot_wal_keep_size', 'max_slot_xid_age' can be
> another parameter to
Hi Jelte,
I am one of the contributors to this RFC.
Andrey's patch corresponds exactly to Fixed-Length Dedicated Counter Bits
(Method 1).
Andrey and you simply did not read the RFC a little further down in the text:
__
The
On 2024-Mar-12, Jelte Fennema-Nio wrote:
> On Tue, 12 Mar 2024 at 10:19, Alvaro Herrera wrote:
> > Here's a last one for the cfbot.
>
> Thanks for committing the first 3 patches btw. Attached a tiny change
> to 0001, which adds "(backing struct for PGcancelConn)" to the comment
> on
On Mon, Mar 11, 2024 at 3:44 PM Amit Kapila wrote:
>
> Yes, your understanding is correct. I wanted us to consider having new
> parameters like 'inactive_replication_slot_timeout' to be at
> slot-level instead of GUC. I think this new parameter doesn't seem to
> be the similar as
>
> No, we should be keeping the lock until the end of the transaction
> (which in this case would be just the one statement, but it would be the
> whole statement and all of the calls in it). See analyze.c:268 or
> so, where we call relation_close(onerel, NoLock); meaning we're closing
> the
Got it. Here is an updated patch where I added a corresponding comment.
Thank you!
Playing around I found one more place which could easily modified with
hash_seq_init_with_hash_value() call.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
Hi!
I looked at the changes and I liked them. Here are my thoughts:
0001:
1. I think, this is a good idea to use RAM. Since, it's still a UFS, and
we lose nothing in terms of testing, but win in speed significantly.
2. Change from "swapoff -a || true" to "swapoff -a" is legit in my view,
since
On Tue, Mar 12, 2024 at 9:11 PM Bertrand Drouvot
wrote:
>
> > AFAIR, we don't prevent similar invalidations due to
> > 'max_slot_wal_keep_size' for sync slots,
>
> Right, we'd invalidate them on the standby should the standby sync slot
> restart_lsn
> exceeds the limit.
Right. Help me
On Tue, 12 Mar 2024 at 15:04, Jelte Fennema-Nio wrote:
> Attached a tiny change to 0001
One more tiny comment change, stating that pg_cancel is used by the
deprecated PQcancel function.
v36-0001-libpq-Add-encrypted-and-non-blocking-query-cance.patch
Description: Binary data
On Tue, Mar 12, 2024 at 5:51 PM Amit Kapila wrote:
>
> > Would that make sense to "simply" discard/prevent those kind of
> > invalidations
> > for "synced" slot on standby? I mean, do they make sense given the fact that
> > those slots are not usable until the standby is promoted?
>
> AFAIR, we
On Tue, 12 Mar 2024 at 07:32, Michael Paquier wrote:
> Sure, there is no problem in discussing a patch to implement a
> behavior. But I disagree about taking a risk in merging something
> that could become non-compliant with the approved RFC, if the draft is
> approved at the end, of course.
Hi,
On Tue, Mar 12, 2024 at 05:51:43PM +0530, Amit Kapila wrote:
> On Tue, Mar 12, 2024 at 1:24 PM Bertrand Drouvot
> wrote:
> >
> > On Fri, Mar 08, 2024 at 10:42:20PM +0530, Bharath Rupireddy wrote:
> > > On Wed, Mar 6, 2024 at 4:49 PM Amit Kapila
> > > wrote:
> > > >
> > > > You might want
On Mon, 11 Mar 2024 at 19:27, Andrey M. Borodin wrote:
> Sorry for this long and vague explanation, if it still seems too uncertain we
> can have a chat or something like that. I don't think this number picking
> stuff deserve to be commented, because it still is quite close to random. RFC
>
On Mon, Mar 11, 2024 at 11:26 AM Amit Kapila wrote:
>
> > Hm. I get the concern. Are you okay with having inavlidation_reason
> > separately for both logical and physical slots? In such a case,
> > logical slots that got invalidated on the standby will have duplicate
> > info in conflict_reason
On Mon, Mar 11, 2024 at 2:43 PM Andrei Lepikhov
wrote:
> On 11/3/2024 18:31, Alexander Korotkov wrote:
> >> I'm not convinced about this limit. The initial reason was to combine
> >> long lists of ORs into the array because such a transformation made at
> >> an early stage increases efficiency.
>
On Tue, Mar 12, 2024 at 6:05 PM Amit Kapila wrote:
>
> The patch looks mostly good to me. I have changed the comments and
> commit message in the attached. I am planning to push this tomorrow
> unless you or others have any comments on it.
LGTM.
--
Bharath Rupireddy
PostgreSQL Contributors
> On 12 Mar 2024, at 14:38, Xing Guo wrote:
> Would it be possible to add a new switch in the pgxs.mk framework to
> allow users to disable this feature?
Something like that doesn't seem unreasonable I think.
--
Daniel Gustafsson
> On 12 Mar 2024, at 15:19, Tom Lane wrote:
> users are probably going to end up applying an AS clause most of
> the time if they care about the column name at all.
If anything, we could perhaps add a short note in the CASE documentation about
column naming, the way it's phrased now a new user
On Thu, Aug 3, 2023 at 5:22 AM Jian Guo wrote:
> I have write an initial patch to retire the disable_cost GUC, which labeled a
> flag on the Path struct instead of adding up a big cost which is hard to
> estimate. Though it involved in tons of plan changes in regression tests, I
> have tested
"David G. Johnston" writes:
> On Tuesday, March 12, 2024, adjk...@126.com wrote:
>> Nee we change the title of the case-when output column?
> Choosing either a or b as the label seems wrong and probably worth changing
> to something that has no meaning and encourages the application of a column
On Tue, 12 Mar 2024 at 10:19, Alvaro Herrera wrote:
> Here's a last one for the cfbot.
Thanks for committing the first 3 patches btw. Attached a tiny change
to 0001, which adds "(backing struct for PGcancelConn)" to the comment
on pg_cancel_conn.
From d340fde6883a249fd7c1a90033675a3b5edb603e Mon
Hi,
> > Aleksander, I would greatly appreciate if you join me in managing CF.
> > Together we can move more stuff :)
> > Currently, I'm going through "SQL Commands". And so far I had not come to
> > "Performance" and "Server Features" at all... So if you can handle updating
> > statuses of
Hi Andrey,
> > If you need any help please let me know.
>
> Aleksander, I would greatly appreciate if you join me in managing CF.
> Together we can move more stuff :)
> Currently, I'm going through "SQL Commands". And so far I had not come to
> "Performance" and "Server Features" at all... So
Hi hackers,
When the PostgreSQL server is configured with --with-llvm, the pgxs.mk
framework will generate LLVM bitcode for extensions automatically.
Sometimes, I don't want to generate bitcode for some extensions. I can
turn off this feature by specifying with_llvm=0 in the make command.
```
On Mon, Mar 11, 2024 at 11:11 PM Jingxian Li wrote:
> Your version changes less code than mine by pushing the nowait flag down
> into ProcSleep(). This looks fine in general, except for a little advice,
> which I don't think there is necessary to add 'waiting' suffix to the
> process name in
Hi,
> > On 6 Mar 2024, at 18:49, Andrey M. Borodin wrote:
> >
> > Here are statuses for "Refactoring" section:
>
> [...]
> Aleksander, I would greatly appreciate if you join me in managing CF.
> Together we can move more stuff :)
> Currently, I'm going through "SQL Commands". And so far I had
On 3/12/24 13:47, Peter Eisentraut wrote:
> On 06.03.24 22:34, Tomas Vondra wrote:
>> 0001
>>
>>
>> 1) I think this bit in ALTER STATISTICS docs is wrong:
>>
>> - > class="parameter">new_target
>> + SET STATISTICS { > class="parameter">integer | DEFAULT }
>>
>> because it means
Hi,
> I took a closer look at this patch over the last couple days, and I did
> a bunch of benchmarks to see how expensive the accounting is. The good
> news is that I haven't observed any overhead - I did two simple tests,
> that I think would be particularly sensitive to this:
>
> [...]
Just
On Tuesday, March 12, 2024, adjk...@126.com wrote:
>
> Nee we change the title of the case-when output column?
>
>
Choosing either a or b as the label seems wrong and probably worth changing
to something that has no meaning and encourages the application of a column
alias.
David J.
Hi David,
> I have finished the reworking of this particular patch series, and have tried
> to
> organize this in such a way that it will be easily reviewable. It is
> constructed progressively to be able to follow what is happening here. As
> such,
> each individual commit is not guaranteed
On 06.03.24 22:34, Tomas Vondra wrote:
0001
1) I think this bit in ALTER STATISTICS docs is wrong:
- new_target
+ SET STATISTICS { integer | DEFAULT }
because it means we now have list entries for name, ..., new_name,
new_schema, and then suddenly "SET STATISTICS { integer |
Hi hackers,
Below is a `case when` demo,
```sql
create table foo(a int, b int);
insert into foo values (1, 2);
select case 1 when 1 then a else b end from foo;
```
Currently, psql output is,
```text
b
---
1
(1 row)
```
At the first glance at the output column title, I assume the result
On Thu, Jan 25, 2024 at 5:07 PM Amit Kapila wrote:
>
> On Thu, Jan 25, 2024 at 4:27 PM Bharath Rupireddy
> wrote:
> >
> > Thanks. I'll wait a while and then add it to CF to not lose it in the wild.
> >
>
> Feel free to add it to CF. However, I do plan to look at it in the
> next few days.
>
The
On Mon, 26 Feb 2024 at 21:54, stepan rutz wrote:
>
> Hi Matthias, thanks for picking it up. I still believe this is valuable
> to a lot of people out there. Thanks for dealing with my proposal.
> Matthias, Tom, Tomas everyone.
>
> Two (more or less) controversial remarks from side.
>
> 1.
On Tue, Mar 12, 2024 at 1:24 PM Bertrand Drouvot
wrote:
>
> On Fri, Mar 08, 2024 at 10:42:20PM +0530, Bharath Rupireddy wrote:
> > On Wed, Mar 6, 2024 at 4:49 PM Amit Kapila wrote:
> > >
> > > You might want to consider its interaction with sync slots on standby.
> > > Say, there is no activity
On Sun, Jan 14, 2024 at 4:35 AM Alexander Korotkov wrote:
> On Sat, Jan 13, 2024 at 7:33 PM Dmitry Koval wrote:
> > Thank you, there is one small point left (in the comment): can you
> > replace "guarantteed to be to be newer" to "guaranteed to be newer",
> > file
Hi Himanshu,
On Tue, Mar 12, 2024 at 6:42 PM Himanshu Upadhyaya
wrote:
>
> Hi,
>
> wanted to share the below case:
>
> ‘postgres[146443]=#’SELECT JSON_EXISTS(jsonb '{"customer_name": "test",
> "salary":1000, "department_id":1}', '$.* ? (@== $dept_id && @ == $sal)'
> PASSING 1000 AS sal, 1 as
On Thu, 7 Mar 2024 at 19:37, Michail Nikolaev
wrote:
>
> Hello!
>
> > I'm not a fan of this approach. Changing visibility and cleanup
> > semantics to only benefit R/CIC sounds like a pain to work with in
> > essentially all visibility-related code. I'd much rather have to deal
> > with another
On Wed, Mar 6, 2024 at 5:32 PM Richard Guo wrote:
> Please note that this patch only addresses the order of header file
> includes in backend modules (and might not be thorough). It is possible
> that other modules may have a similar issue, but I have not evaluated
> them yet.
>
Attached is
On Mon, 11 Mar 2024 at 17:16, Amit Kapila wrote:
>
> On Tue, Feb 27, 2024 at 2:07 PM Hayato Kuroda (Fujitsu)
> wrote:
> >
> > > PSA the patch for implementing it. It is basically same as Ian's one.
> > > However, this patch still cannot satisfy the condition 3).
> > >
> > > `pg_basebackup -D
On Tue, 12 Mar 2024 at 10:53, Jelte Fennema-Nio wrote:
> I'd rather fail as hard as possible when someone is using the API
> wrongly.
To be clear, this is my way of looking at it. If you feel strongly
about that we should not change conn.status, I'm fine with making that
change to the patchset.
On Fri, Mar 8, 2024 at 6:58 PM Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> On Thu, Mar 7, 2024 at 12:39 PM Richard Guo
> wrote:
> >
> > While rebasing one of my patches I noticed that the header file includes
> > in relnode.c are not sorted in order. So I wrote a naive
> On 12 Mar 2024, at 09:49, Heikki Linnakangas wrote:
>> Barring objections, I'll commit and backpatch the attached to fix that.
>
> Committed.
Sorry for being slow to review, but +1 on this change.
--
Daniel Gustafsson
1 - 100 of 130 matches
Mail list logo
