On Tue, Aug 27, 2024 at 04:01:58PM -0500, Nathan Bossart wrote:
> I've been thinking about this thread some more, and I'm finding myself -0.5
> for adding relpersistence inheritance for UNLOGGED. There are a few
> reasons:
>
> * Existing partitioned tables may be marked UNLOGGED, and after upgrad
On 29.08.24 03:22, Thomas Munro wrote:
Oh, I missed something: I think we're missing FileAcces(), in case the
vfd has to be re-opened, no?
Fixed, thanks.
On Thu, Aug 29, 2024 at 8:44 AM Masahiko Sawada wrote:
>
> On Wed, Aug 28, 2024 at 1:06 AM Amit Kapila wrote:
> >
> > On Mon, May 20, 2024 at 1:49 PM Masahiko Sawada
> > wrote:
> > >
> > > As Euler mentioned earlier, I think it's a decision not to replicate
> > > generated columns because we do
Hi,
Thanks for looking into this.
On Mon, Aug 26, 2024 at 4:35 PM Amit Kapila wrote:
>
> Few comments on 0001:
> 1.
> @@ -651,6 +651,13 @@ synchronize_one_slot(RemoteSlot *remote_slot, Oid
>
> + /*
> + * Skip the sync if the local slot is already invalidated. We do this
> + * beforehand to avoid
Thomas Munro writes:
> The fix I propose to commit shortly is just the first of those new
> lines, to homogenise the initial state. See attached. The previous
> idea works too, I think, but this bigger hammer is more obviously
> removing variation.
+1, but a comment explaining the need for the
On Sat, Aug 24, 2024 at 10:43 AM Thomas Munro wrote:
> On Sat, Aug 24, 2024 at 10:33 AM Nathan Bossart
> wrote:
> > I am seeing the exact problem described in this thread on my laptop since
> > commit 490f869. I have yet to do a thorough investigation, but what I've
> > seen thus far does seem t
On Thursday, August 29, 2024 11:18 AM shveta malik
wrote:
>
> On Thu, Aug 29, 2024 at 4:59 AM Peter Smith
> wrote:
> >
> > On Wed, Aug 28, 2024 at 9:19 PM Amit Kapila
> wrote:
> > >
> > > On Wed, Aug 28, 2024 at 11:43 AM shveta malik
> wrote:
> > > >
> > > > Thanks for the patch. Just thinkin
On Wed, Aug 28, 2024 at 08:28:03PM -0500, Nathan Bossart wrote:
> On Thu, Aug 29, 2024 at 08:00:52AM +0900, Michael Paquier wrote:
>> Indeed, pg_sequence_read_tuple() would not reflect the reality, some
>> ideas:
>> - pg_sequence_read_data
>> - pg_sequence_get_data
>> - pg_sequence_data
>> - More
On Wed, Aug 28, 2024 at 4:07 PM shveta malik wrote:
>
> > On Wed, Aug 28, 2024 at 10:30 AM Ajin Cherian wrote:
> > >
>
> The review is WIP. Please find a few comments on patch001.
>
More comments on ptach001 in continuation of previous comments:
6)
SetDefaultResolvers() can be called from
parse
Japin Li writes:
> On Wed, 28 Aug 2024 at 12:27, Andy Fan wrote:
>> Japin Li writes:
>>
> Nitpick, the minlen is smaller than maxlen, so the maxlen cannot be zero.
>
> After giving it some more thought, it would also be helpful if maxlen is
> equal to minlen.
>
> For example, I want have each r
Tomas Vondra writes:
Hi Tomas,
> Yeah. I think we have agreement on 0001-0007.
Yes, the design of 0001-0007 looks good to me and because of the
existing compexitity, I want to foucs on this part for now. I am doing
code review from yesterday, and now my work is done. Just some small
questions:
Richard Guo 于2024年8月29日周四 10:46写道：
> On Wed, Aug 28, 2024 at 9:01 PM Robert Haas wrote:
> > On Tue, Aug 27, 2024 at 11:57 PM Tender Wang wrote:
> > > I haven't look all of them. I just pick few simple plan test(e.g.
> 19.sql, 45.sql).
> > > For example, 19.sql, eager agg pushdown doesn't get la
Richard Guo 于2024年8月29日周四 10:46写道：
> On Wed, Aug 28, 2024 at 9:01 PM Robert Haas wrote:
> > On Tue, Aug 27, 2024 at 11:57 PM Tender Wang wrote:
> > > I haven't look all of them. I just pick few simple plan test(e.g.
> 19.sql, 45.sql).
> > > For example, 19.sql, eager agg pushdown doesn't get la
On Thu, Aug 29, 2024 at 4:59 AM Peter Smith wrote:
>
> On Wed, Aug 28, 2024 at 9:19 PM Amit Kapila wrote:
> >
> > On Wed, Aug 28, 2024 at 11:43 AM shveta malik
> > wrote:
> > >
> > > Thanks for the patch. Just thinking out loud, since we have names like
> > > 'apply_error_count', 'sync_error_co
On Wed, Aug 28, 2024 at 1:06 AM Amit Kapila wrote:
>
> On Mon, May 20, 2024 at 1:49 PM Masahiko Sawada wrote:
> >
> > On Wed, May 8, 2024 at 4:14 PM Shubham Khanna
> > wrote:
> > >
> > > On Wed, May 8, 2024 at 11:39 AM Rajendra Kumar Dangwal
> > > wrote:
> > > >
> > > > Hi PG Hackers.
> > > >
>
Andrei Lepikhov writes:
> I think, the expression_returns_set examination doesn't necessary and we
> can replace it with an assertion, if needed (see attachment).
I think you may be right that this test is not really necessary given
the upstream parser test, but nonetheless I'm not inclined to r
On Wed, Aug 28, 2024 at 9:01 PM Robert Haas wrote:
> On Tue, Aug 27, 2024 at 11:57 PM Tender Wang wrote:
> > I haven't look all of them. I just pick few simple plan test(e.g. 19.sql,
> > 45.sql).
> > For example, 19.sql, eager agg pushdown doesn't get large gain, but a little
> > performance reg
On Wed, Aug 28, 2024 at 11:57 AM Tender Wang wrote:
> Rectenly, I do some benchmark tests, mainly on tpch and tpcds.
> tpch tests have no plan diff, so I do not continue to test on tpch.
> tpcds(10GB) tests have 22 plan diff as below:
> 4.sql, 5.sql, 8.sql,11.sql,19.sql,23.sql,31.sql,
> 33.sql,39
On Fri, Aug 23, 2024 at 11:59 PM Robert Haas wrote:
> Here are some initial, high-level thoughts about this patch set.
Thank you for your review and feedback! It helps a lot in moving this
work forward.
> 1. As far as I can see, there's no real performance testing on this
> thread. I expect tha
On Thursday, August 29, 2024 8:31 AM Peter Smith wrote:
Hi,
> I tried an experiment where I deliberately violated a primary key during
> initial
> table synchronization.
>
> For example:
...
> test_sub=# 2024-08-29 09:53:57.245 AEST [4345] LOG: logical replication
> apply worker for subscript
On Thu, Aug 29, 2024 at 4:47 AM Tom Lane wrote:
> In the meantime, I think this test case is mighty artificial,
> and it wouldn't bother me any to just take it out again for the
> time being.
Yeah, I think we can remove the 't1.two+t2.two' test case if we go
with your proposed patch to address th
On Thu, Aug 29, 2024 at 08:00:52AM +0900, Michael Paquier wrote:
> On Mon, Aug 26, 2024 at 09:19:06AM -0500, Nathan Bossart wrote:
>> The patch looks reasonable to me. Do you think the name of the function
>> still makes sense now that 1) we might have different sequence AMs in the
>> near future
Oh, I missed something: I think we're missing FileAcces(), in case the
vfd has to be re-opened, no?
On Wed, Aug 28, 2024 at 04:58:16PM +0200, Andreas Karlsson wrote:
> When working on the regex code I noticed that the labels of
> PG_Locale_Strategy had become inconsistent with the addition of
> PG_REGEX_BUILTIN but while at it I also noticed that PG_REGEX_LOCALE_WIDE_L
> and PG_REGEX_LOCALE_1BYTE
On 2024-Aug-28, Tom Lane wrote:
> Heikki Linnakangas writes:
> > Hmm, I don't see the issue. It's an uncommon sentence structure, but it
> > was there before this patch, and it's correct AFAICS. If you grep for
> > "which see ", you'll find some more examples of that.
>
> I didn't check the g
Hi Hou-San.
I tried an experiment where I deliberately violated a primary key
during initial table synchronization.
For example:
test_sub=# create table t1(a int primary key);
CREATE TABLE
test_sub=# insert into t1 values(1);
INSERT 0 1
test_sub=# create subscription sub1 connection 'dbname=te
On Wed, Aug 28, 2024 at 07:25:59PM -0400, Tom Lane wrote:
> Jeff Davis writes:
> > Beyond awkwardness, one case where it matters is the interaction
> > between an extension that provides hints and an extension that offers a
> > CustomScan. How is the hints extension supposed to disable a path it
>
On Mon, Aug 26, 2024 at 09:32:54AM +0300, Heikki Linnakangas wrote:
> Currently, we rely on the fact that all the xl_xact_* structs require
> sizeof(int) alignment. See comment above struct xl_xact_xinfo.
Thanks, I have missed this part. So that explains the alignment I'd
better use in the record
On Wed, Aug 28, 2024 at 9:19 PM Amit Kapila wrote:
>
> On Wed, Aug 28, 2024 at 11:43 AM shveta malik wrote:
> >
> > Thanks for the patch. Just thinking out loud, since we have names like
> > 'apply_error_count', 'sync_error_count' which tells that they are
> > actually error-count, will it be bet
Jeff Davis writes:
> Beyond awkwardness, one case where it matters is the interaction
> between an extension that provides hints and an extension that offers a
> CustomScan. How is the hints extension supposed to disable a path it
> doesn't know about?
This does not seem remarkably problematic to
On Wed, 2024-08-28 at 16:35 -0400, Robert Haas wrote:
> On Wed, Aug 28, 2024 at 4:29 PM Jeff Davis wrote:
> > Preserving a path for the right amount of time seems like the
> > primary
> > challenge for most of the use cases you raised (removing paths is
> > easier than resurrecting one that was pr
On Mon, Aug 26, 2024 at 09:19:06AM -0500, Nathan Bossart wrote:
> I am fine with changes to this function that would allow it to be
> generically useful for all sequence AMs, provided that it can still be used
> for dumpSequenceData(). I only included log_cnt because
> pg_sequence_read_tuple() is
On Wed, Aug 28, 2024 at 04:27:38PM -0400, Robert Haas wrote:
> - Add a call to
> pgstat_report_query_id(queryDesc->plannedstmt->queryId, false) to the
> top of ExecutorRun() with an appropriate comment.
> - Fix the incorrect comment mentioned above.
> - Back-patch to all releases containing 4f0b096
Sorry! I'm having email delivery issues. I thought the first few
didn't go through. I'm working through email DKMS problems where we
were incompatible with the mailing list.
It sounds like it's fixed now! Sorry for the spam!
On 8/28/24 18:38, Tom Lane wrote:
We don't really need four cop
We don't really need four copies of this patch.
regards, tom lane
Hi Hackers!
This would be version v1 of this feature
Basically, the subject says it all: pl/pgperl Patch for being able to
tell which function you're in.
This is a hashref so it will be possible to populate new and exciting
other details in the future as the need arises
This also greatly imp
Hi Hackers!
This would be version v1 of this feature
Basically, the subject says it all: pl/pgperl Patch for being able to
tell which function you're in.
This is a hashref so it will be possible to populate new and exciting
other details in the future as the need arises
This also greatly imp
On Wed, Aug 28, 2024 at 9:00 PM Alexander Lakhin wrote:
> 2024-08-28 08:41:59.304 UTC [338251] DEBUG: starting background worker
> process "parallel worker for PID 338262"
> 2024-08-28 08:41:59.304 UTC [338251] DEBUG: starting background worker
> process "parallel worker for PID 338262"
> 202
Hi Hackers!
This would be version v1 of this feature
Basically, the subject says it all: pl/pgperl Patch for being able to
tell which function you're in.
This is a hashref so it will be possible to populate new and exciting
other details in the future as the need arises
This also greatly imp
Hi Hackers!
This would be version v1 of this feature
Basically, the subject says it all: pl/pgperl Patch for being able to
tell which function you're in.
This is a hashref so it will be possible to populate new and exciting
other details in the future as the need arises
This also greatly imp
I spent some time cleaning up names, comments, etc. Barring additional
feedback, I'm planning to commit this stuff in the September commitfest so
that it has plenty of time to bake in the buildfarm.
--
nathan
>From c38137cd2cbc45c348e8e144f864a62c08bd7b7f Mon Sep 17 00:00:00 2001
From: Nathan Bo
Hi Amit,
On Mon, Aug 26, 2024 at 11:00 PM Amit Kapila wrote:
> I wanted a simple test where in the first case you use
> synchronous_standby_names = 'ANY 3 (A,B,C,D,E)' and in the second case
> use standby_slot_names = A_slot, B_slot, C_slot, D_slot, E_slot. You
> can try some variations of it as
Richard Guo writes:
> Exactly. What Tom's patch does is that if the expression contains
> Vars/PHVs that belong to the subquery, and does not contain any
> non-strict constructs, then it can escape being wrapped.
> In expression 't1.two+t2.two', 't2.two' is a Var that belongs to the
> subquery,
On Wed, Aug 28, 2024 at 4:29 PM Jeff Davis wrote:
> Preserving a path for the right amount of time seems like the primary
> challenge for most of the use cases you raised (removing paths is
> easier than resurrecting one that was pruned too early). If we try to
> keep a path around, that implies t
On Mon, 2024-08-26 at 12:32 -0400, Robert Haas wrote:
> I think there are two basic approaches that are possible here. If
> someone sees a third option, let me know. First, we could allow users
> to hook add_path() and add_partial_path().
...
> The other possible approach is to allow extensions
Hi,
Suppose you set compute_query_id=on and then execute a query using
either the simple or the extended query protocol. With the simple
query protocol, the query ID is advertised during query execution;
with the extended query protocol, it's not. Here's a test case to
demonstrate:
robert.haas=#
On Wed, Aug 28, 2024 at 3:23 PM Jeff Davis wrote:
> On Tue, 2024-08-27 at 15:11 -0400, Robert Haas wrote:
> > - control over scan methods
> > - control over index selection
> > - control over join methods
> > - control over join order
>
> I suggest we split join order into "commutative" and "assoc
On Tue, 2024-08-27 at 15:11 -0400, Robert Haas wrote:
> - control over scan methods
> - control over index selection
> - control over join methods
> - control over join order
I suggest we split join order into "commutative" and "associative".
The former is both useful and seems relatively easy --
On Wed, Aug 28, 2024 at 2:41 PM Andreas Karlsson wrote:
> Not sure if it is correct or not but from some googling it seems to be a
> direct translation of "quod vide". I think "for which, see" would likely
> be more proper English but it is not my native language and we use
> "which see" elsewhere
On 16.08.24 02:48, Thomas Munro wrote:
2. A similar argument applies to Windows canonicalisation. CREATE
COLLATION isn't doing it. CREATE DATABASE is, but again, what is the
point? See previous.
I don't really know about Windows locales. But we are doing
canonicalization of ICU locale nam
On 11.08.24 00:11, Thomas Munro wrote:
v4 adds error handling, in case newlocale("C") fails. I created CF
entry #5166 for this.
I took a look at this. It was quite a complicated discussion that led
to this, but I agree with the solution that was arrived at.
I suggest that the simplificatio
Heikki Linnakangas writes:
> On 28/08/2024 18:26, Andreas Karlsson wrote:
>> Small typo with the extra "which" which makes the sentence not flow
>> correctly
>> "This is called from CreateSharedMemoryAndSemaphores(), which see for
>> more comments."
> Hmm, I don't see the issue. It's an uncommon
On 8/28/24 7:26 PM, Heikki Linnakangas wrote:
Hmm, I don't see the issue. It's an uncommon sentence structure, but it
was there before this patch, and it's correct AFAICS. If you grep for
"which see ", you'll find some more examples of that.
Not sure if it is correct or not but from some googl
On 8/28/24 17:53, Andreas Karlsson wrote:
> On 8/9/24 6:59 PM, Abdoulaye Ba wrote:> The primary use case for
> this hook is to allow extensions to account
>> for additional storage mechanisms that are not covered by the
>> default PostgreSQL relation size calculations. For instance,
Hello Alvaro,
Let me show you another related anomaly, which drongo kindly discovered
recently: [1]. That test failed with:
SELECT dblink_cancel_query('dtest1');
- dblink_cancel_query
--
- OK
+ dblink_cancel_query
+--
+ cancel request timed out
(1 r
On Wed, Aug 28, 2024 at 10:47:32AM +0200, Peter Eisentraut wrote:
>
>
>
>
> Change
> lock mode output labels (Bruce Momjian)
>
>
>
> to
>
>
>
> Change
> lock mode output labels (Bruce Momjian)
>
>
> Author: Bruce Momjian
> 2023-09-2
On 28/08/2024 18:26, Andreas Karlsson wrote:
On 8/7/24 2:08 PM, Heikki Linnakangas wrote:
The attached patches rename them to follow the usual naming convention.
The InitLocks() function is refactored a bit more, splitting the
per-backend initialization to a separate InitLockManagerAccess()
func
On Wed, Aug 28, 2024 at 10:58 AM Robert Haas wrote:
> Ever since I read
> https://15721.courses.cs.cmu.edu/spring2020/papers/22-costmodels/p204-leis.pdf
> I have believed that the cardinality misestimate leading to nested
> loop plans is just because we're doing something dumb.
> We don't even ha
On Wed, Aug 28, 2024 at 8:37 AM Robert Haas wrote:
> This has a big advantage over what I proposed yesterday in that it's
> basically declarative. With one call to the hook, you get all the
> information about the join order that you could ever want. That's
> really nice.
Hmm. On further thought,
Thanks Matthias, table_index_build_scan sounds like what I"m looking for.
On Wed, Aug 28, 2024 at 9:29 PM Matthias van de Meent <
boekewurm+postg...@gmail.com> wrote:
> On Wed, 28 Aug 2024 at 16:21, Sushrut Shivaswamy
> wrote:
> >
> > Hi,
> >
> > I'm trying to create an Index Access Method Rotin
On 8/15/24 12:55 AM, Jeff Davis wrote:
This overlaps a bit with what Peter already proposed here:
https://www.postgresql.org/message-id/4f562d84-87f4-44dc-8946-01d6c437936f%40eisentraut.org
right?
Maybe I am missing something but not as far as I can see. It is related
but I do not see any ov
On 8/9/24 8:24 PM, Jeff Davis wrote:
On Fri, 2024-08-09 at 13:41 +0200, Andreas Karlsson wrote:
I am leaning towards that we should write our own pure ascii
functions
for this.
That makes sense for a lot of call sites, but it could cause breakage
if we aren't careful.
Since we do not suppo
On Wed, 28 Aug 2024 at 16:21, Sushrut Shivaswamy
wrote:
>
> Hi,
>
> I'm trying to create an Index Access Method Roting.
> Building the index requires iterating over all rows and calculating,
> which is then used during index construction.
>
> The methods in the IndexAmRoutine seem to deal with ins
On 8/9/24 6:59 PM, Abdoulaye Ba wrote:> The primary use case for
this hook is to allow extensions to account
for additional storage mechanisms that are not covered by the
default PostgreSQL relation size calculations. For instance, in our
project, we are working with an external i
On 8/7/24 2:08 PM, Heikki Linnakangas wrote:
The attached patches rename them to follow the usual naming convention.
The InitLocks() function is refactored a bit more, splitting the
per-backend initialization to a separate InitLockManagerAccess()
function. That's why it's in a separate commit.
Hi,
On Wed, 28 Aug 2024 at 18:11, Jacob Champion
wrote:
>
> On Wed, Aug 28, 2024 at 6:41 AM Ashutosh Bapat
> wrote:
> > Nazir, since you authored c3382a3c3cc, can you please provide input
> > that Jacob needs?
>
> Specifically, why the PG_TEST_EXTRA variable was being exported at the
> src/test
Hi,
On Wed, 28 Aug 2024 at 16:41, Ashutosh Bapat
wrote:
>
> On Wed, Aug 28, 2024 at 5:26 PM Ashutosh Bapat
> wrote:
> >
> > On Fri, Aug 23, 2024 at 9:55 PM Jacob Champion
> > wrote:
> > >
> > > On Fri, Aug 23, 2024 at 5:59 AM Ashutosh Bapat
> > > wrote:
> > > > If I run
> > > > export PG_TEST_
On Wed, Aug 28, 2024 at 6:41 AM Ashutosh Bapat
wrote:
> Nazir, since you authored c3382a3c3cc, can you please provide input
> that Jacob needs?
Specifically, why the PG_TEST_EXTRA variable was being exported at the
src/test level only. If there's no longer a use case being targeted,
we can always
Hi hackers,
This patch introduces four new columns in pg_stat_database:
* parallel_worker_planned
* parallel_worker_launched
* parallel_maint_worker_planned
* parallel_maint_worker_launched
The intent is to help administrators evaluate the usage of parallel
workers in their databases and help
Hi,
When working on the regex code I noticed that the labels of
PG_Locale_Strategy had become inconsistent with the addition of
PG_REGEX_BUILTIN but while at it I also noticed that
PG_REGEX_LOCALE_WIDE_L and PG_REGEX_LOCALE_1BYTE_L did not make it
obvious that they were libc-related so I prop
On Wed, Aug 28, 2024 at 9:46 AM Jakub Wartak
wrote:
> As a somewhat tiny culprit of the self-flaming done by Robert (due to
> nagging him about this in the past on various occasions), I'm of
> course obligated to +1 to any work related to giving end-users/DBA the
> ability to cage the plans genera
Hi,
I would like to understand the pull_up_simple_values code a little bit more.
Pull-up of simple values was implemented in 2015 by commit f4abd02. In
the is_simple_values I see a check on the expression_returns_set() of
the RTE values list.
But since d43a619 in 2017 the check_srf_call_place
Hi,
I'm trying to create an Index Access Method Roting.
Building the index requires iterating over all rows and calculating,
which is then used during index construction.
The methods in the IndexAmRoutine seem to deal with insertion / index build
one row at a time.
Is there any workaround you can
On Wed, Aug 28, 2024 at 9:25 AM Robert Haas wrote:
> Might make sense to restrict this to VERBOSE mode, too.
If we have to make the new output appear selectively, I'd prefer to do
it this way.
There are lots of small problems with selectively displaying less/no
information based on rules applied
On Wed, Aug 28, 2024 at 9:49 AM Robert Haas wrote:
>
> On Wed, Aug 28, 2024 at 9:41 AM Peter Geoghegan wrote:
> > On Wed, Aug 28, 2024 at 9:35 AM Robert Haas wrote:
> > > > If you think it's important to have this info on all indexes then I'd
> > > > prefer the pgstat approach over adding a fiel
On Wed, Aug 28, 2024 at 9:41 AM Peter Geoghegan wrote:
> On Wed, Aug 28, 2024 at 9:35 AM Robert Haas wrote:
> > > If you think it's important to have this info on all indexes then I'd
> > > prefer the pgstat approach over adding a field in IndexScanDescData.
> > > If instead you think that this i
Hi Robert,
On Mon, Aug 26, 2024 at 6:33 PM Robert Haas wrote:
>
> I'm somewhat expecting to be flamed to a well-done crisp for saying
> this, but I think we need better ways for extensions to control the
> behavior of PostgreSQL's query planner.
[..]
> [..] But all that
> said, as much as anythi
On Tue, Aug 27, 2024 at 2:24 PM Dmitry Koval wrote:
> They contains changes from reverted commits 1adf16b8fb, 87c21bb941, and
> subsequent fixes and improvements including df64c81ca9, c99ef1811a,
> 9dfcac8e15, 885742b9f8, 842c9b2705, fcf80c5d5f, 96c7381c4c, f4fc7cb54b,
> 60ae37a8bc, 259c96fa8f, 44
On Wed, Aug 28, 2024 at 9:35 AM Robert Haas wrote:
> > If you think it's important to have this info on all indexes then I'd
> > prefer the pgstat approach over adding a field in IndexScanDescData.
> > If instead you think that this is primarily important to expose for
> > nbtree index scans, then
On Wed, Aug 28, 2024 at 5:26 PM Ashutosh Bapat
wrote:
>
> On Fri, Aug 23, 2024 at 9:55 PM Jacob Champion
> wrote:
> >
> > On Fri, Aug 23, 2024 at 5:59 AM Ashutosh Bapat
> > wrote:
> > > If I run
> > > export PG_TEST_EXTRA=xid_wraparound; ./configure --prefix=$BuildDir
> > > --enable-tap-tests &&
On Tue, Aug 27, 2024 at 7:22 PM Matthias van de Meent
wrote:
> > Besides, I thought that you wanted me to use some new field in
> > BTScanOpaque? But now you want me to use a global counter. Which is
> > it?
>
> If you think it's important to have this info on all indexes then I'd
> prefer the pgs
On Tue, Aug 27, 2024 at 3:04 PM Tom Lane wrote:
> Peter Geoghegan writes:
> > I see value in making it obvious to users when and how
> > pg_stat_all_indexes.idx_scan advances. Being able to easily relate it
> > to EXPLAIN ANALYZE output is useful, independent of whether or not
> > SAOPs happen to
On Tue, Aug 27, 2024 at 11:57 PM Tender Wang wrote:
> Rectenly, I do some benchmark tests, mainly on tpch and tpcds.
> tpch tests have no plan diff, so I do not continue to test on tpch.
Interesting to know.
> tpcds(10GB) tests have 22 plan diff as below:
> 4.sql, 5.sql, 8.sql,11.sql,19.sql,23.s
Hi,
Here is a new version of the patch. Sorry for the long delay, I was hit
by a motivation drought and was quite busy otherwise.
The guc is now called `log_parallel_workers` and has three possible values:
* "none": disables logging
* "all": logs parallel worker info for all parallel queries
On Tue, Aug 27, 2024 at 4:15 PM Tom Lane wrote:
> Seems reasonable. It might be possible to say that our answer
> to "control over join order" is to provide a hook that can modify
> the "joinlist" before it's passed to make_one_rel. If you want
> to force a particular join order you can rearrang
On Wed, Aug 28, 2024 at 11:43 AM shveta malik wrote:
>
> Thanks for the patch. Just thinking out loud, since we have names like
> 'apply_error_count', 'sync_error_count' which tells that they are
> actually error-count, will it be better to have something similar in
> conflict-count cases, like 'i
Hi Ashutosh,
Ashutosh Bapat 于2024年8月26日周一 19:05写道：
> Hi Shawn,
> It will be good to document usage of this function. Please add
> document changes in your patch. We need to document the impact of this
> function so that users can judiciously decide whether or not to use
> this function and under
> On Wed, Aug 28, 2024 at 10:30 AM Ajin Cherian wrote:
> >
The review is WIP. Please find a few comments on patch001.
1)
logical-repliction.sgmlL
+ Additional logging is triggered for specific conflict_resolvers.
Users can also configure conflict_types while creating the
subscription. Refer to
Hi,
> On 04.10.23 16:37, Peter Eisentraut wrote:
> > On 03.10.23 13:28, Aleksander Alekseev wrote:
> >> While examining the code for similar places I noticed that the
> >> following functions can also be const'ified:
>
> >> - XLogRegisterData (?)
> >
> > I don't think this would work, at least wit
On Wed, Aug 28, 2024 at 12:06 AM Pavel Borisov
wrote:
> I see the following compile time warnings:
> scan.l:1062: warning, rule cannot be matched
> scan.l:1066: warning, rule cannot be matched
> scan.l:1070: warning, rule cannot be matched
> pgc.l:1030: warning, rule cannot be matched
> pgc.l:103
On Wed, Aug 28, 2024 at 3:02 PM wrote:
>
> >
> > The next line related to asynchronous replication is also not required. See
> > attached.
>
> Thanks, I found another ".. without losing data".
>
I'll push this tomorrow unless there are any other suggestions on this patch.
--
With Regards,
Amit
On Wed, Aug 28, 2024 at 12:24 PM Peter Smith wrote:
>
> On Wed, Aug 28, 2024 at 3:53 PM shveta malik wrote:
> >
> > On Wed, Aug 28, 2024 at 9:44 AM Zhijie Hou (Fujitsu)
> > wrote:
> > >
> > > > > +1 on 'update_origin_differs' instead of 'update_origins_differ' as
> > > > > the former is somewhat
> > > > > So, will it be okay if we just remove ".. without losing data"
> > > > > from the sentence? Will that avoid the confusion you have?
> > > > Yes. Additionally, it would be better to add notes about data
> > > > consistency after failover for example
> > > >
> > > > Note that data consisten
These are ok:
select json_query('{"a": 1, "b": 42}'::jsonb, 'lax $.b' without wrapper);
json_query
42
select json_query('{"a": 1, "b": 42}'::jsonb, 'lax $.b' with
unconditional wrapper);
json_query
[42]
But this appears to be wrong:
select json_query('{"a": 1, "
On 26.08.24 18:03, mr.trub...@icloud.com wrote:
This is my first time contribution to the PostgreSQL, so I’m not really
familiar with the whole process. The attached patch adds basic support
for Type=notify-reload systemd services, that is, sends readiness
notifications on service reload. This al
On Wed, Aug 28, 2024 at 6:16 AM wrote:
>
> > > > So, will it be okay if we just remove ".. without losing data" from
> > > > the sentence? Will that avoid the confusion you have?
> > > Yes. Additionally, it would be better to add notes about data
> > > consistency after failover for example
> > >
28.08.2024 07:45, Thomas Munro wrote:
Huh. I can reproduce what I showed with pretty low variance, on my
FreeBSD, Linux and macOS systems. I included
parallel_leader_participation=off so that the workers would hopefully
start as closely together in time as possible, and hopefully allow
only a b
On 22.08.24 19:27, Tom Lane wrote:
Marcos Pegoraro writes:
Well, a process which does this automatically would be cool, but a
modified version of release notes for version 17 was done manually and
seems fine.
So, why not commit this version and later for version 18 then create this
process ?
Hi,
While testing a feature reported by Pavel in this thread[1] I realized
that elements containing whitespaces between them won't be indented with
XMLSERIALIZE( ... INDENT)
SELECT xmlserialize(DOCUMENT '42' AS text INDENT);
xmlserialize
-
+
42+
+
(
Hi hackers!
Recently we faced issues with WAL recovery in our production. Issue
reproduces not frequently, once in 1.5-2 month.
So, the problem looks like this in our production cluster logs:
Postgresql startup process fails with signal 6.
"startup process (PID 369306) was terminated by signal
1 - 100 of 103 matches
Mail list logo
