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
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 Tue, Mar 04, 2025 at 10:25:57PM -0800, Masahiko Sawada wrote:
> On Tue, Mar 4, 2025 at 1:56 PM Andres Freund wrote:
> >
> Thank you for the report.
+1
> It seems that bgwriter wrote another RUNNING_XACTS record during the
> test, making the logical decoding write an extra snapshot on the
On 5/3/2025 03:27, Alexander Korotkov wrote:
On Mon, Mar 3, 2025 at 1:04 PM Andrei Lepikhov wrote:
2. As usage of root->tuple_fraction RelOptInfo it has been criticized,
do you think we could limit this to some simple cases? For instance,
check that RelOptInfo is the final result relation for
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 looks mostly good to me.
> >
>
> + /*
> + * Prior to PostgreSQL 18, max_repli
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 4:44 PM Jakub Wartak
wrote:
>
> On Tue, Mar 4, 2025 at 4:59 AM Amit Kapila wrote:
>
> > > >
> > > > Sure thing. I've just added '(..) In the extreme cases this can..' as
> > > > it is pretty rare to hit it. Patch attached.
> > >
> > > When the clock moves forward or backwar
On 2/23/2025 8:03 PM, Yura Sokolov wrote:
14.02.2025 11:41, Zhou, Zhiguo пишет:
On 2/11/2025 9:25 AM, Japin Li wrote:
On Mon, 10 Feb 2025 at 22:12, "Zhou, Zhiguo" wrote:
On 2/5/2025 4:32 PM, Japin Li wrote:
On Mon, 27 Jan 2025 at 17:30, "Zhou, Zhiguo" wrote:
On 1/26/2025 10:59 PM, Yura
On Tue, Mar 4, 2025 at 4:10 PM Andres Freund wrote:
> This seems to trigger a bunch of CI failures, e.g.:
>
> https://cirrus-ci.com/task/5350341408980992
> https://cirrus-ci.com/task/5537391798124544
> https://cirrus-ci.com/task/4657439905153024
Hm. All Windows.
> https://api.cirrus-ci.com/v1/ar
Good points, thank you. I'm good with going ahead as you've suggested.
Best regards,
Alex Friedman
On Tue, Mar 4, 2025 at 12:23 PM vignesh C wrote:
>
> There is almost negligible dip with the above suggested way, the test
> results for the same is given below(execution time is in milli
> seconds):
> Brach/records | 100 | 1000 | 1| 10 | 100
> Head | 10
On Tue, Mar 04, 2025 at 04:53:14PM -0800, Jacob Champion wrote:
> I'll work on a fix, but it probably won't be fast since I need to
> learn more about the injection points architecture. The test may need
> to be disabled, or the patch backed out, depending on how painful the
> flake is for everybod
On Tuesday, March 4, 2025 7:44 PM Kuroda, Hayato/黒田 隼人
wrote:
Hi,
>
> > > 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 P
Hi all,
While doing some monitoring of a replication setup for a stable
branch, I have been surprised by the fact that we have never tracked
WAL statistics for the WAL receiver in pg_stat_wal because we have
never bothered to update its code so as WAL stats are reported. This
is relevant for the
jian he writes:
> Thanks to commit aaaf9449ec6be62cb0d30ed3588dc384f56274bf[1],
> ExprState.escontext (ErrorSaveContext) was added, and
> ExecEvalConstraintNotNull,
> ExecEvalConstraintCheck were changed to use errsave instead of hard error.
> Now we can use it to evaluate CoerceToDomain in a sof
On Mon, Mar 3, 2025 at 10:24 AM Andrei Lepikhov wrote:
> On 17/2/2025 01:34, Alexander Korotkov wrote:
> > Hi, Andrei!
> >
> > On Tue, Oct 8, 2024 at 8:00 AM Andrei Lepikhov wrote:
> > Thank you for your work on this subject. I agree with the general
> > direction. While everyone has used conse
hi.
Thanks to commit aaaf9449ec6be62cb0d30ed3588dc384f56274bf[1],
ExprState.escontext (ErrorSaveContext) was added, and ExecEvalConstraintNotNull,
ExecEvalConstraintCheck were changed to use errsave instead of hard error.
Now we can use it to evaluate CoerceToDomain in a soft error way, that
is wh
On 3/4/25 10:24 AM, Andreas Karlsson wrote:
Rebased the patch to add support for OLD.* and NEW.*.
Apparently the CI did not like that version.
Andreas
From 795c78c79bc7b2dbddfa828e4c01c5641d0be272 Mon Sep 17 00:00:00 2001
From: Andreas Karlsson
Date: Mon, 18 Nov 2024 00:29:15 +0100
Subject: [
On Mon, Mar 3, 2025 at 1:04 PM Andrei Lepikhov wrote:
>
> On 2/3/2025 09:53, Alexander Korotkov wrote:
> > Hi, Andrei!
> >
> > On Fri, Dec 6, 2024 at 10:13 AM Andrei Lepikhov wrote:
> >>
> >> On 12/6/24 13:48, Andrei Lepikhov wrote:
> >>> On 11/2/24 01:18, Nikita Malakhov wrote:
> I've corre
On Wed, Mar 5, 2025 at 11:02 AM Richard Guo wrote:
> create table t (a int);
> insert into t values (1);
>
> # select a, b
> from (select a, a as b from t) ss
> group by grouping sets(a, b)
> having b = 1;
> a | b
> ---+---
> 1 |
> (1 row)
>
> Note that the having clause filters out the wr
While working on the expansion of virtual generated columns, Dean
encountered $subject in [1], which can be reproduced using the query
below.
create table t (a int);
insert into t values (1);
# select a, b
from (select a, a as b from t) ss
group by grouping sets(a, b)
having b = 1;
a | b
-
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 that I've found useful as a sanity check,
returning all the combinations supported
On Wed, Mar 5, 2025 at 12:36 AM Nathan Bossart wrote:
>
> 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 b
Jaime Casanova writes:
> 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?
I've had trouble in the past with cloning on old/slow machines --- it
seems to time out after awhile. But AFA
On Fri, 2025-02-28 at 17:09 +1300, David Rowley wrote:
> * my_log2() takes a "long" parameter type but transitionSpace is a
> "Size". These types aren't the same width on all platforms we
> support.
> Maybe pg_nextpower2_size_t() is a better option.
Done.
> * Should the following have MAXALIGN(tu
On Tue, Mar 04, 2025 at 08:48:28AM +, Bertrand Drouvot wrote:
> s/report/Report/ and s/system/system./? to be consistent with the other single
> line comments around.
Right.
> Yeah, I also think that's the right location.
We could be more optimal for the WAL receiver if we add more timestamp
On Wed, 5 Mar 2025 at 01:02, Álvaro Herrera wrote:
>
> A database name containing a newline breaks things for this patch:
>
> CREATE DATABASE "foo
> bar";
>
>
> $ pg_dumpall -Fc --file test
> shell command argument contains a newline or carriage return: "
dbname='foo
> bar'"
>
> --
> Álvaro Herrer
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 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 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
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 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
On 3/5/25 12:14 AM, Jelte Fennema-Nio wrote:
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
Andrew Dunstan writes:
> On 2025-03-04 Tu 5:28 PM, Tom Lane wrote:
>> ... I eventually concluded that there's
>> something wrong with the "scalar glob()" idiom you used.
> Well, in scalar context it should give us back the first item found, or
> undef if nothing is found, AIUI.
That's what I wo
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Mon, 3 Mar 2025 11:06:39 -0800,
Masahiko Sawada wrote:
> I agree with the fix and the patch looks good to me. I've updated the
> commit message and am going to push, barring any objections.
Thanks!
I've r
On 2025-03-04 Tu 6:04 PM, Tom Lane wrote:
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 an
> On 4 Mar 2025, at 20:19, Daniel Gustafsson wrote:
>> On 4 Mar 2025, at 20:13, Jacob Champion
>> wrote:
>> Just a reminder that, if we do want to change this for 18 onward, the
>> window is closing. Adding x25519 to the default groups seems like a
>> good idea to me, whether we can get somethi
Hi,
On 2025-03-04 17:51:17 +0900, 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. Attached is t
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
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 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
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
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
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
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
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
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 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 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
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
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 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-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
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 = "$
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 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
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 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
> It'd be nice if the UI had usable hyperlinks that could be bookmarked
> by my browser. One hyperlink for each of the views.
Sounds reasonable!
> Probably "Recommended patches for you to check". Things that are on
> the periphery of my interests have the greatest chance of being picked
> up, I th
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. It's a little more complicated for the other
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_warn_msg.pl',
> + 't/002_ecpg_
Hi,
I just saw a BF failure on skink (valgrind) that asserts out.
Check the 002_compare_backups failure in:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2025-03-04%2017%3A35%3A01
TRAP: failed Assert("TransactionIdPrecedesOrEquals(TransactionXmin,
RecentXmin)"), File: "../pgs
On Tue, Mar 4, 2025 at 4:38 PM Jacob Brazeal wrote:
> Out of curiosity, what features would make it most useful to you? Right now
> it's trying to do all of the following:
> * Summarize threads
> * Help you find threads about things you're interested in, independent of
> what you've commented on
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
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
=?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
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
Hi,
On 2025-03-04 16:30:34 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2025-03-04 19:58:38 +0100, Tomas Vondra wrote:
> >> I noticed sifaka started failing right after I pushed this:
>
> > It's worth noting that
> > a) sifaka doesn't build with ldap support
> > b) the failure is in che
+1 to the general idea, I didn't look at the patches yet.
On Fri, 2025-02-28 at 15:32 -0500, Robert Haas wrote:
> 1. It is much more verbose. I theorize that people will be unhappy
> about having to type EXPLAIN (pg_overexplain.range_table) rather than
> just EXPLAIN (range_table).
That was my fi
> 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,
Andres Freund writes:
> On 2025-03-04 19:58:38 +0100, Tomas Vondra wrote:
>> I noticed sifaka started failing right after I pushed this:
> It's worth noting that
> a) sifaka doesn't build with ldap support
> b) the failure is in checkprep, not when running the tests
> c) the buildfarm unfortunate
On Tue, 4 Mar 2025 at 22:04, Peter Geoghegan wrote:
>
> 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
On Tue, Mar 4, 2025 at 1:53 PM Jeff Davis wrote:
> I don't expect there to be zillions of extensions that only add new and
> exciting explain options. Instead, it seems more likely that all
> TableAM and CustomScan extensions will have 1-3 new explain options,
> and that some of those might collid
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, 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 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 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 to log into my
postgreql.org account, and that doesn't seem to
On Tue, 4 Mar 2025 at 17:15, Peter Eisentraut wrote:
> I think the option of having a list of things that I'm involved in as an
> author *or* reviewer is actually very useful and something I have wanted
> from time to time. But that is apparently not accessible using the
> normal search/filter me
On 2025-03-04 Tu 10:34 AM, Mark Dilger wrote:
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
On Tue, 4 Mar 2025 at 11:35, Álvaro Herrera wrote:
> https://commitfest.postgresql.org/me
I've restored the original homepage and moved this new dashboard
(minus the "Archive" link) to /me:
https://commitfest-test.postgresql.org/me/
On Tue, Mar 4, 2025 at 3:06 PM Jelte Fennema-Nio wrote:
> So patches with failing CI in the "in progress cf" will sort below
> healthy patches in the "open cf". I don't think you necessarily said
> that, but this seemed nice to me. And it's easy to spot which patches
> are for which CF because of
> 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
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 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
On Tue, 4 Mar 2025 at 18:25, Peter Geoghegan wrote:
> From the looks of the screen shot that you posted (can't seem to find
> the same dashboard view on https://commitfest-test.postgresql.org?),
The dashboard is only available if you login. You probably have to
create an account to do so, because
On Tue, Mar 04, 2025 at 08:22:02PM +0200, Heikki Linnakangas wrote:
> To make things less confusing, the attached patch renames all the functions
> that are part of the overall signal/interrupt handling system but are *not*
> executed in a signal handler to e.g. ProcessSomething(), rather than
> Ha
On Wed, Feb 19, 2025 at 03:53:48PM +0530, Ayush Vatsa wrote:
> It seems there's a general consensus that we should maintain a
> original design to support pg_prewarm, with a minor adjustment:
> when querying indexes, we should verify the privileges of the parent table.
>
> I´ve attached a patch fo
On Thu, 2024-10-10 at 02:59 +1300, David Rowley wrote:
> > A few weeks ago David and I discussed this patch. We were curious
> > *why* the
> > flags approach was slower.
...
> > Could it make sense to use bitfields instead of flag values, to
> > reduce the
> > impact?
>
> Yeah. That's a good ide
On 04/03/2025 21:38, Nathan Bossart wrote:
On Tue, Mar 04, 2025 at 08:22:02PM +0200, Heikki Linnakangas wrote:
To make things less confusing, the attached patch renames all the functions
that are part of the overall signal/interrupt handling system but are *not*
executed in a signal handler to e
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 deferrable, alter constraint
fk_a_fkey no inheri
A database name containing a newline breaks things for this patch:
CREATE DATABASE "foo
bar";
$ pg_dumpall -Fc --file test
shell command argument contains a newline or carriage return: " dbname='foo
bar'"
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
On Mon, Jul 29, 2024 at 3:26 PM Daniel Gustafsson wrote:
> > On 17 Jun 2024, at 19:56, Andres Freund wrote:
> > On 2024-06-17 19:51:45 +0200, Daniel Gustafsson wrote:
>
> >> Changing the default of the ecdh GUC would perhaps be doable?
> >
> > I was wondering whether we could change the default s
> On 4 Mar 2025, at 20:13, Jacob Champion
> wrote:
>
> On Mon, Jul 29, 2024 at 3:26 PM Daniel Gustafsson wrote:
>>> On 17 Jun 2024, at 19:56, Andres Freund wrote:
>>> On 2024-06-17 19:51:45 +0200, Daniel Gustafsson wrote:
>>
Changing the default of the ecdh GUC would perhaps be doable?
>
On 2025-Mar-04, Nathan Bossart wrote:
> 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:
> > Here's the fix along with some additional cleanup.
Hi,
On 2025-03-04 19:58:38 +0100, Tomas Vondra wrote:
> Pushed, with the tweaks to use FastPathLockSlotsPerBackend() in a couple
> more places.
Thanks!
> I noticed sifaka started failing right after I pushed this:
>
> https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=sifaka&br=master
1 - 100 of 185 matches
Mail list logo
