On 2023-Aug-08, Andres Freund wrote:
> Given the cost of macos, it seems like it'd be by far the most of affordable
> to just buy 1-2 mac minis (2x ~660USD) and stick them in a shelf somewhere, as
> persistent runners. Cirrus has builtin macos virtualization support - but can
> only host two VMs o
On 2023-Aug-07, Nathan Bossart wrote:
> On Mon, Aug 07, 2023 at 04:02:08PM -0400, Tom Lane wrote:
> > Dave Cramer writes:
> >> Can we vote or whatever it takes to decide on a naming pattern that is
> >> acceptable ?
> >
> > I'm good with Robert's proposal above.
>
> +1
WFM as well.
--
Álvar
On 2023-Aug-07, tender wang wrote:
> The foreign key still works even though partition was detached. Is this
> behavior expected?
Well, there's no reason for it not to, right? For example, if you
detach a partition and then attach it again, you don't have to scan the
partition on attach, because
On 2023-Aug-07, Peter Smith wrote:
> I guess, your patch would not be much different; you can still have
> all the nice names and assign the appropriate values to the enum
> values same as now, but using an enum you might also gain
> type-checking in the code and also get warnings for the "switch"
On 2023-Aug-05, Dean Rasheed wrote:
> Hmm, thinking about this some more, I think this might be the wrong
> approach to fixing the original problem. I think it was probably OK
> that the NOT NULL constraint on the child was marked as inherited, but
> I think what should have happened is that dropp
On 2023-Jul-28, Alvaro Herrera wrote:
> To avoid that, one option would be to make this NN constraint
> undroppable ... but I don't see how. One option might be to add a
> pg_depend row that links the NOT NULL constraint to its PK constraint.
> But this will be a strange
On 2023-Aug-03, Dave Cramer wrote:
> New patch attached which uses PREPARED_SUB_COMMAND and
> PORTAL_SUB_COMMAND instead
Hmm, I would keep the prefix in this case and make the message type a
second prefix, with the subtype last -- PQMSG_CLOSE_PREPARED,
PQMSG_DESCRIBE_PORTAL and so on.
You def
On 2023-Aug-03, Dave Cramer wrote:
> Greetings,
>
> Attached is a patch which introduces a file protocol.h. Instead of using
> the actual characters everywhere in the code this patch names the
> characters and removes the comments beside each usage.
I saw this one last week. I think it's a very
On 2023-Aug-03, tender wang wrote:
> I think old "sub-FK" should not be dropped, that will be violates foreign
> key constraint.
Yeah, I've been playing more with the patch and it is definitely not
doing the right things. Just eyeballing the contents of pg_trigger and
pg_constraint for partitio
On 2023-Aug-01, Peter Smith wrote:
> PSA a small patch making those above-suggested changes. The 'make
> check' and TAP subscription tests are all passing OK.
I think the code ends up more readable with this style of changes, so
+1. I do wonder if these calls should appear in a proc_exit callbac
On 2023-Jul-05, Jehan-Guillaume de Rorthais wrote:
> ALTER TABLE r ATTACH PARTITION r_1 FOR VALUES IN (1);
>
> The old sub-FKs (below 18289) created in this table to enforce the action
> triggers on referenced partitions are not deleted when the table becomes a
> partition. Because of this, we
> > Given the following sequence:
> >
> > drop table if exists p,c;
> > create table p(a int primary key);
> > create table c() inherits (p);
> > alter table p drop constraint p_pkey;
> > However, c.a remains non-nullable, with a NOT NULL constraint that
> > claims to be inherited:
> >
> > \d+ c
On 2023-Jul-28, Michael Paquier wrote:
> So you have faced a race condition where the commit of the transaction
> doing the schema creation for the static workers is delayed long
> enough that the dynamic workers don't see it, and bumped on a catalog
> conflict when they try to create the same sch
On 2023-Jul-26, Alvaro Herrera wrote:
> On 2023-Jul-26, Dean Rasheed wrote:
>
> > The new \d+ output certainly makes testing and reviewing easier,
> > though I do understand people's concerns that this may make the output
> > significantly longer in many real-wo
On 2023-Jul-25, Michael Paquier wrote:
> On Mon, Jul 24, 2023 at 07:40:04PM +, Imseih (AWS), Sami wrote:
> > WaitForOlderSnapshots is used here to ensure that snapshots older than
> > the start of the ALTER TABLE DETACH CONCURRENTLY are completely removed
> > to guarantee consistency, however
Thanks for spending so much time with this patch -- really appreciated.
On 2023-Jul-26, Dean Rasheed wrote:
> On Tue, 25 Jul 2023 at 13:36, Alvaro Herrera wrote:
> >
> > Okay then, I've made these show up in the footer of \d+. This is in
> > patch 0003 here. Plea
Hello
On 2023-Jul-26, Thomas wen wrote:
> Hi Hackes: I found this page :
> https://pgsql-hackers.postgresql.narkive.com/cMxBwq65/incremental-checkopints,PostgreSQL
> no incremental checkpoints have been implemented so far. When a
> checkpoint is triggered, the performance jitter of PostgreSQL i
On 2023-Jul-26, Jian Guo wrote:
> It looks the columns besides `ps_supplycost` and `ps_availqty` are not
> necessary, but fetched from tuples all at once. For the row-based
> storage such as heap, it looks fine, but for column-based storage, it
> would result into unnecessary overhead and impact p
On 2023-Jul-25, Isaac Morland wrote:
> I agree. I definitely do *not* want a bunch of NOT NULL constraint names
> cluttering up displays. Can we legislate that all NOT NULL implementing
> constraints are named by mashing together the table name, column name, and
> something to identify it as a NOT
On 2023-Jul-25, Aleksander Alekseev wrote:
> Hi,
>
> The proposed patch is a small refactoring of inval.{c,h}:
>
> """
> The "public functions" separator comment doesn't reflect reality anymore.
> We could rearrange the order of the functions. However, this would
> complicate
> back-
Hello,
While discussing the matter of multiple constraints with Vik Fearing, I
noticed that we were throwing an unnecessary error if you used
CREATE TABLE foo (a int NOT NULL NOT NULL);
That would die with "redundant NOT NULL declarations", but current
master doesn't do that; and we don't do it
On 2023-Jul-24, Dean Rasheed wrote:
> Something else I noticed: the error message from ALTER TABLE ... ADD
> CONSTRAINT in the case of a duplicate constraint name is not very
> friendly:
>
> ERROR: duplicate key value violates unique constraint
> "pg_constraint_conrelid_contypid_conname_index"
>
On 2023-Jul-24, Tomas Vondra wrote:
> On 7/24/23 13:14, Alvaro Herrera wrote:
> > Do you mind if I get this one pushed later today? Or feel free to push
> > it yourself, if you want. It's an annoying patch to keep seeing posted
> > over and over, with no further value
On 2023-Jul-20, Andrew Dunstan wrote:
> On 2023-07-20 Th 05:52, Alvaro Herrera wrote:
> > On 2023-Jul-19, Andrew Dunstan wrote:
> >
> > > The result you report suggest to me that somehow the old version is no
> > > longer a PostgreSQL::Version object. Here
On 2023-Jul-24, Michael Paquier wrote:
> On Sun, Jul 23, 2023 at 11:21:47PM +0300, Anton A. Melnikov wrote:
> > After some research, found this happens when the LimitAdditionalPins()
> > returns exactly zero.
> > In the current master, this will happen e.g. if shared_buffers = 10MB and
> > max_w
On 2023-Jul-20, Tomas Vondra wrote:
> From 809d60be7e636b8505027ad87bcb9fc65224c47b Mon Sep 17 00:00:00 2001
> From: Tomas Vondra
> Date: Wed, 5 Apr 2023 22:49:41 +0200
> Subject: [PATCH 1/6] Make test_decoding ddl.out shorter
>
> Some of the test_decoding test output was extremely wide, because
On 2023-Jul-24, Dean Rasheed wrote:
> Hmm, I'm not so sure. I think perhaps multiple NOT NULL constraints on
> the same column should just be allowed, otherwise things might get
> confusing. For example:
>
create table p1 (a int not null check (a > 0));
create table p2 (a int not null check (a
On 2023-Jul-24, Dean Rasheed wrote:
> Hmm, I don't particularly like that approach, because I think it will
> be difficult to cram any additional details into the table, and also I
> don't know whether having multiple not null constraints for a
> particular column can be entirely ruled out.
>
> I
On 2023-Jul-21, Amit Langote wrote:
> I’m thinking of pushing 0001 and 0002 tomorrow barring objections.
0001 looks reasonable to me. I think you asked whether to squash that
one with the other bugfix commit for the same code that you already
pushed to master; I think there's no point in committ
r — https://www.EnterpriseDB.com/
>From 055b0d89f7c6667b79ba0b97f54ea5aef64dfbb1 Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: Wed, 19 Jul 2023 17:54:09 +0200
Subject: [PATCH v2] Compare only major versions in AdjustUpgrade.pm
Because PostgreSQL::Version is very nuanced about devel
On 2023-Jul-19, Andrew Dunstan wrote:
>
> On 2023-07-19 We 07:05, Alvaro Herrera wrote:
> > I just hit a snag testing this. It turns out that the
> > PostgreSQL::Version comparison stuff believes that 16beta2 < 16, which
> > sounds reasonable. However, because of
I just hit a snag testing this. It turns out that the
PostgreSQL::Version comparison stuff believes that 16beta2 < 16, which
sounds reasonable. However, because of that, the AdjustUpgrade.pm
stanza that tries to drop tables public.gtest_normal_child{2} in
versions earlier than 16 fails, because b
I tried this out. It looks good to me, and I like it. Not translating
the labels seems correct to me.
+1 for backpatching to 16, given that it's a psql-only change that
pertains to a backend change that was done in the 16 timeframe.
Regarding the controversy of showing SET for previous versions
On 2023-Jul-17, Nathan Bossart wrote:
> @@ -35,7 +42,11 @@ binaryheap_allocate(int capacity, binaryheap_comparator
> compare, void *arg)
> binaryheap *heap;
>
> sz = offsetof(binaryheap, bh_nodes) + sizeof(Datum) * capacity;
> +#ifdef FRONTEND
> + heap = (binaryheap *) pg_malloc
On 2023-Jul-18, Amit Langote wrote:
> Attached updated patches. In 0002, I removed the mention of the
> RETURNING clause in the JSON(), JSON_SCALAR() documentation, which I
> had forgotten to do in the last version which removed its support in
> code.
> I think 0001 looks ready to go. Alvaro?
On 2023-Jul-17, Garrett Thornburg wrote:
> That's a good point, Isaac. Select into, security label, comment, etc are
> all maintenance style commands but are already added to the matrix. I do
> think there's a good case to include other maintenance related commands as
> event triggers. Suppose you
On 2023-Jul-17, Ashutosh Bapat wrote:
> Prologue of psprintf() says
>
> * Errors are not returned to the caller, but are reported via elog(ERROR)
> * in the backend, or printf-to-stderr-and-exit() in frontend builds.
> * One should therefore think twice about using this in libpq.
>
> If an error
On 2023-Jul-14, Dave Cramer wrote:
> David,
>
> I will try to get a tcpdump file. Doing this in libpq seems challenging as
> I'm not aware of how to create a portal in psql.
You can probably have a look at src/test/modules/libpq_pipeline/libpq_pipeline.c
as a basis to write some test code for th
On 2023-Jul-14, Peter Eisentraut wrote:
> diff --git a/src/backend/parser/Makefile b/src/backend/parser/Makefile
> index 9f1c4022bb..3d33b082f2 100644
> --- a/src/backend/parser/Makefile
> +++ b/src/backend/parser/Makefile
> @@ -64,8 +64,8 @@ scan.c: FLEX_FIX_WARNING=yes
> # Force these dependenc
.
--
Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
>From 44504a8fe96ad76a375c77e5f53e4f897e3ca2f2 Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: Thu, 13 Jul 2023 18:06:07 +0200
Subject: [PATCH 1/2] trivial fixups
---
src/backend/utils/adt/jsonfuncs.c | 5 ++---
src
On 2023-Jul-13, Peter Eisentraut wrote:
> I suppose we could just say "logical replication worker" in all cases. That
> should be enough precision for the purpose of these messages.
Agreed. IMO the user doesn't care about specifics.
--
Álvaro Herrera 48°01'N 7°57'E — https://ww
On 2023-Jul-12, Tristan Partin wrote:
> Attached is a patch which does just that without overriding the
> binaries. I investigated the bin_targets stuff, but some test
> executables get added there, so it wouldn't work out that well.
This seems useful. Maybe we should have some documentation cha
lusión de ellos" (Tanenbaum)
>From db07c83e4baa04146a4c8e5ebc663c7eb5cfaa10 Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: Wed, 12 Jul 2023 14:19:23 +0200
Subject: [PATCH 1/1] document RelationGetIndexAttrBitmap
---
src/backend/utils/cache/relcache.c | 12 +---
src/i
On 2023-Jul-12, Gurjeet Singh wrote:
> The init-steps are severely under-documented in pgbench --help output.
> I think at least a pointer to the the pgbench docs should be mentioned
> in the pgbench --help output; an average user may not rush to read the
> code to find the explanation, but a hint
On 2023-Jun-28, Peter Eisentraut wrote:
> The MergeAttributes() and related code in and around tablecmds.c is huge and
> ancient, with many things bolted on over time, and difficult to deal with.
> I took some time to make careful incremental updates and refactorings to
> make the code easier to f
On 2023-Jul-11, Masahiko Sawada wrote:
> Since the numerical value is important only in invalid message type
> cases, how about using a format like "??? (88)" in unknown message
> type cases, in both error and context messages?
+1
--
Álvaro Herrera 48°01'N 7°57'E — https://www.E
On 2023-Jul-11, Jeevan Chalke wrote:
> 4. However, 2nd path was already sorted and passed as is to the add_path().
> 5. add_path() decides to reject this new path on some metrics. However, in
> the end, it pfree() this passed in path. It seems wrong as its references
> do present elsewhere. For ex
On 2023-Jul-10, Tom Lane wrote:
> Michael Paquier writes:
> > On Thu, Jul 06, 2023 at 10:09:20AM -0700, Andres Freund wrote:
> >> I also don't think pg_dump will dump the changed schema, which means a
> >> dump/restore leads to a different schema - IMO something to avoid.
>
> > Yes, you're right
I forgot to add:
* 0001 looks an obvious improvement. You could just push it now, to
avoid carrying it forward anymore. I would just put the constructName
ahead of value expr in the argument list, though.
* 0002: I have no idea what this is (though I probably should). I would
also push it righ
On 2023-Jul-10, Amit Langote wrote:
> > I see that you add json_returning_clause_opt, but we already have
> > json_output_clause_opt. Shouldn't these two be one and the same?
> > I think the new name is more sensible than the old one, since the
> > governing keyword is RETURNING; I suppose naming
Hello,
On 2023-Jul-03, Masahiko Sawada wrote:
> While testing PG16, I observed that in PG16 there is a big performance
> degradation in concurrent COPY into a single relation with 2 - 16
> clients in my environment. I've attached a test script that measures
> the execution time of COPYing 5GB dat
On 2023-Jul-09, Michael Paquier wrote:
> Patch 0002 introduces a set of simplifications for the format of
> wait_event_names.txt:
> - Removal of the first column for the enums.
I don't like this bit, because it means the .txt file is now ungreppable
as source of the enum name. Things become myst
Looking at 0001 now.
I noticed that it adds JSON, JSON_SCALAR and JSON_SERIALIZE as reserved
keywords to doc/src/sgml/keywords/sql2016-02-reserved.txt; but those
keywords do not appear in the 2016 standard as reserved. I see that
those keywords appear as reserved in sql2023-02-reserved.txt, so I
On 2023-Jul-05, Gurjeet Singh wrote:
> +BEGIN;
> +COPY (
> +MERGE INTO sq_target t
> +USING v
> +ON tid = sid
> +WHEN MATCHED AND tid > 2 THEN
> +UPDATE SET balance = t.balance + delta
> +WHEN NOT MATCHED THEN
> +INSERT (balance, tid) VALUES (balance + delta, si
On 2023-Jul-05, Alvaro Herrera wrote:
> On 2023-Jul-05, Euler Taveira wrote:
>
> > Isn't this numerical value already exposed in the error message (X = 88)?
> > In this example, it is:
> >
> > ERROR: invalid logical replication message type "X&q
On 2023-Jul-05, Euler Taveira wrote:
> Isn't this numerical value already exposed in the error message (X = 88)?
> In this example, it is:
>
> ERROR: invalid logical replication message type "X"
> CONTEXT: processing remote data for replication origin "pg_16638" during
> message type "??? (88)
On 2023-Jul-05, Amit Kapila wrote:
> I think after returning "???" from logicalrep_message_type(), the
> above is possible when we get the error: "invalid logical replication
> message type "X"" from apply_dispatch(), right? If so, then what about
> the case when we forgot to handle some message i
On 2023-Jul-05, Michael Paquier wrote:
> The same thing as HEAD could be done on its back-branches by removing
> --with-openssl and bring more consistency, but pg_upgrade has never
> been good at handling upgrades with different library requirements.
> Something I am wondering is if AdjustUpgrade.
On 2023-Jun-29, Heikki Linnakangas wrote:
> I can hit the above error with the attached test case. That seems wrong,
> although I don't know if it means that the check is wrong or it exposed a
> long-standing bug.
> +CREATE SCHEMA test_func_dep1;
> +CREATE SCHEMA test_func_dep2;
> +CREATE EXTENSI
On 2023-Jul-03, Soumyadeep Chakraborty wrote:
> My colleague, Ashwin, pointed out to me that brininsert's per-tuple init
> of the revmap access struct can have non-trivial overhead.
>
> Turns out he is right. We are saving 24 bytes of memory per-call for
> the access struct, and a bit on buffer/l
On 2023-Jun-19, Juan José Santamaría Flecha wrote:
> Ok, let's see where the report goes:
>
> https://developercommunity.visualstudio.com/t/CompareStringEx-non-transitive/10393003?q=comparestringex
Hm, so this appears to have been marked as solved by Microsoft. Can you
recheck? Also, what does
On 2023-Jun-30, Andres Freund wrote:
> On 2023-06-30 13:44:03 +0200, Alvaro Herrera wrote:
>
> > The main novelty in this version of the patch, is that we now emit
> > "throwaway" NOT NULL constraints when a column is part of the primary
> > key. Then, after th
Hello,
On 2023-Jul-02, Andres Freund wrote:
> I like that we now have a builtin backtrace ability. Unfortunately I think the
> backtraces are often not very useful, because only externally visible
> functions are symbolized.
Agreed, these backtraces are pretty close to useless. Not completely,
On 2023-Jun-28, Peter Eisentraut wrote:
> The MergeAttributes() and related code in and around tablecmds.c is huge and
> ancient, with many things bolted on over time, and difficult to deal with.
> I took some time to make careful incremental updates and refactorings to
> make the code easier to f
On 2023-Jun-21, Peter Smith wrote:
> Except, please note that there are already multiple message format
> strings in the HEAD code that look like "%s for subscription ...",
> that are using the get_worker_name() function for the name
> substitution.
>
> e.g.
> - "%s for subscription \"%s\" will s
On 2023-May-31, Bruce Momjian wrote:
> I guess we could try looking for pg_bsd_indent-$MAJOR_VERSION first,
> then pg_bsd_indent.
Do you mean with $MAJOR_VERSION being Postgres' version? That means we
need to install a new symlink every year, even when pg_bsd_indent
doesn't change. I'd rather h
On 2023-Jun-16, Masahiko Sawada wrote:
> The walreceiver process doesn't use CRS_EXPORT_SNAPSHOT actually,
> right? I think replacing it with CRS_EXPORT_SNAPSHOT would rather
> confuse me
libpqwalreceiver.c does use it. But I agree -- I think it would be
better to not use the enum in walreceiver
On 2023-Jun-13, Amit Kapila wrote:
> I'll push this tomorrow unless there are any suggestions or comments.
Note the proposed commit message is wrong about which commit is to blame
for the original problem -- it mentions e7e7da2f8d57 twice, but one of
them is actually c3afe8cf5a1e.
--
Álvaro Her
On 2023-Jun-15, Peter Smith wrote:
> PSA a small patch to modify the code accordingly. This is not intended
> to be a functional change - just a code cleanup.
>From a translation standpoint, this doesn't seem good. Consider this
proposed message:
"lost connection to the %s"
It's not possible
On 2023-Jun-13, Morris de Oryx wrote:
> Quick follow-up: I've heard back from AWS regarding applying Tom Lane's
> patch. Nope. RDS releases numbered versions, nothing else.
Sounds like a reasonable policy to me.
> As Postgres is now at 15.8/15.3 in the wild and on 15.7/15.3 on RDS,
> I'm guessin
Note that you changed one comment from "permission checks" to
"permission hecks".
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"No nos atrevemos a muchas cosas porque son difíciles,
pero son difíciles porque no nos atrevemos a hacerlas" (Séneca)
On 2023-Jun-06, Laurenz Albe wrote:
> At a quick glance, it looks like you resolve "timezone" at the time
> the query is parsed. Shouldn't the resolution happen at query
> execution time?
Sounds like it -- consider the case where the timestamp value is a
partition key and one of the partition bo
On 2023-Jun-07, Peter Geoghegan wrote:
> On Wed, Jun 7, 2023 at 5:12 PM Andres Freund wrote:
> > I don't really understand why the patch does s/heaprel/heapRel/.
>
> That has been the style used within nbtree for many years now.
IMO this kind of change definitely does not have place in a post-
On 2023-May-21, Tom Lane wrote:
> Since we're hard up against the beta1 wrap deadline, I went ahead
> and pushed the v5 patch. I doubt that it's perfect yet, but it's
> a small change and demonstrably fixes the cases we know about.
>
> As I said in the commit message, the main knock I'd lay on v
On 2023-Jun-05, Peter Geoghegan wrote:
> My current plan is to commit this later in the week, unless there are
> further objections. Wednesday or possibly Thursday.
I've added this as an open item for 16, with Peter and Andres as owners.
--
Álvaro Herrera PostgreSQL Developer — https:
On 2023-Apr-24, Andres Freund wrote:
> A prototype of that approach is attached. I pushed the retry handling into the
> pg_* routines where applicable. I guess we could add pg_* routines for
> FileFallocate(), FilePrewarm() etc as well, but I didn't do that here.
>
> Christoph, could you verify
On 2023-May-25, Laurenz Albe wrote:
> @@ -1335,7 +1335,7 @@ Author: Peter Eisentraut
>
>
>
> -Add Windows process the system collations (Jose Santamaria Flecha)
> +Add Windows to process the system collations (Jose Santamaria Flecha)
> ADD THIS?
>
>
Hmm, not sure this describes the ch
On 2023-May-25, Peter Geoghegan wrote:
> Attached patch completely removes the changes to _bt_getbuf()'s
> signature from 61b313e4.
I suppose you're not thinking of applying this to current master, but
instead just leave it for when pg17 opens, right? I mean, clearly it
seems far too invasive to
On 2023-May-22, Alvaro Herrera wrote:
> Hah, yeah, that's because an empty pipeline never calls the code to
> allocate the flag array. Here's the trivial fix.
Pushed to both branches, thanks for the report.
--
Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
Hi,
On 2023-May-22, Tristan Partin wrote:
> Some files were missing information from the c.h header.
Actually, these omissions are intentional, and we have bespoke handling
for this in our own header-checking scripts (src/tools/pginclude). I
imagine this is documented somewhere, but ATM I can't
empty pipeline never calls the code to
allocate the flag array. Here's the trivial fix.
--
Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
"El hombre nunca sabe de lo que es capaz hasta que lo intenta" (C. Dickens)
>From 50685847e057eb8e7509293fdd8
I noticed that the value that enables this feature at libpq client side
is 'enable'. However, for other Boolean settings like sslsni,
keepalives, requiressl, sslcompression, the value that enables feature
is '1' -- we use strings only for "enum" type of settings.
Also, it looks like connectOption
On 2023-May-19, Andrey M. Borodin wrote:
> I have a question, but mostly for my own knowledge. Translation
> changes seem trivial for all languages, do we typically fix .po files
> in such cases? Or do we leave it to translators to revise the stuff?
The translations use a completely separate sour
en algo que te dan y te lo muestran?" (Germán Poo)
>From 5eb799984252cf231064d6d174e13d63880577df Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: Fri, 19 May 2023 12:58:54 +0200
Subject: [PATCH] Tweak xheader_width input parsing
Don't throw away the previous value when an invalid value is proposed.
Als
On 2023-May-11, Daniel Gustafsson wrote:
> > On 10 May 2023, at 19:54, Alvaro Herrera wrote:
> > Therefore, I propose to turn these messages into errmsg_internal(), so
> > that we do not translate them.
>
> AFAICT from following the code that seems correct, and I ag
On 2023-May-13, John Naylor wrote:
>
> 2. Propose to move to the "Not Wanted list":
> Consider having single-page pruning update the visibility map
> -> Comment from Heikki in the thread:
> "I think I was worried about the possible performance impact of having to
> clear the
On 2023-May-15, Tom Lane wrote:
> Laurenz Albe writes:
> > On Mon, 2023-05-15 at 08:37 +0200, Pavel Stehule wrote:
> >> This looks little bit strange
> >>
> >> What about /* comments
> >> Like
> >> /*** Query /
> >> Or just
> >> Query
>
> > +1 for either of Pavel's
On 2023-May-14, Tom Lane wrote:
> Steve Chavez writes:
> > In this case I just propose adding 'tags'. I believe it's reasonable to
> > ignore these as they're produced by make_ctags.
>
> Our policy on this is that the project's .gitignore files should ignore
> files that are produced by our stan
On 2023-May-07, Tomas Vondra wrote:
> > Álvaro wrote:
> >> In backbranches, the new field to BrinMemTuple needs to be at the end of
> >> the struct, to avoid ABI breakage.
>
> Unfortunately, this is not actually possible :-(
>
> The BrinMemTuple has a FLEXIBLE_ARRAY_MEMBER at the end, so we can'
On 2023-May-12, Pavel Stehule wrote:
> It hangs in perl
I wonder if "hanging" actually means that it interpreted the sleep time
as a very large integer, so it's just sleeping for a long time.
About the server locale, note that the ->new() call explicitly requests
the C locale -- it's only psql t
On 2023-May-11, Yurii Rashkovskii wrote:
> Relying on a variable number of lines may be counter-productive here if we
> want postmaster.pid to be easily readable by shell scripts.
Oh, I was thinking in Peter E's proposal to list the interface/port
number pairs in a separate file named 'ports' or
Hi
While translating the v15 message catalog (yes, I'm quite late!), I
noticed that commit 1f39bce02154 introduced three copies of the
following message in hashagg_batch_read():
+ ereport(ERROR,
+ (errcode_for_file_access(),
+errmsg("unexpected EOF for tape %d:
BTW, I spent some time adding a cross-check to see if the code was at
least approximately correct for all the queries in the MERGE regression
tests, and couldn't find any failures. I then extended the test to the
other optimizable commands, and couldn't find any problems there either.
My approach
On 2023-Apr-24, Peter Eisentraut wrote:
> The GUC settings lc_collate and lc_ctype are from a time when those locale
> settings were cluster-global. When we made those locale settings
> per-database (PG 8.4), we kept them as read-only. As of PG 15, you can use
> ICU as the per-database locale pr
On 2023-May-08, Ranier Vilela wrote:
> Em seg., 8 de mai. de 2023 às 14:26, Alvaro Herrera
> escreveu:
>
> > The problem I see is that each of these new functions has a single
> > caller, and the only one that looks like it could have a performance
> > advantage is
On 2023-May-08, Peter Eisentraut wrote:
> On 23.04.23 08:42, Richard Guo wrote:
> > Thanks for the suggestion. I've split the patch into two as attached.
> > 0001 is just a minor simplification by replacing lfirst(list_head(list))
> > with linitial(list). 0002 introduces new functions to reduce
On 2023-Apr-19, Yurii Rashkovskii wrote:
> If we consider this path, then (if we assume the format of the file is
> still to be private), we can make the port line accept multiple ports using
> a delimiter like `:` so that the next line still remains the same.
This made me wonder if storing the u
On 2023-May-07, Tom Lane wrote:
> I wrote:
> > Ping? The hours grow short, if we're to get this into 15.3.
>
> I went ahead and pushed v2, since we can't wait any longer if
> we're to get reasonable buildfarm coverage before 15.3 wraps.
Much appreciated. I wanted to get back to this yesterday
complicated way
why does it need to be complicated?
Because it's MakeMaker.
>From a89d46592ba4d113f57a890b63ef123d8470db45 Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: Fri, 5 May 2023 20:40:38 +0200
Subject: [PATCH] add ruleutils.c support for MERGE
---
src/backend/utils/adt/ruleut
On 2023-May-05, Tom Lane wrote:
> I made this function:
>
> CREATE OR REPLACE FUNCTION test_fun()
> RETURNS void
> LANGUAGE SQL
> BEGIN ATOMIC
> MERGE INTO target
> USING source s on s.id = target.id
> WHEN MATCHED THEN
> UPDATE SET data = s.data
> WHEN NOT MATCHED THEN
> INSERT VALUES (s.id,
601 - 700 of 3481 matches
Mail list logo
