On 2024-Mar-04, Hayato Kuroda (Fujitsu) wrote:
> Dear hackers,
>
> While reading codes, I found that ApplyLauncherShmemInit() and
> AutoVacuumShmemInit() are always called even if they would not be
> launched.
Note that there are situations where the autovacuum launcher is started
even though au
Hi,
On 2024-03-04 17:43:50 +1300, David Rowley wrote:
> On Thu, 29 Feb 2024 at 00:29, David Rowley wrote:
> > I switched over to working on doing what you did in 0002 for
> > generation.c and slab.c.
> >
> > See the attached patch which runs the same test as in [1] (aset.c is
> > just there for c
> On 29 Feb 2024, at 19:47, Danil Anisimow wrote:
>
> Answering your questions might take some time as I want to write a sample
> patch for pg_stat_statements and make some tests.
> What do you think about putting the patch to commitfest as it closing in a
> few hours?
I’ve switched the pat
> On 4 Mar 2024, at 02:01, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> I took the liberty to add this to the upcoming CF to make sure we don't lose
>> track of it.
>
> Thanks for doing that, because the cfbot pointed out a problem:
> I should have written pg_strncasecmp not strncasecmp.
Hi,
On Sun, Mar 03, 2024 at 03:44:34PM -0600, Nathan Bossart wrote:
> On Sun, Mar 03, 2024 at 11:40:00PM +0530, Bharath Rupireddy wrote:
> > On Sat, Mar 2, 2024 at 3:41 AM Nathan Bossart
> > wrote:
> >> Would you ever see "conflict" as false and "invalidation_reason" as
> >> non-null for a logic
> On 3 Mar 2024, at 01:19, Melanie Plageman wrote:
>
> I'm not
> sure if the ones that do have a target version = 17 are actually all
> the patches targeting 17.
Yes, for me it’s only a hint where to bump things up. I will extend scope on
other versions when I fill finish a pass though entr
On Fri, Mar 01, 2024 at 03:03:14PM -0600, Justin Pryzby wrote:
> I think if the user sets something "explicitly", the catalog should
> reflect what they set. Tablespaces have dattablespace, but AMs don't --
> it's a simpler case.
Okay.
> For 001: we don't *need* to support "ALTER SET AM default"
Hi,
On Thu, Feb 29, 2024 at 03:38:59PM +0530, Amit Kapila wrote:
> On Thu, Feb 29, 2024 at 9:13 AM Peter Smith wrote:
> >
> > On Tue, Feb 27, 2024 at 11:35 PM Amit Kapila
> > wrote:
> > >
> >
> > > Also, adding wait sounds
> > > more like a boolean. So, I don't see the proposed names any better
Dear Alvaro,
Thanks for giving comments!
> > While reading codes, I found that ApplyLauncherShmemInit() and
> > AutoVacuumShmemInit() are always called even if they would not be
> > launched.
>
> Note that there are situations where the autovacuum launcher is started
> even though autovacuum is
On Mon, 4 Mar 2024 at 06:27, Michael Paquier wrote:
> I have mentioned that on a separate thread,
Yeah, I didn't read all emails related to this feature
> Perhaps we could consider that as an exception in "contrib", or have a
> separate path for test modules we're OK to install (the calls had
>
On Mon, Mar 4, 2024 at 9:35 AM Peter Smith wrote:
>
> OK, if the code will remain as-is wouldn't it be better to anyway
> change the function name to indicate what it really does?
>
> e.g. NeedToWaitForWal --> NeedToWaitForWalFlushOrStandbys
>
This seems too long. I would prefer the current name
Tomas Vondra wrote on 18.02.2024 01:29:
Hi,
Please don't too-post on this list. The custom is to bottom-post or
reply inline, and it's much easier to follow such replies.
On 12/23/23 23:45, Przemysław Sztoch wrote:
date_bin has big problem with DST.
In example, if you put origin in winter zone
On Sun, Mar 3, 2024 at 9:28 PM Joe Conway wrote:
>
> All,
>
> The PostgreSQL Contributor Page
> (https://www.postgresql.org/community/contributors/) includes people who
> have made substantial, long-term contributions of time and effort to the
> PostgreSQL project. The PostgreSQL Contributors Team
On Sun, Mar 3, 2024 at 9:28 PM Joe Conway wrote:
>
> All,
>
> The PostgreSQL Contributor Page
> (https://www.postgresql.org/community/contributors/) includes people who
> have made substantial, long-term contributions of time and effort to the
> PostgreSQL project. The PostgreSQL Contributors Team
Hi,
On Sun, Mar 03, 2024 at 07:56:32AM +, Zhijie Hou (Fujitsu) wrote:
> Here is the V104 patch which addressed above and Peter's comments.
Thanks!
A few more random comments:
1 ===
+The function may be blocked if the specified slot is a failover enabled
s/blocked/waiting/ ?
2 ===
On Sun, Mar 3, 2024 at 9:28 PM Joe Conway wrote:
>
> All,
>
> The PostgreSQL Contributor Page
> (https://www.postgresql.org/community/contributors/) includes people who
> have made substantial, long-term contributions of time and effort to the
> PostgreSQL project. The PostgreSQL Contributors Team
On Mon, Mar 4, 2024 at 4:52 PM Bertrand Drouvot
wrote:
>
> On Sun, Mar 03, 2024 at 07:56:32AM +, Zhijie Hou (Fujitsu) wrote:
> > Here is the V104 patch which addressed above and Peter's comments.
>
> Thanks!
>
>
> 4 ===
>
> + /*
> +* Don't need to wait for the standbys to catch u
David Rowley writes:
> On Sun, 3 Mar 2024 at 20:08, Andy Fan wrote:
>> The issue can be reproduced with the following steps:
>>
>> create table x_events (.., created_at timestamp, a int, b int);
>>
>> create index idx_1 on t(created_at, a);
>> create index idx_2 on t(created_at, b);
>>
>> quer
Andrei Lepikhov writes:
> On 3/3/2024 14:01, Andy Fan wrote:
>> 1. We can let the user define the column as the value is increased day by
>> day. the syntax may be:
>> ALTER TABLE x_events ALTER COLUMN created_at ALWAYS_INCREASED.
>> then when a query like 'create_at op const', the
Em seg., 4 de mar. de 2024 às 03:18, Andrey M. Borodin
escreveu:
>
>
> > On 14 Jan 2024, at 18:55, John Naylor wrote:
> >
> > On Sat, Jan 13, 2024 at 9:36 PM Ranier Vilela
> wrote:
> >>
> >> Em ter., 9 de jan. de 2024 às 06:31, John Naylor <
> johncnaylo...@gmail.com> escreveu:
> >
> >>> This j
On Mon, Mar 4, 2024 at 1:05 PM Masahiko Sawada wrote:
>
> On Sun, Mar 3, 2024 at 2:43 PM John Naylor wrote:
> > Right, I should have said "reset". Resetting a context will delete
> > it's children as well, and seems like it should work to reset the tree
> > context, and we don't have to know whe
Richard Guo writes:
> Hi All,
>
> Eager aggregation is a query optimization technique that partially
> pushes a group-by past a join, and finalizes it once all the relations
> are joined. Eager aggregation reduces the number of input rows to the
> join and thus may result in a better overall p
> On 4 Mar 2024, at 13:42, Andrey M. Borodin wrote:
>
> Here’s my take on “Miscellaneous” section.
I’ve read other small sections.
Monitoring & Control
* Logging parallel worker draught
The patchset on improving loggin os resource starvation when parallel
workers are spawned. Some m
On 2024-Mar-04, Hayato Kuroda (Fujitsu) wrote:
> However, the second idea is still valid, which allows the allocation
> of shared memory dynamically. This is a bit efficient for the system
> which tuples won't be frozen. Thought?
I think it would be worth allocating AutoVacuumShmem->av_workItems
Hi hackers,
I wanted to hook into the EXPLAIN output for queries and add some extra
information, but since there is no standard_ExplainOneQuery() I had to copy
the code and create my own version.
Since the pattern with other hooks for a function WhateverFunction() seems
to be that there is a stan
On 3/4/24 02:29, Andy Fan wrote:
>
> Tomas Vondra writes:
>
>> On 3/3/24 07:10, Andy Fan wrote:
>>>
>>> Hi,
>>>
>>> Here is a updated version, the main changes are:
>>>
>>> 1. an shared_detoast_datum.org file which shows the latest desgin and
>>> pending items during discussion.
>>> 2. I rem
Hi,
> >> The call for a CFM volunteer is still open.
> >
> > I always wanted to try. And most of the stuff I'm interested in is already
> > committed.
> >
> > But given importance of last commitfest before feature freeze, we might be
> > interested in more experienced CFM.
> > If I can do someth
> > All,
> >
> > The PostgreSQL Contributor Page
> > (https://www.postgresql.org/community/contributors/) includes people who
> > have made substantial, long-term contributions of time and effort to the
> > PostgreSQL project. The PostgreSQL Contributors Team recognizes the
> > following people for
Tomas Vondra writes:
>>> But I'm a bit surprised the patch needs to pass a
>>> MemoryContext to so many places as a function argument - that seems to
>>> go against how we work with memory contexts. Doubly so because it seems
>>> to only ever pass CurrentMemoryContext anyway. So what's that abo
On 09.02.24 10:05, Andy Fan wrote:
2. Where is the current feature blocked for the past few months?
It's error message compatible issue! Continue with above setup:
master:
select * from tb where (a->'b')::numeric > 3::numeric;
ERROR: cannot cast jsonb string to type numeric
select * from tb
Hi hackers,
>> I did not see any test addition for this, can we add it?
>
>
> Ok, added it in the attached version.
>
> This was an experimental patch, I was looking for the comment on the proposed
> approach -- whether we could simply skip the throwaway NOT NULL constraint for
> deferred PK const
Hi,
> I wanted to hook into the EXPLAIN output for queries and add some extra
> information, but since there is no standard_ExplainOneQuery() I had to copy
> the code and create my own version.
>
> Since the pattern with other hooks for a function WhateverFunction() seems to
> be that there is
On 27.02.24 14:25, Alvaro Herrera wrote:
I like this idea and I think we should integrate it with the objective
of it becoming the workhorse of ABI-stability testing. However, I do
not think that the subsequent patches should be part of the tree at all;
certainly not the produced .xml files in y
Hi Teodor,
> I'd like to suggest two independent patches to improve performance of type
> cache
> cleanup. I found a case where type cache cleanup was a reason for low
> performance. In short, customer makes 100 thousand temporary tables in one
> transaction.
>
> 1 mapRelType.patch
>It just a
Dear Alvaro,
Thanks for discussing!
>
> I think it would be worth allocating AutoVacuumShmem->av_workItems using
> dynamic shmem allocation, particularly to prevent workitems from being
> discarded just because the array is full¹; but other than that, the
> struct is just 64 bytes long so I doub
When a backend is blocked on writing data (such as with a network
error or a very slow client), indicated with wait event ClientWrite,
it appears to not properly notice that it's overrunning
max_standby_streaming_delay, and therefore does not cancel the
transaction on the backend.
I've reproduced
Le samedi 2 mars 2024, 23:29:52 CET Tomas Vondra a écrit :
> These are "my" animals (running at a local university). There's a couple
> interesting details:
Hi Tomas,
do you still have the failing cluster data ?
Noah pointed me to this thread, and it looks a bit similar to the FSM
corruption is
On Monday, March 4, 2024 7:22 PM Bertrand Drouvot
wrote:
>
> Hi,
>
> On Sun, Mar 03, 2024 at 07:56:32AM +, Zhijie Hou (Fujitsu) wrote:
> > Here is the V104 patch which addressed above and Peter's comments.
>
> Thanks!
>
> A few more random comments:
Thanks for the comments!
>
> 1 ===
>
On Monday, March 4, 2024 9:55 AM Peter Smith wrote:
>
> On Sun, Mar 3, 2024 at 6:51 PM Zhijie Hou (Fujitsu)
> wrote:
> >
> > On Sunday, March 3, 2024 7:47 AM Peter Smith
> wrote:
> > >
>
> > > 3.
> > > +
> > > +
> > > + Value * is not accepted as it is
> > > inappropria
On Monday, March 4, 2024 5:52 PM Amit Kapila wrote:
>
> On Mon, Mar 4, 2024 at 9:35 AM Peter Smith
> wrote:
> >
> > OK, if the code will remain as-is wouldn't it be better to anyway
> > change the function name to indicate what it really does?
> >
> > e.g. NeedToWaitForWal --> NeedToWaitForWalF
On 3/4/24 14:16, Ronan Dunklau wrote:
> Le samedi 2 mars 2024, 23:29:52 CET Tomas Vondra a écrit :
>> These are "my" animals (running at a local university). There's a couple
>> interesting details:
>
> Hi Tomas,
> do you still have the failing cluster data ?
>
> Noah pointed me to this threa
On Mon, 4 Mar 2024 at 12:34, Aleksander Alekseev
wrote:
>
> > This was an experimental patch, I was looking for the comment on the
> > proposed
> > approach -- whether we could simply skip the throwaway NOT NULL constraint
> > for
> > deferred PK constraint. Moreover, skip that for any PK cons
Hello Hayato,
On 2024-Mar-04, Hayato Kuroda (Fujitsu) wrote:
> OK, I understood that my initial proposal is not so valuable, so I can
> withdraw it.
Yeah, that's what it seems to me.
> About the suggetion, you imagined AutoVacuumRequestWork() and
> brininsert(), right?
Correct.
> I agreed it
Hello,
As we are currently experiencing a FSM corruption issue [1], we need to
rebuild FSM when we detect it.
I noticed we have something to truncate a visibility map, but nothing for the
freespace map, so I propose the attached (liberally copied from the VM
counterpart) to allow to truncate
> On 6 Jan 2024, at 00:03, Nathan Bossart wrote:
> I gave it a try.
Looking at this again I think this is about ready to go in. My only comment is
that doc/src/sgml/archive-modules.sgml probably should be updated to refer to
setting the errdetail, especially since we document the errormessage t
Hi,
On Tue, Feb 20, 2024 at 02:24:52AM -0500, Corey Huinker wrote:
> On Thu, Feb 15, 2024 at 4:09 AM Corey Huinker
> wrote:
>
> > Posting v5 updates of pg_import_rel_stats() and pg_import_ext_stats(),
> > which address many of the concerns listed earlier.
> >
> > Leaving the export/import script
Op 3/4/24 om 10:40 schreef Amit Langote:
Hi Jian,
Thanks for the reviews and sorry for the late reply. Replying to all
emails in one.
> [v40-0001-Add-SQL-JSON-query-functions.patch]
> [v40-0002-Show-function-name-in-TableFuncScan.patch]
> [v40-0003-JSON_TABLE.patch]
In my hands (applying with
On 2024-Mar-04, Erik Rijkers wrote:
> In my hands (applying with patch), the patches, esp. 0001, do not apply.
> But I see the cfbot builds without problem so maybe just ignore these FAILED
> lines. Better get them merged - so I can test there...
It's because of dbbca2cf299b. It should apply cl
On 2024-Mar-03, Tom Lane wrote:
> This is certainly simpler, but I notice that it holds the current
> LWLock across the line
>
> ptr = (MultiXactMember *) palloc(length * sizeof(MultiXactMember));
>
> where the old code did not. Could the palloc take long enough that
> holding the lock is
On 01/03/2024 23:49, Jacob Champion wrote:
On Wed, Feb 28, 2024 at 4:10 AM Heikki Linnakangas wrote:
I think we'd want to *avoid* changing the major protocol version in a
way that would introduce a new roundtrip, though.
I'm starting to get up to speed with this patchset. So far I'm mostly
te
Hi,
On Mon, Mar 04, 2024 at 01:28:04PM +, Zhijie Hou (Fujitsu) wrote:
> Attach the V105 patch set
Thanks!
Sorry I missed those during the previous review:
1 ===
Commit message: "these functions will block until"
s/block/wait/ ?
2 ===
+when used with logical failover slots, will
Thanks for looking into this.
On Thu, Feb 22, 2024 at 1:54 AM Jeff Davis wrote:
>
> > 3.
> > @@ -6371,7 +6373,9 @@ GetFlushRecPtr(TimeLineID *insertTLI)
> > If at all, a read
> > barrier is warranted here, we can use atomic read with full barrier
>
> I don't think we need a full barrier but I'm
On 3/4/24 02:23, Andy Fan wrote:
>
> Tomas Vondra writes:
>
>> On 2/26/24 16:29, Andy Fan wrote:
>>>
>>> ...>
>>> I can understand the benefits of the TOAST cache, but the following
>>> issues looks not good to me IIUC:
>>>
>>> 1). we can't put the result to tts_values[*] since without the pl
Peter Eisentraut writes:
> On 09.02.24 10:05, Andy Fan wrote:
>> 2. Where is the current feature blocked for the past few months?
>> It's error message compatible issue! Continue with above setup:
>> master:
>> select * from tb where (a->'b')::numeric > 3::numeric;
>> ERROR: cannot cast jsonb
On 3/4/24 06:33, David Rowley wrote:
> On Sun, 3 Mar 2024 at 20:08, Andy Fan wrote:
>> The issue can be reproduced with the following steps:
>>
>> create table x_events (.., created_at timestamp, a int, b int);
>>
>> create index idx_1 on t(created_at, a);
>> create index idx_2 on t(created_at, b)
> On 4 Mar 2024, at 16:47, Ranier Vilela wrote:
>
> Does filling a memory area, one by one, with branches, need strong evidence
> to prove that it is better than filling a memory area, all at once, without
> branches?
I apologise for being too quick to decide to mark the patch RwF. Wold yo
On Mon, Mar 04, 2024 at 03:21:59PM +0100, Daniel Gustafsson wrote:
> Looking at this again I think this is about ready to go in. My only comment
> is
> that doc/src/sgml/archive-modules.sgml probably should be updated to refer to
> setting the errdetail, especially since we document the errormess
FWIW there's a stupid bug in 0002, which is fixed here. I'm writing a
simple test for it.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"Now I have my system running, not a byte was off the shelf;
It rarely breaks and when it does I fix the code myself.
It's st
Hi,
The function var_strcmp is a critical function.
Inside the function, there is a shortcut condition,
which allows for a quick exit.
Unfortunately, the current code calls a very expensive function beforehand,
which if the test was true, all the call time is wasted.
So, IMO, it's better to postp
On Mon, 4 Mar 2024 at 18:39, Ranier Vilela wrote:
>
> Hi,
>
> The function var_strcmp is a critical function.
> Inside the function, there is a shortcut condition,
> which allows for a quick exit.
>
> Unfortunately, the current code calls a very expensive function beforehand,
> which if the test
>
> I decided to whip up a PoC patch implementing this approach, to get a
> better idea of how it compares to the original proposal, both in terms
> of performance and code complexity.
>
> Attached are two patches that both add a simple cache in detoast.c, but
> differ in when exactly the caching
Em seg., 4 de mar. de 2024 às 14:54, Matthias van de Meent <
boekewurm+postg...@gmail.com> escreveu:
> On Mon, 4 Mar 2024 at 18:39, Ranier Vilela wrote:
> >
> > Hi,
> >
> > The function var_strcmp is a critical function.
> > Inside the function, there is a shortcut condition,
> > which allows for
On Sat, Mar 2, 2024 at 10:46 AM James Coleman wrote:
> If I can rephrase this idea: it's basically "delay this interrupt
> until inline to the next ExecProcNode execution".
Yes, but it's not just that. It also means that the code which would
handle the interrupt doesn't need to be called at every
Hi,
On 2024-03-04 08:47:11 -0300, Ranier Vilela wrote:
> Does filling a memory area, one by one, with branches, need strong evidence
> to prove that it is better than filling a memory area, all at once, without
> branches?
That's a bogus comparison:
a) the memset version modifies the whole array
On Sat, Feb 24, 2024 at 12:10 PM Noah Misch wrote:
> Agreed, those don't touch relation data files. I think you've got all
> relation data file mutations. XLOG_DBASE_CREATE_FILE_COPY and XLOG_DBASE_DROP
> are the only record types that touch a relation data file without mentioning
> it in XLogRe
Hi,
On Wed, Feb 21, 2024 at 10:26:11PM +0100, Tomas Vondra wrote:
> Thanks for the patch. I took a closer look at v3, so let me share some
> review comments. Please push back if you happen to disagree with some of
> it, some of this is going to be more a matter of personal preference.
Thanks! As
On Mon, Mar 4, 2024 at 12:35 AM Amul Sul wrote:
> Yes, you are correct. Both the current caller of get_controlfile() has
> access to the root directory.
>
> I have dropped the 0002 patch -- I don't have a very strong opinion to
> refactor
> get_controlfile() apart from saying that it might be goo
I wrote:
> Now that the multirange issue is fixed (3e8235ba4), here's a
> new version that includes the needed recursion in ALTER EXTENSION.
> I spent some more effort on a proper test case, too.
I looked this over again and pushed it.
regards, tom lane
> On 14 Feb 2024, at 21:48, Daniel Gustafsson wrote:
>> On 14 Feb 2024, at 19:51, Nathan Bossart wrote:
>> On Wed, Feb 14, 2024 at 10:04:49AM -0500, Tom Lane wrote:
>>> Daniel Gustafsson writes:
Attached is a diff to show what it would look like to remove adminpack
(catalog
vers
On 3/4/24 18:08, Andy Fan wrote:
> ...
>>
>>> I assumed that releasing all of the memory at the end of executor once
>>> is not an option since it may consumed too many memory. Then, when and
>>> which entry to release becomes a trouble for me. For example:
>>>
>>> QUERY PLAN
>>>
> On 4 Mar 2024, at 18:22, Nathan Bossart wrote:
>
> On Mon, Mar 04, 2024 at 03:21:59PM +0100, Daniel Gustafsson wrote:
>> Looking at this again I think this is about ready to go in. My only comment
>> is
>> that doc/src/sgml/archive-modules.sgml probably should be updated to refer to
>> settin
On Mon, Mar 4, 2024 at 2:43 PM Michael Banck wrote:
> > 3) Do we actually need the exponential_backoff GUC? Wouldn't it be
> > sufficient to have the maximum value, and if it's -1 treat that as no
> > backoff?
>
> That is a good question, I guess that makes sense.
>
> The next question then is: wh
On Sat, 2 Mar 2024 at 02:30, Peter Geoghegan wrote:
>
> On Thu, Feb 15, 2024 at 6:36 PM Peter Geoghegan wrote:
> > Attached is v11, which now says something like that in the commit
> > message.
>
> Attached is v12.
Some initial comments on the documentation:
> +that searches for multiple va
> On 16 Nov 2023, at 21:49, Daniel Gustafsson wrote:
>
> In the "Allow tests to pass in OpenSSL FIPS mode" thread [0] it was discovered
> that 3DES is joining the ranks of NIST disallowed algorithms. The attached
> patch adds a small note to the pgcrypto documentation about deprecated uses of
>
Hi,
First, apologies on the patch. Find re-attached updated version.
Now I have some questions
#1
> -#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
> +#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31)
> +<< 31))
>
> IME this means that the autoconf yo
On Mon, Mar 04, 2024 at 09:27:23PM +0100, Daniel Gustafsson wrote:
> Looks good from a read-through, I like it. A few comments on the commit
> message only:
>
> actionable details about the source of the miconfiguration. This
> s/miconfiguration/misconfiguration/
I reworded the commit message a
Hi,
On Mon, Mar 04, 2024 at 03:50:07PM -0500, Robert Haas wrote:
> I agree that two GUCs here seems to be one more than necessary, but I
> wonder whether we couldn't just say 0 means no exponential backoff and
> any other value is the maximum time.
Alright, I have changed it so that auth_delay.m
Nathan Bossart writes:
> On Mon, Mar 04, 2024 at 09:27:23PM +0100, Daniel Gustafsson wrote:
>> Reviewed-by: Daniel Gustafsson, ¡lvaro Herrera
>> Alvaro's name seems wrong.
> Hm. It looks alright to me. I copied the name from his e-mail signature,
> which has an accent over the first 'A'. I ass
Alvaro Herrera writes:
> Pushed that way, but we can discuss further wording improvements/changes
> if someone wants to propose any.
I just noticed that drongo is complaining about two lines added
by commit 53c2a97a9:
drongo| 2024-03-04 14:34:52 |
../pgsql/src/backend/access/transam/sl
(Please don't top-post on the Postgres lists.)
On Mon, Mar 04, 2024 at 09:39:36PM +, Amonson, Paul D wrote:
> First, apologies on the patch. Find re-attached updated version.
Thanks for the new version of the patch.
>> -#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
>> +#def
On Mon, Mar 04, 2024 at 10:51:41AM +0100, Jelte Fennema-Nio wrote:
> Yeah, it makes sense that you'd want to backport fixes/changes to
> this. As long as you put a disclaimer in the docs that you can do that
> for this module, I think it would be fine. Our tests fairly regularly
> break anyway when
I wrote:
> It looks like SLRU_PAGE_EMPTY has (by chance, or deliberately)
> the numeric value of zero, so I guess the majority of our BF
> animals are understanding this as "address != NULL". But that
> doesn't look like a useful test to be making.
In hopes of noticing whether there are other sim
On Mon, Mar 04, 2024 at 10:03:13PM +0100, Daniel Gustafsson wrote:
> Cleaning out my inbox I came across this which I still think is worth doing,
> any objections to going ahead with it?
I think the general idea is reasonable, but I have two small comments:
* Should this be a "Warning" and/or mov
On Mon, Mar 04, 2024 at 03:08:03PM -0300, Ranier Vilela wrote:
> I can't see any user validation at the function pg_newlocale_from_collation.
Matthias is right, look closer. I can see more than one check,
especially note the one related to the collation version mismatch that
should not be silentl
On Tue, 5 Mar 2024 at 00:37, Andy Fan wrote:
>
> David Rowley writes:
> > I don't think it would be right to fudge the costs in any way, but I
> > think the risk factor for IndexPaths could take into account the
> > number of unmatched index clauses and increment the risk factor, or
> > "certaint
On Mon, Mar 04, 2024 at 05:00:00AM +0530, Bharath Rupireddy wrote:
> How about an extra option to error_action ignore-with-verbose which is
> similar to ignore but when specified emits one NOTICE per malformed
> row? With this, one can say COPY x FROM stdin (ON_ERROR
> ignore-with-verbose);.
>
> A
Michael Paquier writes:
> On Mon, Mar 04, 2024 at 03:08:03PM -0300, Ranier Vilela wrote:
>> I can't see any user validation at the function pg_newlocale_from_collation.
> Matthias is right, look closer. I can see more than one check,
> especially note the one related to the collation version mis
On Tue, 2024-02-27 at 09:48 -0500, Stephen Frost wrote:
> Attached is an updated patch which drops the 'such as' and adds a
> sentence mentioning that BRIN is the only in-core summarizing index.
The original patch reads more clearly to me. In v4, summarizing (the
exception) feels like it's dominat
Here are some review comments for v105-0001
==
doc/src/sgml/config.sgml
1.
+
+The standbys corresponding to the physical replication slots in
+standby_slot_names must configure
+sync_replication_slots = true so they can receive
+logical failover slot
On Mon, Feb 26, 2024 at 02:01:45PM +, Bertrand Drouvot wrote:
> Though [1] mentioned up-thread is not pushed yet, I'm Sharing the POC patch
> now
> (see the attached).
I have looked at what you have here.
First, in a build where 818fefd8fd is included, this makes the test
script a lot slower
On Mon, Feb 26, 2024 at 09:51:40AM +0530, Robert Haas wrote:
> > I am not sure that it is a good idea to relax that for PG17 at this
> > stage of the development cycle, though, as we have already done a lot
> > in this area for pg_upgrade and it may require more tweaks during the
> > beta period de
On Mon, Mar 4, 2024 at 8:48 PM John Naylor wrote:
>
> On Mon, Mar 4, 2024 at 1:05 PM Masahiko Sawada wrote:
> >
> > On Sun, Mar 3, 2024 at 2:43 PM John Naylor wrote:
>
> > > Right, I should have said "reset". Resetting a context will delete
> > > it's children as well, and seems like it should w
Dear Alvaro,
Thanks for giving comments!
> > I agreed it sounds good, but I don't think it can be implemented by
> > current interface. An interface for dynamically allocating memory is
> > GetNamedDSMSegment(), and it returns the same shared memory region if
> > input names are the same. Theref
cfbot claims that this one needs another rebase.
I've spent some time thinking about this one. I'll admit I'm a bit worried
about adding more complexity to this state machine, but I also haven't
thought of any other viable approaches, and this still seems like a useful
feature. So, for now, I th
On Mon, Oct 23, 2023 at 03:25:42PM -0500, Nathan Bossart wrote:
> rebased
I saw that this thread was referenced elsewhere [0], so I figured I'd take
a fresh look. From a quick glance, I'd say 0001 and 0002 are pretty
reasonable and could probably be committed for v17. 0003 probably requires
some
Hi, Here are some review comments for v7-0001
1.
/*
* binaryheap_free
*
* Releases memory used by the given binaryheap.
*/
void
binaryheap_free(binaryheap *heap)
{
pfree(heap);
}
Shouldn't the above function (not modified by the patch) also firstly
free the memory allocated for the heap->bh_
On Mon, Mar 4, 2024 at 10:33 AM wenhui qiu wrote:
> HI Richard
> Now it is starting the last commitfest for v17, can you respond to
> Alena Rybakina points?
>
Thanks for reminding. Will do that soon.
Thanks
Richard
On Tue, Jan 30, 2024 at 2:51 PM Alena Rybakina
wrote:
> I have reviewed your patch and I think it is better to add an Assert for
> JOIN_RIGHT_SEMI to the ExecMergeJoin and ExecNestLoop functions to
> prevent the use of RIGHT_SEMI for these types of connections (NestedLoop
> and MergeJoin).
Hmm,
On Mon, 4 Mar 2024 at 17:43, Aleksander Alekseev
wrote:
>
> > > All,
> > >
> > > The PostgreSQL Contributor Page
> > > (https://www.postgresql.org/community/contributors/) includes people who
> > > have made substantial, long-term contributions of time and effort to the
> > > PostgreSQL project. T
>
>> 2. more likely to use up all the memory which is allowed. for example:
>> if we set the limit to 1MB, then we kept more data which will be not
>> used and then consuming all of the 1MB.
>>
>> My method is resolving this with some helps from other modules (kind of
>> invasive) but can contr
1 - 100 of 126 matches
Mail list logo
