public inbox for [email protected]
help / color / mirror / Atom feed[PATCH 1/2] Fix not-null constraint representation in \d+
35+ messages / 13 participants
[nested] [flat]
* [PATCH 1/2] Fix not-null constraint representation in \d+
@ 2023-08-28 05:38 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 35+ messages in thread
From: Kyotaro Horiguchi @ 2023-08-28 05:38 UTC (permalink / raw)
The recent commit b0e96f3119 added the description about not-null
constraints in the output of \d+ command. It hided constraints' origin
when it is marked as NO INHERIT. Show their origin irrespective of
the NO INHERIT state.
---
src/bin/psql/describe.c | 22 +++++++---
src/test/regress/expected/constraints.out | 12 ++---
src/test/regress/expected/create_table.out | 6 +--
.../regress/expected/create_table_like.out | 6 +--
src/test/regress/expected/foreign_data.out | 44 +++++++++----------
src/test/regress/expected/generated.out | 2 +-
src/test/regress/expected/inherit.out | 30 ++++++-------
7 files changed, 66 insertions(+), 56 deletions(-)
diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c
index bac94a338c..3bf1c0cb97 100644
--- a/src/bin/psql/describe.c
+++ b/src/bin/psql/describe.c
@@ -3079,16 +3079,26 @@ describeOneTableDetails(const char *schemaname,
/* Might be an empty set - that's ok */
for (i = 0; i < tuples; i++)
{
+ bool noinherit = PQgetvalue(result, i, 2)[0] == 't';
bool islocal = PQgetvalue(result, i, 3)[0] == 't';
bool inherited = PQgetvalue(result, i, 4)[0] == 't';
- printfPQExpBuffer(&buf, " \"%s\" NOT NULL \"%s\"%s",
+ printfPQExpBuffer(&buf, " \"%s\" NOT NULL \"%s\"",
PQgetvalue(result, i, 0),
- PQgetvalue(result, i, 1),
- PQgetvalue(result, i, 2)[0] == 't' ?
- " NO INHERIT" :
- islocal && inherited ? _(" (local, inherited)") :
- inherited ? _(" (inherited)") : "");
+ PQgetvalue(result, i, 1));
+ if (inherited || noinherit)
+ {
+ appendPQExpBufferChar(&buf, ':');
+
+ if (inherited)
+ {
+ if (islocal)
+ appendPQExpBufferStr(&buf, _(" local"));
+ appendPQExpBufferStr(&buf, _(" inherited"));
+ }
+ if (noinherit)
+ appendPQExpBufferStr(&buf, _(" uninheritable"));
+ }
printTableAddFooter(&cont, buf.data);
}
diff --git a/src/test/regress/expected/constraints.out b/src/test/regress/expected/constraints.out
index b7de50ad6a..d4adbaa518 100644
--- a/src/test/regress/expected/constraints.out
+++ b/src/test/regress/expected/constraints.out
@@ -914,7 +914,7 @@ ALTER TABLE cnn_parent ADD PRIMARY KEY (b);
a | integer | | | | plain | |
b | integer | | not null | | plain | |
Not-null constraints:
- "cnn_grandchild_b_not_null" NOT NULL "b" (local, inherited)
+ "cnn_grandchild_b_not_null" NOT NULL "b": local inherited
Inherits: cnn_child
Child tables: cnn_grandchild2
@@ -925,7 +925,7 @@ Child tables: cnn_grandchild2
a | integer | | | | plain | |
b | integer | | not null | | plain | |
Not-null constraints:
- "cnn_grandchild_b_not_null" NOT NULL "b" (inherited)
+ "cnn_grandchild_b_not_null" NOT NULL "b": inherited
Inherits: cnn_grandchild,
cnn_child2
@@ -951,7 +951,7 @@ ERROR: multiple primary keys for table "cnn_parent" are not allowed
a | integer | | | | plain | |
b | integer | | not null | | plain | |
Not-null constraints:
- "cnn_grandchild_b_not_null" NOT NULL "b" (local, inherited)
+ "cnn_grandchild_b_not_null" NOT NULL "b": local inherited
Inherits: cnn_child
Child tables: cnn_grandchild2
@@ -962,7 +962,7 @@ Child tables: cnn_grandchild2
a | integer | | | | plain | |
b | integer | | not null | | plain | |
Not-null constraints:
- "cnn_grandchild_b_not_null" NOT NULL "b" (inherited)
+ "cnn_grandchild_b_not_null" NOT NULL "b": inherited
Inherits: cnn_grandchild,
cnn_child2
@@ -988,7 +988,7 @@ ALTER TABLE cnn_parent ADD PRIMARY KEY USING INDEX b_uq;
a | integer | | | | plain | |
b | integer | | not null | | plain | |
Not-null constraints:
- "cnn_grandchild_b_not_null" NOT NULL "b" (local, inherited)
+ "cnn_grandchild_b_not_null" NOT NULL "b": local inherited
Inherits: cnn_child
Child tables: cnn_grandchild2
@@ -999,7 +999,7 @@ Child tables: cnn_grandchild2
a | integer | | | | plain | |
b | integer | | not null | | plain | |
Not-null constraints:
- "cnn_grandchild_b_not_null" NOT NULL "b" (inherited)
+ "cnn_grandchild_b_not_null" NOT NULL "b": inherited
Inherits: cnn_grandchild,
cnn_child2
diff --git a/src/test/regress/expected/create_table.out b/src/test/regress/expected/create_table.out
index 344d05233a..293e4292e9 100644
--- a/src/test/regress/expected/create_table.out
+++ b/src/test/regress/expected/create_table.out
@@ -855,7 +855,7 @@ drop table test_part_coll_posix;
Partition of: parted FOR VALUES IN ('b')
Partition constraint: ((a IS NOT NULL) AND (a = 'b'::text))
Not-null constraints:
- "part_b_b_not_null" NOT NULL "b" (local, inherited)
+ "part_b_b_not_null" NOT NULL "b": local inherited
-- Both partition bound and partition key in describe output
\d+ part_c
@@ -868,7 +868,7 @@ Partition of: parted FOR VALUES IN ('c')
Partition constraint: ((a IS NOT NULL) AND (a = 'c'::text))
Partition key: RANGE (b)
Not-null constraints:
- "part_c_b_not_null" NOT NULL "b" (local, inherited)
+ "part_c_b_not_null" NOT NULL "b": local inherited
Partitions: part_c_1_10 FOR VALUES FROM (1) TO (10)
-- a level-2 partition's constraint will include the parent's expressions
@@ -881,7 +881,7 @@ Partitions: part_c_1_10 FOR VALUES FROM (1) TO (10)
Partition of: part_c FOR VALUES FROM (1) TO (10)
Partition constraint: ((a IS NOT NULL) AND (a = 'c'::text) AND (b IS NOT NULL) AND (b >= 1) AND (b < 10))
Not-null constraints:
- "part_c_b_not_null" NOT NULL "b" (inherited)
+ "part_c_b_not_null" NOT NULL "b": inherited
-- Show partition count in the parent's describe output
-- Tempted to include \d+ output listing partitions with bound info but
diff --git a/src/test/regress/expected/create_table_like.out b/src/test/regress/expected/create_table_like.out
index 61956773ff..6604d0c7fa 100644
--- a/src/test/regress/expected/create_table_like.out
+++ b/src/test/regress/expected/create_table_like.out
@@ -360,7 +360,7 @@ NOTICE: merging constraint "ctlt1_a_check" with inherited definition
Check constraints:
"ctlt1_a_check" CHECK (length(a) > 2)
Not-null constraints:
- "ctlt1_inh_a_not_null" NOT NULL "a" (local, inherited)
+ "ctlt1_inh_a_not_null" NOT NULL "a": local inherited
Inherits: ctlt1
SELECT description FROM pg_description, pg_constraint c WHERE classoid = 'pg_constraint'::regclass AND objoid = c.oid AND c.conrelid = 'ctlt1_inh'::regclass;
@@ -383,7 +383,7 @@ Check constraints:
"ctlt3_a_check" CHECK (length(a) < 5)
"ctlt3_c_check" CHECK (length(c) < 7)
Not-null constraints:
- "ctlt13_inh_a_not_null" NOT NULL "a" (inherited)
+ "ctlt13_inh_a_not_null" NOT NULL "a": inherited
Inherits: ctlt1,
ctlt3
@@ -403,7 +403,7 @@ Check constraints:
"ctlt3_a_check" CHECK (length(a) < 5)
"ctlt3_c_check" CHECK (length(c) < 7)
Not-null constraints:
- "ctlt13_like_a_not_null" NOT NULL "a" (inherited)
+ "ctlt13_like_a_not_null" NOT NULL "a": inherited
Inherits: ctlt1
SELECT description FROM pg_description, pg_constraint c WHERE classoid = 'pg_constraint'::regclass AND objoid = c.oid AND c.conrelid = 'ctlt13_like'::regclass;
diff --git a/src/test/regress/expected/foreign_data.out b/src/test/regress/expected/foreign_data.out
index 1dfe23cc1e..17cdd7e5b3 100644
--- a/src/test/regress/expected/foreign_data.out
+++ b/src/test/regress/expected/foreign_data.out
@@ -1421,7 +1421,7 @@ Child tables: ft2, FOREIGN
c2 | text | | | | | extended | |
c3 | date | | | | | plain | |
Not-null constraints:
- "fd_pt1_c1_not_null" NOT NULL "c1" (inherited)
+ "fd_pt1_c1_not_null" NOT NULL "c1": inherited
Server: s0
FDW options: (delimiter ',', quote '"', "be quoted" 'value')
Inherits: fd_pt1
@@ -1474,7 +1474,7 @@ Child tables: ft2, FOREIGN
c2 | text | | | | | extended | |
c3 | date | | | | | plain | |
Not-null constraints:
- "ft2_c1_not_null" NOT NULL "c1" (local, inherited)
+ "ft2_c1_not_null" NOT NULL "c1": local inherited
Server: s0
FDW options: (delimiter ',', quote '"', "be quoted" 'value')
Inherits: fd_pt1
@@ -1497,7 +1497,7 @@ NOTICE: merging column "c3" with inherited definition
c2 | text | | | | | extended | |
c3 | date | | | | | plain | |
Not-null constraints:
- "ft2_c1_not_null" NOT NULL "c1" (local, inherited)
+ "ft2_c1_not_null" NOT NULL "c1": local inherited
Server: s0
FDW options: (delimiter ',', quote '"', "be quoted" 'value')
Inherits: fd_pt1
@@ -1512,7 +1512,7 @@ Child tables: ct3,
c2 | text | | | | extended | |
c3 | date | | | | plain | |
Not-null constraints:
- "ft2_c1_not_null" NOT NULL "c1" (inherited)
+ "ft2_c1_not_null" NOT NULL "c1": inherited
Inherits: ft2
\d+ ft3
@@ -1523,7 +1523,7 @@ Inherits: ft2
c2 | text | | | | | extended | |
c3 | date | | | | | plain | |
Not-null constraints:
- "ft3_c1_not_null" NOT NULL "c1" (local, inherited)
+ "ft3_c1_not_null" NOT NULL "c1": local inherited
Server: s0
Inherits: ft2
@@ -1563,8 +1563,8 @@ Child tables: ft2, FOREIGN
c7 | integer | | not null | | | plain | |
c8 | integer | | | | | plain | |
Not-null constraints:
- "ft2_c1_not_null" NOT NULL "c1" (local, inherited)
- "fd_pt1_c7_not_null" NOT NULL "c7" (inherited)
+ "ft2_c1_not_null" NOT NULL "c1": local inherited
+ "fd_pt1_c7_not_null" NOT NULL "c7": inherited
Server: s0
FDW options: (delimiter ',', quote '"', "be quoted" 'value')
Inherits: fd_pt1
@@ -1584,8 +1584,8 @@ Child tables: ct3,
c7 | integer | | not null | | plain | |
c8 | integer | | | | plain | |
Not-null constraints:
- "ft2_c1_not_null" NOT NULL "c1" (inherited)
- "fd_pt1_c7_not_null" NOT NULL "c7" (inherited)
+ "ft2_c1_not_null" NOT NULL "c1": inherited
+ "fd_pt1_c7_not_null" NOT NULL "c7": inherited
Inherits: ft2
\d+ ft3
@@ -1601,8 +1601,8 @@ Inherits: ft2
c7 | integer | | not null | | | plain | |
c8 | integer | | | | | plain | |
Not-null constraints:
- "ft3_c1_not_null" NOT NULL "c1" (local, inherited)
- "fd_pt1_c7_not_null" NOT NULL "c7" (inherited)
+ "ft3_c1_not_null" NOT NULL "c1": local inherited
+ "fd_pt1_c7_not_null" NOT NULL "c7": inherited
Server: s0
Inherits: ft2
@@ -1649,8 +1649,8 @@ Child tables: ft2, FOREIGN
c7 | integer | | | | | plain | |
c8 | text | | | | | external | |
Not-null constraints:
- "ft2_c1_not_null" NOT NULL "c1" (local, inherited)
- "fd_pt1_c6_not_null" NOT NULL "c6" (inherited)
+ "ft2_c1_not_null" NOT NULL "c1": local inherited
+ "fd_pt1_c6_not_null" NOT NULL "c6": inherited
Server: s0
FDW options: (delimiter ',', quote '"', "be quoted" 'value')
Inherits: fd_pt1
@@ -1682,7 +1682,7 @@ Child tables: ft2, FOREIGN
c2 | text | | | | | extended | |
c3 | date | | | | | plain | |
Not-null constraints:
- "ft2_c1_not_null" NOT NULL "c1" (local, inherited)
+ "ft2_c1_not_null" NOT NULL "c1": local inherited
Server: s0
FDW options: (delimiter ',', quote '"', "be quoted" 'value')
Inherits: fd_pt1
@@ -1729,7 +1729,7 @@ Child tables: ft2, FOREIGN
Check constraints:
"fd_pt1chk2" CHECK (c2 <> ''::text)
Not-null constraints:
- "ft2_c1_not_null" NOT NULL "c1" (local, inherited)
+ "ft2_c1_not_null" NOT NULL "c1": local inherited
Server: s0
FDW options: (delimiter ',', quote '"', "be quoted" 'value')
Inherits: fd_pt1
@@ -1780,7 +1780,7 @@ Child tables: ft2, FOREIGN
Check constraints:
"fd_pt1chk2" CHECK (c2 <> ''::text)
Not-null constraints:
- "ft2_c1_not_null" NOT NULL "c1" (local, inherited)
+ "ft2_c1_not_null" NOT NULL "c1": local inherited
Server: s0
FDW options: (delimiter ',', quote '"', "be quoted" 'value')
Inherits: fd_pt1
@@ -1815,7 +1815,7 @@ Check constraints:
"fd_pt1chk2" CHECK (c2 <> ''::text)
"fd_pt1chk3" CHECK (c2 <> ''::text) NOT VALID
Not-null constraints:
- "ft2_c1_not_null" NOT NULL "c1" (local, inherited)
+ "ft2_c1_not_null" NOT NULL "c1": local inherited
Server: s0
FDW options: (delimiter ',', quote '"', "be quoted" 'value')
Inherits: fd_pt1
@@ -1846,7 +1846,7 @@ Check constraints:
"fd_pt1chk2" CHECK (c2 <> ''::text)
"fd_pt1chk3" CHECK (c2 <> ''::text)
Not-null constraints:
- "ft2_c1_not_null" NOT NULL "c1" (local, inherited)
+ "ft2_c1_not_null" NOT NULL "c1": local inherited
Server: s0
FDW options: (delimiter ',', quote '"', "be quoted" 'value')
Inherits: fd_pt1
@@ -1881,7 +1881,7 @@ Check constraints:
"f2_check" CHECK (f2 <> ''::text)
"fd_pt1chk2" CHECK (f2 <> ''::text)
Not-null constraints:
- "ft2_c1_not_null" NOT NULL "f1" (local, inherited)
+ "ft2_c1_not_null" NOT NULL "f1": local inherited
Server: s0
FDW options: (delimiter ',', quote '"', "be quoted" 'value')
Inherits: fd_pt1
@@ -1942,7 +1942,7 @@ Partitions: fd_pt2_1 FOR VALUES IN (1), FOREIGN
Partition of: fd_pt2 FOR VALUES IN (1)
Partition constraint: ((c1 IS NOT NULL) AND (c1 = 1))
Not-null constraints:
- "fd_pt2_c1_not_null" NOT NULL "c1" (inherited)
+ "fd_pt2_c1_not_null" NOT NULL "c1": inherited
Server: s0
FDW options: (delimiter ',', quote '"', "be quoted" 'value')
@@ -2024,7 +2024,7 @@ Partitions: fd_pt2_1 FOR VALUES IN (1), FOREIGN
Partition of: fd_pt2 FOR VALUES IN (1)
Partition constraint: ((c1 IS NOT NULL) AND (c1 = 1))
Not-null constraints:
- "fd_pt2_1_c1_not_null" NOT NULL "c1" (inherited)
+ "fd_pt2_1_c1_not_null" NOT NULL "c1": inherited
Server: s0
FDW options: (delimiter ',', quote '"', "be quoted" 'value')
@@ -2058,7 +2058,7 @@ Partition constraint: ((c1 IS NOT NULL) AND (c1 = 1))
Check constraints:
"p21chk" CHECK (c2 <> ''::text)
Not-null constraints:
- "fd_pt2_1_c1_not_null" NOT NULL "c1" (inherited)
+ "fd_pt2_1_c1_not_null" NOT NULL "c1": inherited
"fd_pt2_1_c3_not_null" NOT NULL "c3"
Server: s0
FDW options: (delimiter ',', quote '"', "be quoted" 'value')
diff --git a/src/test/regress/expected/generated.out b/src/test/regress/expected/generated.out
index dc97ed3fe0..4a1744f129 100644
--- a/src/test/regress/expected/generated.out
+++ b/src/test/regress/expected/generated.out
@@ -316,7 +316,7 @@ NOTICE: merging column "b" with inherited definition
b | integer | | | generated always as (a * 22) stored | plain | |
x | integer | | | | plain | |
Not-null constraints:
- "gtestx_a_not_null" NOT NULL "a" (inherited)
+ "gtestx_a_not_null" NOT NULL "a": inherited
Inherits: gtest1
CREATE TABLE gtestxx_1 (a int NOT NULL, b int);
diff --git a/src/test/regress/expected/inherit.out b/src/test/regress/expected/inherit.out
index 6daca12340..c80e398f71 100644
--- a/src/test/regress/expected/inherit.out
+++ b/src/test/regress/expected/inherit.out
@@ -2007,7 +2007,7 @@ Child tables: cc2
f4 | double precision | | | | plain | |
a2 | integer | | not null | | plain | |
Not-null constraints:
- "nn" NOT NULL "a2" (inherited)
+ "nn" NOT NULL "a2": inherited
Inherits: pp1,
cc1
@@ -2031,7 +2031,7 @@ Child tables: cc1,
f3 | integer | | | | plain | |
a2 | integer | | not null | | plain | |
Not-null constraints:
- "pp1_f1_not_null" NOT NULL "f1" (inherited)
+ "pp1_f1_not_null" NOT NULL "f1": inherited
"nn" NOT NULL "a2"
Inherits: pp1
Child tables: cc2
@@ -2046,8 +2046,8 @@ Child tables: cc2
f4 | double precision | | | | plain | |
a2 | integer | | not null | | plain | |
Not-null constraints:
- "pp1_f1_not_null" NOT NULL "f1" (inherited)
- "nn" NOT NULL "a2" (inherited)
+ "pp1_f1_not_null" NOT NULL "f1": inherited
+ "nn" NOT NULL "a2": inherited
Inherits: pp1,
cc1
@@ -2065,7 +2065,7 @@ alter table cc1 alter column a2 drop not null;
f3 | integer | | | | plain | |
a2 | integer | | | | plain | |
Not-null constraints:
- "pp1_f1_not_null" NOT NULL "f1" (inherited)
+ "pp1_f1_not_null" NOT NULL "f1": inherited
Inherits: pp1
Child tables: cc2
@@ -2082,7 +2082,7 @@ ERROR: cannot drop inherited constraint "pp1_f1_not_null" of relation "cc2"
f4 | double precision | | | | plain | |
a2 | integer | | | | plain | |
Not-null constraints:
- "pp1_f1_not_null" NOT NULL "f1" (inherited)
+ "pp1_f1_not_null" NOT NULL "f1": inherited
Inherits: pp1,
cc1
@@ -2112,8 +2112,8 @@ create table inh_child () inherits (inh_parent1, inh_parent2);
a | integer | | not null | | plain | |
b | integer | | not null | | plain | |
Not-null constraints:
- "nn" NOT NULL "a" (inherited)
- "inh_child_b_not_null" NOT NULL "b" (inherited)
+ "nn" NOT NULL "a": inherited
+ "inh_child_b_not_null" NOT NULL "b": inherited
Inherits: inh_parent1,
inh_parent2
@@ -2147,9 +2147,9 @@ select conrelid::regclass, conname, contype, conkey,
d | integer | | not null | | plain | |
e | integer | | | | plain | |
Not-null constraints:
- "inh_child_a_not_null" NOT NULL "a" (inherited)
- "inh_child_b_not_null" NOT NULL "b" (inherited)
- "inh_child_d_not_null" NOT NULL "d" (inherited)
+ "inh_child_a_not_null" NOT NULL "a": inherited
+ "inh_child_b_not_null" NOT NULL "b": inherited
+ "inh_child_d_not_null" NOT NULL "d": inherited
Inherits: inh_parent1,
inh_parent2
@@ -2188,7 +2188,7 @@ Inherits: inh_nn_parent
--------+---------+-----------+----------+---------+---------+--------------+-------------
a | integer | | not null | | plain | |
Not-null constraints:
- "inh_nn_parent_a_not_null" NOT NULL "a" NO INHERIT
+ "inh_nn_parent_a_not_null" NOT NULL "a": uninheritable
Child tables: inh_nn_child,
inh_nn_child2
@@ -2223,7 +2223,7 @@ Child tables: inh_child1
--------+---------+-----------+----------+---------+---------+--------------+-------------
f1 | integer | | not null | | plain | |
Not-null constraints:
- "inh_child1_f1_not_null" NOT NULL "f1" (local, inherited)
+ "inh_child1_f1_not_null" NOT NULL "f1": local inherited
Inherits: inh_parent
Child tables: inh_child2
@@ -2233,7 +2233,7 @@ Child tables: inh_child2
--------+---------+-----------+----------+---------+---------+--------------+-------------
f1 | integer | | not null | | plain | |
Not-null constraints:
- "inh_child2_f1_not_null" NOT NULL "f1" (local, inherited)
+ "inh_child2_f1_not_null" NOT NULL "f1": local inherited
Inherits: inh_child1
select conrelid::regclass, conname, contype, coninhcount, conislocal
@@ -2277,7 +2277,7 @@ Child tables: inh_child2,
--------+---------+-----------+----------+---------+---------+--------------+-------------
f1 | integer | | not null | | plain | |
Not-null constraints:
- "inh_child2_f1_not_null" NOT NULL "f1" (local, inherited)
+ "inh_child2_f1_not_null" NOT NULL "f1": local inherited
Inherits: inh_child1
select conrelid::regclass, conname, contype, coninhcount, conislocal
--
2.39.3
----Next_Part(Mon_Aug_28_16_16_58_2023_869)--
Content-Type: Text/X-Patch; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="0002-Add-tests-for-d-not-null-constraints.patch"
^ permalink raw reply [nested|flat] 35+ messages in thread
* Commitfest app release on Feb 17 with many improvements
@ 2025-01-31 14:23 Jelte Fennema-Nio <[email protected]>
0 siblings, 7 replies; 35+ messages in thread
From: Jelte Fennema-Nio @ 2025-01-31 14:23 UTC (permalink / raw)
To: PostgreSQL Hackers <[email protected]>; +Cc: Jacob Brazeal <[email protected]>
At the FOSDEM dev meeting we discussed potential improvements to the
commitfest app and how to handle deploying future changes with minimal
disruption to existing workflows. We're going to try a new approach:
announcing a new commitfest release ~2 weeks in advance, including
release notes. That way people can try out the changes on the staging
environment and raise concerns/objections. So hereby such an
announcement:
The next commitfest app release will take place on February 17 and
will contain the following user facing changes:
1. Showing CFBot status on patch and commitfest pages
2. Showing a link to the CFBot github diff on patch and commitfest pages
3. Showing total additions/deletions of the most recent patchset on
patch and commitfest pages
4. Showing additions/deletions of the first patch of the most recent
patchset on the patch page
5. Showing the version and number of patches of the most recent
patchset on the patch page
6. Canonical links for the patch page are now /patch/{patchid} instead
of /{cfid}/{patchid}
7. If you subscribed for emails or patches where you're an author, you
will now get an email when your patch needs a rebase.
8. Clicking headers will toggle sorting, instead of always enabling it
9. Allow sorting patches by name
10. Allow sorting patches by total additions/deletions (added together
for total lines changed)
11. Add ID column to commitfest page (allows sorting)
12. Allow sorting using the header of closed patches too
13. Fix dropdown direction for dropdowns at the bottom of the page
(they now drop up)
14. The previous GiHub and CirrusCI links are now integrated into the
new CFBot status row of the patch page
15. The previous GitHub checkout instructions are now integrated into
the new CFBot status row as a button that copies the commands to the
clipboard
You can try out these changes on the staging environment[1] with
pgtest:pgtest as user & password for the http auth. If you want to
make edits you need to create a new account, read-only doesn't need an
account.
[1]: https://commitfest-test.postgresql.org/
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Commitfest app release on Feb 17 with many improvements
@ 2025-02-01 11:03 Jelte Fennema-Nio <[email protected]>
parent: Jelte Fennema-Nio <[email protected]>
6 siblings, 0 replies; 35+ messages in thread
From: Jelte Fennema-Nio @ 2025-02-01 11:03 UTC (permalink / raw)
To: PostgreSQL Hackers <[email protected]>; +Cc: Jacob Brazeal <[email protected]>
On Fri, 31 Jan 2025 at 15:23, Jelte Fennema-Nio <[email protected]> wrote:
> You can try out these changes on the staging environment
It seems that someone tried it out, and found a 500 error when
searching by Message-ID. That's fixed now.
I also fixed some broken links to CirrusCI on the patch page.
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Commitfest app release on Feb 17 with many improvements
@ 2025-02-03 20:12 Nathan Bossart <[email protected]>
parent: Jelte Fennema-Nio <[email protected]>
6 siblings, 0 replies; 35+ messages in thread
From: Nathan Bossart @ 2025-02-03 20:12 UTC (permalink / raw)
To: Jelte Fennema-Nio <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>; Jacob Brazeal <[email protected]>
On Fri, Jan 31, 2025 at 03:23:56PM +0100, Jelte Fennema-Nio wrote:
> At the FOSDEM dev meeting we discussed potential improvements to the
> commitfest app and how to handle deploying future changes with minimal
> disruption to existing workflows. We're going to try a new approach:
> announcing a new commitfest release ~2 weeks in advance, including
> release notes. That way people can try out the changes on the staging
> environment and raise concerns/objections. So hereby such an
> announcement:
Thanks for doing this!
> The next commitfest app release will take place on February 17 and
> will contain the following user facing changes:
>
> 1. Showing CFBot status on patch and commitfest pages
> 2. Showing a link to the CFBot github diff on patch and commitfest pages
> 3. Showing total additions/deletions of the most recent patchset on
> patch and commitfest pages
> 4. Showing additions/deletions of the first patch of the most recent
> patchset on the patch page
> 5. Showing the version and number of patches of the most recent
> patchset on the patch page
> 6. Canonical links for the patch page are now /patch/{patchid} instead
> of /{cfid}/{patchid}
> 7. If you subscribed for emails or patches where you're an author, you
> will now get an email when your patch needs a rebase.
> 8. Clicking headers will toggle sorting, instead of always enabling it
> 9. Allow sorting patches by name
> 10. Allow sorting patches by total additions/deletions (added together
> for total lines changed)
> 11. Add ID column to commitfest page (allows sorting)
> 12. Allow sorting using the header of closed patches too
> 13. Fix dropdown direction for dropdowns at the bottom of the page
> (they now drop up)
> 14. The previous GiHub and CirrusCI links are now integrated into the
> new CFBot status row of the patch page
> 15. The previous GitHub checkout instructions are now integrated into
> the new CFBot status row as a button that copies the commands to the
> clipboard
I'm not sure #4 will be very helpful, but the rest looks reasonable to me.
--
nathan
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Commitfest app release on Feb 17 with many improvements
@ 2025-02-04 16:27 Álvaro Herrera <[email protected]>
parent: Jelte Fennema-Nio <[email protected]>
6 siblings, 2 replies; 35+ messages in thread
From: Álvaro Herrera @ 2025-02-04 16:27 UTC (permalink / raw)
To: Jelte Fennema-Nio <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>; Jacob Brazeal <[email protected]>
On 2025-Jan-31, Jelte Fennema-Nio wrote:
> 3. Showing total additions/deletions of the most recent patchset on
> patch and commitfest pages
> 4. Showing additions/deletions of the first patch of the most recent
> patchset on the patch page
> 5. Showing the version and number of patches of the most recent
> patchset on the patch page
I think this has potential for excessive clutter. I propose that, if
we're going to have a column with addition/deletions, we have two
things:
1. the total number of addition and deletions in the whole patch
series, for the last patchset version posted. This would be shown in
the column.
2. a per-patch breakdown of the number of addition and deletions for the
last patchset version posted, one line per patch. This would appear
in a tooltip on the column for the totals, to avoid interface
clutter.
> 10. Allow sorting patches by total additions/deletions (added together
> for total lines changed)
Seems reasonable, though I don't see much of an use-case for this.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Postgres is bloatware by design: it was built to house
PhD theses." (Joey Hellerstein, SIGMOD annual conference 2002)
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Commitfest app release on Feb 17 with many improvements
@ 2025-02-04 22:52 Jelte Fennema-Nio <[email protected]>
parent: Álvaro Herrera <[email protected]>
1 sibling, 0 replies; 35+ messages in thread
From: Jelte Fennema-Nio @ 2025-02-04 22:52 UTC (permalink / raw)
To: Álvaro Herrera <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>; Jacob Brazeal <[email protected]>
On Tue, 4 Feb 2025 at 17:27, Álvaro Herrera <[email protected]> wrote:
> I think this has potential for excessive clutter. I propose that, if
> we're going to have a column with addition/deletions, we have two
> things:
>
> 1. the total number of addition and deletions in the whole patch
> series, for the last patchset version posted. This would be shown in
> the column.
To be clear: the only stats column currently in the staging
environment shows exactly this. Changes 4 and 5 are *not* visible in
columns on the commitfest page, that info is currently only visible on
the patch details page. (For context for others: during the FOSDEM
meeting 4 was a column on the commitfest page, but I reverted that
after the feedback there)
So, I guess clutter wise the current staging is acceptable to you.
> 2. a per-patch breakdown of the number of addition and deletions for the
> last patchset version posted, one line per patch. This would appear
> in a tooltip on the column for the totals, to avoid interface
> clutter.
Statistics for each patch would definitely be nice. Not trivial to add
though, because it would need cfbot to get those statistics for each
patch. I created a github issue for this idea to track it[1]
> > 10. Allow sorting patches by total additions/deletions (added together
> > for total lines changed)
>
> Seems reasonable, though I don't see much of an use-case for this.
My main idea behind this is to allow people to easily find some small
patchsets, for when they have ~30 minutes to review something. Or for
new contributors to find something to review without getting
overwhelmed.
[1]: https://github.com/postgres/pgcommitfest/issues/24
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Commitfest app release on Feb 17 with many improvements
@ 2025-02-17 09:02 Jelte Fennema-Nio <[email protected]>
parent: Jelte Fennema-Nio <[email protected]>
6 siblings, 1 reply; 35+ messages in thread
From: Jelte Fennema-Nio @ 2025-02-17 09:02 UTC (permalink / raw)
To: PostgreSQL Hackers <[email protected]>; +Cc: Jacob Brazeal <[email protected]>
On Fri, 31 Jan 2025 at 15:23, Jelte Fennema-Nio <[email protected]> wrote:
> The next commitfest app release will take place on February 17 and
> will contain the following user facing changes:
In my part of the world it's February 17th now. So this is now deployed.
A big recommendation, check the "Notify on all where author" checkbox
on your profile page[1]. That way you'll get notified when one of your
patches needs a rebase.
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.
Since the last message on this thread I also fixed the "claim as
committer" button, which was broken due to the new patch URLs.
> 13. Fix dropdown direction for dropdowns at the bottom of the page
> (they now drop up)
I didn't mention it in my previous email, but this was fixed by Jacob
Brazeal btw. He also added some initial dummy data to the repo to make
it much easier for new developers to get started. Thanks Jacob!
[1]: https://commitfest.postgresql.org/account/profile/
[2]: https://commitfest.postgresql.org/52/?text=&status=-1&targetversion=-1&author=-1&rev...
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Commitfest app release on Feb 17 with many improvements
@ 2025-02-17 21:33 Thomas Munro <[email protected]>
parent: Jelte Fennema-Nio <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Thomas Munro @ 2025-02-17 21:33 UTC (permalink / raw)
To: Jelte Fennema-Nio <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>; Jacob Brazeal <[email protected]>
On Mon, Feb 17, 2025 at 10:03 PM Jelte Fennema-Nio <[email protected]> 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 usability improvements too.
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Commitfest app release on Feb 17 with many improvements
@ 2025-02-17 23:38 Peter Geoghegan <[email protected]>
parent: Thomas Munro <[email protected]>
0 siblings, 2 replies; 35+ messages in thread
From: Peter Geoghegan @ 2025-02-17 23:38 UTC (permalink / raw)
To: Thomas Munro <[email protected]>; +Cc: Jelte Fennema-Nio <[email protected]>; PostgreSQL Hackers <[email protected]>; Jacob Brazeal <[email protected]>
On Mon, Feb 17, 2025 at 4:33 PM Thomas Munro <[email protected]> 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 there was a way to see a list of open
patches that I am associated with in any way, either as an author or
as a reviewer (or as a committer). The list of patches would ideally
be organized into two groups: those in the open CF, and those in the
next CF.
I like "Useful links that you can use and bookmark", but I'd prefer if
there was only one link that I needed to bookmark. That is, I'd like
it if "Your entries in the current commitfest", "Your entries in the
open commitfest", and "Entries that you are reviewing in current
commitfest" were all merged into one dashboard view (that also
included "Entries that you are reviewing in the open commitfest").
Essentially, "patches that you're involved in in any capacity that
haven't already been closed out", organized along the same lines as
the existing links (every patch fitting into 1 or those 4 categories),
and presented to me as a single page of patches/items.
I'm not arguing that you should get rid of "Your entries in the
current commitfest", "Your entries in the open commitfest", and
"Entries that you are reviewing in current commitfest". Though I will
say that if you did get rid of them, I wouldn't object (I'd expect to
see the same structure when I viewed the new dashboard view, which
would be all I'd ever want to use).
Thanks
--
Peter Geoghegan
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Commitfest app release on Feb 17 with many improvements
@ 2025-02-17 23:46 Michael Paquier <[email protected]>
parent: Peter Geoghegan <[email protected]>
1 sibling, 0 replies; 35+ messages in thread
From: Michael Paquier @ 2025-02-17 23:46 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; +Cc: Thomas Munro <[email protected]>; Jelte Fennema-Nio <[email protected]>; PostgreSQL Hackers <[email protected]>; Jacob Brazeal <[email protected]>
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
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Commitfest app release on Feb 17 with many improvements
@ 2025-02-18 21:15 Bruce Momjian <[email protected]>
parent: Álvaro Herrera <[email protected]>
1 sibling, 1 reply; 35+ messages in thread
From: Bruce Momjian @ 2025-02-18 21:15 UTC (permalink / raw)
To: Álvaro Herrera <[email protected]>; +Cc: Jelte Fennema-Nio <[email protected]>; PostgreSQL Hackers <[email protected]>; Jacob Brazeal <[email protected]>
On Tue, Feb 4, 2025 at 05:27:18PM +0100, Álvaro Herrera wrote:
> On 2025-Jan-31, Jelte Fennema-Nio wrote:
>
> > 3. Showing total additions/deletions of the most recent patchset on
> > patch and commitfest pages
> > 4. Showing additions/deletions of the first patch of the most recent
> > patchset on the patch page
> > 5. Showing the version and number of patches of the most recent
> > patchset on the patch page
>
> I think this has potential for excessive clutter. I propose that, if
> we're going to have a column with addition/deletions, we have two
> things:
>
> 1. the total number of addition and deletions in the whole patch
> series, for the last patchset version posted. This would be shown in
> the column.
> 2. a per-patch breakdown of the number of addition and deletions for the
> last patchset version posted, one line per patch. This would appear
> in a tooltip on the column for the totals, to avoid interface
> clutter.
>
> > 10. Allow sorting patches by total additions/deletions (added together
> > for total lines changed)
>
> Seems reasonable, though I don't see much of an use-case for this.
Looking at the live version, I can sort the "Stats" column from smallest
to largest, but not from largest to smallest. Is this intended?
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Commitfest app release on Feb 17 with many improvements
@ 2025-02-18 22:39 Jelte Fennema-Nio <[email protected]>
parent: Bruce Momjian <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Jelte Fennema-Nio @ 2025-02-18 22:39 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Álvaro Herrera <[email protected]>; PostgreSQL Hackers <[email protected]>; Jacob Brazeal <[email protected]>; Akshat Jaimini <[email protected]>
On Tue, 18 Feb 2025 at 22:15, Bruce Momjian <[email protected]> wrote:
> Looking at the live version, I can sort the "Stats" column from smallest
> to largest, but not from largest to smallest. Is this intended?
The next release to prod in ~2 weeks will have that as one of the new
features (courtesy of Akshat).
You can try it out on the staging website[1] already, with pgtest as
user and password for the HTTP auth.
[1]: https://commitfest-test.postgresql.org/
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Commitfest app release on Feb 17 with many improvements
@ 2025-02-18 22:57 Jelte Fennema-Nio <[email protected]>
parent: Peter Geoghegan <[email protected]>
1 sibling, 2 replies; 35+ messages in thread
From: Jelte Fennema-Nio @ 2025-02-18 22:57 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; +Cc: Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Jacob Brazeal <[email protected]>
On Tue, 18 Feb 2025 at 00:38, Peter Geoghegan <[email protected]> wrote:
>
> On Mon, Feb 17, 2025 at 4:33 PM Thomas Munro <[email protected]> wrote:
> > This looks fantastic. Thanks so much for working on it! And all the
> > other usability improvements too.
>
> +1.
Thanks all, I'm also very happy that it's deployed.
> I very much welcome a more formal release process for the CF app,
> though with shorter feedback cycles.
Do you mean here that you'd like less than two weeks between the
announced staging deploy and prod deploy?
> I like "Useful links that you can use and bookmark", but I'd prefer if
> there was only one link that I needed to bookmark. That is, I'd like
> it if "Your entries in the current commitfest", "Your entries in the
> open commitfest", and "Entries that you are reviewing in current
> commitfest" were all merged into one dashboard view
I think that indeed would be very useful, but also not a small task to
do well. The links were pretty easy to implement, so I went for that
first.
Overall from what I've heard after talking to people there are a few
main use cases for the commitfest app.
1. As a committer/reviewer/submitter, keep track of all the patches
that you are interested in
2. As a reviewer, find new patches (and from the opposite side, have
reviewers find your submitted patches)
3. As a submitter, trigger CFBot runs
4. Get details on a specific patch (does it pass CI, look at a diff in
a web view, check out the change locally).
5. If there's other usecases please let me know.
I don't use it much for 1 myself. I've been mostly using my
"Interesting" label in my email client for tracking interesting
threads. So instead I focussed mostly on improving 4, and a bit of 2
for now. Now that there's some more useful patch info available for
each patch, I probably also want to start keeping track of patches
that I'm interested in, on the cf app.
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Commitfest app release on Feb 17 with many improvements
@ 2025-02-18 23:01 Jelte Fennema-Nio <[email protected]>
parent: Jelte Fennema-Nio <[email protected]>
1 sibling, 0 replies; 35+ messages in thread
From: Jelte Fennema-Nio @ 2025-02-18 23:01 UTC (permalink / raw)
To: Peter Geoghegan <[email protected]>; +Cc: Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Jacob Brazeal <[email protected]>
On Tue, 18 Feb 2025 at 23:57, Jelte Fennema-Nio <[email protected]> wrote:
> > I like "Useful links that you can use and bookmark", but I'd prefer if
> > there was only one link that I needed to bookmark. That is, I'd like
> > it if "Your entries in the current commitfest", "Your entries in the
> > open commitfest", and "Entries that you are reviewing in current
> > commitfest" were all merged into one dashboard view
>
> I think that indeed would be very useful, but also not a small task to
> do well. The links were pretty easy to implement, so I went for that
> first.
I created an issue to not forget about that:
https://github.com/postgres/pgcommitfest/issues/36
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Commitfest app release on Feb 17 with many improvements
@ 2025-02-19 00:25 Bruce Momjian <[email protected]>
parent: Jelte Fennema-Nio <[email protected]>
0 siblings, 0 replies; 35+ messages in thread
From: Bruce Momjian @ 2025-02-19 00:25 UTC (permalink / raw)
To: Jelte Fennema-Nio <[email protected]>; +Cc: Álvaro Herrera <[email protected]>; PostgreSQL Hackers <[email protected]>; Jacob Brazeal <[email protected]>; Akshat Jaimini <[email protected]>
On Tue, Feb 18, 2025 at 11:39:54PM +0100, Jelte Fennema-Nio wrote:
> On Tue, 18 Feb 2025 at 22:15, Bruce Momjian <[email protected]> wrote:
> > Looking at the live version, I can sort the "Stats" column from smallest
> > to largest, but not from largest to smallest. Is this intended?
>
> The next release to prod in ~2 weeks will have that as one of the new
> features (courtesy of Akshat).
>
> You can try it out on the staging website[1] already, with pgtest as
> user and password for the HTTP auth.
>
> [1]: https://commitfest-test.postgresql.org/
Yes, works perfectly in test, thanks.
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Commitfest app release on Feb 17 with many improvements
@ 2025-02-20 04:16 Thomas Munro <[email protected]>
parent: Jelte Fennema-Nio <[email protected]>
1 sibling, 0 replies; 35+ messages in thread
From: Thomas Munro @ 2025-02-20 04:16 UTC (permalink / raw)
To: Jelte Fennema-Nio <[email protected]>; +Cc: Peter Geoghegan <[email protected]>; PostgreSQL Hackers <[email protected]>; Jacob Brazeal <[email protected]>
On Wed, Feb 19, 2025 at 11:57 AM Jelte Fennema-Nio <[email protected]> wrote:
> On Tue, 18 Feb 2025 at 00:38, Peter Geoghegan <[email protected]> wrote:
> > On Mon, Feb 17, 2025 at 4:33 PM Thomas Munro <[email protected]> wrote:
> > > This looks fantastic. Thanks so much for working on it! And all the
> > > other usability improvements too.
> >
> > +1.
>
> Thanks all, I'm also very happy that it's deployed.
Now that we have CI information in an interactive webapp, do you think
it would make sense to offer ways to control it a bit?
[ ] Enable optional NetBSD task
[ ] Enable optional OpenBSD task
[ ] Enable optional Windows + MinGW task
[ ] Request fresh CI run
Until we have the new proper API endpoint up and running, perhaps we
could include hidden comments on the page the cfbot scrapes to
synchronise its submission list...
The last one would affect cfbot's scheduling choices, ie do this one
next please, and could be cleared as soon as a new CI result arrives.
I suppose the other ones could cause cfbot to add "ci-os-also:"
annotations to its commit message, like the existing "ci-os-only:",
except not exclusive. You probably know if a patch has portability
implications and want to turn those on, but I assume they are still
too slow and expensive to enable by default.
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Commitfest app release on Feb 17 with many improvements
@ 2025-02-20 09:53 Tatsuo Ishii <[email protected]>
parent: Jelte Fennema-Nio <[email protected]>
6 siblings, 1 reply; 35+ messages in thread
From: Tatsuo Ishii @ 2025-02-20 09:53 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]; [email protected]
> At the FOSDEM dev meeting we discussed potential improvements to the
> commitfest app and how to handle deploying future changes with minimal
> disruption to existing workflows. We're going to try a new approach:
> announcing a new commitfest release ~2 weeks in advance, including
> release notes. That way people can try out the changes on the staging
> environment and raise concerns/objections. So hereby such an
> announcement:
>
> The next commitfest app release will take place on February 17 and
> will contain the following user facing changes:
>
> 1. Showing CFBot status on patch and commitfest pages
> 2. Showing a link to the CFBot github diff on patch and commitfest pages
> 3. Showing total additions/deletions of the most recent patchset on
> patch and commitfest pages
> 4. Showing additions/deletions of the first patch of the most recent
> patchset on the patch page
> 5. Showing the version and number of patches of the most recent
> patchset on the patch page
> 6. Canonical links for the patch page are now /patch/{patchid} instead
> of /{cfid}/{patchid}
> 7. If you subscribed for emails or patches where you're an author, you
> will now get an email when your patch needs a rebase.
> 8. Clicking headers will toggle sorting, instead of always enabling it
> 9. Allow sorting patches by name
> 10. Allow sorting patches by total additions/deletions (added together
> for total lines changed)
> 11. Add ID column to commitfest page (allows sorting)
> 12. Allow sorting using the header of closed patches too
> 13. Fix dropdown direction for dropdowns at the bottom of the page
> (they now drop up)
> 14. The previous GiHub and CirrusCI links are now integrated into the
> new CFBot status row of the patch page
> 15. The previous GitHub checkout instructions are now integrated into
> the new CFBot status row as a button that copies the commands to the
> clipboard
>
> You can try out these changes on the staging environment[1] with
> pgtest:pgtest as user & password for the http auth. If you want to
> make edits you need to create a new account, read-only doesn't need an
> account.
>
> [1]: https://commitfest-test.postgresql.org/
I noticed some of entries are shown with the author field being empty.
e.g. https://commitfest.postgresql.org/patch/5525/
Is this normal?
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Commitfest app release on Feb 17 with many improvements
@ 2025-02-20 10:16 Thomas Munro <[email protected]>
parent: Tatsuo Ishii <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Thomas Munro @ 2025-02-20 10:16 UTC (permalink / raw)
To: Tatsuo Ishii <[email protected]>; +Cc: [email protected]; [email protected]; [email protected]
On Thu, Feb 20, 2025 at 10:53 PM Tatsuo Ishii <[email protected]> wrote:
> I noticed some of entries are shown with the author field being empty.
> e.g. https://commitfest.postgresql.org/patch/5525/
When the layout of https://commitfest.postgresql.org/52/ changed,
cfbot's web scraping logic could no longer find the authors :-(.
That's a stupid problem to have, that we are going to solve with a new
machine-friendly API, but let me try to fix it quickly...
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Commitfest app release on Feb 17 with many improvements
@ 2025-02-20 10:53 Jelte Fennema-Nio <[email protected]>
parent: Thomas Munro <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Jelte Fennema-Nio @ 2025-02-20 10:53 UTC (permalink / raw)
To: Thomas Munro <[email protected]>; +Cc: Tatsuo Ishii <[email protected]>; [email protected]; [email protected]
On Thu, 20 Feb 2025 at 11:07, Thomas Munro <[email protected]> wrote:
>
> On Thu, Feb 20, 2025 at 10:53 PM Tatsuo Ishii <[email protected]> wrote:
> > I noticed some of entries are shown with the author field being empty.
> > e.g. https://commitfest.postgresql.org/patch/5525/
>
> When the layout of https://commitfest.postgresql.org/52/ changed,
> cfbot's web scraping logic could no longer find the authors :-(.
> That's a stupid problem to have, that we are going to solve with a new
> machine-friendly API, but let me try to fix it quickly...
I believe Tatsuo was talking about the author field on the commitfest
app, not the cfbot.
Assuming I'm correct there, I think for the link you shared simply no
Author was added when the user created the entry. In the next
commitfest release (March 4th), that should not happen anymor (or at
least not by accident) because then it will start to autofill yourself
as author when you submit a patch.
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Commitfest app release on Feb 17 with many improvements
@ 2025-02-20 11:22 Thomas Munro <[email protected]>
parent: Jelte Fennema-Nio <[email protected]>
0 siblings, 0 replies; 35+ messages in thread
From: Thomas Munro @ 2025-02-20 11:22 UTC (permalink / raw)
To: Jelte Fennema-Nio <[email protected]>; +Cc: Tatsuo Ishii <[email protected]>; [email protected]; [email protected]
On Thu, Feb 20, 2025 at 11:53 PM Jelte Fennema-Nio <[email protected]> wrote:
> On Thu, 20 Feb 2025 at 11:07, Thomas Munro <[email protected]> wrote:
> > When the layout of https://commitfest.postgresql.org/52/ changed,
> > cfbot's web scraping logic could no longer find the authors :-(.
> > That's a stupid problem to have, that we are going to solve with a new
> > machine-friendly API, but let me try to fix it quickly...
>
> I believe Tatsuo was talking about the author field on the commitfest
> app, not the cfbot.
Oh. Well the author was also missing from the commit messages, and
that's now fixed.
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Commitfest app release on Feb 17 with many improvements
@ 2025-03-06 15:35 vignesh C <[email protected]>
parent: Jelte Fennema-Nio <[email protected]>
6 siblings, 1 reply; 35+ messages in thread
From: vignesh C @ 2025-03-06 15:35 UTC (permalink / raw)
To: Jelte Fennema-Nio <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>; Jacob Brazeal <[email protected]>
On Fri, 31 Jan 2025 at 19:54, Jelte Fennema-Nio <[email protected]> wrote:
>
> At the FOSDEM dev meeting we discussed potential improvements to the
> commitfest app and how to handle deploying future changes with minimal
> disruption to existing workflows. We're going to try a new approach:
> announcing a new commitfest release ~2 weeks in advance, including
> release notes. That way people can try out the changes on the staging
> environment and raise concerns/objections. So hereby such an
> announcement:
>
> The next commitfest app release will take place on February 17 and
> will contain the following user facing changes:
>
> 1. Showing CFBot status on patch and commitfest pages
I noticed that the "Truncate logs by max_log_size" commitfest entry
says it requires a rebase in commitfest at [1].
CFBot says the following error at [2]:
++<<<<<<< ours
+ <varlistentry id="guc-md5-password-warnings"
xreflabel="md5_password_warnings">
+ <term><varname>md5_password_warnings</varname> (<type>boolean</type>)
+ <indexterm>
+ <primary><varname>md5_password_warnings</varname>
configuration parameter</primary>
++=======
+ <varlistentry id="guc-max-log-size" xreflabel="max_log_size">
+ <term><varname>max_log_size</varname> (<type>integer</type>)
+ <indexterm>
+ <primary><varname>max_log_size</varname> configuration
parameter</primary>
++>>>>>>> theirs
But it applies neatly for me and Jim also at [3]. Any idea why patch
apply fails with CFbot whereas it passes in our environment?
[1] - https://commitfest.postgresql.org/patch/5272/
[2] - http://cfbot.cputube.org/patch_5272.log
[3] - https://www.postgresql.org/message-id/4c3a4c2f-fa6b-4d56-8947-fba2c06066fd%40uni-muenster.de
Regards,
Vignesh
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Commitfest app release on Feb 17 with many improvements
@ 2025-03-06 16:00 Jelte Fennema-Nio <[email protected]>
parent: vignesh C <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Jelte Fennema-Nio @ 2025-03-06 16:00 UTC (permalink / raw)
To: vignesh C <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>; Jacob Brazeal <[email protected]>
On Thu, 6 Mar 2025 at 16:36, vignesh C <[email protected]> wrote:
> But it applies neatly for me and Jim also at [3]. Any idea why patch
> apply fails with CFbot whereas it passes in our environment?
Okay, the cause of this seems to be that the CFbot currently uses "git
apply --3way", not "git am --3way". For some reason "git apply" fails
to apply the patch while "git am" succeeds. I'll check this weekend if
I can change the logic to use "git am" instead.
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Commitfest app release on Feb 17 with many improvements
@ 2025-03-06 17:10 Tom Lane <[email protected]>
parent: Jelte Fennema-Nio <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Tom Lane @ 2025-03-06 17:10 UTC (permalink / raw)
To: Jelte Fennema-Nio <[email protected]>; +Cc: vignesh C <[email protected]>; PostgreSQL Hackers <[email protected]>; Jacob Brazeal <[email protected]>
Jelte Fennema-Nio <[email protected]> writes:
> Okay, the cause of this seems to be that the CFbot currently uses "git
> apply --3way", not "git am --3way". For some reason "git apply" fails
> to apply the patch while "git am" succeeds. I'll check this weekend if
> I can change the logic to use "git am" instead.
Please see if you can make it use patch(1). IME git is too
stiff-necked about slightly stale patches no matter which
subcommand you use.
regards, tom lane
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Commitfest app release on Feb 17 with many improvements
@ 2025-03-06 17:39 Jelte Fennema-Nio <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Jelte Fennema-Nio @ 2025-03-06 17:39 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: vignesh C <[email protected]>; PostgreSQL Hackers <[email protected]>; Jacob Brazeal <[email protected]>
On Thu, 6 Mar 2025 at 18:10, Tom Lane <[email protected]> wrote:
> Please see if you can make it use patch(1). IME git is too
> stiff-necked about slightly stale patches no matter which
> subcommand you use.
It was using patch(1) in the past for that reason, but with --3way I
was able to get "git apply" to apply patches that patch(1) was unable
to apply. Also with the git command you get much more useful conflict
output.
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Commitfest app release on Feb 17 with many improvements
@ 2025-03-06 23:48 Jelte Fennema-Nio <[email protected]>
parent: Jelte Fennema-Nio <[email protected]>
0 siblings, 2 replies; 35+ messages in thread
From: Jelte Fennema-Nio @ 2025-03-06 23:48 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: vignesh C <[email protected]>; PostgreSQL Hackers <[email protected]>; Jacob Brazeal <[email protected]>
On Thu, 6 Mar 2025 at 18:39, Jelte Fennema-Nio <[email protected]> wrote:
>
> On Thu, 6 Mar 2025 at 18:10, Tom Lane <[email protected]> wrote:
> > Please see if you can make it use patch(1). IME git is too
> > stiff-necked about slightly stale patches no matter which
> > subcommand you use.
>
> It was using patch(1) in the past for that reason, but with --3way I
> was able to get "git apply" to apply patches that patch(1) was unable
> to apply. Also with the git command you get much more useful conflict
> output.
Okay, I went for the approach of just trying everything until one
works. Starting with "git am", then patch(1), and as a final attempt
"git apply". Patch 5272 applies correctly now. I've removed any
backoff caused by repeated failures for all existing patches, so all
should be retried in the next ~48 hours.
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Commitfest app release on Feb 17 with many improvements
@ 2025-03-07 03:08 Tom Lane <[email protected]>
parent: Jelte Fennema-Nio <[email protected]>
1 sibling, 0 replies; 35+ messages in thread
From: Tom Lane @ 2025-03-07 03:08 UTC (permalink / raw)
To: Jelte Fennema-Nio <[email protected]>; +Cc: vignesh C <[email protected]>; PostgreSQL Hackers <[email protected]>; Jacob Brazeal <[email protected]>
Jelte Fennema-Nio <[email protected]> writes:
> Okay, I went for the approach of just trying everything until one
> works. Starting with "git am", then patch(1), and as a final attempt
> "git apply".
+1, thanks!
regards, tom lane
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Commitfest app release on Feb 17 with many improvements
@ 2025-03-07 10:26 Andreas Karlsson <[email protected]>
parent: Jelte Fennema-Nio <[email protected]>
1 sibling, 1 reply; 35+ messages in thread
From: Andreas Karlsson @ 2025-03-07 10:26 UTC (permalink / raw)
To: [email protected]
On 3/7/25 12:48 AM, Jelte Fennema-Nio wrote:
> Okay, I went for the approach of just trying everything until one
> works. Starting with "git am", then patch(1), and as a final attempt
> "git apply". Patch 5272 applies correctly now. I've removed any
> backoff caused by repeated failures for all existing patches, so all
> should be retried in the next ~48 hours.
Out of curiosity: do you track which method works? I would expect
everything to be applied with either git am or patch which can be
applied with git apply making git apply technically unnecessary.
Andreas
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Commitfest app release on Feb 17 with many improvements
@ 2025-03-07 10:49 Jelte Fennema-Nio <[email protected]>
parent: Andreas Karlsson <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Jelte Fennema-Nio @ 2025-03-07 10:49 UTC (permalink / raw)
To: Andreas Karlsson <[email protected]>; +Cc: [email protected]
On Fri, 7 Mar 2025 at 11:26, Andreas Karlsson <[email protected]> wrote:
> Out of curiosity: do you track which method works? I would expect
> everything to be applied with either git am or patch which can be
> applied with git apply making git apply technically unnecessary.
I think we need all of them...
- git apply is unable to apply the patch in 5272 on top of main
- git am, works with that 5272, but cannot apply any patch not created
by git format-patch (for instance 5522)
- I've been unable to get patch(1) not to return a failure if the
patch is already applied. So applying e.g. 5522 twice. git apply
handles that fine.
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Commitfest app release on Feb 17 with many improvements
@ 2025-03-07 16:42 Tom Lane <[email protected]>
parent: Jelte Fennema-Nio <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Tom Lane @ 2025-03-07 16:42 UTC (permalink / raw)
To: Jelte Fennema-Nio <[email protected]>; +Cc: Andreas Karlsson <[email protected]>; [email protected]
Jelte Fennema-Nio <[email protected]> writes:
> On Fri, 7 Mar 2025 at 11:26, Andreas Karlsson <[email protected]> wrote:
>> Out of curiosity: do you track which method works? I would expect
>> everything to be applied with either git am or patch which can be
>> applied with git apply making git apply technically unnecessary.
> I think we need all of them...
> - git apply is unable to apply the patch in 5272 on top of main
> - git am, works with that 5272, but cannot apply any patch not created
> by git format-patch (for instance 5522)
> - I've been unable to get patch(1) not to return a failure if the
> patch is already applied. So applying e.g. 5522 twice. git apply
> handles that fine.
Hm, don't you *want* a failure if the patch is already applied?
regards, tom lane
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Commitfest app release on Feb 17 with many improvements
@ 2025-03-07 17:52 Jelte Fennema-Nio <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Jelte Fennema-Nio @ 2025-03-07 17:52 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Andreas Karlsson <[email protected]>; [email protected]
On Fri, 7 Mar 2025 at 17:42, Tom Lane <[email protected]> wrote:
> Hm, don't you *want* a failure if the patch is already applied?
It's pretty common that in a larger patchset the first 1-2
small/trivial patches get committed before the rest. Having to then
send an additional email, resubmitting the rest of the patchset
because CFBot fails when re-applying those is kind of silly. This
avoids that.
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Commitfest app release on Feb 17 with many improvements
@ 2025-03-07 17:57 Tom Lane <[email protected]>
parent: Jelte Fennema-Nio <[email protected]>
0 siblings, 0 replies; 35+ messages in thread
From: Tom Lane @ 2025-03-07 17:57 UTC (permalink / raw)
To: Jelte Fennema-Nio <[email protected]>; +Cc: Andreas Karlsson <[email protected]>; [email protected]
Jelte Fennema-Nio <[email protected]> writes:
> On Fri, 7 Mar 2025 at 17:42, Tom Lane <[email protected]> wrote:
>> Hm, don't you *want* a failure if the patch is already applied?
> It's pretty common that in a larger patchset the first 1-2
> small/trivial patches get committed before the rest. Having to then
> send an additional email, resubmitting the rest of the patchset
> because CFBot fails when re-applying those is kind of silly. This
> avoids that.
Got it. That is indeed an improvement, though of course it only
helps if those patches were applied verbatim.
regards, tom lane
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Commitfest app release on Feb 17 with many improvements
@ 2025-03-09 02:20 vignesh C <[email protected]>
parent: Jelte Fennema-Nio <[email protected]>
6 siblings, 1 reply; 35+ messages in thread
From: vignesh C @ 2025-03-09 02:20 UTC (permalink / raw)
To: Jelte Fennema-Nio <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>; Jacob Brazeal <[email protected]>
On Fri, 31 Jan 2025 at 19:54, Jelte Fennema-Nio <[email protected]> wrote:
>
> At the FOSDEM dev meeting we discussed potential improvements to the
> commitfest app and how to handle deploying future changes with minimal
> disruption to existing workflows. We're going to try a new approach:
> announcing a new commitfest release ~2 weeks in advance, including
> release notes. That way people can try out the changes on the staging
> environment and raise concerns/objections. So hereby such an
> announcement:
>
> The next commitfest app release will take place on February 17 and
> will contain the following user facing changes:
>
> 1. Showing CFBot status on patch and commitfest pages
Couple of suggestions: a) No need to show CI status as "Needs rebase,"
"Not processed," etc., for committed patches. b) Can we add a filter
for "Needs rebase!"? This would help the CommitFest manager easily
list patches that need updating.
Regards,
Vignesh
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Commitfest app release on Feb 17 with many improvements
@ 2025-03-09 13:35 Jelte Fennema-Nio <[email protected]>
parent: vignesh C <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Jelte Fennema-Nio @ 2025-03-09 13:35 UTC (permalink / raw)
To: vignesh C <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>; Jacob Brazeal <[email protected]>
On Sun, 9 Mar 2025 at 03:21, vignesh C <[email protected]> wrote:
> Couple of suggestions: a) No need to show CI status as "Needs rebase,"
> "Not processed," etc., for committed patches.
Do you mean specifically for committed ones? Or just for any patch
with a "closed" status.
> b) Can we add a filter
> for "Needs rebase!"? This would help the CommitFest manager easily
> list patches that need updating.
That should be pretty easy to implement. But is that really what we
want? In the next release, sorting by "failing since" is implemented.
It sounds like that could be enough instead. i.e. do we really only
want to call out patches that need a rebase? Or also ones that have
been failing in CI for a long time?
I'm even wondering if this whole flow still makes sense. Do we really
want to send an email to the mailing list about this? And if so, why
is someone doing that manually? If people subscribe to updates for
patches that they authored, then they get these "needs rebase"
automatically. Should we maybe simply default that option to true? And
for instance send a notification automatically to all people with a
"needs rebase" CI status whenever we start a new commitfest.
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Commitfest app release on Feb 17 with many improvements
@ 2025-03-11 03:47 vignesh C <[email protected]>
parent: Jelte Fennema-Nio <[email protected]>
0 siblings, 0 replies; 35+ messages in thread
From: vignesh C @ 2025-03-11 03:47 UTC (permalink / raw)
To: Jelte Fennema-Nio <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>; Jacob Brazeal <[email protected]>
On Sun, 9 Mar 2025 at 19:05, Jelte Fennema-Nio <[email protected]> wrote:
>
> On Sun, 9 Mar 2025 at 03:21, vignesh C <[email protected]> wrote:
> > Couple of suggestions: a) No need to show CI status as "Needs rebase,"
> > "Not processed," etc., for committed patches.
>
> Do you mean specifically for committed ones? Or just for any patch
> with a "closed" status.
It is for any closed status patches.
> > b) Can we add a filter
> > for "Needs rebase!"? This would help the CommitFest manager easily
> > list patches that need updating.
>
> That should be pretty easy to implement. But is that really what we
> want? In the next release, sorting by "failing since" is implemented.
> It sounds like that could be enough instead. i.e. do we really only
> want to call out patches that need a rebase? Or also ones that have
> been failing in CI for a long time?
>
> I'm even wondering if this whole flow still makes sense. Do we really
> want to send an email to the mailing list about this? And if so, why
> is someone doing that manually? If people subscribe to updates for
> patches that they authored, then they get these "needs rebase"
> automatically. Should we maybe simply default that option to true? And
> for instance send a notification automatically to all people with a
> "needs rebase" CI status whenever we start a new commitfest.
It will be good if you can send a notification automatically to the
patch requiring a rebase when the CFBot first identifies this(not only
during the start of commitfest) and probably send this notification
once in a day for 3 or so days and then change the status to "waiting
on author" if a new rebased version is not posted in this time.
Regards,
Vignesh
^ permalink raw reply [nested|flat] 35+ messages in thread
* [PATCH v1 4/8] convert PROC_HDR->startupBufferPinWaitBufId to an atomic
@ 2026-07-09 19:26 Nathan Bossart <[email protected]>
0 siblings, 0 replies; 35+ messages in thread
From: Nathan Bossart @ 2026-07-09 19:26 UTC (permalink / raw)
---
src/backend/storage/lmgr/proc.c | 12 +++---------
src/include/storage/proc.h | 2 +-
2 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/src/backend/storage/lmgr/proc.c b/src/backend/storage/lmgr/proc.c
index 9d6e69175a5..5f314efb289 100644
--- a/src/backend/storage/lmgr/proc.c
+++ b/src/backend/storage/lmgr/proc.c
@@ -239,7 +239,7 @@ ProcGlobalShmemInit(void *arg)
dlist_init(&ProcGlobal->autovacFreeProcs);
dlist_init(&ProcGlobal->bgworkerFreeProcs);
dlist_init(&ProcGlobal->walsenderFreeProcs);
- ProcGlobal->startupBufferPinWaitBufId = -1;
+ pg_atomic_init_u32(&ProcGlobal->startupBufferPinWaitBufId, -1);
pg_atomic_init_u32(&ProcGlobal->avLauncherProc, INVALID_PROC_NUMBER);
pg_atomic_init_u32(&ProcGlobal->walwriterProc, INVALID_PROC_NUMBER);
pg_atomic_init_u32(&ProcGlobal->checkpointerProc, INVALID_PROC_NUMBER);
@@ -768,10 +768,7 @@ InitAuxiliaryProcess(void)
void
SetStartupBufferPinWaitBufId(int bufid)
{
- /* use volatile pointer to prevent code rearrangement */
- volatile PROC_HDR *procglobal = ProcGlobal;
-
- procglobal->startupBufferPinWaitBufId = bufid;
+ pg_atomic_write_u32(&ProcGlobal->startupBufferPinWaitBufId, bufid);
}
/*
@@ -780,10 +777,7 @@ SetStartupBufferPinWaitBufId(int bufid)
int
GetStartupBufferPinWaitBufId(void)
{
- /* use volatile pointer to prevent code rearrangement */
- volatile PROC_HDR *procglobal = ProcGlobal;
-
- return procglobal->startupBufferPinWaitBufId;
+ return pg_atomic_read_u32(&ProcGlobal->startupBufferPinWaitBufId);
}
/*
diff --git a/src/include/storage/proc.h b/src/include/storage/proc.h
index 03a1a466fa8..e2034255124 100644
--- a/src/include/storage/proc.h
+++ b/src/include/storage/proc.h
@@ -499,7 +499,7 @@ typedef struct PROC_HDR
/* Current shared estimate of appropriate spins_per_delay value */
int spins_per_delay;
/* Buffer id of the buffer that Startup process waits for pin on, or -1 */
- int startupBufferPinWaitBufId;
+ pg_atomic_uint32 startupBufferPinWaitBufId;
} PROC_HDR;
extern PGDLLIMPORT PROC_HDR *ProcGlobal;
--
2.50.1 (Apple Git-155)
--Ot5x3ffkWEuxilWO
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0005-convert-Sharedsort-currentWorker-workersFinished-.patch
^ permalink raw reply [nested|flat] 35+ messages in thread
end of thread, other threads:[~2026-07-09 19:26 UTC | newest]
Thread overview: 35+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2023-08-28 05:38 [PATCH 1/2] Fix not-null constraint representation in \d+ Kyotaro Horiguchi <[email protected]>
2025-01-31 14:23 Commitfest app release on Feb 17 with many improvements Jelte Fennema-Nio <[email protected]>
2025-02-01 11:03 ` Re: Commitfest app release on Feb 17 with many improvements Jelte Fennema-Nio <[email protected]>
2025-02-03 20:12 ` Re: Commitfest app release on Feb 17 with many improvements Nathan Bossart <[email protected]>
2025-02-04 16:27 ` Re: Commitfest app release on Feb 17 with many improvements Álvaro Herrera <[email protected]>
2025-02-04 22:52 ` Re: Commitfest app release on Feb 17 with many improvements Jelte Fennema-Nio <[email protected]>
2025-02-18 21:15 ` Re: Commitfest app release on Feb 17 with many improvements Bruce Momjian <[email protected]>
2025-02-18 22:39 ` Re: Commitfest app release on Feb 17 with many improvements Jelte Fennema-Nio <[email protected]>
2025-02-19 00:25 ` Re: Commitfest app release on Feb 17 with many improvements Bruce Momjian <[email protected]>
2025-02-17 09:02 ` Re: Commitfest app release on Feb 17 with many improvements Jelte Fennema-Nio <[email protected]>
2025-02-17 21:33 ` Re: Commitfest app release on Feb 17 with many improvements Thomas Munro <[email protected]>
2025-02-17 23:38 ` Re: Commitfest app release on Feb 17 with many improvements Peter Geoghegan <[email protected]>
2025-02-17 23:46 ` Re: Commitfest app release on Feb 17 with many improvements Michael Paquier <[email protected]>
2025-02-18 22:57 ` Re: Commitfest app release on Feb 17 with many improvements Jelte Fennema-Nio <[email protected]>
2025-02-18 23:01 ` Re: Commitfest app release on Feb 17 with many improvements Jelte Fennema-Nio <[email protected]>
2025-02-20 04:16 ` Re: Commitfest app release on Feb 17 with many improvements Thomas Munro <[email protected]>
2025-02-20 09:53 ` Re: Commitfest app release on Feb 17 with many improvements Tatsuo Ishii <[email protected]>
2025-02-20 10:16 ` Re: Commitfest app release on Feb 17 with many improvements Thomas Munro <[email protected]>
2025-02-20 10:53 ` Re: Commitfest app release on Feb 17 with many improvements Jelte Fennema-Nio <[email protected]>
2025-02-20 11:22 ` Re: Commitfest app release on Feb 17 with many improvements Thomas Munro <[email protected]>
2025-03-06 15:35 ` Re: Commitfest app release on Feb 17 with many improvements vignesh C <[email protected]>
2025-03-06 16:00 ` Re: Commitfest app release on Feb 17 with many improvements Jelte Fennema-Nio <[email protected]>
2025-03-06 17:10 ` Re: Commitfest app release on Feb 17 with many improvements Tom Lane <[email protected]>
2025-03-06 17:39 ` Re: Commitfest app release on Feb 17 with many improvements Jelte Fennema-Nio <[email protected]>
2025-03-06 23:48 ` Re: Commitfest app release on Feb 17 with many improvements Jelte Fennema-Nio <[email protected]>
2025-03-07 03:08 ` Re: Commitfest app release on Feb 17 with many improvements Tom Lane <[email protected]>
2025-03-07 10:26 ` Re: Commitfest app release on Feb 17 with many improvements Andreas Karlsson <[email protected]>
2025-03-07 10:49 ` Re: Commitfest app release on Feb 17 with many improvements Jelte Fennema-Nio <[email protected]>
2025-03-07 16:42 ` Re: Commitfest app release on Feb 17 with many improvements Tom Lane <[email protected]>
2025-03-07 17:52 ` Re: Commitfest app release on Feb 17 with many improvements Jelte Fennema-Nio <[email protected]>
2025-03-07 17:57 ` Re: Commitfest app release on Feb 17 with many improvements Tom Lane <[email protected]>
2025-03-09 02:20 ` Re: Commitfest app release on Feb 17 with many improvements vignesh C <[email protected]>
2025-03-09 13:35 ` Re: Commitfest app release on Feb 17 with many improvements Jelte Fennema-Nio <[email protected]>
2025-03-11 03:47 ` Re: Commitfest app release on Feb 17 with many improvements vignesh C <[email protected]>
2026-07-09 19:26 [PATCH v1 4/8] convert PROC_HDR->startupBufferPinWaitBufId to an atomic Nathan Bossart <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox