Looks good. Some minor changes:
On 2024-May-22, Jonathan S. Katz wrote:
> ### Query and Operational Performance Improvements
>
> PostgreSQL 17 builds on recent releases and continues to improve performance
> across the entire system.
>
Hello,
Regarding this item
: Allow the SLRU cache sizes to be configured (Andrey Borodin, Dilip Kumar)
:
: The new server variables are commit_timestamp_buffers,
: multixact_member_buffers, multixact_offset_buffers, notify_buffers,
: serializable_buffers, subtransaction_buffers, and
On 2024-May-21, Andres Freund wrote:
> Which reminds me: Eventually I'd like to add links to the most important
> commits related to release note entries. We already do much of the work of
> building that list of commits for each entry. That'd allow a reader to find
> more details if interested.
On 2024-May-22, Dmitry Dolgov wrote:
> Yeah, that's a bummer. Interestingly enough, the db2 implementation of
> global session variables mechanism is mentioned as similar to what we
> have in the patch. But weirdly, the db2 documentation just states
> possibility of a resolution conflict for
On 2024-May-21, David Rowley wrote:
> I've attached 2 patches.
>
> 0001 is a simple revert of Tom's revert (7204f3591).
> 0002 fixes the issue reported by Hubert.
I would like to request that you don't keep 0001's message as you have
it here. It'd be more readable to take 66c0185a3d14's whole
On 2024-May-19, Tom Lane wrote:
> (The cfbot tends to discourage this, since as soon as one of the
> patches is committed it no longer knows how to apply the rest.
> Can we improve on that tooling somehow?)
I think a necessary next step to further improve the cfbot is to get it
integrated in
On 2024-May-16, David Rowley wrote:
> On Thu, 16 May 2024 at 17:37, zaidagilist wrote:
> > I am trying to open the 17 docs but it looks removed. Getting
> > following message "Page not found"
> >
> > https://www.postgresql.org/docs/17/
>
> It's called "devel" for "development" until we branch
On 2024-May-19, Jonathan S. Katz wrote:
> ### Query and Operational Performance Improvements
In this section I'd add mention the new GUCs to control SLRU memory
size, which is going to be a huge performance boon for cases where the
current fixed-size buffers cause bottlenecks. Perhaps something
On 2024-Jan-30, Dmitry Dolgov wrote:
> Yep, in this constellation the implementation holds much better (in
> terms of memory) in my create/let/drop testing.
>
> I've marked the CF item as ready for committer, but a note for anyone
> who would like to pick up it from here -- we're talking about
On 2024-May-17, Robert Haas wrote:
> Anyone else want to vote?
I had pretty much the same thought as you. It seems a waste to leave
the code in existing branches be slow only because we have a much better
approach for a branch that doesn't even exist yet.
--
Álvaro Herrera PostgreSQL
On 2024-May-17, Michael Paquier wrote:
> On Thu, May 16, 2024 at 11:57:10AM +0300, Aleksander Alekseev wrote:
> > I propose my original v1 patch for correcting the --help output of
> > 'postgres' too. I agree with the above comments that corresponding
> > changes in v4 became somewhat unwieldy.
>
On 2024-May-16, Sriram RK wrote:
> Hi Team,
>
> We have an update wrt to the PG17 AIX port.
>
> We have reverted the changes specific to AIX (that were removed in
> 0b16bb8776bb8) to the latest PG17 (head).
>
> The Buildfarm succeeded for these changes. All the tests passed.
Excellent.
>
On 2024-May-16, Peter Eisentraut wrote:
> I think we should accept your two patches
>
> v6-0001-GUC-names-docs.patch
> v6-0002-GUC-names-add-quotes.patch
>
> which effectively everyone was in favor of and which seem to be the most
> robust and sustainable solution.
I think we should also take
On 2024-May-14, Melanie Plageman wrote:
> On Tue, May 14, 2024 at 4:05 PM Alvaro Herrera
> wrote:
> > I do wonder how do we _know_ that the test is testing what it wants to
> > test:
> We include the explain output (the plan) to ensure it is still
> using a bi
Sorry to interject, but --
On 2024-May-15, Bharath Rupireddy wrote:
> It looks like with the use of the new multi insert table access method
> (TAM) for COPY (v20-0005), pgbench regressed about 35% [1].
Where does this acronym "TAM" comes from for "table access method"? I
find it thoroughly
On 2024-May-14, Bruce Momjian wrote:
> On Tue, May 14, 2024 at 03:39:26PM -0400, Melanie Plageman wrote:
> > I think that we need to more clearly point out the implications of the
> > feature added by Sawada-san (and reviewed by John) in 667e65aac35497.
> > Vacuum no longer uses a fixed amount
On 2024-May-14, Bruce Momjian wrote:
> Turns out these commits generated a single release note item, which I
> have now removed with the attached committed patch.
Hmm, but the commits about not-null constraints for domains were not
reverted, only the ones for constraints on relations. I think
On 2024-May-14, Alvaro Herrera wrote:
> BTW, I was running the explain while desultorily enabling and disabling
> these GUCs and hit this assertion failure:
>
> #4 0x55e6c72afe28 in ExceptionalCondition
> (conditionName=conditionName@entry=0x55e6c731a928
> "scan-&
On 2024-May-14, Tomas Vondra wrote:
> On 5/14/24 19:42, Melanie Plageman wrote:
>
> >>> +SET enable_indexonlyscan = off;
> >>> +set enable_indexscan = off;
> >>> +SET enable_seqscan = off;
> >>
> >> Nit: adjusting the casing of the second SET here.
> >
> > I've fixed this. I've also set
On 2024-May-14, Tom Lane wrote:
> I don't have a position on whether we want
> these additional files or not; but if we do, I think the best answer
> is to stick 'em under .github/ where they are out of the way but yet
> updatable by any committer.
+1 for .github/, that was my first reaction as
On 2024-May-14, Robert Haas wrote:
> On Tue, May 14, 2024 at 10:42 AM Alvaro Herrera
> wrote:
> > This had already been committed as 270af6f0df76 (the day before it was
> > sent to the next commitfest). This commit wasn't included in the
> > reverted set, though, so
On 2024-May-14, Robert Haas wrote:
> On Thu, Mar 7, 2024 at 12:32 PM Alvaro Herrera
> wrote:
> > On 2024-Mar-07, Alvaro Herrera wrote:
> > > Maybe we can add a flag RelationData->rd_ispkdeferred, so that
> > > RelationGetPrimaryKeyIndex returned InvalidOid for d
On 2024-May-14, Jakub Wartak wrote:
> On Sun, May 12, 2024 at 10:33 PM Peter Eisentraut
> wrote:
> > Don't production builds use debug
> > symbols nowadays as well?
>
> Reality is apparently mixed,at least from what I have checked :
> - all RHEL 7.x/8.x (PGDG and our forks) do NOT come with
>
On 2024-May-13, Robert Haas wrote:
> It seems to me that the practical thing to do about this problem is
> just decide not to solve it. I mean, it's currently the case that if
> you establish a PRIMARY KEY when you create a table, the columns of
> that key are marked NOT NULL and remain NOT NULL
On 2024-May-13, Robert Haas wrote:
> On Mon, May 13, 2024 at 9:44 AM Alvaro Herrera
> wrote:
> > The problematic point is the need to add NOT NULL constraints during
> > table creation that don't exist in the table being dumped, for
> > performance of primary
On 2024-May-13, Nathan Bossart wrote:
> > If we want to enhance the GitHub experience, we can also add these files to
> > the organization instead:
> > https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/creating-a-default-community-health-file
>
> This was
On 2024-May-13, Robert Haas wrote:
> On Sat, May 11, 2024 at 5:40 AM Alvaro Herrera
> wrote:
> > Specifically, the problem is that I mentioned that we could restrict the
> > NOT NULL NO INHERIT addition in pg_dump for primary keys to occur only
> > in
On 2024-May-09, Robert Haas wrote:
> Yeah, I have to admit that the ongoing bug fixing here has started to
> make me a bit nervous, but I also can't totally follow everything
> that's under discussion, so I don't want to rush to judgement.
I have found two more problems that I think are going to
On 2024-May-10, Alvaro Herrera wrote:
> Not sure what's going on here, or why it fails for me while the
> buildfarm is all happy.
Ah, I ran 'git clean -dfx' and now it works correctly. I must have had
an incomplete rebuild.
--
Álvaro Herrera PostgreSQL Developer —
On 2024-May-09, Michael Paquier wrote:
> Fix overread in JSON parsing errors for incomplete byte sequences
I'm getting this error in the new test:
t/002_inline.pl 1/?
# Failed test 'incomplete UTF-8 sequence, chunk size 3: correct error output'
# at t/002_inline.pl
On 2024-May-09, Robert Haas wrote:
> * not null constraints break dump/restore. I asked whether all of the
> issues had been addressed here and Justin Pryzby opined that the only
> thing that was still relevant for this release was a possible test
> case change, which I would personally consider
On 2024-May-07, Kyotaro Horiguchi wrote:
> Hello,
>
> At Wed, 1 May 2024 19:49:35 +0200, Alvaro Herrera
> wrote in
> > Here are two patches that I intend to push soon (hopefully tomorrow).
>
> This commit added and edited two error messages, resulting in using
>
On 2024-May-06, Justin Pryzby wrote:
> > (Do you really want the partition to be
> > created without the primary key already there?)
>
> Why not ? The PK will be added when I attach it one moment later.
>
> CREATE TABLE part (LIKE parent);
> ALTER TABLE parent ATTACH PARTITION part ...
Well,
On 2024-May-04, Alvaro Herrera wrote:
> On 2024-May-03, Justin Pryzby wrote:
>
> > But if it's created with LIKE:
> > postgres=# CREATE TABLE t1 (LIKE t);
> > postgres=# ALTER TABLE t ATTACH PARTITION t1 DEFAULT ;
> >
> > ..one also sees:
> >
> &
On 2024-May-06, David G. Johnston wrote:
> On Monday, May 6, 2024, Peter Burbery wrote:
>
> >
> > Business Use-case: I want to create a table named things_that_take_up_a_
> > lot_of_storage_and_space_on_a_computer_and_hard_drive of 75 characters. I
> > also want to create a column named
On 2024-May-03, Justin Pryzby wrote:
> But if it's created with LIKE:
> postgres=# CREATE TABLE t1 (LIKE t);
> postgres=# ALTER TABLE t ATTACH PARTITION t1 DEFAULT ;
>
> ..one also sees:
>
> Not-null constraints:
> "t1_i_not_null" NOT NULL "i"
Hmm, I think the problem here is not ATTACH;
Hello Alexander
On 2024-May-02, Alexander Lakhin wrote:
> Could you also clarify, please, how CREATE TABLE ... LIKE is expected to
> work with NOT NULL constraints?
It should behave identically to 16. If in 16 you end up with a
not-nullable column, then in 17 you should get a not-null
On 2024-Apr-25, Alvaro Herrera wrote:
> > Also, I've found a weird behaviour with a non-inherited NOT NULL
> > constraint for a partitioned table:
> > CREATE TABLE pt(a int NOT NULL NO INHERIT) PARTITION BY LIST (a);
> Ugh. Maybe a way to handle this is to disallow NO INH
On 2024-Apr-26, Tom Lane wrote:
> --- mk-one-release.orig 2024-04-23 17:30:08.983226671 -0400
> +++ mk-one-release2024-04-26 15:17:29.713669677 -0400
> @@ -39,13 +39,17 @@ mkdir pgsql
> git archive ${gitref} | tar xf - -C pgsql
>
> # Include the git ref in the output tarballs
> +#
On 2024-Apr-26, Jonathan S. Katz wrote:
> The Core Team would like to extend our congratulations to Melanie Plageman
> and Richard Guo, who have accepted invitations to become our newest
> PostgreSQL committers.
>
> Please join us in wishing them much success and few reverts!
May your commits
On 2024-Apr-25, Alexander Lakhin wrote:
> While studying the NO INHERIT option, I've noticed that the documentation
> probably misses it's specification for NOT NULL:
> https://www.postgresql.org/docs/devel/sql-createtable.html
>
> where column_constraint is:
> ...
> [ CONSTRAINT constraint_name
On 2024-Apr-24, Bruce Momjian wrote:
> I agree that targeting PG 18 for a new-er AIX port is the reasonable
> approach. If there is huge demand, someone can create an AIX fork for
> PG 17 using the reverted patches --- yeah, lots of pain there, but we
> have carried the AIX pain for too long
On 2024-Apr-22, Alvaro Herrera wrote:
> > On d9f686a72~1 this script results in:
> > ERROR: cannot change NO INHERIT status of inherited NOT NULL constraint
> > "t_a_not_null" on relation "t"
>
> Right. Now I'm beginning to wonder if allowi
On 2024-Apr-22, Tom Lane wrote:
> The main reason there's a delta is that people don't manage to
> maintain the in-tree copy perfectly (at least, they certainly
> haven't done so for this past year). So we need to do that
> to clean up every now and then.
Out of curiosity, I downloaded the
Hi Alexander,
On 2024-Apr-18, Alexander Lakhin wrote:
> 18.04.2024 16:39, Alvaro Herrera wrote:
> > I have pushed a fix which should hopefully fix this problem
> > (d9f686a72e). Please give this a look. Thanks for reporting the issue.
>
> Please look at an assertio
On 2024-Apr-18, Andrew Dunstan wrote:
> On 2024-04-18 Th 11:39, Alvaro Herrera wrote:
> It's not that hard to make it go back to 9.2. Here's a version that's a
> couple of years old, but it supports versions all the way back to 7.2 :-)
Hmm, so I tried grabbing the old-version module de
On 2024-Apr-19, Tender Wang wrote:
> The new patch looks good to me.
Thanks for looking once more. I have pushed it now. I didn't try
pg_upgrade other than running the tests, so maybe buildfarm member crake
will have more to complain about -- we'll see.
--
Álvaro Herrera
5471117953990656
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"La gente vulgar sólo piensa en pasar el tiempo;
el que tiene talento, en aprovecharlo"
>From 28393502b3d6fcf430264c10f931e948bedc Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: T
On 2024-Apr-18, Alexander Lakhin wrote:
> I think the feature implementation should also provide tab completion
> for SPLIT/MERGE.
I don't think that we should be imposing on feature authors or
committers the task of filling in tab-completion for whatever features
they contribute. I mean, if
On 2024-Apr-18, Justin Pryzby wrote:
> That seems like it could be important. I considered but never actually
> test your patch by pg_upgrading across major versions.
It would be a welcome contribution for sure. I've been doing it rather
haphazardly, which is not great.
> BTW, this works up
On 2024-Apr-18, Michael Paquier wrote:
> On Wed, Apr 17, 2024 at 10:31:52AM +0200, Alvaro Herrera wrote:
> > Hmm, maybe we should do a RESET of default_table_access_method before
> > printing the CREATE TABLE to avoid the confusion.
>
> A hard reset would make the busine
On 2024-Apr-18, Alvaro Herrera wrote:
> On 2024-Apr-18, Alvaro Herrera wrote:
>
> > Lastly, make two changes to pg_dump: 1) do not try to drop a not-null
> > constraint that's marked as inherited; this allows a dump to restore
> > with no errors if a table with a PK inh
On 2024-Apr-15, Justin Pryzby wrote:
> Here's a couple more issues affecting upgrades from v16 to v17.
>
> postgres=# CREATE TABLE a(i int NOT NULL); CREATE TABLE b(i int PRIMARY KEY)
> INHERITS (a);
> pg_restore: error: could not execute query: ERROR: constraint
>
On 2024-Jan-25, Andrew Bille wrote:
> Starting from b0e96f31, pg_upgrade fails with inherited NOT NULL constraint:
> For example upgrade from 9c13b6814a (or REL_12_STABLE .. REL_16_STABLE) to
> b0e96f31 (or master) with following two tables (excerpt from
> src/test/regress/sql/rules.sql)
>
>
3692928
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
>From e1b48c62ab46f6aaed366daacdd0560374b1cf07 Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: Wed, 17 Apr 2024 19:23:04 +0200
Subject: [PATCH v2] Fix restore of not-null constraints with inheritance
BTW if nothing else, this thread led me to discover a 18-month-old typo
in the Spanish translation of pg_dump:
-msgstr " --no-tablespaces no volcar métodos de acceso de tablas\n"
+msgstr " --no-table-access-method no volcar métodos de acceso de tablas\n"
Oops.
--
Álvaro
On 2024-Apr-17, Michael Paquier wrote:
> Yeah, that would be easy enough to track but I was wondering about
> adding the relkind instead. Still, one thing that I found confusing
> is the dump generated in this case, as it would mix the SET and the
> ALTER TABLE commands so one reading the dumps
On 2024-Apr-17, Alvaro Herrera wrote:
> Hmm, cannot we simply add a USING clause to the CREATE TABLE command for
> partitioned tables? That would override the
> default_table_access_method, so it should give the correct result, no?
Ah, upthread you noted that pg_restore-time --no-tab
On 2024-Apr-17, Michael Paquier wrote:
> 2) We could limit these extra ALTER TABLE commands to be generated for
> partitioned tables. This is kind of confusing as resulting dumps
> would mix SET commands for default_table_access_method that would
> affect tables with physical storage, while
On 2024-Apr-15, Justin Pryzby wrote:
> Here's a couple more issues affecting upgrades from v16 to v17.
>
> postgres=# CREATE TABLE a(i int NOT NULL); CREATE TABLE b(i int PRIMARY KEY)
> INHERITS (a);
> pg_restore: error: could not execute query: ERROR: constraint
>
On 2024-Apr-15, Alvaro Herrera wrote:
> - Fourth thought: we do as in the third thought, except we also allow
> DROP CONSTRAINT a constraint that's marked "local, inherited" to be
> simply an inherited constraint (remove its "local" marker).
Here is an ini
On 2024-Apr-15, Alvaro Herrera wrote:
> On 2024-Apr-15, Justin Pryzby wrote:
> > postgres=# CREATE TABLE iparent(id serial PRIMARY KEY); CREATE TABLE child
> > (id int) INHERITS (iparent); ALTER TABLE child ALTER id DROP NOT NULL;
> > ALTER TABLE child ADD CONSTRA
On 2024-Apr-15, Justin Pryzby wrote:
> 9b581c5341 can break dump/restore from old versions, including
> pgupgrade.
>
> postgres=# CREATE TABLE iparent(id serial PRIMARY KEY); CREATE TABLE child
> (id int) INHERITS (iparent); ALTER TABLE child ALTER id DROP NOT NULL; ALTER
> TABLE child ADD
(I think I had already argued this point, but I don't see it in the
archives, so here it is again).
On 2024-Feb-07, jian he wrote:
> if you place CommandCounterIncrement inside the `if (recurse)` branch,
> then the regression test will be ok.
Yeah, but don't you think this is too magical? I
On 2024-Apr-13, Bharath Rupireddy wrote:
> It looks like there's missing ConditionVariableCancelSleep() in
> InvalidatePossiblyObsoleteSlot() after waiting for the replication
> slot to be released by another process. Although prepare to sleep
> cancels the sleep if the previous one wasn't
On 2024-Apr-12, jian he wrote:
> Now I am more confused...
> +CREATE TABLE notnull_tbl1 (c0 int, c1 int, PRIMARY KEY (c0, c1));
> +ALTER TABLE notnull_tbl1 DROP c1;
> same query, mysql make let "c0" be not null
Yes, that was Postgres' old model. But the way we think of it now, is
that a
On 2024-Apr-11, Alvaro Herrera wrote:
> Well, I think you were right that we should try to handle the situation
> of unmarking attnotnull as much as possible, to decrease the chances
> that the problematic situation occurs. That means, we can use the
> earlier code to handle DROP
On 2024-Apr-11, jian he wrote:
> now I figured out that
> dropping a column of primary key columns will not change other key
> columns' "not null" property.
> dropping the primary key associated constraint will make all key
> columns "not null" property disappear.
Well, I think you were right
On 2024-Apr-10, Alvaro Herrera wrote:
> One thing missing here is pg_dump support. If you just dump this table,
> it'll end up with no constraint at all. That's obviously bad, so I
> propose we have pg_dump add a regular NOT NULL constraint for those, to
> avoid perpetuating the wei
9c Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: Wed, 10 Apr 2024 13:02:35 +0200
Subject: [PATCH] Handle ALTER .. DROP NOT NULL when no pg_constraint row
exists
---
src/backend/commands/tablecmds.c | 67 +++
src/test/regress/expected/constra
On 2024-Apr-10, jian he wrote:
> another related bug, in master.
>
> drop table if exists notnull_tbl1;
> CREATE TABLE notnull_tbl1 (c0 int not null, c1 int);
> ALTER TABLE notnull_tbl1 ADD CONSTRAINT Q PRIMARY KEY(c0, c1);
> \d+ notnull_tbl1
> ALTER TABLE notnull_tbl1 ALTER c0 DROP NOT NULL;
>
On 2024-Apr-10, Tender Wang wrote:
> Yeah, it should fail as before, because c0 is primary key.
> In master, although c0's pg_attribute.attnotnull is still true, but its
> not-null constraint has been deleted
> in dropconstraint_internal().
Yeah, the problem here is that we need to do the checks
"Tiene valor aquel que admite que es un cobarde" (Fernandel)
>From 397d424cd64020bcb4aff219deefca7fc7b6f88d Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: Tue, 9 Apr 2024 19:18:57 +0200
Subject: [PATCH] Correctly reset attnotnull when constraints dropped
indirectly
On 2024-Apr-09, Stefan Fercot wrote:
> At some point, the only way to really validate a backup is to actually try to
> restore it.
> And if people get encouraged to do that faster thanks to incremental backups,
> they could detect potential issues sooner.
> Ultimately, users will still need
On 2024-Apr-08, Robert Haas wrote:
> And maybe we need to think of a way to further mitigate this crush of
> last minute commits. e.g. In the last week, you can't have more
> feature commits, or more lines of insertions in your commits, than you
> did in the prior 3 weeks combined. I don't know.
On 2024-Apr-07, Jeff Davis wrote:
> On Sun, 2024-04-07 at 14:19 +0200, Alvaro Herrera wrote:
> > I pushed the "copy" pointer now, except that I renamed it to
> > "insert",
> > which is what we call the operation being tracked. I also added some
> >
On 2024-Feb-03, Andrey M. Borodin wrote:
> Here's the test draft. This test reliably reproduces sleep on CV when waiting
> next multixact to be filled into "members" SLRU.
> Cost of having this test:
> 1. We need a new injection point type "wait" (in addition to "error" and
> "notice"). It
I pushed the "copy" pointer now, except that I renamed it to "insert",
which is what we call the operation being tracked. I also added some
comments.
One perhaps significant change from what Bharath submitted is that we
now use the return value from monotonic advance to return an updated
value
On 2024-Apr-05, Jeff Davis wrote:
> Minor comments:
> * Also, I assume that the Max() call in
> pg_atomic_monotonic_advance_u64() is just for clarity? Surely the
> currval cannot be less than _target when it returns. I'd probably just
> do Assert(currval >= _target) and then return currval.
Uhh
Hello,
BTW I noticed that
https://coverage.postgresql.org/src/backend/commands/waitlsn.c.gcov.html
says that lsn_cmp is not covered by the tests. This probably indicates
that the tests are a little too light, but I'm not sure how much extra
effort we want to spend.
I'm still concerned that
On 2024-Apr-05, Regina Obe wrote:
> I think it ends up doing a copy thus the copy error in my log failures which
> don't exist anywhere in the Makefil
>
> cp -pR ../../backend/storage/lmgr/lwlocknames.h
>
> Sorry for not checking on a linux system. I was thinking I should have done
> that
Pushed 0001. Here's the patch that adds the Copy position one more
time, with the monotonic_advance function returning the value.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
>From 3f5c860576245b92701e7bfc517947c418c68510 Mon Sep 17 00:00:00 2001
From: Alv
On 2024-Apr-04, Regina Obe wrote:
> I think I got something not too far off from what's there now that works
> under my msys2 setup again. This is partly using your idea of using
> $(top_builddir) to qualify the path but in the LN_S section that is causing
> me grief.
> This seems to work
to the people who use me," said XML.
https://burningbird.net/the-parable-of-the-languages/
>From 2164778b74681910544a64ba6c2ae36e5204ed9e Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: Fri, 5 Apr 2024 13:21:39 +0200
Subject: [PATCH v16 1/2] Make XLogCtl->log{Write,Flush}Result ac
On 2024-Apr-05, Bharath Rupireddy wrote:
> 1.
> /*
> * Update local copy of shared XLogCtl->log{Write,Flush}Result
> + *
> + * It's critical that Flush always trails Write, so the order of the reads is
> + * important, as is the barrier.
> */
> #define RefreshXLogWriteResult(_target) \
>
://postgr.es/m/202203221611.hqbjdinzsbu2@alvherre.pgsql
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
>From f791c7ee9815871a1843116febffc0077d29a9a3 Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: Wed, 3 Apr 2024 11:48:27 +0200
Subject: [PATCH v16 1/2] M
On 2024-Apr-04, Peter Eisentraut wrote:
> But I don't really see the point of this. The information you are querying
> is already available in various system views. This proposal is just a
> shorthand for a collection of various random things some people like to see.
> Like, by what reason is
https://www.EnterpriseDB.com/
>From 0af8c7039b2c8ed80bc0bddacfe4a9abb8f527b3 Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: Thu, 4 Apr 2024 10:13:07 +0200
Subject: [PATCH] Make libpqsrv_cancel's return type const char *
---
contrib/dblink/dblink.c | 2 +-
contrib/postgres_
On 2024-Apr-03, Bharath Rupireddy wrote:
> On Wed, Apr 3, 2024 at 4:49 PM Alvaro Herrera wrote:
> > So what I do in the attached 0001 is stop using the XLogwrtResult struct
> > in XLogCtl and replace it with separate Write and Flush values, and add
> > the macro XLogUp
Hi Regina,
On 2024-Mar-27, Regina Obe wrote:
> The error is
>
> rm -f '../../src/include/storage/lwlocknames.h'
> cp -pR ../../backend/storage/lmgr/lwlocknames.h
> '../../src/include/storage/lwlocknames.h'
> cp: cannot stat '../../backend/storage/lmgr/lwlocknames.h': No such file or
>
//www.EnterpriseDB.com/
"World domination is proceeding according to plan"(Andrew Morton)
>From 4079dc6a6a6893055b32dee75f178b324bbaef77 Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: Wed, 3 Apr 2024 18:35:15 +0200
Subject: [PATCH] Use an LWLock instead of a spinlock in wai
On 2024-Apr-03, Dilip Kumar wrote:
> Yeah, we missed acquiring the bank lock w.r.t. intervening pages,
> thanks for reporting. Your fix looks correct to me.
Thanks for the quick review! And thanks to Alexander for the report.
Pushed the fix.
--
Álvaro Herrera PostgreSQL Developer —
s" (Nicanor Parra)
>From 44c39cf4bf258fb0b65aa1acc5f84e5d7f729eb1 Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: Wed, 3 Apr 2024 16:00:24 +0200
Subject: [PATCH] Fix zeroing of pg_serial page without SLRU bank lock
---
src/backend/storage/lmgr/predicate.c | 19 ---
1 fi
On 2024-Apr-03, Alvaro Herrera wrote:
> So what I do in the attached 0001 is stop using the XLogwrtResult struct
> in XLogCtl and replace it with separate Write and Flush values, and add
> the macro XLogUpdateLocalLogwrtResult() that copies the values of Write
> and Flush from the sh
nal systems: you end up with a whole raft of programmers, none of
whom has had a Date with the clue stick." (Andrew Sullivan)
https://postgr.es/m/20050809113420.gd2...@phlogiston.dyndns.org
>From e6ddbe87d598c6a1090e39845a4a308060f0af1e Mon Sep 17 00:00:00 2001
From: Alvaro He
On 2024-Apr-02, David E. Wheeler wrote:
> That quotation comes from this Debian patch[2] maintained by Christoph
> Berg. I’d like to formally propose integrating this patch into the
> core. And not only because it’s overhead for package maintainers like
> Christoph, but because a number of use
Hello, I noticed that commit 06c418e163e9 uses waitLSN->mutex (a
spinlock) to protect the contents of waitLSN -- and it's used to walk an
arbitrary long list of processes waiting ... and also, an arbitrary
number of processes could be calling this code. I think using a
spinlock for this is
On 2024-Apr-02, Nathan Bossart wrote:
> Another idea I had is to turn pg_popcount() into a macro that just uses the
> pg_number_of_ones array when called for few bytes:
>
> static inline uint64
> pg_popcount_inline(const char *buf, int bytes)
> {
> uint64
Hello
Yeah, that's what I meant about the translations, thanks.
Two more comments,
- You don't need a two-level conditional here
if (pset.sversion >= 90500)
{
if (pset.sversion < 14)
appendPQExpBuffer(,
On 2024-Mar-31, Nathan Bossart wrote:
> +uint64
> +pg_popcount_avx512(const char *buf, int bytes)
> +{
> + uint64 popcnt;
> + __m512i accum = _mm512_setzero_si512();
> +
> + for (; bytes >= sizeof(__m512i); bytes -= sizeof(__m512i))
> + {
> + const
1 - 100 of 5351 matches
Mail list logo
