On 12.03.24 14:38, Xing Guo wrote:
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 th
Hi, some minor issues:
[ WITH with_query [, ...] ]
MERGE INTO [ ONLY ] target_table_name [ * ] [ [ AS ]
target_alias ]
USING data_source ON
join_condition
when_clause [...]
[ RETURNING * | output_expression [ [ AS ]
output_name ] [, ...] ]
here the "WITH" part should have "[ RECURSIVE ]" like:
[
On 2024-03-13 We 02:31, Andrew Dunstan wrote:
On 2024-03-13 We 02:22, Peter Eisentraut wrote:
On 13.03.24 07:11, Andrew Dunstan wrote:
I and several colleagues have just been trying to build from a
tarball with meson.
That seems pretty awful and unfriendly and I didn't see anything
about
On Tue, Mar 12, 2024 at 08:38:43PM -0400, Andrew Dunstan wrote:
> On 2024-03-12 Tu 14:43, Jacob Champion wrote:
>> Two notes that I wanted to point out explicitly:
>> - On the other thread, Daniel contributed a destroyStringInfo()
>> counterpart for makeStringInfo(), which is optional but seemed us
On 2024-03-13 We 02:22, Peter Eisentraut wrote:
On 13.03.24 07:11, Andrew Dunstan wrote:
I and several colleagues have just been trying to build from a
tarball with meson.
That seems pretty awful and unfriendly and I didn't see anything
about it in the docs.
At https://www.postgresql.org/
On Wed, 13 Mar 2024 at 10:12, Zhijie Hou (Fujitsu)
wrote:
>
> 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 foll
On 13.03.24 07:11, Andrew Dunstan wrote:
I and several colleagues have just been trying to build from a tarball
with meson.
That seems pretty awful and unfriendly and I didn't see anything about
it in the docs.
At https://www.postgresql.org/docs/16/install-requirements.html is says:
"""
Alt
On Wed, Mar 13, 2024 at 01:12:28PM +1300, David Steele wrote:
> On 2/29/24 16:55, Michael Paquier wrote:
>> +unlink("$backup_dir/postmaster.pid")
>> +or BAIL_OUT("unable to unlink $backup_dir/postmaster.pid");
>> +unlink("$backup_dir/postmaster.opts")
>> +or BAIL_OUT("unable to unlink $back
On Fri, Mar 8, 2024, at 6:44 AM, Hayato Kuroda (Fujitsu) wrote:
> Hmm, right. I considered below improvements. Tomas and Euler, how do you
> think?
I'm posting a new patchset v28.
I changed the way that the check function works. From the usability
perspective, it is better to test all conditions
I and several colleagues have just been trying to build from a tarball
with meson.
`meson setup build .` results in this:
[...]
Message: checking for file conflicts between source and build directory
meson.build:2963:2: ERROR: Problem encountered:
Non-clean source code directory det
On Tue, 12 Mar 2024 22:07:17 -0500
Nathan Bossart wrote:
> I did some light editing to prepare this for commit.
Thank you. I confirmed the test you improved and I am fine with that.
Regards,
Yugo Nagata
>
> --
> Nathan Bossart
> Amazon Web Services: https://aws.amazon.com
--
Yugo NAGATA
On 12.03.24 00:44, Michael Paquier wrote:
Anyway, there is one piece of this patch set that I think has a lot of
value outside of the discussion with access methods, which is to
redesign pg_sequence_last_value so as it returns a (last_value,
is_called) tuple rather than a (last_value). This has
> 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 releva
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 optimis
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 som
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]
https://github.com/postgres/postgres/blob/0b84f5c419a300dc1b1a70cf63
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 pr
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 na
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 execu
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 comm
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:
> >> https://commitfest.postgresql.org/47/4816
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 th
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 t
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
> > the
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 r
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 flaky
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 invalid
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 t
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 pg_column_toast_chunk
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 backe
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 like
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 lik
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 040_standby_failover_slo
> 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 ad
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 CFLA
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 c
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 drop
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&dt=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() sequent
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.
Perhaps.
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 l
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 wi
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 public.xm
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 mak
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 wi
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 S
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 tgt
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 in
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 was
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, b
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
https://buildfarm.postgresql.org/cgi-bin/s
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 regression
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 met
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. Un
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 allow
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 followin
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 pg_cancel_co
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 'max_slot_wal_kee
>
> 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 rela
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 understand
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
v36-0002-Start-usi
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 d
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. Thi
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 to
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
> gi
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 an
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 Team
> 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 c
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 o
"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 that
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 if
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.
```
mak
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 funct
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 n
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 we
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 wa
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 t
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 | DEF
1 - 100 of 135 matches
Mail list logo
