On 28.02.25 14:36, Srinath Reddy wrote:
Hi,
I have applied the patch and verified,and patch LGTM.
committed, thanks
Hello Hackers!
Álvaro, Andrey, Aleksander! We have not been discussing anything in the
thread for the past ten days. Can we mark this thread as "Ready for
Merge" or should I improve something in the patch. If I should, I am
ready to do it.
Looking forward to your feedback.
Evgeny Voropaev.
Dear Amit,
> > When the ALTER PUBLICATION command is executed, all entries in
> RelationSyncCache
> > will be discarded anyway. This mechanism works well but is sometimes not
> efficient.
> > For example, when the ALTER PUBLICATION DROP TABLE is executed,
> > 1) the specific entry in RelationSyncC
On 28/2/2025 20:26, Robert Haas wrote:
So here are some patches.
Yes, this is a big pain for extension developers. As I remember, it was
discussed multiple times in the hackers' mailing list.
Because there is no explain node hook, I use a patch in almost each of
my extensions: I write optimisat
On Tue, Mar 4, 2025 at 8:56 AM Andrei Lepikhov wrote:
> Passing through the patches, I would say that changing the order of 0001
> and 0002 would make them more independent.
Hmm, I thought this order made sense, but I could reorder them if
there's some compelling reason to do so. If there's no pa
On 2025/03/04 17:57, jian he wrote:
On Mon, Mar 3, 2025 at 5:05 PM Fujii Masao wrote:
Thanks for the patch!
The patch basically looks good to me.
I’ve made some minor cosmetic adjustments — the updated patch is attached.
Unless there are any objections, I'm thinking to commit it.
I che
Hi,
On Tue, Mar 04, 2025 at 08:54:13AM -0600, Nathan Bossart wrote:
> On Tue, Mar 04, 2025 at 03:12:18PM +0100, Magnus Hagander wrote:
> > In light of bb8dff9995f (add cost delay time to progress views), looking at
> > the output of 30a6ed0ce4b (track per-relation time spent on vacuum and
> > anal
On 4/3/2025 16:14, Robert Haas wrote:
On Tue, Mar 4, 2025 at 10:12 AM Andrei Lepikhov wrote:
Also, I think this feature is quite close to the discussion on the
possibility of adding an extensible list field into Query, PlanState,
Plan, etc. nodes to let extensions gather and transfer some addit
On 04.03.25 02:21, Jelte Fennema-Nio wrote:
6. The "latest email" column now shows "time since" (e.g. 1 week ago)
instead of an exact timestamp. You can still see the exact timestamp
by hovering over the cell.
Another small complaint: I don't like this style of relative times. (I
have also co
On Tue, Mar 4, 2025 at 6:05 AM Mark Dilger
wrote:
> But then I tried:
>
> +DO $$
> +DECLARE
> + a jsonb := '{"": 6, "NU": [{"": [[3]]}, [6], [2], "bCi"], "aaf": [-6,
> -8]}'::jsonb;
> +BEGIN
> + WHILE a IS NOT NULL
> + LOOP
> +RAISE NOTICE '%', a;
> +a := COALESCE(a."NU", a[2]);
> + E
On 3/3/25 21:52, Andres Freund wrote:
> Hi,
>
> On 2025-03-03 21:31:42 +0100, Tomas Vondra wrote:
>> On 3/3/25 19:10, Andres Freund wrote:
>>> On 2024-09-21 20:33:49 +0200, Tomas Vondra wrote:
I've finally pushed this, after many rounds of careful testing to ensure
no regressions, and
On 4/3/2025 15:23, Robert Haas wrote:
On Tue, Mar 4, 2025 at 8:56 AM Andrei Lepikhov wrote:
Passing through the patches, I would say that changing the order of 0001
and 0002 would make them more independent.
Hmm, I thought this order made sense, but I could reorder them if
there's some compel
On Tue, Mar 4, 2025 at 10:12 AM Andrei Lepikhov wrote:
> Also, I think this feature is quite close to the discussion on the
> possibility of adding an extensible list field into Query, PlanState,
> Plan, etc. nodes to let extensions gather and transfer some additional
> data starting with the firs
Robert Haas writes:
> Honestly, I just noticed that the buildfarm member in question had
> been red for over a month and I figured it was a setup issue of some
> kind. I guess I was wrong. It didn't cross my mind that a commit over
> a month ago had broken things and there had been no subsequent r
Hi,
On 2025-03-04 14:05:22 +0100, Tomas Vondra wrote:
> On 3/3/25 21:52, Andres Freund wrote:
> >> It's not a proper constant, of course, but it seemed close
> >> enough. Yes, it might confuse people into thinking it's a constant, or
> >> is there some additional impact?
> >
> > That seems plenty
Hi,
On 2025-03-04 11:53:30 +0300, Nazir Bilal Yavuz wrote:
> I rebased Andres' v2-0002 on top of recent changes and wrote a small
> commit message. v4 is attached.
Thanks for doing that, it does look a lot better after, I think!
Greetings,
Andres Freund
On Mon, Mar 3, 2025 at 6:09 PM Julien Rouhaud wrote:
> Well, AFAIK the usual habit when something is broken and a buildfarm cilent
> upgrade is needed is to warn the buildfarm owners. There was an email
> yesterday for installing libcurl which I did. There was an email before last
> release for
On 2025-03-03 Mo 6:12 PM, Tom Lane wrote:
Julien Rouhaud writes:
On Mon, Mar 3, 2025 at 2:53 PM Tom Lane wrote:
I believe it hasn't been updated with the buildfarm client changes
needed to run sepgsql-check since aeb8ea361.
Well, AFAIK the usual habit when something is broken and a buildfarm
>I decided to leave this out, since I just remembered that the most
> likely change is actually to move to 64-bit offsets, as was proposed
> here and has some enthusiastic support:
>
> https://www.postgresql.org/message-id/CACG=ezawg7_nt-8ey4akv2w9lculthhknwcawmbgeetnjrj...@mail.gmail.com
Thanks f
Rebase on current master.
--
regards, Andrei LepikhovFrom 79dee863be9c3f400c04d74f4e8493c8929eefbe Mon Sep 17 00:00:00 2001
From: "Andrei V. Lepikhov"
Date: Tue, 4 Mar 2025 15:24:28 +0100
Subject: [PATCH v5] Add prosupport helpers to aggregate functions.
Following the spirit of ed1a88d, add a p
On Tue, Mar 04, 2025 at 08:33:46AM -0500, Robert Haas wrote:
> On Mon, Mar 3, 2025 at 6:09 PM Julien Rouhaud wrote:
> > Well, AFAIK the usual habit when something is broken and a buildfarm cilent
> > upgrade is needed is to warn the buildfarm owners. There was an email
> > yesterday for installin
On Tue, Mar 4, 2025 at 5:35 AM Álvaro Herrera wrote:
> The idea of this dashboard
> sounds very good to me, but it shouldn't replace the initial page (list
> of commitfests). Maybe put this in a URL such as
> https://commitfest.postgresql.org/you
> or
> https://commitfest.postgresql.org/me
>
Anthonin Bonnefoy wrote:
> Another possible option would be to directly send the command without
> requiring an additional meta-command, like "SELECT 1 \bind". However,
> this would make it more painful to introduce new parameters, plus it
> makes the \bind and \bind_named inconsistent as
On Tue, 4 Mar 2025 at 13:36, Amit Kapila wrote:
>
> On Tue, Mar 4, 2025 at 4:05 PM Álvaro Herrera wrote:
> > I think showing different pages on the same URL depending on whether
> > you're logged in or not is not great UX.
> >
>
> +1. The default should be what we see today, and there should be s
On Mon, Mar 3, 2025 at 12:23 PM Alexandra Wang
wrote:
> I've attached v10, which addresses your feedback.
>
>
Hi Alex! Thanks for the patches.
In src/test/regress/sql/jsonb.sql, the section marked with "-- slices are
not supported" should be relabeled. That comment predates these patches,
and
On Tue, 4 Mar 2025 at 12:22, vignesh C wrote:
>
> On Mon, 3 Mar 2025 at 16:41, Amit Kapila wrote:
> >
> > On Mon, Mar 3, 2025 at 2:30 PM vignesh C wrote:
> > >
> > > On Tue, 25 Feb 2025 at 15:32, vignesh C wrote:
> > > >
> > > > The attached script has the script that was used for testing. Here
On Tue, Feb 4, 2025 at 2:39 PM Daniel Gustafsson wrote:
>
> > On 4 Feb 2025, at 06:50, Tom Lane wrote:
> >
> > Peter Eisentraut writes:
> >> During the developer meeting at FOSDEM last Thursday,
> >
> > BTW, are there minutes available from that meeting? In past years
> > some notes have been p
In light of bb8dff9995f (add cost delay time to progress views), looking at
the output of 30a6ed0ce4b (track per-relation time spent on vacuum and
analyze), it struck me as a bit unclear of what the time is really showing.
Do we want to do something similar for the table views? Or if not, we
shoul
Hi,
On 2025-03-04 13:27:29 +1300, Thomas Munro wrote:
> On Fri, Apr 26, 2024 at 12:02 AM Nazir Bilal Yavuz wrote:
> > On Sat, 13 Apr 2024 at 05:12, Andres Freund wrote:
> > > I propose that we instead run the task automatically if
> > > $REPO_MINGW_TRIGGER_BY_DEFAULT is set, typically in cirrus'
On Tue, Mar 4, 2025 at 4:05 PM Álvaro Herrera wrote:
>
> On 2025-Mar-04, Jelte Fennema-Nio wrote:
>
> > 1. Major change: The homepage is revamped completely! It now shows a
> > dashboard of open patches where you are author/reviewer/committer if
> > you are logged in. These patches are ordered & g
> On Mar 3, 2025, at 10:39 PM, Quan Zongliang wrote:
>
> I implemented a LISTEN command that supports matching names in the LIKE
> format.
>
> Just like
>
> LISTEN 'c%';
> NOTIFY c1;NOTIFY c2;
>
> Notifications are received for c1 and c2.
>
The parser down-cases ColId. Thus:
LISTEN MiXeD
On Tue, Mar 4, 2025 at 10:18 AM Tom Lane wrote:
> At the point where I complained to you about that other problem,
> it was looking like it might cause a quarter or a third of the
> buildfarm to fail intermittently. Maybe I overestimated the
> frequency of the failure, but if that was accurate it
On Tue, 4 Mar 2025 at 16:29, Peter Eisentraut wrote:
> Another small complaint: I don't like this style of relative times. (I
> have also complained about it for the buildfarm status in the past.) I
> suppose both styles are useful like 50% of the time, but I'll tell you
> some of my reasoning:
On 04.03.25 11:33, Jelte Fennema-Nio wrote:
I'm curious if there was anything specific that you used the old
homepage for. Especially things you did often that are now harder to
do. The only things I used on the homepage were:
1. Going to the "In Progress" and "Open" commitfest (usually with one
On 2025/02/16 16:05, Robins Tharakan wrote:
Hi,
This patch introduces a new function pg_accept_connections_start_time().
Currently, pg_postmaster_start_time() is used to determine when the
database started. However, this is not accurate since the postmaster
process can sometimes be up wherea
On Tue, Mar 04, 2025 at 01:05:17PM +0700, John Naylor wrote:
> On Mon, Mar 3, 2025 at 11:21 PM Nathan Bossart
> wrote:
>> I did that in v3. I also tried to break up this comment into bullet points
>> for better separation and logical flow.
>
> That's much easier to follow, thanks.
Thanks for l
On Thu, Feb 27, 2025 at 5:38 AM Daniel Gustafsson wrote:
> Thanks for the tests, they did in fact uncover a bug in how fallback was
> handled which is now fixed. In doing so I revamped how the default context
> handling is done, it now always use the GUCs in postgresql.conf for
> consistency. Th
Hi,
On 2024-10-14 18:08:10 -0700, Masahiko Sawada wrote:
> I fixed a compiler warning by -Wtypedef-redefinition related to the
> declaration of SnapBuild struct, then pushed both patches.
This just failed on skink (valgrind buildfarm animal):
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?n
> I tried this out, and was pleasantly surprised to see what seemed like
> useful summaries of discussions that I was directly involved in.
Thanks for trying it out! And big thanks to Jelte for helping me get
involved in the project.
> I'm not sure if I'll ever actually use this tool day to day,
=?utf-8?Q?=C3=81lvaro?= Herrera writes:
> I just discovered that trying to set a foreign key as NO INHERIT in
> ALTER TABLE ALTER CONSTRAINT returns an absurd error message:
> create table pk (a int primary key);
> create table fk (a int references pk);
> alter table fk alter constraint fk_a_fkey
Andres Freund writes:
> On 2025-03-04 16:30:34 -0500, Tom Lane wrote:
>> Yeah, I've been poking at that. It's not at all clear why the
>> animal is trying to run src/test/modules/ldap_password_func
>> now when it didn't before.
> It did do so before as well, afaict:
> https://buildfarm.postgresq
On 2025-03-04 Tu 5:01 PM, Tom Lane wrote:
Andres Freund writes:
On 2025-03-04 16:30:34 -0500, Tom Lane wrote:
Yeah, I've been poking at that. It's not at all clear why the
animal is trying to run src/test/modules/ldap_password_func
now when it didn't before.
It did do so before as well, af
On Wed, Mar 5, 2025 at 6:08 AM Jacob Champion
wrote:
> ktruss shows absolutely no syscall activity on the authorization
> server during the failing test, because Curl's talking to something
> else. sockstat confirms that I completely forgot to listen on IPv6 in
> the test server. Dual stack socket
On Tue, 4 Mar 2025 at 20:46, Daniel Gustafsson wrote:
> My preference would be not have any relative times or dates at all and just
> show the date as is.
I pushed a change that both improves the rendering of relative
datetimes and also allows people to choose to disable that and just
show the da
On Tue, Mar 4, 2025 at 2:38 PM Thomas Munro wrote:
> Heh, wow, that was confusing :-) Actually I'm still confused (why
> passing sometimes then?)
Curl doesn't mind if the IPv6 connection fails outright; it'll use the
IPv4 in that case. But if something else ephemeral pops up on IPv6 and
starts s
On Mon, Mar 3, 2025 at 9:07 AM Bertrand Drouvot
wrote:
>
> I did not imagine that much ;-) I was just seeing this code being duplicated
> and just thought about to avoid the duplication. But now that I read your
> comments
> above then I think we could just macro-ize the child_type check (as you
Andrew Dunstan writes:
>> I think I found a logic bug. Testing.
Oh! I bet you are looking at this 18-to-19 diff:
@@ -416,7 +416,8 @@ sub check_install_is_complete
{
$tmp_loc = "$tmp_loc/$install_dir";
$bindir = "$tmp_loc/bin";
- $libdir = "$
Hi,
On 2024-12-09 00:12:32 +0100, Tomas Vondra wrote:
> Hi, the TAP test 001_connection_limits.pl introduced by 6a1d0d470e84
> seems to have problems with valgrind :-( I reliably get this failure:
>
>
> t/001_connection_limits.pl .. 3/? # Tests were run but no plan was
> declared and done_testin
On 2025-03-04 Tu 5:28 PM, Tom Lane wrote:
Andrew Dunstan writes:
I think I found a logic bug. Testing.
Not sure what you are looking at, but I was trying to fix it
by making the loop over test modules skip unbuilt modules,
borrowing the test you added in v19 to skip unbuilt contrib
modules. I
Hi,
On 2024-12-10 12:00:12 +0200, Heikki Linnakangas wrote:
> On 09/12/2024 22:55, Heikki Linnakangas wrote:
> > Not sure how to fix this. A small sleep in the test would work, but in
> > principle there's no delay that's guaranteed to be enough. A more robust
> > solution would be to run a "selec
On Tue, Mar 4, 2025 at 9:26 AM Julien Rouhaud wrote:
> Yes, I do remember the 2 threads and I totally understand. On my side I know
> instructions on the buildfarm client side or something. I did check again a
> few days ago when I was that nothing was pushed anymore on that branch only,
> saw t
On Tue, Mar 4, 2025 at 4:31 PM Nisha Moond wrote:
>
> On Tue, Mar 4, 2025 at 10:30 AM Shubham Khanna
> wrote:
> >
> > Fixed the suggested changes. The attached patch contains the required
> > changes.
> >
>
> Hi Shubham,
>
> Thanks for the patch! I tested its functionality and didn't find any
>
On 3/4/25 14:11, Andres Freund wrote:
> Hi,
>
> On 2025-03-04 14:05:22 +0100, Tomas Vondra wrote:
>> On 3/3/25 21:52, Andres Freund wrote:
It's not a proper constant, of course, but it seemed close
enough. Yes, it might confuse people into thinking it's a constant, or
is there som
On Tue, Mar 04, 2025 at 03:12:18PM +0100, Magnus Hagander wrote:
> In light of bb8dff9995f (add cost delay time to progress views), looking at
> the output of 30a6ed0ce4b (track per-relation time spent on vacuum and
> analyze), it struck me as a bit unclear of what the time is really showing.
>
>
I have pushed Release 19 of the PostgreSQL Buildfarm client.
Release 19 has two main features:
* Adjustment to the way we run Cross version upgrade testing, to
accommodate the recent statistics import feature
* Adjust to the new SEpgsql test setup
Also included
* Tame proliferation of ke
Magnus noted to me off-list that the "et cetera" in the following sentence
in pg_upgrade's docs is doing quite a bit of heavy lifting:
The --jobs option allows multiple CPU cores to be used for
copying/linking of files, dumping and restoring database schemas in
parallel, et
On Tue, Mar 04, 2025 at 07:22:22PM +0100, Álvaro Herrera wrote:
> I just discovered that trying to set a foreign key as NO INHERIT in
> ALTER TABLE ALTER CONSTRAINT returns an absurd error message:
>
> create table pk (a int primary key);
> create table fk (a int references pk);
>
> alter table f
On Tue, Mar 4, 2025 at 4:40 AM Bertrand Drouvot
wrote:
>
> On Mon, Mar 03, 2025 at 06:24:59PM -0500, Melanie Plageman wrote:
> >
> > And I think it would be even simpler to do your idea of groups and to
> > have aliases for different combinations of options. And it would let
> > us keep 'on' and '
On Mon, Mar 3, 2025 at 4:07 PM Jacob Champion
wrote:
> I wonder if
> my test server doesn't handle dual-stack setups correctly.
Spoilers: it's this.
> I'll see if
> I can get ktruss working on either side.
ktruss shows absolutely no syscall activity on the authorization
server during the failin
On Tue, Mar 4, 2025 at 10:26 AM Andrei Lepikhov wrote:
> I wouldn't say there is a thread in the mailing list. I mentioned this
> direction of extensibility multiple times (for example, [1,2]) with no
> reaction. However, letting extensions show data in explan gives this
> idea additional impulse.
Hi,
On Tue, Mar 04, 2025 at 11:48:31AM +0100, Jakub Wartak wrote:
> Hi!
>
> On Thu, Feb 27, 2025 at 4:34 PM Bertrand Drouvot
> wrote:
>
> > I did some tests and it looks like it's giving correct results. I don't see
> > -2
> > anymore and every backend reports correct distribution (with or wit
Hi,
On 2025-02-12 09:49:35 -0500, Andres Freund wrote:
> I finally pushed this.
One thing I noticed is that occasionally the tests fail on openbsd after
exceeding the system wide number of files, not in postgres, but causing meson
test to fail. I could either put an increase of kern.maxfiles in
Hi Rafia,
Sorry for the late response. I have completed my tests, and parallel
workers were successfully launched on the remote server. Below are the
details of my setup and test results.
# Machine Details
CPU: 4 cores
Memory: 8GB
PostgreSQL Version: 17.2 (compiled from source)
OS: Rocky Linux 8.1
On Tue, 2025-03-04 at 10:28 +0530, Ashutosh Bapat wrote:
> >
> > What solution are you suggesting? The only one that comes to mind
> > is
> > moving everything to SECTION_POST_DATA, which is possible, but it
> > seems
> > like a big design change to satisfy a small detail.
>
> We don't have to d
The usual pattern for handling a signal is that the signal handler sets
a global variable and calls SetLatch(MyLatch) to wake up the process,
and later CHECK_FOR_INTERRUPTS() or other code that is part of a wait
loop calls another function to deal with it. The naming of the functions
involved w
On Tue, Mar 4, 2025 at 3:50 PM Robert Haas wrote:
> On Mon, Mar 3, 2025 at 8:21 PM Jelte Fennema-Nio wrote:
> > As always, please test out the current staging website[1] to give some
> > feedback.
> > HTTP auth user and password are both pgtest.
>
> So, that worked for me, but then it wants me t
On Tue, 4 Mar 2025 at 21:57, Peter Geoghegan wrote:
>
> On Tue, Mar 4, 2025 at 3:50 PM Robert Haas wrote:
> > On Mon, Mar 3, 2025 at 8:21 PM Jelte Fennema-Nio wrote:
> > > As always, please test out the current staging website[1] to give some
> > > feedback.
> > > HTTP auth user and password ar
On 3/4/25 2:30 PM, Jelte Fennema-Nio wrote:
On Tue, 4 Mar 2025 at 13:36, Amit Kapila wrote:
On Tue, Mar 4, 2025 at 4:05 PM Álvaro Herrera wrote:
I think showing different pages on the same URL depending on whether
you're logged in or not is not great UX.
+1. The default should be what we
On Tue, Mar 4, 2025 at 4:02 PM Jelte Fennema-Nio wrote:
> You have to create a *new* account to do so, because the staging auth
> and prod auth
> systems are separate. Then you can mark yourself as author/reviewer of
> a few patches to see what it would look like.
How do I do that? Or can I do it
On Tue, Mar 4, 2025 at 12:51 AM Michael Paquier wrote:
>
> On Mon, Mar 03, 2025 at 02:23:51PM +0900, Michael Paquier wrote:
> > This has always been set last and it's still the case in the patch, so
> > let's just remove that.
>
> This first one has been now applied as c76db55c9085.
Thanks!
> At
On Mon, Mar 3, 2025 at 8:21 PM Jelte Fennema-Nio wrote:
> 1. Major change: The homepage is revamped completely! It now shows a
> dashboard of open patches where you are author/reviewer/committer if
> you are logged in. These patches are ordered & grouped in a hopefully
> useful way. If you're not
On Tue, Mar 4, 2025 at 12:02 PM Jelte Fennema-Nio wrote:
>
> On Tue, 4 Mar 2025 at 17:31, Peter Geoghegan wrote:
> > > Peter Geoghegan suggested adding a "dashboard" of this
> > > kind. Feedback on this is very welcome, but depending on the
> > > complexity I don't know when I'll get to it. I'll
On Tue, Mar 04, 2025 at 12:09:09PM +0700, John Naylor wrote:
> On Tue, Mar 4, 2025 at 2:11 AM Nathan Bossart
> wrote:
>> This could potentially lead to a small regression for machines with SSE
>> 4.2 but not PCLMUL, but that may be uncommon enough at this point to not
>> worry aobut.
>
> Note al
On Tue, Mar 4, 2025 at 1:32 PM Daniel Verite wrote:
> But if the code triggered the use of the extended query protocol
> if \bind is in effect *or* a pipeline is active, then the first sequence
> would just push "select 1" into the pipeline.
>
> This would have the advantage that, to submit into
On 3/4/25 15:38, Tomas Vondra wrote:
>
> ...
>
>>>
>>> Attached is a patch doing this, but considering it has nothing to do
>>> with the shmem sizing, I wonder if it's worth it.
>>
>> Yes.
>>
>
> OK, barring objections I'll push the v2.
>
Pushed, with the tweaks to use FastPathLockSlotsPerBacke
I pushed the two smaller parts today.
Here's the remaining two parts, to keep cfbot happy. I don't expect to
get these into PG18, though.
regards
--
Tomas Vondra
From bea52f76255830af45b7122b0fa5786997182cf5 Mon Sep 17 00:00:00 2001
From: Tomas Vondra
Date: Tue, 25 Feb 2025 16:12:37 +0100
Sub
> On 4 Mar 2025, at 17:13, Jelte Fennema-Nio wrote:
> On Tue, 4 Mar 2025 at 16:29, Peter Eisentraut wrote:
>> Another small complaint: I don't like this style of relative times. (I
>> have also complained about it for the buildfarm status in the past.) I
>> suppose both styles are useful like
On Wed, Feb 5, 2025, at 3:51 PM, Álvaro Herrera wrote:
> On 2024-Dec-17, Euler Taveira wrote:
>
> > Sometimes you need to inspect some debug messages from autovacuum worker but
> > you cannot apply the same setting for backends (that could rapidly fill the
> > log
> > file). This proposal aims to
Hi,
On 2025-03-04 09:48:45 +1300, Thomas Munro wrote:
> On Tue, Mar 4, 2025 at 5:48 AM Andres Freund wrote:
> > On 2025-02-24 11:26:56 +0100, Jelte Fennema-Nio wrote:
> > > [1]: https://cirrus-ci.com/task/5571017969500160?logs=test_world#L256
> >
> > A possibly related test failure is:
> >
> > ht
On 2025/03/05 7:26, Jacob Champion wrote:
On Mon, Mar 3, 2025 at 10:02 PM Fujii Masao wrote:
I've pushed the patch. Thanks!
Hi all,
+tests += {
+ 'name': 'ecpg',
+ 'sd': meson.current_source_dir(),
+ 'bd': meson.current_build_dir(),
+ 'tap': {
+'tests': [
+ 't/001_ecpg_err_wa
On Mon, Mar 3, 2025 at 3:24 PM Masahiko Sawada wrote:
>
>
> Another performance regression I can see in the results is that heap
> vacuum phase (phase III) got slower with the patch. It's weired to me
> since I don't touch the code of heap vacuum phase. I'm still
> investigating the cause.
I have
On Sat, Mar 1, 2025, at 10:08 AM, Amit Kapila wrote:
> On Thu, Feb 13, 2025 at 6:48 AM Masahiko Sawada wrote:
> >
> > Thank you for updating the patch! The patch looks mostly good to me.
> >
>
> + /*
> + * Prior to PostgreSQL 18, max_replication_slots was used to set the
> + * number of replicati
On Tue, Mar 4, 2025 at 4:26 PM Jacob Champion
wrote:
> But attaching to that injection point succeeded above, for us to have
> gotten to this point... Does that error message indicate that the
> point itself doesn't exist, or that nothing is currently waiting?
Looks like the latter. With the foll
On Tue, Mar 4, 2025 at 1:56 PM Andres Freund wrote:
>
> Hi,
>
> On 2024-10-14 18:08:10 -0700, Masahiko Sawada wrote:
> > I fixed a compiler warning by -Wtypedef-redefinition related to the
> > declaration of SnapBuild struct, then pushed both patches.
>
> This just failed on skink (valgrind buildf
On Tue, Mar 4, 2025 at 10:42 PM Amit Kapila wrote:
>
> On Wed, Mar 5, 2025 at 6:24 AM Euler Taveira wrote:
> >
> > On Sat, Mar 1, 2025, at 10:08 AM, Amit Kapila wrote:
> >
> > On Thu, Feb 13, 2025 at 6:48 AM Masahiko Sawada
> > wrote:
> > >
> > > Thank you for updating the patch! The patch look
Hi,
On Wed, Mar 05, 2025 at 11:05:48AM +0900, Michael Paquier wrote:
> Hi all,
>
> While working on I/O statistics, I have noticed that it is not
> complicated to break the set of rows returned by pg_stat_io if one is
> not careful when updating pgstat_tracks_io_object().
>
> Attached is a patch
Andrew Dunstan writes:
> Will check your patch out too.
Comparing previous run against current, I now see that my patch
caused it to skip these steps:
module-ldap_password_func-check
module-pg_bsd_indent-check
contrib-sepgsql-check
Skipping the ldap and sepgsql tests is desirable, but it sho
> On 4 Mar 2025, at 23:49, Jelte Fennema-Nio wrote:
>
> On Tue, 4 Mar 2025 at 20:46, Daniel Gustafsson wrote:
>> My preference would be not have any relative times or dates at all and just
>> show the date as is.
>
> I pushed a change that both improves the rendering of relative
> datetimes and
On Tue, Mar 04, 2025 at 10:31:46AM +0100, Anthonin Bonnefoy wrote:
> Saving the printQueryOpt when a command is pushed was an option I had
> in mind if that was straightforward to implement. However, even with
> savePsetInfo, you will need to save values like gfname and gset_prefix
> since it impac
On Tue, 4 Mar 2025 at 22:01, Andreas Karlsson wrote:
> What I need to see is the below (plus any future commit fests).
Thanks you for describing how you use the current homepage. That's
super helpful.
> I am interested in the dates when commit fests open and close
These are the same exact 5 mon
On Tue, Mar 04, 2025 at 05:58:42PM -0500, Andres Freund wrote:
> On 2024-12-10 12:00:12 +0200, Heikki Linnakangas wrote:
>> 2. Move the pgstat_bestart() call earlier in the startup sequence, so that a
>> backend shows up in pg_stat_activity before it acquires a PGPROC entry, and
>> stays visible un
Attached v9 implements log_connections as an enum with a new third
value "timings".
On Mon, Mar 3, 2025 at 11:14 AM Bertrand Drouvot
wrote:
>
>
> On Fri, Feb 28, 2025 at 05:52:35PM -0500, Melanie Plageman wrote:
>
> > We have to be really careful about when log_connections is actually
> > set bef
On 2025-03-04 Tu 5:28 PM, Tom Lane wrote:
Andrew Dunstan writes:
I think I found a logic bug. Testing.
Not sure what you are looking at, but I was trying to fix it
by making the loop over test modules skip unbuilt modules,
borrowing the test you added in v19 to skip unbuilt contrib
modules.
On Tue, Mar 04, 2025 at 06:37:09PM +0100, Anthonin Bonnefoy wrote:
> I do see the idea to make it easier to convert existing scripts into
> using pipelining. The main focus of the initial implementation was
> more on protocol regression tests with psql, so that's not necessarily
> something I had i
Andrew Dunstan writes:
> I'm looking at something else, namely the attached.
Yeah, that avoids the extra installs and brings sifaka's
runtime back to about what it had been.
regards, tom lane
Thanks so much for your review!
On Mon, Mar 3, 2025 at 12:08 PM Fujii Masao wrote:
>
>
> > +bool
> > +check_log_connections(char **newval, void **extra, GucSource source)
> > +{
> >
> > This function is pretty close to check_debug_io_direct() for example and its
> > overall content, memory manage
On Mon, Mar 3, 2025 at 11:45 PM Fujii Masao wrote:
>
> When log_connection is empty string in postgresql.conf and I ran
> "psql -d "options=-clog_connections=all"", I got the following log message.
> You can see the total duration in this message is unexpected.
> It looks like this happens because
On Tue, Mar 4, 2025 at 3:25 PM Melanie Plageman
wrote:
>
> I don't
> see any other TAP tests that are testing connections. There are a
> whole bunch of auth tests, I suppose.
I was going to suggest src/test/authentication, yeah. Not perfect, but
better than nothing?
--Jacob
Hi everyone,
I just tried to clone from git.postgresql.org and it stalled at 99% of
receiving objects, but I could clone from github without any problems.
Is it only me?
--
Jaime Casanova
Director de Servicios Profesionales
SystemGuards - Consultores de PostgreSQL
On Tue, Mar 4, 2025 at 9:22 PM Alex Friedman wrote:
>
> >I decided to leave this out, since I just remembered that the most
> > likely change is actually to move to 64-bit offsets, as was proposed
> > here and has some enthusiastic support:
> >
> > https://www.postgresql.org/message-id/CACG=ezawg7
1 - 100 of 185 matches
Mail list logo
