On Tue, Jan 21, 2025 at 10:21:51PM -0500, Corey Huinker wrote:
> After some research, I think that we should treat partitioned indexes like
> we were before, and just handle the existing special case for regular
> indexes.
Hmm, why? Sounds strange to me to not have the same locking semantics
for
Hi,
On Wed, Jan 22, 2025 at 04:46:00PM -0800, Masahiko Sawada wrote:
> I would like to summarize the proposed approaches thus far:
Thanks!
> Regarding the user interface, there are three approaches:
>
> 1. Implementing SQL function controls (e.g.,
> pg_activate_logical_decoding() and pg_deactiv
On Wed, 22 Jan 2025 at 09:00, Zhijie Hou (Fujitsu)
wrote:
>
> On Tuesday, January 21, 2025 1:31 AM vignesh C wrote:
>
> Hi,
>
> >
> > On Mon, 20 Jan 2025 at 17:31, Amit Kapila wrote:
> > >
> > > On Sat, Jan 18, 2025 at 10:31 AM vignesh C wrote:
> > > >
> > > > Attached patch has the fix for thi
On Wed, Jan 22, 2025 at 03:34:11PM +, Dagfinn Ilmari Mannsåker wrote:
> As I mentioned elsewhere in the thread, I left those alone since the
> error message uses the short spelling even if the command had the long
> one. We could add the long spelling to the preceding comments, like the
> seco
Hi Shubham.
The v12-0001 works OK, but your added TAP tests of this patch do not
conform to the new style of the fat-comma parameter passing since the
recent commit [1], so you'll need to fix them so they do...
==
src/bin/pg_basebackup/t/040_pg_createsubscriber.pl
1.
+command_checks_all(
+ [
čt 23. 1. 2025 v 0:55 odesílatel Jim Jones
napsal:
> Hi Chapman & Robert
>
> Many thanks for the input
>
> On 22.01.25 22:35, Chapman Flack wrote:
> > On 01/22/25 13:41, Robert Treat wrote:
> >> So even if we are following the spec (which I think technically we may
> >> not be),
> > There are def
> Hi,
> I was able to reproduce exactly the problem, with clean compile
> and --enable-cassert:
> test=# SELECT x,y,lead(y) IGNORE NULLS OVER (ORDER BY x) FROM
> (VALUES(1,NULL),(2,2),(3,NULL)) AS v(x,y);
> x | y | lead
> ---+---+--
> 1 | |2
> 2 | 2 |2
> 3 | |2
> (3 rows)
>
Patch v56-0001 LGTM.
==
Kind Regards,
Peter Smith.
Fujitsu Australia
HI Japin
Thank you for you test ,It seems NUM_XLOGINSERT_LOCKS 64 is great , I
think it doesn't need to grow much,What do you think?
Regards
On Thu, Jan 23, 2025 at 10:30 AM Japin Li wrote:
> On Sat, 18 Jan 2025 at 14:53, Yura Sokolov
> wrote:
> > Since it seems Andres missed my request
>
There’s a typo in the commit message (ratio instead of rate). Besides this the
patch looks ready for committer.
Best regards, Andrey Borodin.
On Wed, Jan 22, 2025 at 09:01:09AM -0800, Paul Ramsey wrote:
> This is the Knowledge that was sitting right in front of me, but I could not
> see.
> From the road to Damascus,
Note also that there is some documentation showing how to write a
signal handler and what should not be done:
https://www
Patch v14-0001 LGTM
==
Kind Regards,
Peter Smith.
Fujitsu Australia
> Hello,
> I also played with the v4 patch and it produces correct result:
> test=# SELECT x,y,lead(y) IGNORE NULLS OVER (ORDER BY x) FROM
> (VALUES(1,NULL),(2,2),(3,NULL)) AS v(x,y);
> x | y | lead
> ---+---+--
> 1 | |2
> 2 | 2 |
> 3 | |
> (3 rows)
>
> test=#
> It is from today's
Hi Euler,
As you may have already read, separating the max_replication_slots parameter
is also discussed in the following thread.
https://www.postgresql.org/message-id/flat/CAA4eK1KF4MbyWmPj9ctNo8Fiei%3DK91RGYtzV5ELeCvR%3D_rqNgg%40mail.gmail.com#3012c5c18e40e
21ac553b42d53249e42
I agree with sep
On Thu, Jan 23, 2025 at 2:17 PM Amit Kapila wrote:
>
> On Wed, Jan 22, 2025 at 9:21 AM Peter Smith wrote:
> >
> > On Wed, Jan 22, 2025 at 5:36 AM Masahiko Sawada
> > wrote:
> > >
> > > On Sun, Jan 19, 2025 at 7:53 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Fri, Jan 17, 2025 at 11:19 PM Ma
On Wed, Jan 22, 2025 at 7:22 PM Peter Eisentraut wrote:
>
> On 21.01.25 09:27, vignesh C wrote:
> >> Maybe I have some fundamental misunderstanding here, but I don't see
> >> why "this approach cannot be used with psql because older version
> >> servers may not have these columns". Not having the
Hi Vignesh,
Patch v55-0002 (the docs chapter one) is a re-badged v54-0005.
I've addressed the PeterE review comments [1] as detailed below.:
FYI, because v55-0001 was broken I have posted this DOCS patch
separately. Please add it back into the patch set as vXX-0002 when you
next post it.
On Th
On Wed, Jan 22, 2025 at 1:54 AM Benoit Lobréau
wrote:
> I don’t think pg_basebackup fits naturally under the "File System Level
> Backup" section. I considered creating a "Standalone Physical Backup"
> section with two subsections: FS-level backups and pg_basebackup, but
> that didn’t feel right
On Wed, Jan 22, 2025 at 9:21 AM Peter Smith wrote:
>
> On Wed, Jan 22, 2025 at 5:36 AM Masahiko Sawada wrote:
> >
> > On Sun, Jan 19, 2025 at 7:53 PM Amit Kapila wrote:
> > >
> > > On Fri, Jan 17, 2025 at 11:19 PM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Wed, Jan 15, 2025 at 4:43 PM Pet
On Wed, Jan 22, 2025 at 9:44 PM Sergey Tatarintsev
wrote:
>
> 22.01.2025 18:41, Shlok Kyal пишет:
>
> Also we still don't care about foreign partitions (as I wrote earlier
> we should raise an ERROR for such publications).
>
I think dealing with this separately from the origin vs. partitioned
ta
On Sat, 18 Jan 2025 at 14:53, Yura Sokolov wrote:
> Since it seems Andres missed my request to send answer's copy,
> here it is:
>
> On 2025-01-16 18:55:47 +0300, Yura Sokolov wrote:
>> 16.01.2025 18:36, Andres Freund пишет:
>>> Hi,
>>>
>>> On 2025-01-16 16:52:46 +0300, Yura Sokolov wrote:
Go
Hi!
On 22.01.2025 11:37, John Naylor wrote:
On Fri, Jan 17, 2025 at 4:50 PM John Naylor wrote:
It would be a lot more readable to revert the offending commit
instead, since its predecessor had a much simpler bytewise loop.
Agreed that reverting seems as a preferable way, and here's why.
I f
On Thu, Jan 23, 2025 at 1:00 AM vignesh C wrote:
>
> On Wed, 22 Jan 2025 at 16:22, Amit Kapila wrote:
> >
> > On Tue, Jan 21, 2025 at 1:58 PM vignesh C wrote:
> > >
> >
> > I have pushed the 0001 patch. I don't think 0002 and 0003 need to be
> > committed separately. So, combine them in 0004 and
On Fri, Jan 10, 2025 at 12:33 AM Masahiko Sawada wrote:
>
> On Thu, Jan 9, 2025 at 3:29 AM Ashutosh Bapat
> wrote:
> >
> > On Tue, Dec 31, 2024 at 10:15 AM Masahiko Sawada
> > wrote:
> > >
> > > Hi all,
> > >
> > > Logical decoding (and logical replication) are available only when
> > > wal_lev
Some review comments for patch v54-0004.
(since preparing this post, I saw you have already posted v55-0001 but
AFAIK, since 55-0001 is just a merge, the same review comments are
still applicable)
==
doc/src/sgml/catalogs.sgml
1.
- If true, this publication replicates the store
Hi Chapman & Robert
Many thanks for the input
On 22.01.25 22:35, Chapman Flack wrote:
> On 01/22/25 13:41, Robert Treat wrote:
>> So even if we are following the spec (which I think technically we may
>> not be),
> There are definite ways in which we're not following the SQL/XML spec,
> which we
Hi,
Thanks for continuing to work on this.
On 1/22/25 19:17, Corey Huinker wrote:
> This is a separate thread for work started in [1] but focused purely on
> getting the following functions working:
>
> * pg_set_extended_stats
> * pg_clear_extended_stats
> * pg_restore_extended_stats
>
> These
> On 22 Jan 2025, at 19:59, Joe Conway wrote:
> I found it necessary to add:
> #include
> in
> contrib/pgcrypto/openssl.c
> to avoid a symbol not defined warning.
Makes sense, it doesn't reproduce in my tree but reading OpenSSL code it seems
very plausible (and clearly happens in your environ
On Sat, Jan 18, 2025 at 12:10 PM Robert Treat wrote:
>
> Hey Melanie, took a walk through this version, some minor thoughts below.
Thanks! Attached v9 incorporates all your suggested changes.
> --- a/doc/src/sgml/config.sgml
> +++ b/doc/src/sgml/config.sgml
> @@ -9128,9 +9128,10 @@ COPY postgres
On Wed, 2025-01-22 at 21:48 +0100, Tomas Vondra wrote:
> But these estimates are often pretty fundamentally unreliable - maybe
> not for simple examples, but once you put an aggregate on top of a
> join,
> the errors can be pretty wild.
It would be conditional on whether there's some kind of memor
On 20.01.2025 17:20, Ilia Evdokimov wrote:
On 15.01.2025 20:16, Sami Imseih wrote:
Probably, but first I suggest benchmarking with sampling applied to
all queries. If the results are good, we can later filter certain
queries based on different characteristics.
Absolutely. The benchmark numbe
I wrote:
> * It's kind of sad that we have to add yet another field to
> AfterTriggerSharedData, especially since this one will cost 8 bytes
> thanks to alignment considerations. I'm not sure if there's another
> way, but it seems like ats_relid, ats_rolid, and ats_modifiedcols
> are all going to
On Wed, 2025-01-22 at 19:03 +0100, Peter Eisentraut wrote:
> Building a collation provider on this came much later. It was
> possibly
> a mistake how that was done.
It wasn't a mistake. "Stability within a PG major version" was called a
*benefit* near the top of the first email on the subject[1]
On 01/22/25 13:41, Robert Treat wrote:
> So even if we are following the spec (which I think technically we may
> not be),
There are definite ways in which we're not following the SQL/XML spec,
which we document in an appendix[1]. The one that matters here is that
we just have a single XML type in
On Wed, Jan 22, 2025 at 8:02 AM Shinya Kato
wrote:
>
> Hi, thank you for the reviews.
>
> On 2025-01-18 00:45, Robert Treat wrote:
> > This looks pretty good to me. I think there are a couple of minor
> > grammar changes that could be made, and I think the pg_dumpall section
> > could use a couple
On Mon, Dec 9, 2024 at 1:22 AM Dilip Kumar wrote:
>
> Are we planning to commit this refactoring? I think this refactoring
> makes the overall code of BitmapHeapNext() quite clean and readable.
> I haven't read all patches but 0001-0006 including 0009 makes this
> code quite clean and readable. I
On Wed, Jan 15, 2025 at 12:05 PM Andres Freund wrote:
>
> If you have wal_recycle=true, this overhead will only be paid the first time a
> WAL segment is used, of course, not after recycling.
Today, our pg_stat_wal view [1] does not report the no. of WAL
segments recycled. How about if we add a c
On Wed, Jan 22, 2025 at 2:04 AM Bertrand Drouvot
wrote:
>
> Hi,
>
> On Mon, Jan 06, 2025 at 10:32:52PM -0800, Masahiko Sawada wrote:
> > On Mon, Jan 6, 2025 at 3:20 AM Ashutosh Bapat
> > wrote:
> > >
> > > On Sat, Jan 4, 2025 at 6:03 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Fri, Jan 3
On 1/10/25 19:00, James Hunter wrote:
> ...
>
> **Proposal:**
>
> I propose that we add a “query_work_mem” GUC, which works by
> distributing (using some algorithm to be described in a follow-up
> email) the entire “query_work_mem” to the query’s operators. And then
> each operator will spill when
On Sun, Jan 19, 2025 at 03:57:18PM -0800, Hari Krishna Sunder wrote:
> The restore side speedups suggested by Yang seem reasonable and can
> potentially speed up the process. We can even go a bit further by starting
> the new postgres in a --binary-upgrade mode and skip some of these locks
> comple
On 1/21/25 22:26, Jeff Davis wrote:
> On Fri, 2025-01-10 at 10:00 -0800, James Hunter wrote:
>> How should “query_work_mem” work? Let’s start with an example:
>> suppose
>> we have an OLAP query that has 2 Hash Joins, and no other operators
>> that use work_mem.
>
> So we plan first, and then assi
Hunaid Sohail writes:
> I have attached a new patch v8 with the following changes:
> 1. Fixed cases reported by Maciek.
> 2. Handles leading spaces in input string.
I pushed this after fooling with it a bit more:
* The way you did the leading-space skip would actually skip
anything whatsoever un
On Sun, Jan 19, 2025 at 09:55:32PM +0100, Michail Nikolaev wrote:
> > Stepping back, any variation in the total ordering of step-start and
> > step-complete events necessarily changes the expected output. Hence, we
> want
> > to freeze that ordering. We could do that directly, by having
> isola
On Tue, Jan 21, 2025 at 03:23:31PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > I did write a patch in Novemer 2023 to pass the dimension to the layers
> > that needed it, but it was considered too much code compared to its
> > value:
> > https://www.postgresql.org/message-id/zvwi_ozt8z9
On 1/21/25 17:57, Daniel Gustafsson wrote:
On 21 Jan 2025, at 22:13, Joe Conway wrote:
I think this is a non-issue. Every implementation I have seen, the OS-level
enabling of FIPS mode is just a way to ensure openssl is automatically put into
FIPS mode when the library is loaded, just as if
On 20.01.25 15:01, Aleksander Alekseev wrote:
> This should use ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE, rather than
> ERRCODE_INVALID_PARAMETER_VALUE, for consistency with other similar
> errors.
>
> The bytea -> int[248] cast functions should not be marked as leakproof
> -- see the docs on the
On Tue, Jan 21, 2025 at 6:36 PM Jim Jones wrote:
> On 21.01.25 23:45, Robert Treat wrote:
> > Is there some concrete use case you have seen that this would help
> > with? Not objecting to adding it, but you've mentioned this migration
> > idea twice but it seems to me this doesn't conform with exi
On Wed, 2025-01-22 at 19:08 +0100, Peter Eisentraut wrote:
> But I don't think it would be a compile-time decision. I think it
> would
> be a run-time selection, similar to the theorized multiple-ICU-
> versions
> feature. (Those two features might even go together, since a given
> ICU
> versi
Hi,
On 2025-01-22 09:50:18 -0800, Paul Ramsey wrote:
> > On Jan 22, 2025, at 9:36 AM, Andres Freund wrote:
> > On 2025-01-22 10:22:45 -0600, Nathan Bossart wrote:
> >> On Wed, Jan 22, 2025 at 07:57:52AM -0800, Paul Ramsey wrote:
> >>> The problem we are having in extension land is that we often r
Laurenz Albe writes:
> [ v4-0001-Make-AFTER-triggers-run-with-the-correct-user.patch ]
I started to look at this and got distracted by wondering why
afterTriggerAddEvent's scanning loop wasn't checking ats_modifiedcols.
That led to ea68ea632, which means this now needs a minor rebase.
I have a c
On 06.01.25 15:52, Peter Eisentraut wrote:
On 03.01.25 21:51, Dagfinn Ilmari Mannsåker wrote:
Peter Eisentraut writes:
I suggest we define pg_noreturn as
1. If C11 is supported, then _Noreturn, else
2. If GCC-compatible, then __attribute__((noreturn)), else
Would it be worth also checking
On 20.01.25 22:39, Jeff Davis wrote:
On Fri, 2024-11-15 at 17:09 +0100, Peter Eisentraut wrote:
The practice of regularly updating the Unicode files is older than
the
builtin collation provider. It is similar to updating the time zone
files, the encoding conversion files, the snowball files, et
On 21.01.25 02:06, Jeremy Schneider wrote:
FWIW, after adding ICU support I personally don't think there's a
pressing need to continue updating the tables anymore.
That appears to ignore what these tables are actually used for. They
are used for Unicode normalization, which is used by SCRAM.
22.01.2025 20:57, Álvaro Herrera пишет:
Yes. You need to attach child indexes on all partitions so that this
index becomes valid.
Thanks!
--
With best regards,
Dmitry Koval
Postgres Professional: http://postgrespro.com
Hi,
On 2025-01-22 11:43:20 -0600, Nathan Bossart wrote:
> On Wed, Jan 22, 2025 at 11:21:03AM -0500, Andres Freund wrote:
> > fsync(open(oldname1));
> > fsync(open(oldname2));
> > ..
> > fsync(open(oldnameN));
> >
> > rename(oldname1, newname1);
> > rename(oldname2, newname2);
> > ..
> > rename(old
Alexander Kuzmenkov writes:
> Yeah, I'm referencing this one in my email, but it's a series of
> patches that does a major refactoring changing thousands of lines. I'm
> not sure when or if it's going to land, do you think applying a quick
> fix first would make sense? It makes trivial changes in
On Wed, Jan 22, 2025 at 6:15 PM Tom Lane wrote:
> Really I'd think the right place to be fixing this is at a higher
> level. Where are the repetitive find_ec_member_matching_expr calls
> coming from?
I'm not aware of the repeated calls for the same child, and I mostly
see it called once for ever
On 2025-Jan-22, Dmitry Koval wrote:
> Hi!
> If you create an index on a partitioned table using a method that uses
> pg_dump:
>
> (a) "ALTER TABLE ONLY ... ADD CONSTRAINT .. PRIMARY KEY ..."
> or
> (b) "CREATE INDEX ... ON ONLY ..."
>
> then the index for the partitioned table is created with th
Hi!
If you create an index on a partitioned table using a method that uses
pg_dump:
(a) "ALTER TABLE ONLY ... ADD CONSTRAINT .. PRIMARY KEY ..."
or
(b) "CREATE INDEX ... ON ONLY ..."
then the index for the partitioned table is created with the INVALID
flag.This can be verified using an exampl
> On Jan 22, 2025, at 9:36 AM, Andres Freund wrote:
>
> Hi,
>
> On 2025-01-22 10:22:45 -0600, Nathan Bossart wrote:
>> On Wed, Jan 22, 2025 at 07:57:52AM -0800, Paul Ramsey wrote:
>>> The problem we are having in extension land is that we often run
>>> functions in external libraries that tak
On Wed, Jan 22, 2025 at 11:21:03AM -0500, Andres Freund wrote:
> fsync(open(oldname1));
> fsync(open(oldname2));
> ..
> fsync(open(oldnameN));
>
> rename(oldname1, newname1);
> rename(oldname2, newname2);
> ..
> rename(oldnameN, newnameN);
>
> fsync(open(newname1));
> fsync(open(newname2));
> ..
Hi,
On 2025-01-22 10:22:45 -0600, Nathan Bossart wrote:
> On Wed, Jan 22, 2025 at 07:57:52AM -0800, Paul Ramsey wrote:
> > The problem we are having in extension land is that we often run
> > functions in external libraries that take a long time to return, and we
> > would like to ensure that PgSQ
On 2025-Jan-22, Alexander Kuzmenkov wrote:
> On Wed, Jan 22, 2025 at 5:36 PM Alvaro Herrera
> wrote:
> > I think this is closely related to the work Yuya Watari has been doing
> > at
> > https://postgr.es/m/caj2pmkzzhrhgq5uv0y+stkqx7xvgzenmhl98ubkm-oarvk9...@mail.gmail.com
> > Perhaps you could
> On Jan 22, 2025, at 8:50 AM, Andres Freund wrote:
>
>> It is possible we have been Doing It Wrong all this time, and would love
>> some pointers on the right way to do this.
>
> All your interrupt handler is doing "for you" is setting
> http_interrupt_requested, right? Why do you need tha
Hi,
On 2025-01-22 11:50:30 -0500, Andres Freund wrote:
> On 2025-01-22 07:57:52 -0800, Paul Ramsey wrote:
> > It is possible we have been Doing It Wrong all this time, and would love
> > some pointers on the right way to do this.
>
> All your interrupt handler is doing "for you" is setting
> htt
On Wed, Jan 22, 2025 at 5:36 PM Alvaro Herrera wrote:
> I think this is closely related to the work Yuya Watari has been doing
> at
> https://postgr.es/m/caj2pmkzzhrhgq5uv0y+stkqx7xvgzenmhl98ubkm-oarvk9...@mail.gmail.com
> Perhaps you could contribute by reviewing that patch series.
Yeah, I'm ref
Hi,
On 2025-01-22 07:57:52 -0800, Paul Ramsey wrote:
> I just ran across this change when a bunch of CI’s I run barfed.
>
> https://github.com/postgres/postgres/commit/d4a43b283751b23d32bbfa1ecc2cad2d16e3dde9
>
> The problem we are having in extension land is that we often run functions
> in exter
Hello,
On 2025-Jan-22, Alexander Kuzmenkov wrote:
> Hi hackers,
>
> There's currently an unfortunate CPU sink in the planning for
> partitioned tables. It happens both for the declarative partitioning,
> and for the partitioning through inheritance like we use in
> TimescaleDB.
>
> The gist of
On Wed, Jan 22, 2025 at 07:57:52AM -0800, Paul Ramsey wrote:
> I just ran across this change when a bunch of CI´s I run barfed.
Oops, sorry.
> The problem we are having in extension land is that we often run
> functions in external libraries that take a long time to return, and we
> would like to
On 14.01.25 21:01, David E. Wheeler wrote:
I tried `prefix` with semver[3] and it did not work:
``` console
❯ make PG_CONFIG=~/dev/misc/postgres/pgsql-devel/bin/pg_config
prefix=/Users/david/pgsql-test
gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement
-Werror=vla -We
Hi,
On 2025-01-22 01:14:22 +, Andy Fan wrote:
> Andres Freund writes:
> > FWIW, I've seen the fsyncs around recycling being a rather substantial
> > bottleneck. To the point of the main benefit of larger segments being the
> > reduction in number of fsyncs at the end of a checkpoint. I think
22.01.2025 18:41, Shlok Kyal пишет:
On Wed, 22 Jan 2025 at 09:00, Zhijie Hou (Fujitsu)
wrote:
On Tuesday, January 21, 2025 1:31 AM vignesh C wrote:
Hi,
On Mon, 20 Jan 2025 at 17:31, Amit Kapila wrote:
On Sat, Jan 18, 2025 at 10:31 AM vignesh C wrote:
Attached patch has the fix for thi
Nathan,
I just ran across this change when a bunch of CI’s I run barfed.
https://github.com/postgres/postgres/commit/d4a43b283751b23d32bbfa1ecc2cad2d16e3dde9
The problem we are having in extension land is that we often run functions in
external libraries that take a long time to return, and w
On Wed, Jan 22, 2025 at 01:14:22AM +, Andy Fan wrote:
> Andres Freund writes:
>> FWIW, I've seen the fsyncs around recycling being a rather substantial
>> bottleneck. To the point of the main benefit of larger segments being the
>> reduction in number of fsyncs at the end of a checkpoint. I t
On Tue, Jan 21, 2025 at 11:23:06AM -0500, Andres Freund wrote:
> On 2025-01-21 10:13:14 -0600, Nathan Bossart wrote:
>> On Tue, Jan 21, 2025 at 09:52:51AM -0600, Nathan Bossart wrote:
>> > On Tue, Jan 21, 2025 at 03:31:27AM +, Andy Fan wrote:
>> >> 3. Why is the purpose of preallocated_segments
Hi hackers,
There's currently an unfortunate CPU sink in the planning for
partitioned tables. It happens both for the declarative partitioning,
and for the partitioning through inheritance like we use in
TimescaleDB.
The gist of it is that there's a linear search of the EM corresponding
to the gi
On Wed, 22 Jan 2025 at 09:00, Zhijie Hou (Fujitsu)
wrote:
>
> On Tuesday, January 21, 2025 1:31 AM vignesh C wrote:
>
> Hi,
>
> >
> > On Mon, 20 Jan 2025 at 17:31, Amit Kapila wrote:
> > >
> > > On Sat, Jan 18, 2025 at 10:31 AM vignesh C wrote:
> > > >
> > > > Attached patch has the fix for thi
"David G. Johnston" writes:
> On Wednesday, January 22, 2025, Daniel Gustafsson wrote:
>> On 22 Jan 2025, at 11:23, Daniel Gustafsson wrote:
>>> On 22 Jan 2025, at 09:27, Robin Dupret wrote:
-special provision: you must write
+special provision you must write:
>> Re-reading i
Hi Michael,
Thanks for committing!
Michael Paquier writes:
> On Tue, Jan 21, 2025 at 02:17:03PM +, Dagfinn Ilmari Mannsåker wrote:
>> Thanks again for reviewing this monster patch.
>
> +$node->command_checks_all(
> + [ 'pg_amcheck', '--exclude-user' => 'no_such_user', 'postgres' ],
>
> Ex
On Wed, Jan 22, 2025 at 11:04:22AM +, chiranmoy.bhattacha...@fujitsu.com
wrote:
> If there is no further feedback from the community, may we submit the
> patch for the next commit fest?
I would encourage you to create a commitfest entry so that it is picked up
by our automated patch testing t
On Wed, 22 Jan 2025 at 17:02, Yura Sokolov wrote:
> I believe, I know why it happens: I was in hurry making v2 by
> cherry-picking internal version. I reverted some changes in
> CalcCuckooPositions manually and forgot to add modulo
> PREV_LINKS_HASH_CAPA.
>
> Here's the fix:
>
> pos->pos[0
On Wed, Jan 22, 2025 at 9:08 AM Peter Eisentraut wrote:
> > It might be worth holding off for now. It's possible that I'll find
> > --header-insertion=iwyu has big problems in some unforeseen way. But
> > offhand it looks like a real improvement, even though I foresee
> > certain minor downsides.
Hi,
The attached patch enables SCRAM authentication for dblink connections when
using dblink_fdw without requiring a plain-text password on user mapping
properties. The implementation is very similar to what was implemented on
postgres_fdw [0].
To make it more closer to what was implemented on po
22.01.2025 10:54, Japin Li wrote:
On Wed, 22 Jan 2025 at 10:25, Yura Sokolov wrote:
22.01.2025 09:09, Japin Li пишет:
Hi, Yura Sokolov
Thanks for updating the patch.
I test the v2 patch using BenchmarkSQL 1000 warehouse, and here is the tpmC
result:
case | min| avg
On 15.01.25 20:51, Peter Geoghegan wrote:
On Wed, Jan 15, 2025 at 2:21 PM Peter Eisentraut wrote:
I have committed this. Thanks for the feedback.
Thanks for working on this.
Is it worth documenting how to get clangd working sensibly with
"--header-insertion=iwyu"?
I enabled it just now. I
Hi everyone,
Many thanks for all your great feedback.
> In any case, Aleksander, I don't mean to sign you up for all that; the
> `ssl` suite also seems good enough to me if you're interested in
> pursuing that side of the patch further.
OK, I moved the named tests to src/test/ssl/t/003_sslinfo.p
22.01.2025 15:37, Japin Li пишет:
On Wed, 22 Jan 2025 at 16:49, Japin Li wrote:
On Wed, 22 Jan 2025 at 11:22, Yura Sokolov wrote:
22.01.2025 10:54, Japin Li пишет:
On Wed, 22 Jan 2025 at 10:25, Yura Sokolov wrote:
22.01.2025 09:09, Japin Li пишет:
Hi, Yura Sokolov
Thanks for updating the
Hi all,
I am writing to propose an enhancement to the pg_createsubscriber
utility that enables it to automatically fetch all non-template
databases from the publisher when no specific databases are specified
by the user. This was an open item from [1] that was planned for
future implementation. Th
What does this patch give on aglobal scale? Does it save much memory or
increase performance? How many times?
This patch makes the code semantically more correct and we don't lose
anything. It is obviously not about performance or memory optimisation.
This will only reduce the size of the
$P
On 21.01.25 09:27, vignesh C wrote:
Maybe I have some fundamental misunderstanding here, but I don't see
why "this approach cannot be used with psql because older version
servers may not have these columns". Not having the columns is the
whole point of using an alias approach in the first place e
On Wednesday, January 22, 2025, Daniel Gustafsson wrote:
> > On 22 Jan 2025, at 11:23, Daniel Gustafsson wrote:
> >> On 22 Jan 2025, at 09:27, Robin Dupret wrote:
>
> >> -special provision: you must write
> >> +special provision you must write:
> >
> > Nice catch, will fix.
>
> Re-readi
Hi,
I have attached a new patch v8 with the following changes:
1. Fixed cases reported by Maciek.
2. Handles leading spaces in input string.
I have also added a few more negative tests after Maciek reported
a few cases.
I have also updated the format in the round trip test:
...to_char(i, 'FMRN')
Hi, thank you for the reviews.
On 2025-01-18 00:45, Robert Treat wrote:
This looks pretty good to me. I think there are a couple of minor
grammar changes that could be made, and I think the pg_dumpall section
could use a couple tweaks, specifically 1) not all incantations of
pg_dumpall emit psql
Dear Hackers,
I hope you may find this patch worth to consider. You may consider this patch
as one more step to a complete migration to FullTransactionId in twophase.c for
17+ versions.
The patch fixes TwoPhaseFilePath function. The current version gets
TransactionId as an argument and makes a
On Wed, 22 Jan 2025 at 16:49, Japin Li wrote:
> On Wed, 22 Jan 2025 at 11:22, Yura Sokolov wrote:
>> 22.01.2025 10:54, Japin Li пишет:
>>> On Wed, 22 Jan 2025 at 10:25, Yura Sokolov wrote:
22.01.2025 09:09, Japin Li пишет:
> Hi, Yura Sokolov
> Thanks for updating the patch.
> I
On Fri, 2024-09-13 at 16:18 +0900, Yugo Nagata wrote:
> I've attached a updated patch. The test is rewritten using
> has_largeobject_privilege()
> function instead of calling loread & lowrite, which makes the test a bit
> simpler.
> Thare are no other changes.
When I tried to apply this patch, I
> Attached version moves the setting of IGNORE_NULLS to the window
> function itself, with the functions that don't allow it erroring out.
> This is done with a new api: WinCheckAndInitializeNullTreatment.
>
> Custom functions that don't call this will simply not have the
> IGNORE_NULLS option set
Hi,
On Tue, Nov 05, 2024 at 06:36:47PM +0100, Frédéric Yhuel wrote:
> Hi, I thought it would be nice to give the user a better idea of what
> avg_leaf_density and leaf_fragmentation mean.
>
> Patch attached. What do you think?
Yeah, I think that can not hurt to give more details, thanks for the
On Fri, Jan 17, 2025 at 3:39 AM Peter Smith wrote:
>
> Patch v11-0001 LGTM.
>
> ==
Following the recent comments on Patch v11-0001, the patch was not
applied to the HEAD. I have addressed the feedback and prepared a
rebased version to incorporate the necessary adjustments.
Please find the upd
I realized I didn't attach the patch.
v2-0001-SVE-support-for-hex-encode-and-hex-decode.patch
Description: v2-0001-SVE-support-for-hex-encode-and-hex-decode.patch
1 - 100 of 121 matches
Mail list logo
