On Fri, Nov 1, 2024 at 6:13 PM Torsten Förtsch wrote:
>
> On Wed, Oct 30, 2024 at 9:01 AM Peter Eisentraut wrote:
>>
>> On 27.10.24 13:37, Torsten Förtsch wrote:
>> > The attached patch enables pg_recvlogical to create a temporary slot.
>>
>> I think you should explain a bit why you want to do th
> On 2024-07-01 15:08 +0200, Yugo NAGATA wrote:
> I would like to propose to add a new field to psql's \dAo+ meta-command
> to show whether the underlying function of an operator is leak-proof.
>
I agree that this is useful information to have, but why add it to
\dAo+ instead of \do+? Taking the e
On Sun, 3 Nov 2024 at 03:33, Junwang Zhao wrote:
>
> PFA v11.
>
Testing this with an array with non-default lower bounds, it fails to
preserve the array bounds, which I think it should (note:
array_reverse() and array_shuffle() do preserve the bounds):
SELECT array_reverse(a), array_shuffle(a),
On 13/09/2024 13:41, Ashutosh Bapat wrote:
On Thu, Sep 12, 2024 at 4:28 PM Nazir Bilal Yavuz wrote:
Once this is done, I think we can mark this CF entry as RFC.
Thanks for the changes. I applied all of them in respective patches.
Thanks a lot. PFA the patchset with
1. Improved comment rel
On Mon, 4 Nov 2024 at 16:25, Amit Kapila wrote:
>
> On Wed, Oct 30, 2024 at 9:46 PM vignesh C wrote:
> >
> ...
> + /*
> + * For non-column list publications—such as TABLE (without a column
> + * list), ALL TABLES, or ALL TABLES IN SCHEMA publications consider
> + * all columns of the table, inclu
On Mon, 4 Nov 2024 at 15:41, Bruce Momjian wrote:
>
> Someone emailed me privately saying they were confused because they
> thought pg_dump --no-comments would remove SQL comments, not the SQL
> COMMENT commands. Is this something worth clarifying in our docs? I am
> not even sure how I would ex
On Fri, 1 Nov 2024 at 09:23, Peter Smith wrote:
>
> On Thu, Oct 31, 2024 at 3:16 AM vignesh C wrote:
>
> > Thanks for committing this patch, here is a rebased version of the
> > remaining patches.
> >
>
> Hi Vignesh.
>
> Here are my review comments for the docs patch v1-0002.
>
> ==
> Commit
On Sun, Nov 3, 2024 at 11:40 PM Amul Sul wrote:
> +1 for the back-patching.
>
> For 0002, I think we could report the error a bit earlier — the better
> place might be in the else part of the following IF-block, IMO:
>
> /*
> * If s->header_length == 0, then this is a full file; otherwise, it's
>
On Mon, Nov 4, 2024 at 9:19 AM Alvaro Herrera wrote:
> It's looking to me like there's just too much cruft in the quest to
> avoid having to reach consensus on new syntax. This might be a mistake.
> Is it possible to backtrack on that decision?
There's also the patch that Heikki posted to wait u
On 04/11/2024 17:53, Robert Haas wrote:
On Mon, Nov 4, 2024 at 9:19 AM Alvaro Herrera wrote:
It's looking to me like there's just too much cruft in the quest to
avoid having to reach consensus on new syntax. This might be a mistake.
Is it possible to backtrack on that decision?
There's als
On Thu, Oct 31, 2024 at 07:58:06PM +, Devulapalli, Raghuveer wrote:
> LGTM.
Thanks. Barring additional feedback, I plan to commit this soon.
--
nathan
Ronan Dunklau writes:
> Le mercredi 1 septembre 2021, 19:27:35 heure normale d’Europe centrale Tom
> Lane a écrit :
>> The rest of this is stuck pending investigation of the ideas about
>> making new-style function creation safer when the creation-time path
>> isn't secure, so I suppose we should
On 10/09/2024 19:53, Maxim Orlov wrote:
I looked at the patch set and found it quite useful.
The first 7 patches are just refactoring and may be committed separately
if needed.
There were minor problems: patch #5 don't want to apply clearly and the
#8 is complained
about partitionLock is unuse
Hi team!
I found this bug in the create type command. If you miss the comma
between the elements, the command doesn't fail; it runs and concatenates
the elements.
I detected the problem in v14.4, and it is alive in v17.
pglatest$ psql -h 127.0.0.1 -p 55532
Password for user daf:
Time: 0.481
On Mon, Nov 4, 2024 at 10:57 AM Heikki Linnakangas wrote:
> > There's also the patch that Heikki posted to wait using a
> > protocol-level facility.
>
> It was Peter E
Oops.
> > Maybe that's just a better fit and we don't need either a procedure
> > or new syntax.
> I think it would still be goo
On Mon, 2024-11-04 at 11:22 -0500, Tom Lane wrote:
> The cfbot points out a minor problem [1]:
>
> create role groot;
> +WARNING: roles created by regression test cases should have names starting
> with "regress_"
> create role outis;
> +WARNING: roles created by regression test cases should
Hi.
Em seg., 4 de nov. de 2024 às 14:18, Bertrand Drouvot <
bertranddrouvot...@gmail.com> escreveu:
> Hi,
>
> On Tue, Nov 05, 2024 at 12:24:48AM +1300, David Rowley wrote:
> > On Sat, 2 Nov 2024 at 01:50, Bertrand Drouvot
> > wrote:
> > >
> > > On Fri, Nov 01, 2024 at 09:47:05PM +1300, David Row
Hi,
When I gave my talk on pg_basebackup at pgconf.eu, people took the
opportunity to mention various improvements which they would find
useful. One of those improvements was the ability to combine several
incremental backups into one. This might be useful if you take very
frequent incremental bac
On Fri, Nov 1, 2024 at 7:10 AM Peter Smith wrote:
>
>
> ==
> doc/src/sgml/protocol.sgml
>
> 3.
>
> - Next, one of the following submessages appears for each column:
> + Next, one of the following submessages appears for each column
> (except generated columns):
>
> Hmm. Now th
Hi Michael,
> On Tue, Oct 29, 2024 at 03:23:15PM +0300, Aleksander Alekseev wrote:
> >> While unfortunately named, we cannot deprecate TRIM_ARRAY() because it
> >> is mandated by the standard.
> >
> > I didn't know that, thanks.
>
> Wow. Neither did I.
>
> > Still PostgreSQL doesn't follow the st
Hi,
On Thu, Oct 31, 2024 at 05:09:56AM +, Bertrand Drouvot wrote:
> === OPTIONS ===
>
> So, based on this, I think that we could:
>
> Option 1: "move" the existing PGSTAT_KIND_IO to variable-numbered and let this
> KIND take care of the aggregated view (pg_stat_io) and the per-backend stats.
Someone emailed me privately saying they were confused because they
thought pg_dump --no-comments would remove SQL comments, not the SQL
COMMENT commands. Is this something worth clarifying in our docs? I am
not even sure how I would express it. It currently says:
--no-comments
Hi,
> I played with patch v3. All in all it seems to be in good shape.
>
> I wonder though whether tablefunc extension is the right place for the
> function. To me it seems to be as useful as array_shuffle().
>
> Personally I would name the function array_rand() in order to be
> consistent with th
On Fri, 1 Nov 2024 at 15:43, Kirill Reshke wrote:
>
> Hi hackers!
>
> I have been working on cloudberry/greenplum tab completion features,
> and I spotted that the postgres version of psql does not tab-complete
> ALTER TABLE ADD COLUMN IF NOT EXISTS pattern.
> So, I propose to support this.
>
> --
On 2024-Nov-04, Alexander Korotkov wrote:
> On Mon, Nov 4, 2024 at 8:04 AM Michael Paquier wrote:
> > Using output parameters in a procedure is something I did not recall.
> > Based on your point about not using a function due your argument based
> > on the snapshots, let's just use that and for
Hi,
I found a typo in the comment of gistdoinsert() when I read the codes.
See the attached patch.
--
Thanks,
Tender Wang
From 9c614b424418d451fb375294733b0cdc3740a1b7 Mon Sep 17 00:00:00 2001
From: Tender Wang
Date: Mon, 4 Nov 2024 22:28:24 +0800
Subject: [PATCH] Fix a typo in the comment of g
Hi everyone,
> >> Thanks for the detailed feedback! Here is the rebased version.
> >>
> >
> > I took another look at this and I think it's in reasonable shape.
> >
> > I'm attaching an update, rebasing it on top of 9be4e5d293.
>
> Thank you Dean.
>
> > Also it was missing a required update to the
Daniel Gustafsson writes:
> On 18 Sep 2023, at 14:11, Daniel Gustafsson wrote:
>> Unless something sticks out in a second pass over it I will go ahead and
>> apply
>> it.
> And applied, closing the CF entry.
I believe this patch (commit cca97ce6a) is the cause of bug #18685,
which reports that
Hi,
On Tue, Nov 05, 2024 at 12:24:48AM +1300, David Rowley wrote:
> On Sat, 2 Nov 2024 at 01:50, Bertrand Drouvot
> wrote:
> >
> > On Fri, Nov 01, 2024 at 09:47:05PM +1300, David Rowley wrote:
> > > I've attached what I thought a more optimal version might look like in
> > > case anyone thinks ma
On 30/09/2024 11:15, jian he wrote:
In, 0001-func.sgml-Consistently-use-optional-to-indicate-opti.patch
-format(formatstr
text [, formatarg
"any" [, ...] ])
+format(formatstr
text , formatarg
"any" [, ...] )
i change it further to
+format(formatstr
text , formatarg
"any" , ... )
i did these ki
On 04/11/2024 18:53, Robert Haas wrote:
On Mon, Nov 4, 2024 at 10:57 AM Heikki Linnakangas wrote:
Maybe that's just a better fit and we don't need either a procedure
or new syntax.
I think it would still be good to expose the feature at SQL level too.
Makes it easier to test and makes it usabl
On Mon, 4 Nov 2024 at 18:14, Tom Lane wrote:
> perhaps under the illusion that dbname and connection_string can't
> both be NULL.
Yeah, I'm pretty sure I didn't realise that was an option. I think I
probably misinterpreted this comment (might be nice to clarify there
that both being NULL is also
On Mon, Nov 4, 2024 at 6:31 AM Tender Wang wrote:
>
> Hi,
>
> I found a typo in the comment of gistdoinsert() when I read the codes.
> See the attached patch.
Thank you for the patch. Pushed.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
Thank you for the quick comments.
At Thu, 31 Oct 2024 23:24:36 +0200, Heikki Linnakangas wrote
in
> On 31/10/2024 10:01, Kyotaro Horiguchi wrote:
> > After some delays, here’s the new version. In this update, UNDO logs
> > are WAL-logged and processed in memory under most conditions. During
> >
On Tue, 5 Nov 2024 at 07:55, Peter Smith wrote:
>
> Hi Vignesh,
>
> Here are my review comments for the v47-0002 (DOCS) patch.
>
> ==
> diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
> index 577bcb4b71..a13f19bdbe 100644
> --- a/doc/src/sgml/ddl.sgml
> +++ b/doc/src/sgml/ddl.sgml
>
Hi,
On Tue, Nov 05, 2024 at 05:08:41PM +1300, David Rowley wrote:
> I was happy enough with my patch with Bertrand's comments. I'm not
> sure why unsigned chars are better than chars. It doesn't seem to have
> any effect on the compiled code.
>
I think that unsigned chars is better than char fo
On Mon, Nov 04, 2024 at 10:42:36AM +0100, Anthonin Bonnefoy wrote:
> This allows the removal of the XACT_FLAGS_PIPELINING check in
> IsInTransactionBlock and PreventInTransactionBlock since the
> transaction state will correctly reflect the ongoing implicit block.
> Additionally, it will reuse the
Hi,
On Tue, Nov 05, 2024 at 01:31:58PM +0900, Michael Paquier wrote:
> On Mon, Nov 04, 2024 at 05:17:54PM +, Bertrand Drouvot wrote:
> > Hi,
> >
> > On Tue, Nov 05, 2024 at 12:24:48AM +1300, David Rowley wrote:
> > > On Sat, 2 Nov 2024 at 01:50, Bertrand Drouvot
> > > wrote:
> > > >
> > > >
On Mon, Nov 4, 2024 at 7:02 PM Ryohei Takahashi (Fujitsu)
wrote:
>
> On the other hand, pgevent.dll is moved from lib/ directory to bin/directory
> on PG 17.0
>
> (It seems that it is moved because of meson)
>
> So, I think the documentation need to be updated like attached.
I'm unable to confir
Hi,
On Mon, Nov 04, 2024 at 02:51:10PM -0500, Robert Haas wrote:
> On Mon, Nov 4, 2024 at 4:27 AM Bertrand Drouvot
> wrote:
> > Then I think we should go with the "sometimes I don't know the relation OID
> > so I want to use the relfilenumber instead, without changing the user
> > experience"
>
Hi,
I do not use pkgconf in my Windows environment.
In my Windows environment, I could not build the following OSS with meson.
- 0001 icu
- 0002 libxml
- 0003 libxslt
- 0004 lz4
- 0005 tcl
- 0006 zlib
- 0007 zstd
[1]thread, I created a patch like the one in the attached file, and now I can
build
> On 4 Nov 2024, at 06:00, jian he wrote:
> + if (cnt != 1)
> + {
> + /*
> + * Either the lexer screwed up or our assumption above isn't true, and
> + * either way a developer needs to take a look.
> + */
> + Assert(cnt == 1);
> + return 1; /* don't fall through in release builds */
> + }
> The
On 29.10.24 18:15, Jacob Champion wrote:
libfuzzer is unhappy about the following code in MatchText:
+while (p1len > 0)
+{
+if (*p1 == '\\')
+{
+found_escape = true;
+NextByte(p1, p1len);
+
On Mon, 4 Nov 2024 at 08:25, Michael Paquier wrote:
> Perhaps it would be simpler to use a {0} like anywhere else for
> PgStat_HashKey in pgstat_fetch_entry() and pgstat_drop_entry(), then
> initialize the individual fields?
{0} doesn't clear padding, it only sets all the fields to 0.
So in many
Hi hackers
A few days ago, I was looking at the sql server documentation and found
that sql server has optimized the algorithm related to updating statistics
in the 2016 ,version,I think we can also learn from the implementation
method of sql server to optimize the problem of automatic vacuum t
Hi,
On Mon, Nov 04, 2024 at 09:27:43AM +0100, Jelte Fennema-Nio wrote:
> On Mon, 4 Nov 2024 at 08:25, Michael Paquier wrote:
> > Perhaps it would be simpler to use a {0} like anywhere else for
> > PgStat_HashKey in pgstat_fetch_entry() and pgstat_drop_entry(), then
> > initialize the individual f
Hi,
On Mon, Nov 04, 2024 at 04:25:00PM +0900, Michael Paquier wrote:
> On Sun, Nov 03, 2024 at 04:25:41AM +, Bertrand Drouvot wrote:
> > We are using sizeof(PgStat_HashKey) in pgstat_cmp_hash_key() and we compute
> > the
> > hash hash key in pgstat_hash_hash_key() using the PgStat_HashKey str
On Sat, 2024-11-02 at 08:36 +0100, Pavel Stehule wrote:
> so 2. 11. 2024 v 6:46 odesílatel Laurenz Albe
> napsal:
> > - The commit message is headed "memory cleaning after DROP VARIABLE", but
> > the rest of the commit message speaks of sinval messages. These two
> > things are independent,
Hi,
On Tue, Sep 10, 2024 at 05:30:32AM +, Bertrand Drouvot wrote:
> Hi,
>
> On Thu, Sep 05, 2024 at 04:48:36AM +, Bertrand Drouvot wrote:
> > Please find attached a mandatory rebase.
> >
> > In passing, checking if based on the previous discussion (and given that we
> > don't have the re
On Mon, Nov 04, 2024 at 09:27:38AM +, Bertrand Drouvot wrote:
> On Tue, Sep 10, 2024 at 05:30:32AM +, Bertrand Drouvot wrote:
> > Hi,
> >
> > On Thu, Sep 05, 2024 at 04:48:36AM +, Bertrand Drouvot wrote:
> > > Please find attached a mandatory rebase.
> > >
> > > In passing, checking i
On Mon, Nov 04, 2024 at 10:07:37AM +, Bertrand Drouvot wrote:
> On Mon, Nov 04, 2024 at 06:49:04PM +0900, Michael Paquier wrote:
>> but if we do for the sake of a bug fix,
>> which is always a possibility as ABI does not matter much for this
>> internal structure, that's potentially trouble wai
On Tue, 20 Aug 2024 at 13:40, David Rowley wrote:
> I made a few more tweaks to the comments and pushed the result.
While working on the patch to make HashAgg / hashed subplans and
hashed setops to use ExprState hashing, I discovered a bug in that
code when hashing 0 hashkeys (Possible with SELEC
On Mon, Nov 04, 2024 at 03:16:35PM +0800, jian he wrote:
> drop table if exists t;
> CREATE TABLE t (a int[]);
> insert into t values ('{1,3}'),('{1,2,3}'),('{11}');
> insert into t values ('{{1,12}}'), ('{{4,3}}');
> SELECT array_sort(a) from t;
>
> In the above case,
> tuplesort_begin_datum need
Andreas Karlsson writes:
> When working on a new feature for PostgreSQL I noticed that the
> pg_upgrade tests became flaky due to rules being dumped in a different
> order between the original cluster and the upgraded cluster. (For
> context: my regress scripts left a bunch of views with depend
On Sat, Nov 2, 2024 at 4:08 AM Joel Jacobson wrote:
>
> On Fri, Nov 1, 2024, at 22:28, Masahiko Sawada wrote:
> > As I mentioned in a separate email, if we use the OS default EOL as
> > the default EOL in raw format, it would not be necessary to allow it
> > to be multi characters. I think it's wo
On Mon, Nov 4, 2024 at 4:19 PM Alvaro Herrera wrote:
> On 2024-Nov-04, Alexander Korotkov wrote:
>
> > On Mon, Nov 4, 2024 at 8:04 AM Michael Paquier wrote:
>
> > > Using output parameters in a procedure is something I did not recall.
> > > Based on your point about not using a function due your
Daniel Gustafsson writes:
> +1 on your patch, reading through I can't see anything it misses. Maybe a
> comment above the change with a note on why dbname is tested for NULL there
> would be good?
I thought Jelte's suggestion of clarifying the first comment was good:
-/* pg_recvlogical uses
On Mon, Nov 4, 2024 at 4:27 AM Bertrand Drouvot
wrote:
> Then I think we should go with the "sometimes I don't know the relation OID
> so I want to use the relfilenumber instead, without changing the user
> experience"
> way.
So does the latest version of the patch implement that principal
unifo
On Mon, 4 Nov 2024 at 14:46, Aleksander Alekseev
wrote:
>
> Any reason not to have an interface as simple and straightforward as
> this:
>
> =# SELECT array_random(1, 10, random(0, 3)) FROM generate_series( ... )
> {5}
> {1, 3, 8}
> {7, 6}
> ...
>
Yeah, that looks like a neater API.
Something th
Hi Vignesh,
Here are my review comments for the v47-0002 (DOCS) patch.
==
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index 577bcb4b71..a13f19bdbe 100644
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -517,7 +517,8 @@ CREATE TABLE people (
Generated columns a
On Monday, October 28, 2024 1:40 PM Peter Smith wrote:
>
> Hi Hou-San, here are a few trivial comments remaining for patch v6-0001.
Thanks for the comments!
>
> ==
> doc/src/sgml/protocol.sgml
>
> 3.
> +Primary status update (B)
> +
> +
> +
> +
Hi,
I noticed that the COPY performance on PG 17.0 Windows is worse than PG 16.4.
* Environment
OS: Windows Server 2022
CPU: 22 core * 2CPU
Memory: 512GB
Storage: 700GB HDD
* Input data
10GB csv file
* Executed command
psql -c 'copy table from '\''C:\data.csv'\'' WITH csv'
(Only
>
>
> I'd also like feedback, though I feel very strongly that we should do what
> ANALYZE does. In an upgrade situation, nearly all tables will have stats
> imported, which would result in an immediate doubling of pg_class - not the
> end of the world, but not great either.
>
> Given the recent bu
On Fri, 18 Oct 2024 at 18:17, Peter Geoghegan wrote:
>
> On Wed, Oct 16, 2024 at 1:14 PM Peter Geoghegan wrote:
> > Attached is v10, which is another revision that's intended only to fix
> > bit rot against the master branch. There are no notable changes to
> > report.
>
> Attached is v11, which
> On 4 Nov 2024, at 17:24, Erik Wienhold wrote:
>
> On 2024-11-04 16:13 +0100, Matthias van de Meent wrote:
>> On Mon, 4 Nov 2024 at 15:41, Bruce Momjian wrote:
>>>
>>> Someone emailed me privately saying they were confused because they
>>> thought pg_dump --no-comments would remove SQL comment
Hi Vignesh,
Here are my review comments for your latest patch v47-0001.
==
doc/src/sgml/ddl.sgml
1.
- Generated columns can be replicated during logical replication by
- including them in the column list of the
- CREATE PUBLICATION command.
+ Generated columns are
On Mon, Nov 4, 2024 at 07:49:45PM +0100, Daniel Gustafsson wrote:
> > On 4 Nov 2024, at 17:24, Erik Wienhold wrote:
> > But I also think that
> > "SQL" in front of the command name is unnecessary because the man page
> > uses the "FOOBAR command" form throughout
>
> Agreed.
>
> >--inserts
>
> On 4 Nov 2024, at 21:00, Bruce Momjian wrote:
> Proposed patch attached.
LGTM.
--
Daniel Gustafsson
Jelte Fennema-Nio writes:
> The new documentation looks good to me, but I think the same change
> should be applied to the documentation for pg_receivewal.
Good idea, will do.
regards, tom lane
Hi,
PostgreSQL 17.0 Documentation teach us to run the following command.
regsvr32 pgsql_library_directory/pgevent.dll
On the other hand, pgevent.dll is moved from lib/ directory to bin/directory on
PG 17.0
(It seems that it is moved because of meson)
So, I think the documentation need to be
On Mon, Nov 4, 2024, at 19:34, Masahiko Sawada wrote:
> On Sat, Nov 2, 2024 at 4:08 AM Joel Jacobson wrote:
>>
>> On Fri, Nov 1, 2024, at 22:28, Masahiko Sawada wrote:
>> > As I mentioned in a separate email, if we use the OS default EOL as
>> > the default EOL in raw format, it would not be neces
On Tue, 5 Nov 2024 at 06:39, Ranier Vilela wrote:
> I think we can add a small optimization to this last patch [1].
> The variable *aligned_end* is only needed in the second loop (for).
> So, only before the for loop do we actually declare it.
>
> Result before this change:
> check zeros using BER
On Mon, Nov 4, 2024 at 8:04 AM Michael Paquier wrote:
> On Mon, Nov 04, 2024 at 06:29:42AM +0200, Alexander Korotkov wrote:
> > The attached patchset contains patch 0001, which improves handling of
> > not in recovery state by usage of PromoteIsTriggered(). When
> > (PromoteIsTriggered() == false
On Mon, Nov 4, 2024 at 5:57 PM Heikki Linnakangas wrote:
> On 04/11/2024 17:53, Robert Haas wrote:
> > On Mon, Nov 4, 2024 at 9:19 AM Alvaro Herrera
> > wrote:
> >> It's looking to me like there's just too much cruft in the quest to
> >> avoid having to reach consensus on new syntax. This might
Heikki Linnakangas writes:
> On 30/09/2024 11:15, jian he wrote:
>> In, 0001-func.sgml-Consistently-use-optional-to-indicate-opti.patch
>> -format(formatstr
>> text [, formatarg
>> "any" [, ...] ])
>> +format(formatstr
>> text , formatarg
>> "any" [, ...] )
>> i change it further to
>> +format(fo
> On 4 Nov 2024, at 18:14, Tom Lane wrote:
> perhaps under the illusion that dbname and connection_string can't
> both be NULL.
Ugh, yes, I failed to capture that nuance.
> I think the attached will fix it, but I wonder if there are edge
> cases I'm not thinking of.
+1 on your patch, reading t
On Mon, 4 Nov 2024 at 19:57, Tom Lane wrote:
> I'm intending to go with the attached.
The new documentation looks good to me, but I think the same change
should be applied to the documentation for pg_receivewal.
On Wed, Oct 30, 2024 at 6:45 PM Tatsuo Ishii wrote:
> doesn't work, right? I don't like clients need to know the exact order
> of each protocol extensions.
I agree with this criticism, at least for the most part. Years and
years ago, the only way to specify EXPLAIN options was to say EXPLAIN
[ANA
On 2024-11-04 21:03 +0100, Daniel Gustafsson wrote:
> > On 4 Nov 2024, at 21:00, Bruce Momjian wrote:
>
> > Proposed patch attached.
>
> LGTM.
Seconded.
--
Erik
On Thu, Oct 10, 2024 at 3:55 PM Masahiko Sawada wrote:
>
> On Tue, Oct 8, 2024 at 8:34 PM Michael Paquier wrote:
> >
> > On Mon, Oct 07, 2024 at 03:23:08PM -0700, Masahiko Sawada wrote:
> > > In the benchmark, I've applied the v20 patch set and 'master' in the
> > > result refers to a19f83f87966.
On Tue, Nov 5, 2024 at 7:00 AM Peter Smith wrote:
>
>
> ~
>
> 1b.
> Everywhere in this patch (except here), this is called the
> 'publish_generated_columns' parameter (not "option") so it should be
> called a parameter here also. Anyway, apparently that is the docs rule
> -- see [1].
>
In the thr
Hi,
On Mon, Nov 4, 2024 at 12:28 PM jian he wrote:
>
> hi.
> about v5.
> if (exprs_known_equal(root, expr1, expr2, btree_opfamily))
> {
> /*
> * Ensure that the collation of the expression matches
> * th
On Mon, Nov 04, 2024 at 05:17:54PM +, Bertrand Drouvot wrote:
> Hi,
>
> On Tue, Nov 05, 2024 at 12:24:48AM +1300, David Rowley wrote:
> > On Sat, 2 Nov 2024 at 01:50, Bertrand Drouvot
> > wrote:
> > >
> > > On Fri, Nov 01, 2024 at 09:47:05PM +1300, David Rowley wrote:
> > > > I've attached wh
On 11/3/24 00:09, Tom Lane wrote:
Ashutosh Bapat writes:
On Tue, Oct 29, 2024 at 10:49 PM Tom Lane wrote:
regression=# SELECT x
regression-#FROM ( VALUES (4), (2), (3), (1)
regression(# ORDER BY t1_1.x
regression(# LIMIT 2) t1(x);
ERROR: missing FROM-clause entry for t
On Tue, 5 Nov 2024 at 06:39, Ranier Vilela wrote:
> I think we can add a small optimization to this last patch [1].
I think if you want to make it faster, you could partially unroll the
inner-most loop, like:
// size_t * 4
for (; p < aligned_end - (sizeof(size_t) * 3); p += sizeof(size_t) * 4)
{
On Tue, Nov 05, 2024 at 04:23:34PM +1300, David Rowley wrote:
> I tried your optimisation in the attached allzeros.c and here are my results:
>
> # My version
> $ gcc allzeros.c -O2 -o allzeros && for i in {1..3}; do ./allzeros; done
> char: done in 1543600 nanoseconds
> size_t: done in 196300 nan
On Mon, Nov 4, 2024 at 7:22 PM Joel Jacobson wrote:
>
> On Mon, Nov 4, 2024, at 19:34, Masahiko Sawada wrote:
> > On Sat, Nov 2, 2024 at 4:08 AM Joel Jacobson wrote:
> >>
> >> On Fri, Nov 1, 2024, at 22:28, Masahiko Sawada wrote:
> >> > As I mentioned in a separate email, if we use the OS default
Hi Vignesh,
Here are my review comments for patch v48-0001.
==
src/backend/catalog/pg_publication.c
has_column_list_defined:
1.
+ if (HeapTupleIsValid(cftuple))
+ {
+ bool isnull = true;
+
+ /* Lookup the column list attribute. */
+ (void) SysCacheGetAttr(PUBLICATIONRELMAP, cftuple,
+An
On Mon, Nov 4, 2024 at 7:34 PM Dean Rasheed wrote:
>
> Testing this with an array with non-default lower bounds, it fails to
> preserve the array bounds, which I think it should (note:
> array_reverse() and array_shuffle() do preserve the bounds):
>
> SELECT array_reverse(a), array_shuffle(a), arr
On 30.10.24 10:03, Jelte Fennema-Nio wrote:
On Mon, 28 Oct 2024 at 16:51, Peter Eisentraut wrote:
Thoughts?
+ snprintf(xloc, sizeof(xloc), "%X/%X",
LSN_FORMAT_ARGS(logptr))
+ pq_sendstring(&buf, xloc);
nit: I feel that sending the LSN as a string seems unn
On Wed, Oct 30, 2024 at 9:46 PM vignesh C wrote:
>
...
+ /*
+ * For non-column list publications—such as TABLE (without a column
+ * list), ALL TABLES, or ALL TABLES IN SCHEMA publications consider
+ * all columns of the table, including generated columns, based on the
+ * pubgencols option.
+ */
On Mon, Nov 4, 2024 at 8:04 AM Michael Paquier wrote:
>
> On Mon, Nov 04, 2024 at 06:29:42AM +0200, Alexander Korotkov wrote:
> > The attached patchset contains patch 0001, which improves handling of
> > not in recovery state by usage of PromoteIsTriggered(). When
> > (PromoteIsTriggered() == fal
On Wed, 30 Oct 2024, 18:45 Jelte Fennema-Nio, wrote:
>
> On Wed, 30 Oct 2024 at 18:18, Ants Aasma wrote:
> > The idea is great, I have been wanting something like this for a long
> > time. For future proofing it might be a good idea to not require the
> > communicated-waited value to be a LSN.
>
On Sat, 2 Nov 2024 at 01:50, Bertrand Drouvot
wrote:
>
> On Fri, Nov 01, 2024 at 09:47:05PM +1300, David Rowley wrote:
> > I've attached what I thought a more optimal version might look like in
> > case anyone thinks making it better is a good idea.
> >
>
> Thanks for the proposal!
>
> I like the
On Thu, 24 Oct 2024 at 18:08, hugo <2689496...@qq.com> wrote:
>
> Hi!
>
>When looking at the partition-related code, I found that the
> ispartitioned
>
> field in CreateStmtContext is not used. It looks like we can safely remove it
> and
>
> avoid invalid assignment logic.
>
>
>
> Here's
Hi,
On Fri, Nov 01, 2024 at 12:50:10PM +, Bertrand Drouvot wrote:
> Hi,
>
> On Fri, Nov 01, 2024 at 09:47:05PM +1300, David Rowley wrote:
> > On Fri, 1 Nov 2024 at 20:49, Michael Paquier wrote:
> > I've attached what I thought a more optimal version might look like in
> > case anyone thinks
On Mon, Nov 04, 2024 at 08:52:04AM +, Bertrand Drouvot wrote:
> Yeah, but not only the relfilenode ones. All kinds were affected as random
> data
> was in the padding bytes for all of them.
A quick test where I add some padding junk in PgStat_HashKey proves
that you are right. I'm wondering
On Sat, Nov 2, 2024 at 4:11 AM Michael Paquier wrote:
> Now, here is a fancy case: SAVEPOINT and its two brothers. An error
> would be reported on HEAD if attempting a SAVEPOINT, complaining that
> we are not in a transaction block. The patch causes a different, more
> confusing, failure:
> FATA
Hi,
On Mon, Nov 04, 2024 at 06:49:04PM +0900, Michael Paquier wrote:
> On Mon, Nov 04, 2024 at 08:52:04AM +, Bertrand Drouvot wrote:
> > Yeah, but not only the relfilenode ones. All kinds were affected as random
> > data
> > was in the padding bytes for all of them.
>
> A quick test where I
On Wed, 9 Oct 2024 at 19:24, Daniel Gustafsson wrote:
>
> > On 9 Oct 2024, at 16:05, Heikki Linnakangas wrote:
>
> Thanks for looking!
>
> > I guess the '1000' was supposed to be the maximum, but ParseVariableDouble
> > doesn't take a maximum.
>
> Doh, I had a max parameter during hacking but re
1 - 100 of 104 matches
Mail list logo
