On 2023-Aug-16, Erik Rijkers wrote:
> Hello,
>
> The following surprised me enough to think it might be a bug:
> (17devel)
>
> select
>regexp_replace('Abc Def'
> , '([a-z]) ([A-Z])'
> , '\1 ' || lower('\2') );
>
> regexp_replace
>
> Abc Def
What's happening here is
On 2023-Aug-16, Michael Paquier wrote:
> > Personally I think backpatching 28b5726 has a really low risk of
> > breaking anything.
>
> I agree about the low-risk argument, though. This is just new code.
Here's a way to think about it. If 16.1 was already out, would we add
libpq support for
On 2023-Aug-16, Michael Paquier wrote:
> On Wed, Aug 16, 2023 at 06:25:09AM +0900, Tatsuo Ishii wrote:
> > Currently pqcomm.h needs c.h which is not problem for Pgpool-II. But
> > what about other middleware?
>
> Why do you need to include directly c.h? There are definitions in
> there that are
On 2023-Aug-15, Dean Rasheed wrote:
> I think perhaps for ALTER TABLE INHERIT, it should check that the
> child has a NOT NULL constraint, and error out if not. That's the
> current behaviour, and also matches other constraints types (e.g.,
> CHECK constraints).
Yeah, I reached the same
On 2023-Aug-13, Fabien COELHO wrote:
> 4. libevent development seems slugish, last bugfix was published 3 years ago,
> version
>2.2 has been baking for years, but the development seems lively (+100
> contributors).
Ugh, I would stay away from something like that. Would we become
hostage
On 2023-Aug-14, Pavel Stehule wrote:
> jsonb_populate_array(anyarray, jsonb) returns anyarray
>
> Usage:
>
> select jsonb_populate_array(null::text[], '["cust_full_name","cust_email"]')
I don't understand what this does. Can you be more explicit?
--
Álvaro Herrera 48°01'N
On 2023-Aug-09, Tomas Vondra wrote:
> On 8/9/23 11:11, Alvaro Herrera wrote:
> > I was trying to use RelationGetIndexAttrBitmap for something and
> > realized that its header comment does not really explain things very
> > well. That was already the ca
Hello
So pginfra had a little chat about this. Firstly, there's consensus
that it makes sense for pginfra to help out with some persistent workers
in our existing VM system; however there are some aspects that need
some further discussion, to avoid destabilizing the rest of the
infrastructure.
On 2023-Aug-09, Nathan Bossart wrote:
> On Wed, Aug 09, 2023 at 10:44:42AM -0600, Dave Cramer wrote:
> > On Wed, 9 Aug 2023 at 10:34, Tom Lane wrote:
> >> I agree with Peter: let's use the names in the protocol document
> >> with a single prefix. I've got mixed feelings about whether that
On 2023-Aug-09, Melih Mutlu wrote:
> --Patch
> name | used_bytes | free_bytes | total_bytes
> ---+++-
> RelCacheMemoryContext |4706464 |3682144 | 8388608
> CatCacheMemoryContext |3489384 | 770712 |
On 2023-Aug-09, Peter Eisentraut wrote:
> I wonder whether the root of these problems is that we mix together primary
> key constraints and not-null constraints. I understand that right now, with
> the proposed patch, when a table inherits from a parent table with a primary
> key constraint, we
ni "Hello USA\n".
>From db4c89d15d121bf0e15c4160cb2f0770bc98195a Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: Wed, 12 Jul 2023 14:19:23 +0200
Subject: [PATCH] Document RelationGetIndexAttrBitmap better
Commit 19d8e2308bc5 changed the list of set-of-columns that can be
returned by Re
seDB.com/
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end." (2nd Commandment for C programmers)
>From df8b71428481f718ac6bb60a3ca5969a6876da7e Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: Thu, 3 Aug 2023 11:44:15 +0200
Subject: [PATCH] Js
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
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.
--
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,
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
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
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 case
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
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
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
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
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,
> > 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+
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
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 rea
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. Please le
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
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
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
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
>
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's t
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
> >
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,
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.
>
>
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
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 developmen
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
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
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 *)
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
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
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
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
— 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/include/utils/jsonfuncs.h | 8
2 fil
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 —
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
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/include/uti
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
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
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 —
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
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
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
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
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
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
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,
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&qu
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 "???
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
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
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
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
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
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, afte
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
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
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
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
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
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
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
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
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
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 —
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
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
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
line 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 50685847e057eb8e7509293fdd81247eb49854ef M
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
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
ot; (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.
Also, change the error messages to not need sepa
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
501 - 600 of 5369 matches
Mail list logo
