Hi,
On Wed, Jan 08, 2025 at 02:32:24PM -0500, Andres Freund wrote:
> On 2025-01-08 14:48:21 +, Bertrand Drouvot wrote:
> > === 2
> >
> > + default:
> > + /* all signals sent by postmaster should be listed
> > here */
> > + Assert(false
Hi,
On Thu, 9 Jan 2025 at 10:15, Nazir Bilal Yavuz wrote:
>
> On Thu, 9 Jan 2025 at 05:59, Michael Paquier wrote:
> >
> >
> > +static inline bool
> > +is_ioop_tracked_in_bytes(IOOp io_op)
> > +{
> > +Assert((unsigned int) io_op < IOOP_NUM_TYPES);
> > +return io_op >= IOOP_EXTEND;
> > +}
On Thu, Jan 09, 2025 at 10:15:20AM +0300, Nazir Bilal Yavuz wrote:
> I am a bit confused, are you suggesting these two alternatives:
> 1- Making pgstat_count_io_op_n() static and continuing to use
> pgstat_count_io_op() as it is.
> 2- Removing pgstat_count_io_op() and instead using
> pgstat_count_i
On Monday, December 30, 2024 04:08 MSK, Michael Paquier
wrote:
> Instead, I have gone with a new
> FullTransactionIdFromCurrentEpoch() that replaces
> AdjustToFullTransactionId(). It cleans up most of the calls to
> ReadNextFullTransactionId() compared to the previous patch. It is
> true that
On Wed, Jan 8, 2025 at 4:18 PM Tom Lane wrote:
>
> Matthias van de Meent writes:
> > DefineCustomXXXVariable has a 'flags' argument, into which GUC_UNIT_*
> > can be or-ed.
Thanks Matthias and Tom for the explaination.
Since I'm needing to define "seconds", GUC_UNIT_S is what I was looking for.
On Thu, Jan 9, 2025 at 12:14 AM Peter Eisentraut wrote:
>
> Here is a new patch version where I have gathered various pieces of
> feedback and improvement suggestions that are scattered over this
> thread. I hope I got them all. I will respond to the respective
> messages directly to give my res
> If we go with the 3 column format, then we will just
> have a bunch of repeated values for Category, which
> looks cluttered, IMO.
"cluttered" is maybe the wrong description. I meant the output
will look overwhelming due to the repeated values :)
Regards,
Sami
Hi,
On 2025-01-09 20:10:24 +0200, Ants Aasma wrote:
> On Thu, 9 Jan 2025 at 18:25, Andres Freund wrote:
> > > I'm curious about this because the checksum code should be fast enough
> > > to easily handle that throughput.
> >
> > It seems to top out at about ~5-6 GB/s on my 2x Xeon Gold 6442Y
> >
HI Nathan Frédéric Yhuel
On 1/7/25 23:57, Nathan Bossart wrote:
> Here is a rebased patch for cfbot. AFAICT we are still pretty far from
> consensus on which approach to take, unfortunately.
>
> For what it's worth, although I would have preferred the sub-linear
> growth thing, I'd much rath
On Thu, Jan 09, 2025 at 03:30:37PM +, Bertrand Drouvot wrote:
> We first use an Assert in is_ioop_tracked_in_bytes() and then we return
> a value "just" to check another Assert. I wonder if it wouldn't make more
> sense
> to get rid of this function and use a macro instead, something like?
>
On Fri, Mar 01, 2024 at 01:16:37PM +0900, Kyotaro Horiguchi wrote:
> This code intends to prevent a page header error from causing a record
> reread, when a record is required to be read from multiple sources. We
> could restrict this to only fire at segment boundaries. At segment
> boundaries, we
Andy Fan writes:
> Hi:
>
> I run into the {subject} issue with the below setup.
>
> cat foo.sql
>
> \setshell txn_mode echo ${TXN_MODE}
> \setshell speed echo ${SPEED}
> \setshell sleep_ms echo ${SLEEP_MS}
> \setshell subtxn_mode echo ${SUBTXN_MODE}
>
> select 1;
>
> $ TXN_MODE=-1 SPEED=1 SLEEP_M
On Wed, Jan 8, 2025 at 3:05 PM Kirill Reshke wrote:
>
> So, in this version you essentially removed support for REJECT_LIMIT +
> SET_TO_NULL feature? Looks like a promising change. It is more likely
> to see this committed.
> So, +1 on that too.
>
> However, v9 lacks tests for REJECT_LIMIT vs erro
On Thu, Jan 09, 2025 at 03:21:41PM +0900, Tatsuo Ishii wrote:
> Ok, I have created v3 patch to do more inlining as you suggested. With
> the patch I confirmed that there's no call to functions except palloc
> in makeStringInfo, makeStringInfoExt, initStringInfo and
> initStringInfoExt in the asm co
On 1/9/25 21:42, Melanie Plageman wrote:
> On Tue, Dec 31, 2024 at 6:07 PM Tomas Vondra wrote:
>>
>> This means that ultimately it's either (1) or (3), and the more I've
>> been looking into this the more I prefer (1), for a couple reasons:
>>
>> * It's much simpler (it doesn't really change an
Hi Shubham,
Some review comments for patch v8=0001.
==
Commit message.
1.
By ensuring 'max_slot_wal_keep_size' is -1, this patch prevents the potential
deletion of required WAL files on the publisher that could disrupt logical
replication. A test case has been added to validate correct warni
I wrote:
> 0003 is new work that fixes the pg_timezone_abbrevs view so
> that its output matches the new behavior.
Hmph ... the cfbot doesn't like that one bit. It appears that the
"LMT" abbrev is known in my machine's system-provided tzdata tree,
but not when building our own timezone files. I
On Tue, Dec 31, 2024 at 11:29:26AM +, Bertrand Drouvot wrote:
> === 1
>
> + * Copyright (c) 2001-2024, PostgreSQL Global Development Group
>
> As pgstat_kind.h is a new file, s/Copyright (c) 2001-2024/Copyright (c) 2025/
> maybe?
Fixed.
> No more comments, as v2-0002 is "just" moving so
On Thu, Jan 09, 2025 at 11:21:38AM +0300, Давыдов Виталий wrote:
> Could you please send the latest version of the patch, if any? I haven't
> found any new patches in the latest email.
I've applied fixes for this stuff as of e3584258154f (down to 13) and
7e125b20eed6 (down to 17) with tests for a
On Thu, Jan 09, 2025 at 01:00:06PM +0100, Daniel Gustafsson wrote:
> On 9 Jan 2025, at 11:45, Alvaro Herrera wrote:
>> Dunno what others think, this seems useless churn to me.
>
> I agree, I don't see this providing enough value to warrant the changes.
Same here, let's leave things as they are.
Hi,
On Fri, 10 Jan 2025 at 04:47, Michael Paquier wrote:
>
> On Thu, Jan 09, 2025 at 03:30:37PM +, Bertrand Drouvot wrote:
> > We first use an Assert in is_ioop_tracked_in_bytes() and then we return
> > a value "just" to check another Assert. I wonder if it wouldn't make more
> > sense
> > t
Aleksander Alekseev writes:
> I tested and reviewed the patch. It fixes the originally reported bug
> and looks good to me.
Thanks for looking at it! I'm not sure we have full consensus on
this yet, but at least there seem to be a majority in favor.
So here's a v2 with some loose ends cleaned up
On Thu, Jan 09, 2025 at 07:05:54AM +, Bertrand Drouvot wrote:
> PFA v3 which is v2 refactoring with your proposed above changes.
An extra thing I have finished by doing is removing
PgStat_BackendPendingIO, then applied the change. It was useful when
returned as a result of pgstat_prep_backend
On Mon, 2024-12-02 at 23:58 -0800, Jeff Davis wrote:
> On Mon, 2024-12-02 at 16:39 +0100, Andreas Karlsson wrote:
> > I feel your first patch in the series is something you can just
> > commit.
>
> Done.
>
> I combined your patches and mine into the attached v10 series.
Here's v12 after committ
Hello!
Sorry, I should have expressed my thoughts in more detail, as they don't
matter as much as the time you took to answer.
>I don't quite read it as covering IOS. To me, the comment is more
> along the lines of (extensively extended):
My idea was just to add a few more details about the lock
Thanks for the feedback, everyone. Attached a followup with the
following changes compared to the initial version:
1. Converted sslkeylogfile to a connection parameter
2. Added a mechanism to chmod the key log file to 0600
3. Added docs and tests
I tested this manually. Also ran make check and ma
On Fri, 10 Jan 2025 at 02:46, Amit Langote wrote:
>
> On Mon, Jan 6, 2025 at 10:18 PM David Rowley wrote:
> > I've attached my workings of what I was messing around with. It seems
> > to perform about the same as your version. I think maybe we'd need
> > some sort of execScan.h instead of where I
> On 9 Jan 2025, at 23:35, Jacob Champion
> wrote:
>
> On Thu, Jan 9, 2025 at 12:40 PM Daniel Gustafsson wrote:
>> + * Find the start of the .well-known prefix. IETF rules state this must be
>> + * at the beginning of the path component, but OIDC defined it at the end
>> + * instead, so we have
> On Thu, Jan 9, 2025 at 5:30 PM Daniel Gustafsson wrote:
>
> > On 9 Jan 2025, at 11:45, Alvaro Herrera wrote:
>
> > Dunno what others think, this seems useless churn to me.
>
> I agree, I don't see this providing enough value to warrant the changes.
>
I agree about most of the changes however
Hello.
One thing I think we could add to the patches is to adapt the 10-years-old
comment below with notice about IOS:
/*
* We save the LSN of the page as we read it, so that we know whether it
* safe to apply LP_DEAD hints to the page later. This allows us to drop
* the pin for MVCC scans, which
On Sun, Jan 5, 2025 at 10:00 PM Tomas Vondra wrote:
>
> I think the general idea and formula explained in [1] is right, but
> while working on the PoC patch I started to think about how to formalize
> this. And I ended up creating two tables that I think visualize is
> pretty nicely.
>
> Imagine a
On 1/9/25 23:18, Melanie Plageman wrote:
> On Sun, Jan 5, 2025 at 10:00 PM Tomas Vondra wrote:
>>
>> I think the general idea and formula explained in [1] is right, but
>> while working on the PoC patch I started to think about how to formalize
>> this. And I ended up creating two tables that I th
On Thu, Jan 9, 2025 at 2:46 AM Peter Smith wrote:
>
> On Sat, Jan 4, 2025 at 4:23 AM Robert Treat wrote:
> >
> > On Wed, Dec 18, 2024 at 5:56 AM Amit Kapila wrote:
> > >
> > > On Thu, Feb 8, 2024 at 9:57 AM Laurenz Albe
> > > wrote:
> > > >
> > > > On Thu, 2024-02-08 at 13:40 +1100, Peter Smit
On Sun, Dec 8, 2024 at 10:57 AM Tomas Vondra wrote:
>
> On 8/22/24 05:21, Peter Smith wrote:
> > ...
> >>>
> >>> I also don't see a test for this error condition. However, it is not
> >>> clear to me how important is it to cover this error code path. This
> >>> code has existed for a long time and
On 09.01.2025 22:13, Alena Rybakina wrote:
Hi! Thank you for the work with this subject.
I looked at your patch and noticed that this part of the code is
repeated several times:
if (nesting_level == 0)
{
if (!IsParallelWorker())
current_query_sampled =
pg_prng_doubl
On Thu, Jan 9, 2025 at 12:40 PM Daniel Gustafsson wrote:
> + * Find the start of the .well-known prefix. IETF rules state this must be
> + * at the beginning of the path component, but OIDC defined it at the end
> + * instead, so we have to search for it anywhere.
> I was looking for a reference f
On Wed, Jan 8, 2025 at 7:26 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Thursday, January 9, 2025 9:48 AM Masahiko Sawada
> wrote:
>
> Hi,
>
> >
> > On Wed, Jan 8, 2025 at 3:00 AM Zhijie Hou (Fujitsu)
> > wrote:
> > >
> > > On Wednesday, January 8, 2025 6:33 PM Masahiko Sawada
> > wrote:
> > >
> > >
Hi Robert.
The content and rendering of patch v2 LGTM.
Should the word wrapping within the file
doc/src/sgml/logical-replication.sgml be tidied up though?
==
Kind Regards,
Peter Smith.
Fujitsu Australia
On Thu, 9 Jan 2025 at 22:00, Michail Nikolaev
wrote:
>
> Hello.
>
> One thing I think we could add to the patches is to adapt the 10-years-old
> comment below with notice about IOS:
>
> /*
> * We save the LSN of the page as we read it, so that we know whether it
> * safe to apply LP_DEAD hints to
> Looks generally reasonable to me.
Thanks for looking into the patch.
> +/*
> + * initStringInfoInternal
> + *
> + * Initialize a StringInfoData struct (with previously undefined contents)
> + * to describe an empty string.
> + * The initial memory allocation size is specified by 'initsize'.
> +
Hi:
I run into the {subject} issue with the below setup.
cat foo.sql
\setshell txn_mode echo ${TXN_MODE}
\setshell speed echo ${SPEED}
\setshell sleep_ms echo ${SLEEP_MS}
\setshell subtxn_mode echo ${SUBTXN_MODE}
select 1;
$ TXN_MODE=-1 SPEED=1 SLEEP_MS=0 SUBTXN_MODE=-1 pgbench -n -ffoo.sql
On Mon, Jan 6, 2025 at 1:29 PM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Shubham,
>
> Thanks for creating a patch. I have one comment about it.
>
> check_publisher() assumed that the SQL function
> `pg_catalog.current_setting('max_slot_wal_keep_size')`
> will return the numeric, but it just return
On 22.11.2024 09:08, Alexander Korotkov wrote:
On Wed, Nov 20, 2024 at 12:07 AM Michael Paquier wrote:
On Tue, Nov 19, 2024 at 09:39:21AM -0500, Greg Sabino Mullane wrote:
Oh, and a +1 in general to the patch, OP, although it would also be nice to
start finding the bottlenecks that cause suc
On Thu, 9 Jan 2025 at 18:25, Andres Freund wrote:
> > I'm curious about this because the checksum code should be fast enough
> > to easily handle that throughput.
>
> It seems to top out at about ~5-6 GB/s on my 2x Xeon Gold 6442Y
> workstation. But we don't have a good ready-made way of testing t
> On 9 Jan 2025, at 02:45, Melanie Plageman wrote:
> Attached is v2 (required a rebase).
I think this is a really good restructuring which will make life easier for our
users. Some of the comments below are on wording which wasn't introduced in
this patch, but which I hadn't thought about befor
On Thu, Jan 09, 2025 at 12:27:20PM -0600, Nathan Bossart wrote:
> LGTM. I'll plan on committing this shortly.
Committed.
--
nathan
On Wed, 8 Jan 2025 at 16:14, Peter Eisentraut wrote:
>
> One thing I could use some review on is the access control handling and
> security in general. You can create virtual generated columns that have
> their own access privileges but which can read columns that the user
> does not have access
Hi!
On 04.10.2024 12:05, Andrei Lepikhov wrote:
We also have an implementation of VALUES -> ARRAY transformation.
Because enterprises must deal with users' problems, many of these
users employ automatically generated queries.
Being informed very well of the consensus about that stuff, we've
de
On Thu, 9 Jan 2025 at 08:11, Mahendra Singh Thalor
wrote:
>
> On Thu, 9 Jan 2025 at 02:30, Guillaume Lelarge
wrote:
> >
> > Hi,
> >
> > Le mer. 8 janv. 2025 à 17:41, Mahendra Singh Thalor
a écrit :
> >>
> >> On Wed, 8 Jan 2025 at 20:07, Mahendra Singh Thalor
wrote:
> >> >
> >> > Hi all,
> >> >
On Wed, Jan 08, 2025 at 07:01:53PM -0500, Robert Treat wrote:
> To be frank, this patch feels like a solution in search of a problem,
> and as I read back through the thread, it isn't clear what problem
> this is intended to fix.
Thanks for sharing your thoughts. FWIW I've heard various strategie
On Wed, Jan 08, 2025 at 06:07:44PM -0500, Tom Lane wrote:
> Nathan Bossart writes:
>> AFAICT TAS_SPIN() is only used for s_lock(), which doesn't appear to be
>> used by LWLocks. But I did retry my test from upthread without
>> pg_stat_statements and was surprised to find a reproducible 4-6%
>> re
On Wed, Jan 08, 2025 at 09:32:58PM +, Vinícius Abrahão wrote:
> Please also provide the tests on the new parameter you want to introduce.
I skimmed around and didn't see any existing tests for these kinds of
parameters, which of course isn't a great reason not to add tests, but it's
also not c
On Thu, Jan 09, 2025 at 11:22:05AM +, devanga.susmi...@fujitsu.com wrote:
> This email aims to discuss the contribution of optimized hex_encode and
> hex_decode functions for ARM (aarch64) machines. These functions are
> widely used for encoding and decoding binary data in the bytea data type.
Hi,
On 2025-01-07 15:46:26 -0500, Melanie Plageman wrote:
> For table storage options, those related to vacuum but not autovacuum
> are in the main StdRdOptions struct. Of those, some are overridden by
> VACUUM command parameters which are parsed out into the VacuumParams
> struct. Though the memb
On 09.01.2025 05:29, Sami Imseih wrote:
Unfortunately, these changes do not achieve the intended sampling goal.
I looked into this more deeply: while the sampled-out queries do not
appear in pg_stat_statements, an entry is still allocated in the hash
table after normalization, which, in my view
On Mon, Jan 6, 2025 at 10:18 PM David Rowley wrote:
> On Sat, 21 Dec 2024 at 00:41, Amit Langote wrote:
> > To address (1), I tried assigning specialized functions to
> > PlanState.ExecProcNode in ExecInitSeqScan() based on whether qual or
> > projInfo are NULL. Inspired by David Rowley’s suggest
Hi,
Thanks for working on this!
On Wed, 8 Jan 2025 at 22:26, Andres Freund wrote:
>
> I'm currently to plan the four patches relatively soon, unless somebody speaks
> up, of course. They seem fairly uncontroversial. The renaming of the phases
> doesn't need to wait much longer, I think.
>
> The
On Thu, Jan 09, 2025 at 10:13:11AM +0800, cca5507 wrote:
> I modified the patch according to Tom's suggestion.
LGTM. I'll plan on committing this shortly.
--
nathan
Hi,
On Fri, Jan 10, 2025 at 1:50 AM Sami Imseih wrote:
> > If we go with the 3 column format, then we will just
> > have a bunch of repeated values for Category, which
> > looks cluttered, IMO.
>
> "cluttered" is maybe the wrong description. I meant the output
> will look overwhelming due to the
Peter Eisentraut writes:
> The second patch contemplates raising the minimum required flex version,
> but what to?
Meh, let's just rip out the version check. It's no longer very
relevant. Nobody is going to be using anything older than 2.5.35.
While 2.5.35 produces compile warnings, it does st
hello, this is a feature request that I wanted to discuss with you
*Problem:*
While PostgreSQL's postmaster manages all child processes, there's limited
visibility into its health metrics and process management statistics. This
information could be valuable for monitoring and debugging purposes.
Hi,
Thanks for reviewing the patch - I've added a few changes and it looks as
follows:
diff --git a/meson.build b/meson.build
index e5ce437a5c7..37d4e9ca741 100644
--- a/meson.build
+++ b/meson.build
@@ -1343,14 +1343,41 @@ if sslopt in ['auto', 'openssl']
# via library + headers
if not ss
On Thu, Jan 9, 2025 at 12:46 PM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Shubham,
>
> Thanks for updating the patch. Few comments.
>
> ```
> +#include "common/int.h"/* include for strtoi64 */
> ```
>
> I could build the source code without the inclusion. Can you remove?
>
>
On Wednesday, January 8, 2025 3:49 PM Nisha Moond
wrote:
>
> On Tue, Jan 7, 2025 at 6:04 PM Zhijie Hou (Fujitsu)
> wrote:
> >
> >
> > Attached the V19 patch which addressed comments in [1][2][3][4][5][6][7].
> >
>
> Here are a couple of initial review comments on v19 patch set:
>
> 1) The sub
On 2025-Jan-09, Ashutosh Bapat wrote:
> Sorry for reviewing late. The patch looks ok.
Dunno what others think, this seems useless churn to me.
> I found some more
> static const struct
> {
> LOCKMODE hwlock;
> int lockstatus;
> int updstatus;
> }
>
> tupleLockExtraInfo[MaxLockTupleMode + 1] =
>
> On 9 Jan 2025, at 02:30, Melanie Plageman wrote:
>
> On Wed, Jan 8, 2025 at 6:35 AM Daniel Gustafsson wrote:
>>
>>> On 7 Jan 2025, at 21:14, Tom Lane wrote:
>>
>>> I might be wrong, but I had the idea that our docs website has a
>>> capability to provide such redirects. You'd probably need
On 07/01/2025 23:56, Noah Misch wrote:
On Tue, Dec 24, 2024 at 12:18:09AM +0200, Heikki Linnakangas wrote:
I'm thinking of the attached to fix this. It changes the strategy for
detecting concurrent cache invalidations. Instead of the "recheck" mechanism
that was introduced in commit ad98fb1422,
On Thu, Jan 9, 2025 at 3:28 AM Peter Eisentraut wrote:
>
> On 08.01.25 17:38, Tom Lane wrote:
> > Peter Eisentraut writes:
> >> On 03.12.24 15:15, jian he wrote:
> >>> SELECT attrelid, attname, attgenerated FROM pg_attribute WHERE
> >>> attgenerated IN ('v') and (attnotnull or not atthasdef);
> >
> On 7 Jan 2025, at 19:25, Darek Ślusarczyk wrote:
> Thanks for reviewing the patch - I've added a few changes and it looks as
> follows:
Thanks for the new version, I've tested it in CI against v17 and plan to commit
it soon.
--
Daniel Gustafsson
Thanks for the review!
Em qua., 8 de jan. de 2025 às 07:49, Peter Eisentraut
escreveu:
>
> This patch is surprisingly compact and straightforward for providing
> such complex functionality.
>
> I have one major code comment that needs addressing:
>
> In src/interfaces/libpq/fe-auth-scram.c, there
On Fri, Aug 2, 2024 at 4:00 PM Kirill Reshke wrote:
>
> Thanks for review!
>
> On Fri, 2 Aug 2024 at 14:31, Ashutosh Bapat
> wrote:
> >
> > On Fri, Aug 2, 2024 at 1:55 PM Kirill Reshke wrote:
> > >
> > > I hate to be "that guy", but there are many places in sources where we use
> > > LOCKMODE lo
On 2025/01/09 20:34, Ryo Kanbayashi wrote:
Dear Tom, Fujii-san, Kuroda-san,
I saw comments of yours and recognized that better fix is below.
- Fix of first attached patch which does not change warning message
And I created patch entry of commitfest :)
https://commitfest.postgresql.org/52/54
Hi,
On Wed, Jan 08, 2025 at 02:26:15PM -0500, Andres Freund wrote:
> I'm currently to plan the four patches relatively soon, unless somebody speaks
> up, of course. They seem fairly uncontroversial. The renaming of the phases
> doesn't need to wait much longer, I think.
Thanks for the patches.
> On 9 Jan 2025, at 11:45, Alvaro Herrera wrote:
> Dunno what others think, this seems useless churn to me.
I agree, I don't see this providing enough value to warrant the changes.
--
Daniel Gustafsson
> On 9 Jan 2025, at 02:17, Tom Lane wrote:
> I think it might be safer if we only accepted it as a connection
> parameter and not via an environment variable.
+1
--
Daniel Gustafsson
> On 2025/01/09 20:34, Ryo Kanbayashi wrote:
> > Dear Tom, Fujii-san, Kuroda-san,
> >
> > I saw comments of yours and recognized that better fix is below.
> >
> > - Fix of first attached patch which does not change warning message
> >
> > And I created patch entry of commitfest :)
> > https://commi
On 1/7/2025 10:49 AM, Юрий Соколов wrote:
On 6 Jan 2025, at 09:46, Zhou, Zhiguo wrote:
Hi Yura and Wenhui,
Thanks for kindly reviewing this work!
On 1/3/2025 9:01 PM, wenhui qiu wrote:
Hi
Thank you for your path，NUM_XLOGINSERT_LOCKS increase to 128，I
think it will be challenged，do we make
On 08.01.25 21:29, Jacob Champion wrote:
It'd also couple clients against libpq-int.h, so they'd have to
remember to recompile every release. I'm worried that'd cause a bunch
of ABI problems...
Couldn't that function use PQsocket() to get at the actual socket from
the PGconn handle?
It's an out
On Tue, Dec 31, 2024 at 6:07 PM Tomas Vondra wrote:
>
> So I decided to revisit the three patches from 2019. Attached are
> rebased and cleaned up versions. A couple comments on each one:
>
>
> 1) v20241231-adjust-limit-0001-Account-for-batch-files-in-ha.patch
>
> I believe this is the way to go,
On 09.01.25 02:45, Melanie Plageman wrote:
On Wed, Jan 8, 2025 at 8:39 AM Peter Eisentraut wrote:
On 07.01.25 18:31, Melanie Plageman wrote:
Oh, one thing I forgot to say. Though I increased the indentation of
some of the subsections that I moved, I didn't rewrap the lines
because they were
Hi,
On 2025-01-09 10:59:22 +0200, Ants Aasma wrote:
> On Wed, 8 Jan 2025 at 22:58, Andres Freund wrote:
> > master: ~18 GB/s
> > patch, buffered:~20 GB/s
> > patch, direct, worker: ~28 GB/s
> > patch, direct, uring: ~35 GB/s
> >
> >
> > This was with io_workers=32, io_m
> If we loop through conn->pstatus, we will be bypassing the official API.
> The list is of type pgParameterStatus, which is an internal struct defined in
> libpq-int.h.
> As the file's header warns, including this file can lead to issues. Or am I
> missing something?
you're right about the warn
On 1/9/25 17:17, Melanie Plageman wrote:
> On Tue, Dec 31, 2024 at 6:07 PM Tomas Vondra wrote:
>>
>> So I decided to revisit the three patches from 2019. Attached are
>> rebased and cleaned up versions. A couple comments on each one:
>>
>>
>> 1) v20241231-adjust-limit-0001-Account-for-batch-fil
Hi,
On Thu, Jan 09, 2025 at 02:20:16PM +0300, Nazir Bilal Yavuz wrote:
> Hi,
>
> On Thu, 9 Jan 2025 at 11:11, Michael Paquier wrote:
> >
> > On Thu, Jan 09, 2025 at 10:15:20AM +0300, Nazir Bilal Yavuz wrote:
> > > I am a bit confused, are you suggesting these two alternatives:
> > > 1- Making pg
> Regina Obe писал(а) 2025-01-03 23:08:
> > I tested this with a patched version of the EDB PG 17 installer that
> > includes this patch and it fixed the issue I was having described in:
> >
> > https://www.postgresql.org/message-
> id/01db1df8%2449765bb0%24dc6313
> > 10%24%40pcorp.us
> >
> > I
Hi
čt 9. 1. 2025 v 14:35 odesílatel Alvaro Herrera
napsal:
> On 2024-Dec-11, Antonin Houska wrote:
>
> > Oh, it was too messy. I think I was thinking of too many things at once
> (such
> > as locking the old heap, the new heap and the new heap's TOAST). Also,
> one
> > thing that might have cont
Alvaro Herrera wrote:
> On 2024-Dec-11, Antonin Houska wrote:
>
> > Oh, it was too messy. I think I was thinking of too many things at once
> > (such
> > as locking the old heap, the new heap and the new heap's TOAST). Also, one
> > thing that might have contributed to the confusion is that mak
Kohei Harikae (Fujitsu) писал(а) 2025-01-06 16:57:
Hi,
- 0001 icu
- 0002 libxml
- 0003 libxslt
- 0004 lz4
- 0005 tcl
- 0006 zlib
- 0007 zstd
These libraries could not be built by setting extra_include_dirs and
extra_lib_dirs.
These libraries may not have .pc file created.
For example, if I
Hi,
On Thu, 9 Jan 2025 at 11:11, Michael Paquier wrote:
>
> On Thu, Jan 09, 2025 at 10:15:20AM +0300, Nazir Bilal Yavuz wrote:
> > I am a bit confused, are you suggesting these two alternatives:
> > 1- Making pgstat_count_io_op_n() static and continuing to use
> > pgstat_count_io_op() as it is.
>
On Wednesday, January 8, 2025 7:03 PM vignesh C wrote:
Hi,
> Consider a LR setup with retain_conflict_info=true for a table t1:
> Publisher:
> insert into t1 values(1);
> -- Have a open transaction before delete operation in subscriber begin;
>
> Subscriber:
> -- delete the record that was repl
On Wed, 8 Jan 2025 at 22:58, Andres Freund wrote:
> master: ~18 GB/s
> patch, buffered:~20 GB/s
> patch, direct, worker: ~28 GB/s
> patch, direct, uring: ~35 GB/s
>
>
> This was with io_workers=32, io_max_concurrency=128,
> effective_io_concurrency=1000 (doesn't need to
On Tue, Dec 31, 2024 at 10:15 AM Masahiko Sawada wrote:
>
> Hi all,
>
> Logical decoding (and logical replication) are available only when
> wal_level = logical. As the documentation says[1], Using the 'logical'
> level increases the WAL volume which could negatively affect the
> performance. For
Regina Obe писал(а) 2025-01-03 23:08:
I tested this with a patched version of the EDB PG 17 installer that
includes this patch and it fixed the issue I was having described in:
https://www.postgresql.org/message-id/01db1df8%2449765bb0%24dc631310%24%40pcorp.us
It would be great if this was
On Thu, Jan 9, 2025 at 12:15 PM jian he wrote:
> hi.
> in create_grouping_expr_infos
>
> tce = lookup_type_cache(exprType((Node *) tle->expr),
> TYPECACHE_BTREE_OPFAMILY);
> if (!OidIsValid(tce->btree_opf) ||
> !OidIsValid(tce->btree_opin
On Thu, Jan 9, 2025 at 4:12 AM Thomas Munro wrote:
>
> On Tue, Jan 7, 2025 at 9:54 AM Thomas Munro wrote:
> > On Tue, Jan 7, 2025 at 5:23 AM Andrew Dunstan wrote:
> > > Do you have a plan for moving ahead with this?
> >
> > I think that all looks good, and I'll go ahead and commit it in the
> >
Dear Tom, Fujii-san, Kuroda-san,
I saw comments of yours and recognized that better fix is below.
- Fix of first attached patch which does not change warning message
And I created patch entry of commitfest :)
https://commitfest.postgresql.org/52/5497/
What should I do additionally?
Do I need to
Hi Alexander,
On Sun, 22 Dec 2024 at 17:57, Robins Tharakan wrote:
>
> So if that's a key reason here, then probably by this time next week
things should
> settle down. I've begun setting it correctly (2 done with a few more to
go) - although
> given that some machines are at work, I'll try
On 2024-Dec-11, Antonin Houska wrote:
> Oh, it was too messy. I think I was thinking of too many things at once (such
> as locking the old heap, the new heap and the new heap's TOAST). Also, one
> thing that might have contributed to the confusion is that make_new_heap() has
> the 'lockmode' argum
On Thu, Jan 9, 2025 at 12:28 PM Sami Imseih wrote:
> > v35 seems fine to me from a UI standpoint; I suggest we move forward
> > with that.
>
> I am also OK with moving forward with a single \conninfo+, but
> I think we should include all parameters in [1] as part of the output.
> These are the pa
On 2025-Jan-09, Antonin Houska wrote:
> It seems you accidentally fixed another problem :-) I was referring to the
> 'lockmode' argument of make_new_heap(). I can try to write a patch for that
> but ...
>
> > Meanwhile the patch 0004 has some seemingly trivial conflicts. If you
> > want to rebas
1 - 100 of 109 matches
Mail list logo
