On Tue, Feb 18, 2025 at 07:29:51AM +, Hayato Kuroda (Fujitsu) wrote:
> According to the original thread [1], there was a wide consensus
> replication-related
> operations can be rejected, except the slot removal. I feel this is
> reasonable.
>
> Currently pg_drop_replication_slot() requires
Dear hackers:
Two months ago, we enhanced the group by key value elimination function. This
is a very useful function. When I was learning, I found a regression test case
that was not suitable, as follows:
-- When there are multiple supporting unique indexes and the GROUP BY contains
-- colu
Dear Michael,
> Perhaps a very naive question, but is there any point in authorizing
> manipulations of MyReplicationSlot in single-user mode, to begin with?
> With this remark, I would mean to apply a rule to
> ReplicationSlotAcquire(), so as all its callers would know about that.
According to t
On 13.02.2025 02:00, Alexander Korotkov wrote:
Thank you. I've integrated that into a patch. However, I've to
change keep_rinfo_list to be passed by pointer to
add_non_redundant_clauses(), because it might be changed in
distribute_restrictinfo_to_rels(). Without that there is a case of
duplica
On Tue, Jan 14, 2025 at 09:49:02AM +0100, Anthonin Bonnefoy wrote:
> During my tests, I've noticed I didn't handle query cancellation, this
> is now fixed. I've also added additional comments related to
> available_results to make it clearer that it depends on what the
> server has flushed to the c
Hi,
Thank you for working on this!
On Tue, 11 Feb 2025 at 21:41, Matheus Alcantara
wrote:
>
> Thanks for the review! v3 with the fixes attached.
I have a small comment.
diff --git a/contrib/amcheck/verify_heapam.c b/contrib/amcheck/verify_heapam.c
index 827312306f6..8c83870db7d 100644
--- a/co
On Wed, Feb 5, 2025 at 8:34 PM John Naylor wrote:
>
>
> On Tue, Jan 14, 2025 at 4:22 PM Andrey Borodin wrote:
> >
> > Looks good to me.
> > Nice stats for some cleaning up 34 insertions(+), 48 deletions(-).
>
> Great, I've attached v11 with a draft commit message. It also adds a comment
> for th
On Mon, 17 Feb 2025 at 09:49, Peter Smith wrote:
>
> Hi Shubham
>
> Some review comments for v7-0001.
>
> (I am late to this thread. If some of my comments have already been
> discussed and rejected please let me know).
>
> ==
> 1 GENERAL. Option Name?
>
> Wondering why the patch is introducin
On Monday, February 17, 2025, Sergey Prokhorenko <
sergeyprokhore...@yahoo.com.au> wrote:
> This means exactly the opposite of what you wrote. There is a big
> difference between UUID versions and data types. The properties of
> identifiers strongly depend on the implementation of generating funct
On Monday, February 17, 2025, Hayato Kuroda (Fujitsu) <
kuroda.hay...@fujitsu.com> wrote:
>
> backend> SELECT pg_create_physical_replication_slot(slot_name :=
> 'physical_slot', immediately_reserve := true);
Since this function releases the slot when it returns, re-acquisition, even
by the same
Hi All,
Thank you very much for your feedback! We investigated the recommendations as
we developed the current patch. Please refer to the comments below.
> I'd suggest targeting pg_qsort() directly, instead of list_sort().
> list_sort() is not used in very performance critical parts.
Using x86-
On Tue, Feb 18, 2025 at 12:41 AM Nathan Bossart
wrote:
>
> On Mon, Feb 17, 2025 at 05:58:01PM +0700, John Naylor wrote:
> > I tried using branching for the runtime check, and this looks like the
> > way to go:
> > - Existing -msse4.2 builders will still call directly, but inside the
> > function t
On Tue, Feb 18, 2025 at 05:33:05AM +, Hayato Kuroda (Fujitsu) wrote:
> I found $SUBJECT when I'm playing with the single user mode.
Perhaps a very naive question, but is there any point in authorizing
manipulations of MyReplicationSlot in single-user mode, to begin with?
With this remark, I wo
hi.
pg_restore
restore a PostgreSQL database from an
archive file created by pg_dump
or restore multiple PostgreSQL database from an
archive directory created by pg_dumpall
i think it's way too verbose. we can change it to:
restore PostgreSQL database from an
archiv
On Wed, 2025-02-12 at 17:01 -0800, Jeff Davis wrote:
> In any case, it seems like we have agreement to switch to the Bump
> context, so I'll do another round of tests to see if there are any
> downsides, then clean it up and commit v7-0001.
Results for v7-0001 (switch to Bump Allocator for table e
On Tue, Feb 18, 2025 at 10:32:40AM +0900, Kyotaro Horiguchi wrote:
> I found that a recent commit (fc069a3a631) introduced an inconsistent
> description for a new GUC variable, enable_self_join_elimination. It
> is written as "Enable removal of unique self-joins.", whereas similar
> variables use "
Dear hackers,
I found $SUBJECT when I'm playing with the single user mode.
How to reproduce
===
You can reproduce the failure with below steps.
```
# Initialize an instance
$ initdb -D data -U postgres
# Start it as single user mode
$ postgres --single -D data/ postgres
PostgreSQL stan
Ramanathan writes:
> I propose modifying the use of an EXCLUSIVE lock during the backward scan
> phase, then upgrading that lock to ACCESS EXCLUSIVE only for the actual
> truncation phase. Since the truncation phase should be relatively quick,
> the impact of the ACCESS EXCLUSIVE lock should be mi
On Tue, Feb 18, 2025 at 12:47 AM Álvaro Herrera wrote:
>
> Hello,
>
> On 2025-Feb-17, Amul Sul wrote:
>
> > I have renamed AlterConstraintStmt to ATAlterConstraint as per your
> > suggestion in the attached version. Apart from this, there are no
> > other changes, as the final behavior is still un
Hi,
The vacuum truncate operation consists of two phases: a backward scan of
the heap [1] followed by the work to perform the actual truncation [2]. In
the current implementation, both phases maintain an ACCESS EXCLUSIVE lock
on the relation for the duration of the processing. The ACCESS EXCLUSIVE
Hi,
i think during restore we should not force user to use -C during cases like
./pg_restore pdd -g -f -
./pg_restore pdd -a -f -
./pg_restore pdd -s -f -
because its not good to use -C to create database every time when we are
using these options individually.
latest patch throws following error f
> Attached version doesn't use the nonnulls array if an Exclude is
> specified, as I think it's not going to work with exclusions (as it's
> only an optimization, this is ok and can be taken out entirely if you
> prefer). I've also added your tests above to the tests.
I applied the v7 patch and ra
On Mon, Feb 17, 2025 at 10:18 PM Nathan Bossart
wrote:
>
> On Mon, Feb 17, 2025 at 07:57:22AM +0530, Amit Kapila wrote:
>
> > Alvaro, Nathan, do let us know if you would like to discuss more on
> > the use case for this new GUC idle_replication_slot_timeout?
> > Otherwise, we can proceed with this
On Thu, Feb 13, 2025 at 10:49 PM Fujii Masao
wrote:
>
>
>
> On 2025/02/06 8:57, Ryo Kanbayashi wrote:
> > On Wed, Feb 5, 2025 at 9:31 PM Ryo Kanbayashi
> > wrote:
> >>
> >> Hi hackers,
> >>
> >> When I wrote patch of ecpg command notice bug, I recognized needs of
> >> regression tests for ecpg c
On Tue, Feb 18, 2025 at 11:12:13AM +0800, Japin Li wrote:
> When I test test_escape, I find the usage of test_escape declares it
> support -c option, however, when I use it, it complains it is an
> invalid option.
>
> Here is a patch to fix it.
You are right, obviously. The only reason why this
On Mon, Feb 17, 2025 at 11:39:14AM -0800, Jeff Davis wrote:
> On Mon, 2024-11-18 at 13:58 +0900, Michael Paquier wrote:
>> Worth noting that unaccent.rules is unchanged after switching to
>> 16.0.0:
>> cd contrib/unaccent && make update-unicode
>
> What diffs are you seeing? I don't see any diffs
On Tue, Feb 11, 2025 at 11:48:03AM -0800, Jeff Davis wrote:
> I committed just the injection points part. It seemed simple and low-
> risk.
This has been committed and there was a CF entry:
https://commitfest.postgresql.org/patch/5560/
Switched it as committed now.
--
Michael
signature.asc
Desc
Hi, all
When I test test_escape, I find the usage of test_escape declares it
support -c option, however, when I use it, it complains it is an
invalid option.
Here is a patch to fix it.
diff --git a/src/test/modules/test_escape/test_escape.c
b/src/test/modules/test_escape/test_escape.c
index 0
Hello Sébastien
this case can be solved by xid64,but it seems like very few people
are interested.But it seems to me that xid64 should be implemented as soon
as possible.
Thanks
On Mon, Feb 17, 2025 at 9:47 PM Sébastien wrote:
> Hello weuhui,
>
> It's not a problem with heavy insert tabl
Dear Shubham,
Thanks for updating the patch. Few comments.
```
+ If a database is present on the source but missing on the target, an
+ error is raised.
```
I'm not sure this description is accurate. I feel there is a case the command
can
succeed.
Assuming that there are three data
On Feb 18, 2025 at 08:49 +0800, Michael Paquier , wrote:
> On Mon, Feb 17, 2025 at 07:14:59PM +0800, Zhang Mingli wrote:
> > On Feb 17, 2025 at 15:24 +0800, Michael Paquier ,
> > wrote:
> > > + * For foreign tables, they have no storage in Postgres.
> > > + * Inapplicable options are ignored.
> >
Hello.
I found that a recent commit (fc069a3a631) introduced an inconsistent
description for a new GUC variable, enable_self_join_elimination. It
is written as "Enable removal of unique self-joins.", whereas similar
variables use "Enables xxx". The attached first patch makes the
message consistent
On Mon, Feb 17, 2025 at 07:14:59PM +0800, Zhang Mingli wrote:
> On Feb 17, 2025 at 15:24 +0800, Michael Paquier , wrote:
>> + * For foreign tables, they have no storage in Postgres.
>> + * Inapplicable options are ignored.
>>
>> Wording is a bit strange here.
>
> * Foreign tables do not store dat
Dear Vignesh,
> > If a new database is created on the primary server while
> > pg_createsubscriber is running, the subscription will not be created
> > for the new database.
> > To reproduce this issue, follow these steps:
> > Debug pg_createsubscriber and set a breakpoint after the
> > fetch_sour
On Sat, Dec 21, 2024 at 1:57 AM Joel Jacobson wrote:
> How about:
>
> COPY table_name [ ( column_name ) ] { FROM | TO } 'filename' (FORMAT
> jsonb);
>
> - If column list is omitted, table_name must have exactly one column.
> - If column list is specified, it must be of length one.
> - The column
On Tue, Feb 18, 2025 at 2:21 AM Michael Paquier wrote:
>
> On Mon, Feb 17, 2025 at 11:25:05AM -0500, Tom Lane wrote:
> > This timeout failure on hachi looks suspicious as well:
> >
> > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hachi&dt=2025-02-17%2003%3A05%3A03
> >
> > Might be relev
On Mon, Feb 17, 2025 at 11:25:05AM -0500, Tom Lane wrote:
> This timeout failure on hachi looks suspicious as well:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hachi&dt=2025-02-17%2003%3A05%3A03
>
> Might be relevant that they are both aarch64?
Just logged into the host. The log
On Sat, Nov 23, 2024 at 5:30 AM Marcos Pegoraro wrote:
> There is no rule of when the number of records at the end of the lists
> should be shown or not
> Sometimes we show that line "(4 rows)", but sometimes not.
> Should we have a standard for it ?
>
I'm inclined toward no.
If we do, we proba
On Mon, Feb 17, 2025 at 06:38:07PM -0500, Peter Geoghegan wrote:
> +1. I very much welcome a more formal release process for the CF app,
> though with shorter feedback cycles.
Interesting evolution of the CF app. Thanks for all that.
--
Michael
signature.asc
Description: PGP signature
On Mon, Feb 17, 2025 at 4:33 PM Thomas Munro wrote:
> This looks fantastic. Thanks so much for working on it! And all the
> other usability improvements too.
+1. I very much welcome a more formal release process for the CF app,
though with shorter feedback cycles.
On that note: It'd be nice if
On Mon, Feb 17, 2025 at 03:14:59PM +, Bertrand Drouvot wrote:
> PFA the whole picture. 0001 is implementing the fields removal in pg_stat_wal
> (and also PendingWalStats). I think that's ok given the backend's type for
> which
> pgstat_tracks_io_bktype() returns false. But now you make me doub
On Wed, Jan 15, 2025 at 10:38 PM Peter Smith wrote:
> On Thu, Jan 16, 2025 at 3:26 PM Tom Lane wrote:
> >
> > Peter Smith writes:
> > > During some recent reviews, I came across some comments mentioning
> "toast" ...
> > > TOAST is a PostgreSQL acronym for "The Oversized-Attribute Storage
> > >
On Fri, Jan 17, 2025 at 05:11:41PM -0800, Masahiko Sawada wrote:
> Thank you for reviewing the patches. I agree with all the comments you
> made. I've addressed them and I've attached new version patches that
> now have some regression tests.
> Subject: [PATCH v3 4/5] pg_upgrade: Add --set-char-si
On Wed, Aug 28, 2024 at 9:52 AM Peter Geoghegan wrote:
> On Wed, Aug 28, 2024 at 9:49 AM Robert Haas wrote:
> > > > I agree with this analysis. I don't see why IndexScanDesc would ever
> > > > be the right place for this.
> > >
> > > Then what do you think is the right place?
> >
> > The paragrap
On Fri, Feb 14, 2025 at 2:02 AM Nazir Bilal Yavuz wrote:
> On Wed, 12 Feb 2025 at 17:49, Andres Freund wrote:
> > Obviously not your fault, but I do think it's pretty crazy that with the
> > same
> > available resources, netbsd and openbsd take considerably longer than linux
> > and freebsd, whi
On Mon, Feb 17, 2025 at 3:02 PM Tom Lane wrote:
> Ayush Vatsa writes:
> > Thanks Robert for confirming, let me submit a patch to fix the same.
>
> Well, the first thing you need is consensus on what the behavior
> should be instead.
>
> I have a very vague recollection that we concluded that SEL
On 18.02.2025 00:55, Nathan Bossart wrote:
On Tue, Feb 18, 2025 at 08:14:58AM +1100, Peter Smith wrote:
SUGGESTION
"-1 disables logging plans. 0 means log all plans."
+1
DefineCustomIntVariable("auto_explain.log_parameter_max_length",
"Sets the maximum length of query parameters to log
On Tue, Jan 21, 2025 at 11:21 PM jian he
wrote:
> hi.
>
> attached patch add function argument name to function substring and substr
> you can see the visual changes.
> mater behavior:
>
> \df substring
> List of functions
>Schema | Name| Result data type
Ayush Vatsa writes:
> Thanks Robert for confirming, let me submit a patch to fix the same.
Well, the first thing you need is consensus on what the behavior
should be instead.
I have a very vague recollection that we concluded that SELECT
privilege was a reasonable check because if you have that
On Tue, Feb 18, 2025 at 08:14:58AM +1100, Peter Smith wrote:
> SUGGESTION
> "-1 disables logging plans. 0 means log all plans."
+1
> DefineCustomIntVariable("auto_explain.log_parameter_max_length",
> "Sets the maximum length of query parameters to log.",
> - "Zero logs no query parameters, -1
Nathan Bossart writes:
> Perhaps another variation
> on this idea is to create a query walker that just looks for hasRowSecurity
> flags throughout the tree (and to use that to mark the plan cache entry
> appropriately).
That seems like a pretty plausible compromise position. So we'd
redefine Qu
> I'm not sure if I'd call that a "design". Sounds like I just made a
> mistake here.
Thanks Robert for confirming, let me submit a patch to fix the same.
Regards
Ayush Vatsa
ADE AWS
On Mon, Feb 17, 2025 at 01:08:29PM -0500, Tom Lane wrote:
> I think you're being too impatient. It's still an interesting
> topic, it just needs more thought to get to something committable.
Maybe I am. Thanks for chiming in.
> I find this has-row-security marking problem to be comparable
> to
On Mon, Feb 17, 2025 at 2:57 PM Tom Lane wrote:
> Ayush Vatsa writes:
> >> As it stands, a superuser can prewarm an index (because she bypasses all
> >> privilege checks including this one), but nobody else can.
>
> > That's not fully true. Any role can prewarm an index if the role has the
> > co
On Mon, Feb 17, 2025 at 10:03 PM Jelte Fennema-Nio wrote:
> The cfbot statuses will get filled in over the next few (12?) hours.
> The first few are already available[2]. If you notice any problems,
> please let me know.
This looks fantastic. Thanks so much for working on it! And all the
other
On Mon, Feb 17, 2025 at 8:50 PM Ilia Evdokimov
wrote:
>
>
> On 14.02.2025 19:47, Nathan Bossart wrote:
> > On Thu, Feb 13, 2025 at 05:01:59PM -0600, Nathan Bossart wrote:
> >> Okay, I took your suggestions in v7.
> > Committed. Thanks, David, Peter, and Daniel!
> >
>
> Hi,
>
> Maybe I'm being pic
Hi,
On 2025-02-12 13:00:22 -0500, Robert Haas wrote:
> On Tue, Feb 11, 2025 at 4:43 PM Andres Freund wrote:
> > One way we could avoid the need for a mechanism to reset-batch-in-progress
> > would be to make batch submission controlled by a flag on the IO. Something
> > like
> > pgaio_io_set_
On Sun, Feb 16, 2025 at 5:34 PM Michael Paquier wrote:
>
> On Sat, Feb 15, 2025 at 10:29:41AM +0100, Andrei Lepikhov wrote:
> > I have already implemented it twice in different ways as a core patch.
> > In my projects, we need to track queryId and plan node ID for two reasons:
>
> Are these availa
On Mon, 17 Feb 2025 at 18:24, Andres Freund wrote:
> Why not do this only in the if (rlim.rlim_cur < nclients + 3) case?
Done, I also changed it to not bump to rlim_max, but only to nclients
+ 3. The rest of the patches I'll update later. But response below.
> I think it might be better to have
On Fri, Feb 14, 2025 at 2:35 AM Bertrand Drouvot
wrote:
>
> Hi,
>
> On Fri, Feb 14, 2025 at 12:17:48AM -0800, Masahiko Sawada wrote:
> > On Tue, Feb 11, 2025 at 11:44 PM Bertrand Drouvot
> > wrote:
>
> > Looking at the latest custodian worker patch, the basic architecture
> > is to have a single
On Mon, Feb 17, 2025 at 12:57 PM Sergey Prokhorenko <
sergeyprokhore...@yahoo.com.au> wrote:
>
>
> Sergey Prokhorenko sergeyprokhore...@yahoo.com.au
>
>
> On Monday 17 February 2025 at 04:21:31 am GMT+3, Andrew Alsup <
> bluesbrea...@gmail.com> wrote:
>
>
> Sergey,
>
> I took a look at your patch
Ayush Vatsa writes:
>> As it stands, a superuser can prewarm an index (because she bypasses all
>> privilege checks including this one), but nobody else can.
> That's not fully true. Any role can prewarm an index if the role has the
> correct privileges.
Ah, right. An index will have null pg_cl
Matthias,
First off, I can't thank you enough for taking the time to review in detail the
patch. I appreciate and value your time and excellent feedback.
Second, I think that I should admit to the fact that I've also been working on
making PHOT functional again. I have it rebased against mast
> This test was to catch a crash that was happening in older version of
> the patch, so it doesn't have to verify the actual pgss entry.
It seems odd to keep this test because of crash behavior experienced
in a previous version of the patch. if the crash reason was understood
and resolved, why kee
On Fri, 2025-02-14 at 09:02 +0100, Peter Eisentraut wrote:
> This all looks quite reasonable to me. The code could obviously use
> a
> bit closer inspection, but the way you've structured it looked quite
> okay to me.
Attached a version that rebases both patches. In my patch, I added a
report_s
> On 17 Feb 2025, at 20:23, Tom Lane wrote:
> Daniel Gustafsson writes:
>
>> Isn't it postgres version mostly? We fixed so the testsuite passed on FIPS
>> enabled machines by just not using anything that violates FIPS but I don't
>> remember anything OpenSSL version specific.
>
> No, there are
> As it stands, a superuser can prewarm an index (because she bypasses all
> privilege checks including this one), but nobody else can.
That's not fully true. Any role can prewarm an index if the role has the
correct privileges.
postgres=# GRANT CREATE ON SCHEMA PUBLIC TO alpha;
GRANT
postgres=# SE
On Mon, 2024-11-18 at 13:58 +0900, Michael Paquier wrote:
> Worth noting that unaccent.rules is unchanged after switching to
> 16.0.0:
> cd contrib/unaccent && make update-unicode
What diffs are you seeing? I don't see any diffs to unaccent.rules
since Unicode 14.0.0.
Aside: it looks like that ta
Daniel Gustafsson writes:
> On 17 Feb 2025, at 17:26, Tom Lane wrote:
>> I believe the main concern is OpenSSL 1.x versus 3.x, not a specific
>> platform.
> Isn't it postgres version mostly? We fixed so the testsuite passed on FIPS
> enabled machines by just not using anything that violates FIP
Hello,
On 2025-Feb-17, Amul Sul wrote:
> I have renamed AlterConstraintStmt to ATAlterConstraint as per your
> suggestion in the attached version. Apart from this, there are no
> other changes, as the final behavior is still unclear based on the
> discussions so far.
Okay, thanks. I've taken yo
> On 17 Feb 2025, at 17:26, Tom Lane wrote:
>
> Mark Wong writes:
>> On Feb 17, 2025, at 2:36 AM, Álvaro Herrera wrote:
>>> As I understand, both of these Ubuntu versions ship with OpenSSL 1.1,
>>> though of course OpenSSL 3 could be installed on them. Should I just
>>> delete these requests?
On 17.02.2025 17:19, Robert Haas wrote:
On Mon, Feb 17, 2025 at 3:08 AM Ilia Evdokimov
wrote:
You're right—floor shouldn't be used since it behaves differently across
platforms, as Tom also pointed out earlier. I like the idea of using %,
but since the compiler doesn't allow this operation wit
On Mon, Feb 17, 2025 at 9:43 PM vignesh C wrote:
>
> On Wed, 22 Jan 2025 at 16:23, Shubham Khanna
> wrote:
> >
> > Hi,
> >
> > Following the recent comments on Patch v13-0001, the patch was not
> > applied to the HEAD. I have addressed the feedback and prepared a
> > rebased version to incorporat
On 17.02.2025 20:56, Peter Geoghegan wrote:
On Wed, Nov 27, 2024 at 8:36 AM Matthias van de Meent
wrote:
I think we should divide them because by dividing the total buffer usage by the
number of loops, user finds the average buffer consumption per loop. This gives
them a clearer picture of t
On Mon, Feb 17, 2025 at 4:03 AM Daniel Gustafsson wrote:
> The attached v51 squashes your commits together, discarding the changes
> discussed here, and takes a stab at a commit message for these as this is
> getting very close to be able to go in. There are no additional changes.
Awesome, thank
On Fri, Feb 14, 2025 at 2:21 PM Melanie Plageman
wrote:
>
> On Wed, Feb 12, 2025 at 5:37 PM Masahiko Sawada wrote:
> >
> > Since we introduced the eagar vacuum scan (052026c9b9), I need to
> > update the parallel heap vacuum patch. After thinking of how to
> > integrate these two features, I find
Nathan Bossart writes:
> Given there doesn't seem to be a huge amount of interest in this, I plan to
> mark it as Withdrawn soon.
I think you're being too impatient. It's still an interesting
topic, it just needs more thought to get to something committable.
I find this has-row-security marking
On Mon, Feb 17, 2025 at 05:58:01PM +0700, John Naylor wrote:
> I tried using branching for the runtime check, and this looks like the
> way to go:
> - Existing -msse4.2 builders will still call directly, but inside the
> function there is a length check and only for long input will it do a
> runtim
On Wed, Nov 27, 2024 at 8:36 AM Matthias van de Meent
wrote:
> > I think we should divide them because by dividing the total buffer usage by
> > the number of loops, user finds the average buffer consumption per loop.
> > This gives them a clearer picture of the resource intensity per basic unit
Given there doesn't seem to be a huge amount of interest in this, I plan to
mark it as Withdrawn soon.
--
nathan
Andres Freund writes:
> On 2025-02-12 22:52:52 +0100, Jelte Fennema-Nio wrote:
>> +/*
>> + * Bump the soft limit to the hard limit to not
>> run into low
>> + * file limits.
>> + */
>>
On 2/16/25 17:56, Tomas Vondra wrote:
>...
>
> Thanks. These patches look fine to me. I'll get them committed.
>
I've pushed both patches. Thanks!
--
Tomas Vondra
Hi,
Thanks for these patches!
On 2025-02-12 22:52:52 +0100, Jelte Fennema-Nio wrote:
> From 8e964db585989734a5f6c1449ffb4c62e1190a6a Mon Sep 17 00:00:00 2001
> From: Jelte Fennema-Nio
> Date: Tue, 11 Feb 2025 22:04:44 +0100
> Subject: [PATCH v2 1/3] Bump pgbench soft open file limit (RLIMIT_NOFI
> On Mon, Feb 17, 2025 at 09:51:32AM GMT, Sami Imseih wrote:
> > This should do it. The last patch for today,
>
> I looked at v27 today and have a few comments.
>
> 1/ It looks like the CTE test is missing a check for results.
This test was to catch a crash that was happening in older version of
t
Hi,
On 2024-12-25 15:57:34 +0300, Nazir Bilal Yavuz wrote:
> 1- It is time consuming to evict all shared buffers one by one using
> the pg_buffercache_evict() function.
This is really useful for benchmarking. When testing IO heavy workloads it
turns out to be a lot lower noise to measure with sha
Oops, I send wrong patch as a fix.
The right one is attached.
Pavel
On Mon, 17 Feb 2025 at 13:40, Pavel Borisov wrote:
>
> Hi, Kirill!
> Per your report, I revised the comment to fix typos. Also some little
> changes in grammar.
>
> Kind regards,
> Pavel Borisov
v2-0001-Fix-typo-and-grammar-in
On Mon, Feb 17, 2025 at 07:57:22AM +0530, Amit Kapila wrote:
> On Wed, Feb 12, 2025 at 1:16 PM Zhijie Hou (Fujitsu)
> wrote:
>> On Wednesday, February 12, 2025 11:56 AM Amit Kapila
>> wrote:
>> > Also, we previously didn't have a good experience with XID-based threshold
>> > parameters like vacu
Alexander Korotkov writes:
> I've spotted the failure on the buildfarm.
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=batta&dt=2025-02-17%2008%3A05%3A03
> I can't quickly guess the reason. I'm going to revert patch for now,
> then we investigate
This timeout failure on hachi looks su
Mark Wong writes:
> On Feb 17, 2025, at 2:36 AM, Álvaro Herrera wrote:
>> As I understand, both of these Ubuntu versions ship with OpenSSL 1.1,
>> though of course OpenSSL 3 could be installed on them. Should I just
>> delete these requests?
> I’m away from my desk until later this week so I do
On Mon, 10 Feb 2025 at 22:14, vignesh C wrote:
>
> On Mon, 10 Feb 2025 at 20:36, Shubham Khanna
> wrote:
> >
> > The attached patch contains the suggested changes.
>
> If a new database is created on the primary server while
> pg_createsubscriber is running, the subscription will not be created
>
Hi,
I was looking at CI on postgres's github mirror and noticed this failure:
https://cirrus-ci.com/task/6719398406258688
https://api.cirrus-ci.com/v1/artifact/task/6719398406258688/testrun/build/testrun/pg_waldump/001_basic/log/regress_log_001_basic
https://api.cirrus-ci.com/v1/artifact/task/6719
On Wed, 22 Jan 2025 at 16:23, Shubham Khanna
wrote:
>
> Hi,
>
> Following the recent comments on Patch v13-0001, the patch was not
> applied to the HEAD. I have addressed the feedback and prepared a
> rebased version to incorporate the necessary adjustments.
> Please find the updated patch.
The p
On Fri, 14 Feb 2025 at 12:59, Shlok Kyal wrote:
>
> I have used the changes suggested by you. Also I have updated the
> comments and the function name.
There is another concurrency issue possible:
+/* Check if a partitioned table has a foreign partition */
+bool
+check_partrel_has_foreign_table(F
On Fri, Feb 07, 2025 at 03:05:09PM -0600, Nathan Bossart wrote:
> Okay, I'll actually look at the patches next...
Ugh, it's already been 10 days since I said that. A couple of thoughts on
0001:
I'm not sure I understand the reason for capping relallfrozen to
relallvisible. From upthread, I gath
> On Feb 17, 2025, at 2:36 AM, Álvaro Herrera wrote:
> Hello,
>
> So in light of this conversation, what to do about the following pending
> requests?
>
> pgbfprod=> select format('%s %s', operating_system, os_version) as "OS" from
> pending();
> OS
>
> This should do it. The last patch for today,
I looked at v27 today and have a few comments.
1/ It looks like the CTE test is missing a check for results.
"""
-- Test constants evaluation in a CTE, which was causing issues in the past
WITH cte AS (
SELECT 'const' as const FROM test_merge
)
SELE
On Mon, 17 Feb 2025 at 15:45, Daniel Gustafsson wrote:
>> On 17 Feb 2025, at 15:39, Japin Li wrote:
>
>> When I read the ListenServerPort(), I noticed two incorrect translator
>> implementations: 1) the translator for setsockopt(SO_REUSEADDR), which
>> should not be "Unix"; 2) the translator for
Hi,
On Mon, Feb 17, 2025 at 07:59:26AM +, Bertrand Drouvot wrote:
> Hi,
>
> On Mon, Feb 17, 2025 at 04:25:46PM +0900, Michael Paquier wrote:
> > On Mon, Feb 17, 2025 at 06:59:40AM +, Bertrand Drouvot wrote:
> > > There is still something that would simplify what is done here: it's the
> >
> On 17 Feb 2025, at 15:39, Japin Li wrote:
> When I read the ListenServerPort(), I noticed two incorrect translator
> implementations: 1) the translator for setsockopt(SO_REUSEADDR), which
> should not be "Unix"; 2) the translator for setsockopt(IPV6_V6ONLY),
> which is applicable only to IPv6.
Hi, Victor!
On Mon, 17 Feb 2025 at 12:47, Victor Yegorov wrote:
>
> Hey.
>
> I find “Get rid of WALBufMappingLock" commit message misleading, 'cos Lock
> it's being replaced by CV, actually.
>
> Should the subject be changed to “Replace WALBufMappingLock with
> ConditionVariable” instead?
The
1 - 100 of 127 matches
Mail list logo
