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
On 2024-Mar-31, Maiquel Grassi wrote:
> Yes Álvaro, I have already appointed you as the patch reviewer.
> It's true, even before publishing it on Commifest, you have
> already provided good ideas and guidance.
Thanks.
> I adjusted the translation syntax for the SSL and GSSAPI columns.
> After
Hello,
Note that, in the patch as posted, the column names are not
translatable. In order to be translatable, the code needs to do
something like
appendPQExpBuffer(,
" NULL AS \"%s\",\n"
" NULL AS \"%s\",\n"
" NULL AS \"%s\",\n"
Due to commit 61461a300c1c, this patch needs to be reworked.
--
Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
"La fuerza no está en los medios físicos
sino que reside en una voluntad indomable" (Gandhi)
On 2024-Mar-28, Amonson, Paul D wrote:
> > -Original Message-
> > From: Nathan Bossart
> > Sent: Thursday, March 28, 2024 2:39 PM
> > To: Amonson, Paul D
> >
> > * The latest patch set from Paul Amonson appeared to support MSVC in the
> > meson build, but not the autoconf one. I
On 2024-Mar-28, Tom Lane wrote:
> Jelte Fennema-Nio writes:
>
> > I think we don't really want to make the timeout too short. Otherwise
> > the query might get cancelled before we push any query down to the
> > FDW. I guess that means that for some slow machines even 10ms is not
> > enough to
On 2024-Mar-28, Amit Langote wrote:
> Here's patch 1 for the time being that implements barebones
> JSON_TABLE(), that is, without NESTED paths/columns and PLAN clause.
> I've tried to shape the interfaces so that those features can be added
> in future commits without significant rewrite of the
On 2024-Mar-28, Jelte Fennema-Nio wrote:
> Ugh that's annoying, the RESET is timing out too I guess.
Hah, you're right, I can reproduce with a smaller timeout, and using SET
LOCAL works as a fix. If we're doing that, why not reduce the timeout
to 1ms? We don't need to wait extra 9ms ...
--
Eh, kestrel has also failed[1], apparently every query after the large
JOIN that this commit added as test fails with a statement timeout error.
[1]
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=kestrel=2024-03-28%2016%3A01%3A14
--
Álvaro Herrera 48°01'N 7°57'E —
On 2024-Mar-26, Justin Pryzby wrote:
> Looks right. That's how I originally wrote it, except for the
> "stmt->accessMethod != NULL" case.
>
> I prefered my way - the grammar should refuse to set stmt->accessMethod
> for inappropriate relkinds. And you could assert that.
Hmm, I didn't like
On 2024-Mar-28, Alvaro Herrera wrote:
> Undefined symbols for architecture arm64:
> "_libintl_gettext", referenced from:
> _libpqsrv_cancel in dblink.o
> _libpqsrv_cancel in dblink.o
> ld: symbol(s) not found for architecture arm64
> clang: error: lin
Hm, indri failed:
ccache gcc -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Werror=vla -Werror=unguarded-availability-new
-Wendif-labels -Wmissing-format-attribute -Wcast-function-type
-Wformat-security -fno-strict-aliasing -fwrapv
-Wno-unused-command-line-argument
On 2024-Mar-28, Jelte Fennema-Nio wrote:
> Your changes look good, apart from the prverror stuff indeed. If you
> remove the prverror stuff again I think this is ready to commit.
Great, thanks for looking. Pushed now, I'll be closing the commitfest
entry shortly.
--
Álvaro Herrera
On 2024-Mar-28, Tender Wang wrote:
> RemoveConstraintById() should think recurse(e.g. partition table)? I'm not
> sure now.
> If we should think process recurse in RemoveConstraintById(), the
> function will look complicated than before.
No -- this function handles just a single constraint,
On 2024-Mar-27, Alvaro Herrera wrote:
> I changed it so that the error messages are returned as translated
> phrases, and was bothered by the fact that if errors happen repeatedly,
> the memory for them might be leaked. Maybe this is fine depending on
> the caller's memory contex
On 2024-Mar-22, Jelte Fennema-Nio wrote:
> On Thu, 21 Mar 2024 at 03:54, Noah Misch wrote:
> >
> > On Mon, Mar 18, 2024 at 07:40:10PM +0100, Alvaro Herrera wrote:
> > > I enabled the test again and also pushed the changes to dblink,
> > > isolationtester a
On 2024-Mar-26, Nathan Bossart wrote:
> FWIW I'd really prefer to have something like max_slot_xid_age for this. A
> time-based parameter would likely help with most cases, but transaction ID
> usage will vary widely from server to server, so it'd be nice to have
> something to protect against
On 2024-Mar-26, Tender Wang wrote:
> postgres=# CREATE TABLE t1(c0 int, c1 int);
> postgres=# ALTER TABLE t1 ADD CONSTRAINT Q PRIMARY KEY(c0, c1);
> postgres=# ALTER TABLE t1 DROP c1;
>
> postgres=# ALTER TABLE t1 ALTER c0 DROP NOT NULL;
> ERROR: could not find not-null constraint on column
On 2024-Mar-26, Alexander Lakhin wrote:
> Hello Alvaro,
>
> 21.03.2024 15:07, Alvaro Herrera wrote:
> > Given that Michaël is temporarily gone, I propose to push the attached
> > tomorrow.
>
> Please look at a new anomaly introduced with 374c7a229.
> Starting f
On 2024-Mar-26, Amit Kapila wrote:
> On Tue, Mar 26, 2024 at 1:09 PM Alvaro Herrera
> wrote:
> > On 2024-Mar-26, Amit Kapila wrote:
> > > I would also like to solicit your opinion on the other slot-level
> > > parameter we are planning to introduce.
On 2024-Mar-26, Amit Kapila wrote:
> We have a consensus on inactive_since, so I'll make that change.
Sounds reasonable. So this is a timestamptz if the slot is inactive,
NULL if active, right? What value is it going to have for sync slots?
> I would also like to solicit your opinion on the
On 2024-Mar-25, Dean Rasheed wrote:
> Also (not this patch's fault), psql doesn't seem to offer a way to
> display domain constraint names -- something you need to know to drop
> or alter them. Perhaps \dD+ could be made to do that?
Ooh, I remember we had offered a patch for \d++ to display
On 2024-Mar-21, Robert Haas wrote:
> On Thu, Mar 21, 2024 at 9:38 AM Tom Lane wrote:
> > I'd follow the extend.sgml precedent: have a file corresponding to the
> > chapter and containing any top-level text we need, then that includes
> > a file per sect1.
>
> OK, here's a new patch set. I've
On 2024-Mar-21, Sriram RK wrote:
> Hello Team,
>
> We are working on AIX systems and noticed that the thread on removing AIX
> support in Postgres going forward.
>
> https://github.com/postgres/postgres/commit/0b16bb8776bb834eb1ef8204ca95dd7667ab948b”
>
> We would be glad to understand any
Given that Michaël is temporarily gone, I propose to push the attached
tomorrow.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
really, I see PHP as like a strange amalgamation of C, Perl, Shell
inflex: you know that "amalgam" means "mixture with mercury",
On 2024-Mar-12, Dean Rasheed wrote:
> While playing around with EXPLAIN and SubPlans, I noticed that there's
> a bug in how this is handled for MERGE. [...]
> However, that isn't working properly for MERGE because the inner_plan
> and inner_tlist of the corresponding deparse_namespace aren't set
On 2024-Mar-20, Robert Haas wrote:
> 0003 merges all of the "Internals" chapters whose names are the names
> of built-in index access methods (Btree, Gin, etc.) into a single
> chapter called "Built-In Index Access Methods". All of these chapters
> have a very similar structure and none of them
On 2024-Mar-19, Tom Lane wrote:
> The bit about "(Not meaningful if the relation has no on-disk file.)"
> is not correct, and now it's adjacent to text that contradicts it.
> Maybe more like
>
>The tablespace in which this relation is stored.
>If zero, the database's default
://postgr.es/m/202403191013.w2kr7wqlamqz@alvherre.pgsql
--
Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
>From fe4d53f33c688ab3ff132964bf42ba5fc8cdaa6e Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: Tue, 19 Mar 2024 09:49:46 +0100
Subject: [PATCH] Rev
On 2024-Mar-19, Alvaro Herrera wrote:
> 0001 is Michaël's patch, 0002 are my proposed changes.
Doh, I sent the wrong set of attachments. But I see no reason to post
again: what I attached as 0001 is what I wrote was going to be 0002,
Michaël's patch is already in archives, and the CI te
sgau, Deutschland — https://www.EnterpriseDB.com/
"Hay que recordar que la existencia en el cosmos, y particularmente la
elaboración de civilizaciones dentro de él no son, por desgracia,
nada idílicas" (Ijon Tichy)
>From 8b4408ac6cc46af2257e9c613d95a0eb38238a8e Mon Sep 17 00:00:00 2001
From: Alvaro Herrer
On 2024-Mar-18, Peter Eisentraut wrote:
> * src/bin/pg_basebackup/pg_createsubscriber.c
>
> I think the connection string handling is not robust against funny
> characters, like spaces, in database names etc.
Maybe it would be easier to deal with this by passing around a struct
with
I enabled the test again and also pushed the changes to dblink,
isolationtester and fe_utils (which AFAICS is used by pg_dump,
pg_amcheck, reindexdb and vacuumdb). I chickened out of committing the
postgres_fdw changes though, so here they are again. Not sure I'll find
courage to get these done
On 2024-Mar-16, Wolfgang Walther wrote:
> The upstream name for the ossp-uuid package / pkg-config file is "uuid". Many
> distributions change this to be "ossp-uuid" to not conflict with e2fsprogs.
I can confirm that this is true for Debian, at least; the packaging
rules have this in
On 2023-Aug-28, Michael Paquier wrote:
> I have looked again at that, and switching wait_event_names.txt to use
> two columns made of the typedef definitions and the docs like is not a
> problem:
> FOO_BAR "Waiting on Foo Bar."
>
> WAIT_EVENT_ is appended to the typedef definitions in the
On 2024-Mar-17, Bharath Rupireddy wrote:
> I think the code can be simplified a bit by using
> SplitIdentifierString like in the attached patch. With this,
> backtrace_function_list variable and assign_backtrace_functions() will
> go away.
Did you read the discussion that led to the current
On 2024-Mar-14, Tom Lane wrote:
> Michael Paquier writes:
> > Hmm. I am not sure how much protection this would offer, TBH. One
> > thing that I find annoying with common/stringinfo.c as it is currently
> > is that we have two exit() calls in the enlarge path, and it does not
> > seem wise to
On 2024-Mar-14, Shlok Kyal wrote:
> Andrew Atkinson wrote:
>
> > Anyway, hopefully these examples show “node” and “database” are
> > mixed and perhaps others agree using one consistently might help the
> > goals of the docs.
>
> For me the existing content looks good, I felt let's keep it as it
On 2024-Mar-13, Dean Rasheed wrote:
> On Wed, 13 Mar 2024 at 06:44, jian he wrote:
> >
> >
> > [ WITH with_query [, ...] ]
> > MERGE INTO [ ONLY ] >
> > here the "WITH" part should have "[ RECURSIVE ]"
>
> Actually, no. MERGE doesn't support WITH RECURSIVE.
>
> It's not entirely clear to me
On 2024-Mar-14, Peter Eisentraut wrote:
> Perhaps it would make sense if we change the ALTER TABLE command to be like
>
> ALTER TABLE t1 ADD IF NOT EXISTS NOT NULL c1
>
> Then the behavior is like one would expect.
>
> For ALTER TABLE, we would reject this command if IF NOT EXISTS is not
>
On 2024-Mar-14, Jelte Fennema-Nio wrote:
> On Wed, 13 Mar 2024 at 20:08, Jacob Champion
> wrote:
> > I hit this on my machine. With the attached diff I can reproduce
> > constantly (including with the most recent test patch); I think the
> > cancel must be arriving between the bind/execute
On 2024-Mar-13, Jelte Fennema-Nio wrote:
> I agree it's probably a timing issue. The cancel being received after
> the query is done seems very unlikely, since the query takes 180
> seconds (assuming PG_TEST_TIMEOUT_DEFAULT is not lowered for these
> animals). I think it's more likely that the
About 0002:
I think we should just drop it. Look at the changes it produces in the
plans for aliases XMLTABLE:
> @@ -1556,7 +1556,7 @@ SELECT f.* FROM xmldata, LATERAL
> xmltable('/ROWS/ROW[COUNTRY_NAME="Japan" or COU
> Output: f."COUNTRY_NAME", f."REGION_ID"
> -> Seq Scan on
On 2024-Mar-12, Alvaro Herrera wrote:
> Hmm, buildfarm member kestrel (which uses
> -fsanitize=undefined,alignment) failed:
>
> # Running: libpq_pipeline -r 700 cancel port=49975 host=/tmp/dFh46H7YGc
> dbname='postgres'
> test cancellations...
> libpq_pipeline:260: qu
Hmm, buildfarm member kestrel (which uses
-fsanitize=undefined,alignment) failed:
# Running: libpq_pipeline -r 700 cancel port=49975 host=/tmp/dFh46H7YGc
dbname='postgres'
test cancellations...
libpq_pipeline:260: query did not fail when it was expected
On 2024-Mar-12, Jeff Davis wrote:
> Do not use perl empty patterns like // or qr// or s//.../, the behavior
> is too surprising for perl non-experts.
Yeah, nasty.
> There are a few such uses in
> our tests; patch attached. Unfortunately, there is no obvious way to
> automatically detect them so
On 2024-Mar-12, Jelte Fennema-Nio wrote:
> On Tue, 12 Mar 2024 at 10:19, Alvaro Herrera wrote:
> > Here's a last one for the cfbot.
>
> Thanks for committing the first 3 patches btw. Attached a tiny change
> to 0001, which adds "(backing struct for PGcanc
Aurelius, Meditations)
>From fc0cbf0a6184d374e12e051f88f9f8eef7cc30d9 Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: Tue, 12 Mar 2024 10:09:25 +0100
Subject: [PATCH v34 1/2] libpq: Add encrypted and non-blocking query
cancellation routines
The existing PQcancel API uses blocking IO, which makes PQcanc
On 2024-Mar-01, Euler Taveira wrote:
> I don't like to break backward compatibility but in this case I suspect that
> it
> is ok. I don't recall the last time I saw a script that makes use of -d
> option.
> How often do you need a pgbench debug information?
I wondered what the difference
On 2024-Mar-11, Shruthi Gowda wrote:
> *CASE 2:*
> --
> SELECT * FROM JSON_TABLE(jsonb '{
> "id" : 901,
> "age" : 30,
> "*FULL_NAME*" : "KATE DANIEL"}',
> '$'
> COLUMNS(
> FULL_NAME varchar(20),
>
On 2024-Mar-01, Tristan Partin wrote:
> On Fri Mar 1, 2024 at 8:00 AM CST, Alvaro Herrera wrote:
> > I'm pretty disappointed of not being able to remove
> > generate-lwlocknames.pl (it now generates the .h, no longer the .c
> > file), but I can't find a way to do the equiv
On 2024-Mar-08, Stephen Frost wrote:
> Thanks for testing! That strikes me as perfectly reasonable and seems
> unlikely that we'd get much benefit from parallelizing it, so I'd say it
> makes sense to keep this code simple.
Okay, agreed, that amount of time sounds reasonable to me too; but I
On 2024-Mar-08, Bharath Rupireddy wrote:
> This works only if '* 'is specified as the only one character in
> backtrace_functions = '*', right? If yes, what if someone sets
> backtrace_functions = 'foo, bar, *, baz'?
It throws an error, as expected. This is a useless waste of resources:
On 2024-Feb-16, Antonin Houska wrote:
> BTW, I'm failing to understand why cluster_rel() has no argument of the
> BufferAccessStrategy type. According to buffer/README, the criterion for using
> specific strategy is that page "is unlikely to be needed again
> soon". Specifically for
On 2024-Mar-04, Amonson, Paul D wrote:
> > -#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
> > +#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31)
> > +<< 31))
> >
> > IME this means that the autoconf you are using has been patched. A
> > quick search on the
On 2024-Mar-07, Alvaro Herrera wrote:
> Maybe we can add a flag RelationData->rd_ispkdeferred, so that
> RelationGetPrimaryKeyIndex returned InvalidOid for deferrable PKs; then
> logical replication would continue to not know about this PK, which
> perhaps is what we want. I'll
On 2024-Mar-07, Dean Rasheed wrote:
> On Thu, 7 Mar 2024 at 13:00, Alvaro Herrera wrote:
> >
> > So I think the original developers of REPLICA IDENTITY had the right
> > idea here (commit 07cacba983ef), and we mustn't change this aspect,
> > because it'll lead to dat
On 2024-Mar-07, Tomas Vondra wrote:
> I was experimenting with the v42 patches, and I think the handling of ON
> EMPTY / ON ERROR clauses may need some improvement.
Well, the 2023 standard says things like
::=
JSON_VALUE
[ ]
[ ON EMPTY ]
[ ON ERROR ]
which
On 2024-Mar-05, Dean Rasheed wrote:
> So I think RelationGetIndexAttrBitmap() should include deferrable PKs,
I tried this, but it doesn't actually lead to a good place, because if
we allow deferrable PKs to identify rows, then they are not useful to
find the tuple to update when replicating.
Docs: one bogus "that that".
Did we consider having PQcancelConn() instead be called
PQcancelCreate()? I think this better conveys that what we're doing is
create an object that can be used to do something, and that nothing else
is done with it by default. Also, the comment still says
Hello,
I suppose this is important to do if we ever want to move SLRUs into
shared buffers. However, I wonder about the extra time this adds to
pg_upgrade. Is this something we should be concerned about? Is there
any measurement/estimates to tell us how long this would be? Right now,
if you
On 2024-Mar-06, Thomas Munro wrote:
> Even on the heap, 16GB is too much to assume we can allocate during a
> base backup. I don't claim that's a real-world problem for
> incremental backup right now in master, because I don't have any
> evidence that anyone ever really uses --with-segsize (do
On 2024-Mar-06, Daniel Gustafsson wrote:
> Good catch, that's an incorrect copy/paste, it should use ERRCODE_NO_DATA.
> I'm
> not convinced that a function to read from a pipe should consider not reading
> anything successful by default, output is sort expected here. We could add a
> flag
the idea I proposed? That was:
> On Thu, Feb 29, 2024 at 4:05 PM Alvaro Herrera
> wrote:
> > I think we should tighten this up: an asterisk should be allowed
> > only if it appears alone in the string (short-circuiting
> > check_backtrace_functions before strspn); and let
On 2024-Mar-05, Dean Rasheed wrote:
> Looking at the other places that call RelationGetIndexAttrBitmap()
> with INDEX_ATTR_BITMAP_PRIMARY_KEY, they all appear to want to include
> deferrable PKs, since they are relying on the result to see which
> columns are not nullable.
Hmm, I find this
On 2024-Mar-05, Jeff Davis wrote:
> Fix search_path to a safe value during maintenance operations.
>
> While executing maintenance operations (ANALYZE, CLUSTER, REFRESH
> MATERIALIZED VIEW, REINDEX, or VACUUM), set search_path to
> 'pg_catalog, pg_temp' to prevent inconsistent behavior.
>
>
nd — https://www.EnterpriseDB.com/
"La persona que no quería pecar / estaba obligada a sentarse
en duras y empinadas sillas/ desprovistas, por cierto
de blandos atenuantes" (Patricio Vogel)
>From cc7032c3f62949d20bc98d4b3c70cb2cb8a0dd5e Mon Sep 17 00:00:00 2001
F
On 2024-Mar-04, Tom Lane wrote:
> In hopes of noticing whether there are other similar thinkos,
> I permuted the order of the SlruPageStatus enum values, and
> now I get the expected warnings from gcc:
Thanks for checking! I pushed the fixes.
Maybe we should assign a nonzero value (= 1) to the
On 2024-Mar-05, Hayato Kuroda (Fujitsu) wrote:
> Basically sounds good. My concerns are:
>
> * GetNamedDSMSegment() does not returns a raw pointer to dsm_segment. This
> means
> that it may be difficult to do dsm_unpin_segment on the caller side.
Maybe we don't need a "named" DSM segment at
It's stable, clean and elegant, and lightning fast as well,
And it doesn't cost a nickel, so Bill Gates can go to hell."
>From ecf613092a3cbc4c5112d30af7eea55b668decec Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: Mon, 4 Mar 2024 11:49:01 +0100
Subject: [PATCH v3] Rework r
right, do not do it.
If it is not true, do not say it." (Marcus Aurelius, Meditations)
>From a6be7cac5de83a36e056147f3e81bea2eb1096bd Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: Sun, 3 Mar 2024 15:20:36 +0100
Subject: [PATCH v2 1/3] rework locking code in GetMultiXactIdMembers
Per Cove
On 2024-Mar-04, Erik Rijkers wrote:
> In my hands (applying with patch), the patches, esp. 0001, do not apply.
> But I see the cfbot builds without problem so maybe just ignore these FAILED
> lines. Better get them merged - so I can test there...
It's because of dbbca2cf299b. It should apply
Hello Hayato,
On 2024-Mar-04, Hayato Kuroda (Fujitsu) wrote:
> OK, I understood that my initial proposal is not so valuable, so I can
> withdraw it.
Yeah, that's what it seems to me.
> About the suggetion, you imagined AutoVacuumRequestWork() and
> brininsert(), right?
Correct.
> I agreed it
On 2024-Mar-04, Hayato Kuroda (Fujitsu) wrote:
> However, the second idea is still valid, which allows the allocation
> of shared memory dynamically. This is a bit efficient for the system
> which tuples won't be frozen. Thought?
I think it would be worth allocating AutoVacuumShmem->av_workItems
On 2024-Mar-04, Hayato Kuroda (Fujitsu) wrote:
> Dear hackers,
>
> While reading codes, I found that ApplyLauncherShmemInit() and
> AutoVacuumShmemInit() are always called even if they would not be
> launched.
Note that there are situations where the autovacuum launcher is started
even though
On 2024-Feb-28, Alvaro Herrera wrote:
> Improve performance of subsystems on top of SLRU
Coverity had the following complaint about this commit:
*** CID NNN: Control flow iss
On 2024-Feb-29, Alvaro Herrera wrote:
> On 2024-Feb-29, Kyotaro Horiguchi wrote:
> > Some of them, commit_timestamp_buffers, transaction_buffers,
> > subtransaction_buffers use 0 to mean auto-tuning based on
> > shared-buffer size. I think it's worth adding an
On 2024-Feb-23, Heikki Linnakangas wrote:
> On 12/02/2024 19:01, Tristan Partin wrote:
> > On Wed Jan 24, 2024 at 8:09 AM CST, Alvaro Herrera wrote:
> > > IMO it would be less ugly to have the origin file lwlocknames.txt be
> > > not a text file but a .h with
On 2024-Feb-29, Tom Lane wrote:
> I agree that perminfoindex seems to have suffered from add-at-the-end
> syndrome, and if we do touch the field order you made an improvement
> there. (BTW, who thought they needn't bother with a comment for
> perminfoindex?)
There is a comment for it, or at
aminsert is called, then
aminsertcleanup must be called afterwards, period.
> On 1/8/24 16:51, Alvaro Herrera wrote:
> > So I think we should do 0001 and perhaps some further tweaks to the
> > original brininsert optimization commit: I think the aminsertcleanup
> > callback sh
On 2024-Feb-29, Kyotaro Horiguchi wrote:
> At Tue, 27 Feb 2024 18:33:18 +0100, Alvaro Herrera
> wrote in
> > Here's the complete set, with these two names using the singular.
>
> The commit by the second patch added several GUC descriptions:
>
> > Sets the size o
On 2024-Feb-28, Jelte Fennema-Nio wrote:
> diff --git a/src/backend/utils/error/elog.c b/src/backend/utils/error/elog.c
> index 699d9d0a241..553e4785520 100644
> --- a/src/backend/utils/error/elog.c
> +++ b/src/backend/utils/error/elog.c
> @@ -843,6 +843,8 @@ matches_backtrace_functions(const
On 2024-Feb-29, Dean Rasheed wrote:
> Going over this again, I spotted a bug -- the UPDATE path in
> ExecMergeMatched() wasn't calling ExecUpdateEpilogue() for
> trigger-updatable views, because it wasn't setting updateCxt.updated
> to true. (This matters if you have an auto-updatable view WITH
101 - 200 of 5369 matches
Mail list logo
