>> - New comments have been added to pg_upgrade to mention the SLRU
>> page header change as the reason for upgrading clog files.
>
> That seems reasonable, but were any alternatives discussed? Do we have
> consensus that this is the right thing to do?
In general, there are two approaches. Eith
On 18.03.24 09:17, Daniel Gustafsson wrote:
On 18 Mar 2024, at 07:27, Peter Eisentraut wrote:
After some pondering, I figured the exclude list is better.
Agreed.
So here is a squashed patch, also with a complete commit message.
Looks good from a read-through. It would have been nice to
Hi,
I'm looking at an open proposal to introduce row-level security policy
templates [0], and I have been making some progress on it.
The proposal aims to introduce templates for RLS policies, where the idea
is to allow users to define policies as a template, and apply it to
multiple tables. The
On Tue, Jan 30, 2024 at 10:33 AM Richard Guo wrote:
> Attached is an updated patch. Nothing else has changed.
>
Here is another rebase over master so it applies again. Nothing else
has changed.
Thanks
Richard
v7-0001-Support-run-time-partition-pruning-for-hash-join.patch
Description: Binary
On Mon, Mar 18, 2024 at 8:19 PM Bertrand Drouvot
wrote:
>
> On Thu, Mar 14, 2024 at 12:27:26PM +0530, Amit Kapila wrote:
> > On Wed, Mar 13, 2024 at 10:16 PM Bharath Rupireddy
> > wrote:
> > >
> > > On Wed, Mar 13, 2024 at 11:13 AM shveta malik
> > > wrote:
> > > >
> > > > > Thanks. v8-0001 is
On 14/3/2024 16:31, Alexander Korotkov wrote:
On Wed, Mar 13, 2024 at 2:16 PM Andrei Lepikhov
As you can see this case is not related to partial indexes. Just no
index selective for the whole query. However, splitting scan by the OR
qual lets use a combination of two selective indexes.
I have
Hi,
On Fri, Mar 8, 2024 at 7:37 PM Bharath Rupireddy
wrote:
>
> On Sat, Mar 2, 2024 at 12:02 PM Bharath Rupireddy
> wrote:
> >
> > On Mon, Jan 29, 2024 at 5:16 PM Bharath Rupireddy
> > wrote:
> > >
> > > > Please find the attached v9 patch set.
> >
> > I've had to rebase the patches due to comm
On Fri, 2024-03-15 at 13:12 +0530, Bharath Rupireddy wrote:
> Hi,
>
> While working on [1], it was identified that
> WaitXLogInsertionsToFinish emits a LOG message, and adjusts the upto
> ptr to proceed further when caller requests to flush past the end of
> generated WAL. There's a comment explai
Dear Peter,
Thanks for giving comments. I want to reply some of them.
> > 17.
> >
> > "specifies promote"
> >
> > We can do double-quote for the word promote.
>
> The v30 patch has promote, which I think is adequate.
Opps. Actually I did look v29 patch while firstly reviewing. Sorry for noise.
On Mon, Mar 18, 2024 at 3:33 PM Amit Langote
wrote:
> Himanshu,
>
> On Mon, Mar 18, 2024 at 4:57 PM Himanshu Upadhyaya
> wrote:
> > I have tested a nested case but why is the negative number allowed in
> subscript(NESTED '$.phones[-1]'COLUMNS), it should error out if the number
> is negative.
Thomas Munro writes:
> On Tue, Mar 19, 2024 at 11:55 AM Tom Lane wrote:
This is causing all CI jobs to fail the "compiler warnings" check.
>>> I did run CI before checkin, and it passed:
> Maybe I misunderstood this exchange but ...
> Currently Windows warnings don't make any CI tasks fai
On Tue, Mar 19, 2024 at 11:55 AM Tom Lane wrote:
> Jeff Davis writes:
> > On Mon, 2024-03-18 at 18:04 -0400, Tom Lane wrote:
> >> This is causing all CI jobs to fail the "compiler warnings" check.
>
> > I did run CI before checkin, and it passed:
> > https://cirrus-ci.com/build/5382423490330624
>
On Tue, Mar 19, 2024 at 8:35 AM John Naylor wrote:
>
> On Mon, Mar 18, 2024 at 11:12 AM Masahiko Sawada
> wrote:
> >
> > On Sun, Mar 17, 2024 at 11:46 AM John Naylor
> > wrote:
>
> > > Random offsets is what I was thinking of (if made distinct and
> > > ordered), but even there the code is fai
On Tue, Mar 19, 2024 at 10:03:36AM +0700, John Naylor wrote:
> I took a brief look, and 0001 isn't quite what I had in mind. I can't
> quite tell what it's doing with the additional branches and "goto
> retry", but I meant something pretty simple:
Do you mean 0002? 0001 just adds a 2-register loo
On Tue, Mar 19, 2024 at 9:03 AM Nathan Bossart wrote:
>
> On Sun, Mar 17, 2024 at 09:47:33AM +0700, John Naylor wrote:
> > I haven't looked at the patches, but the graphs look good.
>
> I spent some more time on these patches. Specifically, I reordered them to
> demonstrate the effects on systems
>
> Of course you can, but this will only convert disk space into memory space.
> For details, please see the case in Email [1].
>
> [1]
> https://www.postgresql.org/message-id/CAGfChW51P944nM5h0HTV9HistvVfwBxNaMt_s-OZ9t%3DuXz%2BZbg%40mail.gmail.com
>
> Regards, lijie
>
>
Hi lijie,
Overall, I thi
(Sorry it takes me some time to get back to this thread.)
On Thu, Mar 7, 2024 at 7:13 PM Ashutosh Bapat
wrote:
> I did a deeper review of the patch. Here are some comments
>
Thank you for the review!
> Approach
>
> The equijoin condition between partition keys doesn't appear in the j
On Sun, Mar 17, 2024 at 09:47:33AM +0700, John Naylor wrote:
> I haven't looked at the patches, but the graphs look good.
I spent some more time on these patches. Specifically, I reordered them to
demonstrate the effects on systems without AVX2 support. I've also added a
shortcut to jump to the
On Thu, Mar 14, 2024 at 09:40:29AM +0900, Michael Paquier wrote:
> In the context of this thread, this removes the dependency of sequence
> value lookup to heap.
I am not sure where this is leading in combination with the sequence
stuff for logical decoding, so for now I am moving this patch to th
On Tue, Mar 19, 2024 at 08:00:00AM +0800, jian he wrote:
> I think the "X" and "-" mean in this matrix [0] is not very intuitive.
> mainly because "X" tends to mean negative things in most cases.
> we can write a sentence saying "X" means this, "-" means that.
>
> or maybe Check mark [1] and Cros
On Mon, Mar 18, 2024 at 06:17:18AM -0700, Jacob Champion wrote:
> Great! Thanks everyone.
Cool. Thanks for the commit.
--
Michael
signature.asc
Description: PGP signature
On Mon, Mar 18, 2024 at 05:57:02PM +, Bertrand Drouvot wrote:
> Thanks for looking at it!
> Oh right, the comment is wrong, re-worded in v2 attached.
I've added a couple of fake events in my txt file, and this results in
an ordering of the wait events in the docs while the backpatched wait
eve
On Thu, Mar 14, 2024 at 11:46 PM vignesh C wrote:
>
> On Thu, 14 Mar 2024 at 15:49, Amit Kapila wrote:
> >
> > On Thu, Mar 14, 2024 at 1:45 PM Masahiko Sawada
> > wrote:
> > >
> > > On Thu, Mar 14, 2024 at 2:27 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Thu, Mar 14, 2024 at 5:57 AM Masahi
Hi Rahul,
On 03/18/24 15:52, Rahul Uniyal wrote:
> Since the column format is text and not binary it converts the value
> to BigDecimal and give back the value as 40 .
> ...
> Now since the format is Binary ... it returns DOUBLE from there
> result in 40.0
>
> Now i am not sure for the same tabl
Dean Rasheed writes:
> On Mon, 18 Mar 2024 at 23:19, Tom Lane wrote:
>> After thinking a bit more, I understood what was bothering me about
>> that notation: it looks too much like a call of a user-defined
>> function named "rescan()". I think we'd be better off with the
>> all-caps "RESCAN()".
hi.
I think the "X" and "-" mean in this matrix [0] is not very intuitive.
mainly because "X" tends to mean negative things in most cases.
we can write a sentence saying "X" means this, "-" means that.
or maybe Check mark [1] and Cross mark [2] are more universal.
and we can use these marks.
"O
On Mon, Mar 18, 2024 at 10:24:00AM +0100, Alvaro Herrera wrote:
> FTR I had a rather unpleasant time last week upon finding a wait event
> named PgSleep. If you grep for that, there are no matches at all; and I
> spent ten minutes (for real) trying to figure out where that was coming
> from, until
On Mon, 18 Mar 2024 at 23:19, Tom Lane wrote:
>
> > Hm. I used "rescan(SubPlan)" in the attached, but it still looks
> > a bit odd to my eye.
>
> After thinking a bit more, I understood what was bothering me about
> that notation: it looks too much like a call of a user-defined
> function named "
On Mon, Mar 18, 2024 at 08:49:34AM -0700, Noah Misch wrote:
> On Mon, Mar 18, 2024 at 09:04:44AM +, Bertrand Drouvot wrote:
>> +# Ensure that the wait events under the "Backpatch" delimiter are placed in
>> the
>> +# same order as in the pre 17 wait_event_types.h (see VERSION_FILE_SYNC as
>>
Going to agree with Robert Treat here about an extension being a great
solution. I resisted posting earlier as I wanted to see how this all pans
out, but I wrote a quick little POC extension some months ago that does
the disabling and works well (and cannot be easily worked around).
On Mon, Mar 18
On Mon, Mar 18, 2024 at 11:12 AM Masahiko Sawada wrote:
>
> On Sun, Mar 17, 2024 at 11:46 AM John Naylor wrote:
> > Random offsets is what I was thinking of (if made distinct and
> > ordered), but even there the code is fairy trivial, so I don't have a
> > strong feeling about it.
>
> Agreed.
L
On Mon, Mar 18, 2024 at 6:51 PM Tom Lane wrote:
> This might be a silly suggestion, but: could we just render the
> "most important" chapter titles in a larger font?
It's not the silliest suggestion ever -- you could have proposed
! -- but I also suspect it's not the right answer. Of course,
vary
On Tue, 19 Mar 2024 at 11:08, Nathan Bossart wrote:
>
> On Mon, Mar 18, 2024 at 04:29:19PM -0500, Nathan Bossart wrote:
> > Agreed. Will send an updated patch shortly.
>
> As promised...
Looks good.
David
I wrote:
> Hm. I used "rescan(SubPlan)" in the attached, but it still looks
> a bit odd to my eye.
After thinking a bit more, I understood what was bothering me about
that notation: it looks too much like a call of a user-defined
function named "rescan()". I think we'd be better off with the
all
Jeff Davis writes:
> On Mon, 2024-03-18 at 18:04 -0400, Tom Lane wrote:
>> This is causing all CI jobs to fail the "compiler warnings" check.
> I did run CI before checkin, and it passed:
> https://cirrus-ci.com/build/5382423490330624
Weird, why did it not report with the same level of urgency?
Laurenz Albe writes:
> On Mon, 2024-03-18 at 10:11 -0400, Robert Haas wrote:
>> I don't know what to do about "I. SQL commands". It's obviously
>> impractical to promote that to a top-level section, because it's got a
>> zillion sub-pages which I don't think we want in the top-level
>> documentati
On Mon, 2024-03-18 at 18:04 -0400, Tom Lane wrote:
> This is causing all CI jobs to fail the "compiler warnings" check.
I did run CI before checkin, and it passed:
https://cirrus-ci.com/build/5382423490330624
If I open up the windows build, I see the warning:
https://cirrus-ci.com/task/51999790
On Mon, Mar 18, 2024 at 1:48 PM Cary Huang wrote:
> Attached is the v10 patch with the above changes. Thanks again for the review.
Awesome, looks good.
On my final review pass I saw one last thing that bothered me (sorry
for not seeing it before). The backend version of
ASN1_TIME_to_timestamptz
On Mon, Mar 18, 2024 at 04:29:19PM -0500, Nathan Bossart wrote:
> Agreed. Will send an updated patch shortly.
As promised...
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From b673663b1d1344549cbd0912220f96ba1712afc6 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Mon, 18
On Thu, Feb 29, 2024 at 10:02:21PM +, Maiquel Grassi wrote:
> Sorry for the delay. I will make the adjustments as requested soon.
Looking forward to it.
//
Hi Nathan!
Sorry for the delay, I was busy with other professional as well as personal
activities.
I made all the changes you
Jeff Davis writes:
> It may be moot soon, but I committed a fix now.
Thanks, but it looks like 846311051 introduced a fresh issue.
MSVC is complaining about
[21:37:15.349] c:\cirrus\src\backend\utils\adt\pg_locale.c(2515) : warning
C4715: 'builtin_locale_encoding': not all control paths return
On Mon, 2024-03-18 at 10:11 -0400, Robert Haas wrote:
> The two sections of the documentation that seem really
> under-emphasized to me are the GUC documentation and the SQL
> reference. The GUC documentation is all buried under "20. Server
> Configuration" and the SQL command reference is under "I
Robert Haas writes:
> On Sat, Mar 16, 2024 at 8:17 PM Tom Lane wrote:
>> Even taking the position that this is an unspecified point that we
>> could implement how we like, I don't think there's a sufficient
>> argument for changing behavior that's stood for a couple of decades.
> I got curious a
On Tue, Mar 19, 2024 at 10:27:58AM +1300, David Rowley wrote:
> On Tue, 19 Mar 2024 at 10:08, Nathan Bossart wrote:
>> On Tue, Mar 19, 2024 at 10:02:18AM +1300, David Rowley wrote:
>> > The only thing I'd question in the patch is in pg_popcount_fast(). It
>> > looks like you've opted to not do the
On Tue, 19 Mar 2024 at 10:08, Nathan Bossart wrote:
>
> On Tue, Mar 19, 2024 at 10:02:18AM +1300, David Rowley wrote:
> > The only thing I'd question in the patch is in pg_popcount_fast(). It
> > looks like you've opted to not do the 32-bit processing on 32-bit
> > machines. I think that's likely
On Mon, Mar 18, 2024 at 09:22:43PM +, Amonson, Paul D wrote:
>> The only reason I left it out was because I couldn't convince myself that it
>> wasn't dead code, given we assume that popcntq is available in
>> pg_popcount64_fast() today. But I don't see any harm in adding that just in
>> case.
> -Original Message-
> From: Nathan Bossart
> Sent: Monday, March 18, 2024 2:08 PM
> To: David Rowley
> Cc: Amonson, Paul D ; Andres Freund
>...
>
> The only reason I left it out was because I couldn't convince myself that it
> wasn't dead code, given we assume that popcntq is available
Dean Rasheed writes:
> The get_rule_expr() code could perhaps be simplified a bit, getting
> rid of the show_subplan_name variable and moving the recursive calls
> to get_rule_expr() to after the switch statement -- if testexpr is
> non-NULL, print it, else print the subplan name probably works fo
On Tue, Mar 19, 2024 at 10:02:18AM +1300, David Rowley wrote:
> I looked at your latest patch and tried out the performance on a Zen4
> running windows and a Zen2 running on Linux. As follows:
Thanks for taking a look.
> The only thing I'd question in the patch is in pg_popcount_fast(). It
> look
On Tue, 19 Mar 2024 at 06:30, Nathan Bossart wrote:
> Here is a more fleshed-out version of what I believe David is proposing.
> On my machine, the gains aren't quite as impressive (~8.8s to ~5.2s for the
> test_popcount benchmark). I assume this is because this patch turns
> pg_popcount() into a
On Mon, Mar 18, 2024 at 4:07 PM Robert Treat wrote:
> You know it's funny, you say #4 has no advantage and should be
> rejected outright, but AFAICT
>
> a) no one has actually laid out why it wouldn't work for them,
> b) and it's the one solution that can be implemented now
> c) and that implement
Hi Jacob
> Hi Cary, did you have any thoughts on the timestamptz notes from my last mail?
>
> > It might also be nice to rename
> > ASN1_TIME_to_timestamp().
> >
> > Squinting further at the server backend implementation, should that
> > also be using TimestampTz throughout, instead of Timestamp?
On 2024-Mar-18, Peter Eisentraut wrote:
> * src/bin/pg_basebackup/pg_createsubscriber.c
>
> I think the connection string handling is not robust against funny
> characters, like spaces, in database names etc.
Maybe it would be easier to deal with this by passing around a struct
with keyword/valu
I enabled the test again and also pushed the changes to dblink,
isolationtester and fe_utils (which AFAICS is used by pg_dump,
pg_amcheck, reindexdb and vacuumdb). I chickened out of committing the
postgres_fdw changes though, so here they are again. Not sure I'll find
courage to get these done b
On 2024-Mar-16, Wolfgang Walther wrote:
> The upstream name for the ossp-uuid package / pkg-config file is "uuid". Many
> distributions change this to be "ossp-uuid" to not conflict with e2fsprogs.
I can confirm that this is true for Debian, at least; the packaging
rules have this in override_dh_
Hello Chapman,
Thanks for the reply and suggestion.
Below are my observations when i was debugging the code of postgres-jdbc driver
for double precision data type.
1- When the value in DB is 40 and fetched value is also 40
A - In the QueryExecuterImpl class method - receiveFields() , we c
On Sat, Mar 16, 2024 at 8:17 PM Tom Lane wrote:
> Even taking the position that this is an unspecified point that we
> could implement how we like, I don't think there's a sufficient
> argument for changing behavior that's stood for a couple of decades.
> (The spelling of the message has changed o
On Thu, Mar 14, 2024 at 12:37 PM Robert Haas wrote:
>
> On Tue, Feb 13, 2024 at 2:05 AM Joel Jacobson wrote:
> > > Wouldn't having system wide EVTs be a generic solution which could be the
> > > infrastructure for this requested change as well as others in the same
> > > area?
> >
> > +1
> >
> >
On Mon, Mar 18, 2024 at 3:32 AM Andrew Dunstan wrote:
> Not very easily. But I think and hope I've fixed the issue you've identified
> above about returning before lex->token_start is properly set.
>
> Attached is a new set of patches that does that and is updated for the
> json_errdetaiil() ch
On Mon, Mar 18, 2024 at 10:12 AM Robert Haas wrote:
> I was looking at the documentation index this morning[1], and I can't
> help feeling like there are some parts of it that are over-emphasized
> and some parts that are under-emphasized. I'm not sure what we can do
> about this exactly, but I t
>
>
>
>
> From testrun/pg_dump/002_pg_dump/log/regress_log_002_pg_dump, search
> for the "not ok" and then look at what it tried to do right before
> that. I see:
>
> pg_dump: error: prepared statement failed: ERROR: syntax error at or
> near "%"
> LINE 1: ..._histogram => %L::real[]) coalesce($2,
Hi,
On Mon, Mar 18, 2024 at 08:49:34AM -0700, Noah Misch wrote:
> On Mon, Mar 18, 2024 at 09:04:44AM +, Bertrand Drouvot wrote:
> > --- a/src/backend/utils/activity/wait_event_names.txt
> > +++ b/src/backend/utils/activity/wait_event_names.txt
> > @@ -24,7 +24,12 @@
> > # SGML tables of
On Mon, Mar 18, 2024 at 12:30:04PM -0500, Nathan Bossart wrote:
> Here is a more fleshed-out version of what I believe David is proposing.
> On my machine, the gains aren't quite as impressive (~8.8s to ~5.2s for the
> test_popcount benchmark). I assume this is because this patch turns
> pg_popcou
On 3/18/24 15:02, Daniel Gustafsson wrote:
>> On 22 Feb 2024, at 03:45, Melanie Plageman wrote:
>> On Fri, Feb 16, 2024 at 3:41 PM Tomas Vondra
>> wrote:
>
>>> - Not sure why we need 0001. Just so that the "estimate" functions in
>>> 0002 have a convenient "start" point? Surely we could look a
On Mon, Mar 18, 2024 at 10:27 AM Robert Haas wrote:
> Right, we're adding this because of environments like Kubernetes,
> which isn't a version, but it is a platform, or at least a deployment
> mode, which is why I thought of that section. I think for now we
> should just file this under "Other pl
On Mon, Mar 18, 2024 at 05:28:32PM +, Amonson, Paul D wrote:
> Question: I applied the patch for the drive_popcount* functions and
> rebuilt. The resultant server complains that the function is missing.
> What is the trick to make this work?
You probably need to install the test_popcount exte
Hello,
I would like to make a feature request for existing implementation of
connection object. What I would like to request you is as follows.
I have configured primary and hot standby PostgreSQL server. The replication
works fine with repmanager. All I need to achieve is to keep the client
co
On Mon, Mar 18, 2024 at 11:20:18AM -0500, Nathan Bossart wrote:
> I don't think David was suggesting that we need to remove the runtime
> checks for AVX512. IIUC he was pointing out that most of the performance
> gain is from removing the function call overhead, which your v8-0002 patch
> already
On 2/22/24 03:45, Melanie Plageman wrote:
> Thanks so much for reviewing!
>
> On Fri, Feb 16, 2024 at 3:41 PM Tomas Vondra
> wrote:
>>
>> When I first read this, I immediately started wondering if this might
>> use the commit timestamp stuff we already have. Because for each commit
>> we alrea
> -Original Message-
> From: Nathan Bossart
> Sent: Monday, March 18, 2024 9:20 AM
> ...
> I don't think David was suggesting that we need to remove the runtime checks
> for AVX512. IIUC he was pointing out that most of the performance gain is
> from removing the function call overhead, w
On Mon, Mar 18, 2024 at 12:19 PM Maciek Sakrejda wrote:
> +1 on Version and Platform Compatibility. Maybe it just needs a new
> subsection there? This is for compatibility with a "deployment
> platform". The "Platform and Client Compatibility" subsection has just
> one entry, so a new subsection w
On Mon, Mar 18, 2024 at 11:46 AM Magnus Hagander wrote:
> > Wouldn't that break pgBackrest which IIRC write to .auto.conf directly
> > without using ALTER SYSTEM?
>
> Ugh of course. And not only that, it would also break pg_basebackup
> which does the same.
>
> So I guess that's not a good idea. I
Hi,
On 03/16/24 11:10, Rahul Uniyal wrote:
> We are encountering an issue where the double precision data type
> in PostgreSQL is giving some intermittent results when fetching data.
> For example, in the database the value is 40, but sometimes this value
> is fetched as 40.0. Similarly, for a val
On Thu, Mar 14, 2024 at 12:15 PM Ashutosh Bapat
wrote:
>
> Hi Robert,
>
> On Thu, Mar 7, 2024 at 10:49 PM Robert Treat wrote:
>>
>> This patch adds a link to the "attach partition" command section
>> (similar to the detach partition link above it) as well as a link to
>> "create table like" as bo
On Mon, Mar 18, 2024 at 10:55 AM Matthias van de Meent
wrote:
> > I don't know what to do about "I. SQL commands". It's obviously
> > impractical to promote that to a top-level section, because it's got a
> > zillion sub-pages which I don't think we want in the top-level
> > documentation index. B
On Sun, 2024-03-17 at 17:46 -0400, Tom Lane wrote:
> Jeff Davis writes:
> > New series attached.
>
> Coverity thinks there's something wrong with builtin_validate_locale,
> and as far as I can tell it's right: the last ereport is unreachable,
> because required_encoding is never changed from its
On Sun, 2024-03-17 at 23:33 -0400, Corey Huinker wrote:
>
> A few TAP tests are still failing and I haven't been able to diagnose
> why, though the failures in parallel dump seem to be that it tries to
> import stats on indexes that haven't been created yet, which is odd
> because I sent the depen
On Mon, Mar 18, 2024 at 04:07:40PM +, Amonson, Paul D wrote:
> Won't I still need the runtime checks? If I compile with a compiler
> supporting the HW "feature" but run on HW without that feature, I will
> want to avoid faults due to illegal operations. Won't that also affect
> performance?
I
On Mon, Mar 18, 2024 at 7:12 AM Jelte Fennema-Nio wrote:
>
> On Mon, 18 Mar 2024 at 13:57, Robert Haas wrote:
> > I would have been somewhat inclined to find an existing section
> > of postgresql.auto.conf for this parameter, perhaps "platform and
> > version compatibility".
>
> I tried to find a
Won't I still need the runtime checks? If I compile with a compiler supporting
the HW "feature" but run on HW without that feature, I will want to avoid
faults due to illegal operations. Won't that also affect performance?
Paul
> -Original Message-
> From: Nathan Bossart
> Sent: Monda
On 3/18/24 15:47, Melanie Plageman wrote:
> On Sun, Mar 17, 2024 at 3:21 PM Tomas Vondra
> wrote:
>>
>> On 3/14/24 22:39, Melanie Plageman wrote:
>>> On Thu, Mar 14, 2024 at 5:26 PM Tomas Vondra
>>> wrote:
On 3/14/24 19:16, Melanie Plageman wrote:
> On Thu, Mar 14, 2024 at 03:32:
On Mon, Mar 18, 2024 at 09:04:44AM +, Bertrand Drouvot wrote:
> --- a/src/backend/utils/activity/wait_event_names.txt
> +++ b/src/backend/utils/activity/wait_event_names.txt
> @@ -24,7 +24,12 @@
> # SGML tables of wait events for inclusion in the documentation.
> #
> # When adding a new
On Mon, Mar 18, 2024 at 5:40 PM Amit Langote
wrote:
>
> >>
> >> Sorry, I should’ve mentioned that I was interested in seeing cpu times
> to compare the two approaches. Specifically, to see if the palloc / frees
> add noticeable overhead.
> >
> > No problem. Here you go
> >
> > tables | master
On Mon, Mar 18, 2024 at 4:44 PM Daniel Gustafsson wrote:
>
> > On 18 Mar 2024, at 16:34, Magnus Hagander wrote:
> >
> > On Mon, Mar 18, 2024 at 2:09 PM Daniel Gustafsson wrote:
> >>
> >>> On 18 Mar 2024, at 13:57, Robert Haas wrote:
> >>
> >>> my proposal is something like this, taking a
> >>>
> On 18 Mar 2024, at 16:34, Magnus Hagander wrote:
>
> On Mon, Mar 18, 2024 at 2:09 PM Daniel Gustafsson wrote:
>>
>>> On 18 Mar 2024, at 13:57, Robert Haas wrote:
>>
>>> my proposal is something like this, taking a
>>> bunch of text from Jelte's patch and some inspiration from Magnus's
>>> e
Alexander Korotkov writes:
> On Mon, Mar 18, 2024 at 2:01 AM jian he wrote:
>> `
>> Datum
>> pg_basetype(PG_FUNCTION_ARGS)
>> {
>> Oid oid;
>>
>> oid = get_fn_expr_argtype(fcinfo->flinfo, 0);
>> PG_RETURN_OID(getBaseType(oid));
>> }
>> `
> Looks good to me. But should it be nam
On Mon, Mar 18, 2024 at 2:09 PM Daniel Gustafsson wrote:
>
> > On 18 Mar 2024, at 13:57, Robert Haas wrote:
>
> > my proposal is something like this, taking a
> > bunch of text from Jelte's patch and some inspiration from Magnus's
> > earlier remarks:
>
> I still think any wording should clearly
Hi,
On Sat, 16 Mar 2024 at 02:53, Thomas Munro wrote:
>
> I am planning to push the bufmgr.c patch soon. At that point the new
> API won't have any direct callers yet, but the traditional
> ReadBuffer() family of functions will internally reach
> StartReadBuffers(nblocks=1) followed by WaitReadB
On Mon, Mar 18, 2024 at 09:56:32AM +1300, David Rowley wrote:
> Maybe it's worth exploring something along the lines of the attached
> before doing the AVX512 stuff. It seems like a pretty good speed-up
> and will apply for CPUs without AVX512 support.
+1
--
Nathan Bossart
Amazon Web Services:
On Thu, Mar 14, 2024 at 7:23 PM Daniel Gustafsson wrote:
>
> > On 14 Mar 2024, at 14:21, Robert Treat wrote:
> > On Thu, Mar 14, 2024 at 8:21 AM Daniel Gustafsson wrote:
>
> >> - canceling connection in psql wouldn't
> >> cancel
> >> + canceling a connection in psql will not
> >> cance
On Mon, 18 Mar 2024 at 15:12, Robert Haas wrote:
I'm not going into detail about the other docs comments, I don't have
much of an opinion either way on the mentioned sections. You make good
arguments; yet I don't usually use those sections of the docs but
rather do code searches.
> I don't know
Hi,
On Thu, Mar 14, 2024 at 12:27:26PM +0530, Amit Kapila wrote:
> On Wed, Mar 13, 2024 at 10:16 PM Bharath Rupireddy
> wrote:
> >
> > On Wed, Mar 13, 2024 at 11:13 AM shveta malik
> > wrote:
> > >
> > > > Thanks. v8-0001 is how it looks. Please see the v8 patch set with this
> > > > change.
>
On Sun, Mar 17, 2024 at 3:21 PM Tomas Vondra
wrote:
>
> On 3/14/24 22:39, Melanie Plageman wrote:
> > On Thu, Mar 14, 2024 at 5:26 PM Tomas Vondra
> > wrote:
> >>
> >> On 3/14/24 19:16, Melanie Plageman wrote:
> >>> On Thu, Mar 14, 2024 at 03:32:04PM +0200, Heikki Linnakangas wrote:
> ...
>
On Sun, 17 Mar 2024 at 19:39, Tom Lane wrote:
>
> Here's a cleaned-up version that seems to successfully resolve
> PARAM_EXEC references in all cases. I haven't changed the
> "(plan_name).colN" notation, but that's an easy fix once we have
> consensus on the spelling.
I took a more detailed look
Wrong file in the previous message - sorry for the noise.Attached is a fixed patch.Thanks,Michal
0001-Pass-key-sk_attno-to-consistent-function.patch
Description: Binary data
On 18 Mar 2024, at 15:14, Michał Kłeczek wrote:I realised it might be enough to pass sk_attno to consistent function as tha
I realised it might be enough to pass sk_attno to consistent function as that should be enough to lookup metadata if needed.Attached is a draft patch that does this.—Michal
0001-Pass-key-sk_attno-to-consistent-function.patch
Description: Binary data
On 18 Mar 2024, at 14:31, Michał Kłeczek wrote:
On Mon, 18 Mar 2024 at 13:57, Robert Haas wrote:
> I would have been somewhat inclined to find an existing section
> of postgresql.auto.conf for this parameter, perhaps "platform and
> version compatibility".
I tried to find an existing section, but I couldn't find any that this
new GUC would fit
I was looking at the documentation index this morning[1], and I can't
help feeling like there are some parts of it that are over-emphasized
and some parts that are under-emphasized. I'm not sure what we can do
about this exactly, but I thought it worth writing an email and seeing
what other people
> On 22 Feb 2024, at 03:45, Melanie Plageman wrote:
> On Fri, Feb 16, 2024 at 3:41 PM Tomas Vondra
> wrote:
>> - Not sure why we need 0001. Just so that the "estimate" functions in
>> 0002 have a convenient "start" point? Surely we could look at the
>> current LSNTimeline data and use the oldest
On 16.03.24 16:42, Euler Taveira wrote:
I'm attaching a new version (v30) that adds:
I have some review comments and attached a patch with some smaller
fixups (mainly message wording and avoid fixed-size string buffers).
* doc/src/sgml/ref/pg_createsubscriber.sgml
I would remove the "How It
1 - 100 of 149 matches
Mail list logo
