On 2025/01/12 2:04, Ryo Kanbayashi wrote:
I wrote a patch for release v13 - v17 additionally and tested it for
each release branch :)
As a result, two patch is needed for this fix.
Thanks for the patches! Barring any objections,
I plan to commit them with the following commit log.
-
On Sat, 11 Jan 2025 19:03:43 -0500
Andres Freund wrote:
> If llvmjit.so isn't available, jit is silently disabled.
Thanks - this is exactly the bit I wasn't sure about. The reason I came
to the hackers list is because I thought this wasn't the case. Normally
I don't delete arbitrary files after
On Wed, 8 Jan 2025 at 12:32, Jeff Davis wrote:
> I committed the earlier cleanup patches and rebased the rest. Attached.
While I do understand the desire to reduce Hash Agg's memory usage,
has this really been through enough performance testing to be getting
committed?
I looked at the changes e0
On Thu, Jan 09, 2025 at 11:39:53AM +0200, Heikki Linnakangas wrote:
> On 07/01/2025 23:56, Noah Misch wrote:
> > On Tue, Dec 24, 2024 at 12:18:09AM +0200, Heikki Linnakangas wrote:
> > > I'm thinking of the attached to fix this. It changes the strategy for
> > > detecting concurrent cache invalidat
On 1/10/25 15:54, Melanie Plageman wrote:
> On Thu, Jan 9, 2025 at 6:59 PM Tomas Vondra wrote:
>>
>> ...
>
>> Robert's idea kept using buffered files, but limited how many we can
>> fill at any phase. Say we'd use a limit of 1024 batches, but we actually
>> need 1M batches. Then we'd do the build
On Fri, Jan 10, 2025 at 11:22:37AM -0800, James Hunter wrote:
> Attached the proposed one-line fix.
Yes, that should be fine as-is based on the original topic.
--
Michael
signature.asc
Description: PGP signature
Hi,
On 2025-01-11 13:22:39 -0800, Jeremy Schneider wrote:
> It's a cleaner solution if JIT works more like an extension, and we can
> run a single build and split JIT into a separate package.
It does work like that. Only llvmjit.so has the llvm dependency, the main
postgres binary doesn't link to
On 1/11/25 00:09, Melanie Plageman wrote:
> On Fri, Jan 10, 2025 at 11:18 AM Tomas Vondra wrote:
>>
>> On 1/10/25 15:54, Melanie Plageman wrote:
>>> On Thu, Jan 9, 2025 at 6:59 PM Tomas Vondra wrote:
>>> I think this is because we get the batch based on
>>>
>>> *batchno = pg_rotate_right32(has
## Jeremy Schneider (schnei...@ardentperf.com):
> I'm running Postgres in containers, and recently did some analysis of
> the total container sizes. I posted some analysis over on the debian
> packaging mailing list [1] [2]. The TLDR is that LLVM alone makes up
> 33% of a postgres container's byte
Thanks for the updates patch!
>> This got me thinking if dropping the index is the only
>> use case we really care about. For example, you may want
>> to prevent an index that is enforcing a constraint from
>> being used by the planner, but you probably don't want to
>> drop it. In fact, I also th
Thanks Alvaro and Jian for the review.
>
> otherwise if the cluster is not setting up.
> ``pg_dumpall --format=d``
> error would be about connection error, not
> "pg_dumpall: error: no output directory specified"
>
> we want ``pg_dumpall --format`` invalid options
> to error out even if the cluste
On Sat, 11 Jan 2025 16:14:19 -0500
Tom Lane wrote:
> Jeremy Schneider writes:
> > Given the large number of bytes that LLVM pulls into a postgres
> > build, I think it would be a good idea to have the ability to split
> > it into a separate [recommended, but optional] package.
>
> Build witho
Jeremy Schneider writes:
> Given the large number of bytes that LLVM pulls into a postgres build,
> I think it would be a good idea to have the ability to split it into a
> separate [recommended, but optional] package.
Build without --with-llvm. Alternatively, split lib/llvmjit.so and
lib/bitcod
On Fri, Jan 3, 2025 at 4:09 PM Sami Imseih wrote:
> + This is the
> + default state for newly created indexes.
>
> This is not needed in the ALTER INDEX docs, IMO.ss
>
> Updated and attached the patch.
> This got me thinking if dropping the index is the only
> use case we really care
On Sat, 11 Jan 2025 12:56:19 -0800
Jeremy Schneider wrote:
> I'm running Postgres in containers, and recently did some analysis of
> the total container sizes. I posted some analysis over on the debian
> packaging mailing list [1] [2]. The TLDR is that LLVM alone makes up
> 33% of a postgres cont
I'm running Postgres in containers, and recently did some analysis of
the total container sizes. I posted some analysis over on the debian
packaging mailing list [1] [2]. The TLDR is that LLVM alone makes up
33% of a postgres container's bytes (143MB / 434MB) [1].
Per the details in the referenced
I wrote:
> Actually, after re-reading the thread that led to 06843df4a [1],
> I think a better idea is to introduce some macro magic to force
> frontend clients to use libpgport's version of pqsignal() instead
> of the one from libpq. We mustn't change the real name of libpq's
> version, but I thi
On 11.01.2025 17:02, Guillaume Lelarge wrote:
Le sam. 11 janv. 2025 à 12:10, Ilia Evdokimov
a écrit :
On 11.01.2025 12:15, Guillaume Lelarge wrote:
Thanks for your patch, this looks like a very interesting feature
that I'd like to see in a future release.
It did a quick r
On Saturday, 11 January 2025, Peter Eisentraut wrote:
> I have applied v8-0001, with some editing of the documentation and in the
> tests. I'll continue reviewing the subsequent patches.
>
Thank you for the improvement and commit.
Regards,
Amul
--
Regards,
Amul Sul
EDB: http://www.enterpris
I have applied v8-0001, with some editing of the documentation and in
the tests. I'll continue reviewing the subsequent patches.
> On Thu, Jan 9, 2025 at 9:27 PM Ryo Kanbayashi
> wrote:
>
> > On 2025/01/09 20:34, Ryo Kanbayashi wrote:
> > > Dear Tom, Fujii-san, Kuroda-san,
> > >
> > > I saw comments of yours and recognized that better fix is below.
> > >
> > > - Fix of first attached patch which does not change warning mes
On Sat, 11 Jan 2025 at 9:30 PM, jian he wrote:
> hi.
> the following two tests, you can add to src/bin/pg_dump/t/001_basic.pl
>
> command_fails_like(
> [ 'pg_restore', '--globals-only', '-f', 'xxx' ],
> qr/\Qpg_restore: error: option -g\/--globals-only requires option
> -d\/--dbname\E/,
>
hi.
the following two tests, you can add to src/bin/pg_dump/t/001_basic.pl
command_fails_like(
[ 'pg_restore', '--globals-only', '-f', 'xxx' ],
qr/\Qpg_restore: error: option -g\/--globals-only requires option
-d\/--dbname\E/,
'pg_restore: error: option -g/--globals-only requires optio
Dean Rasheed writes:
> While looking over ruleutils.c, I noticed a couple of places that fail
> to properly quote certain outputs:
> 1. XML namespace names in XMLTABLE().
+1, but you also need to update the xml_1.out and xml_2.out files.
IIRC, xml_1.out is what comes out without --with-libxml.
I
> > - RETABLE (it's like REINDEX, but for tables)
> > - ALTER TABLE SQUEEZE
> > - SQUEEZE
> > - VACUUM (SQUEEZE)
> > - VACUUM (COMPACT)
> > - MAINTAIN COMPACT
> > - MAINTAIN SQUEEZE
> >
>
> My $0.02:
>
> COMPACT tablename ...
+1 to "COMPACT tablename"
Also the current pg_stat_progress_cluster
Thanks Alvaro for quick feedback.
On Sat, 11 Jan 2025 at 2:14 PM, Alvaro Herrera
wrote:
> Hmm, this patch adds a function connectDatabase() to pg_restore, but a
> function that's almost identical already exists in pg_dumpall.
Yes, you are right. Both functions are same as I copied this functio
Le sam. 11 janv. 2025 à 12:10, Ilia Evdokimov
a écrit :
>
> On 11.01.2025 12:15, Guillaume Lelarge wrote:
>
>
>
> Thanks for your patch, this looks like a very interesting feature that I'd
> like to see in a future release.
>
> It did a quick run: patch OK, make OK, make install OK, but make chec
On 2025-01-09 Th 8:35 AM, Alvaro Herrera wrote:
I'm not happy with the idea of having this new command be VACUUM (FULL
CONCURRENTLY). It's a bit of an absurd name if you ask me. Heck, even
VACUUM (FULL) seems a bit absurd nowadays.
Maybe we should have a new toplevel command. Some ideas th
On Thu, Jan 9, 2025 at 10:41 PM Peter Smith wrote:
>
> Hi Robert.
>
> The content and rendering of patch v2 LGTM.
>
> Should the word wrapping within the file
> doc/src/sgml/logical-replication.sgml be tidied up though?
>
Definitely couldn't hurt; Updated patch cleans that up a bit and
tweaks the
On Sat, Jan 11, 2025 at 10:40 AM Peter Eisentraut
wrote:
> I want to register that I'm not a fan of this change:
>
>
> https://git.postgresql.org/gitweb/?p=pgcommitfest2.git;a=commit;h=eee60a5332ac0745071086477ff4e189b080d3ab
>
> Rationale: It puts the least important information first. For the
While looking over ruleutils.c, I noticed a couple of places that fail
to properly quote certain outputs:
1. XML namespace names in XMLTABLE().
2. variable names in the PASSING clause of the SQL/JSON query
functions JSON_EXISTS(), JSON_QUERY(), and JSON_VALUE() (but not
JSON_TABLE(), which has si
On 11.01.2025 12:15, Guillaume Lelarge wrote:
Thanks for your patch, this looks like a very interesting feature that
I'd like to see in a future release.
It did a quick run: patch OK, make OK, make install OK, but make check
fails quite a lot on partition_prune.sql.
I guess it would need
Hi Amit,
On Fri, Jan 10, 2025 at 7:22 PM Amit Langote wrote:
>
> On Fri, Jan 10, 2025 at 7:36 PM David Rowley wrote:
> > On Fri, 10 Jan 2025 at 22:53, Vladlen Popolitov
> > wrote:
> > > In case of query
> > > select count(*) from test_table where a_1 = 100;
> > > I would expect increase o
Le jeu. 9 janv. 2025 à 04:24, Sami Imseih a écrit :
> > Of course, a patch for that would be a few orders of magnitude
> > larger than what you've got here :-(. But if you're looking
> > for a framework for reporting these sorts of details, I'd
> > much rather go in that direction than follow th
On Fri, 10 Jan 2025 at 11:38, jian he wrote:
> I think there are three remaining issues that may need more attention
> 1.
> Table 27.42. pg_stat_progress_copy View
> (pg_stat_progress_copy)
> column pg_stat_progress_copy.tuples_skipped now the description is
> ""
> When the ON_ERROR option is set
Thank you very much for Peter Geoghegan's help. The issue has been resolved for
some time now. It was indeed caused by corrupted index data, which resulted
from collation differences between the hosts before and after the migration.
Although the collation names were consistent, the differing gli
I want to register that I'm not a fan of this change:
https://git.postgresql.org/gitweb/?p=pgcommitfest2.git;a=commit;h=eee60a5332ac0745071086477ff4e189b080d3ab
Rationale: It puts the least important information first. For the most
part, the CF entry number is irrelevant, so it shouldn't be sh
Hello,
Le jeu. 12 déc. 2024 à 12:57, Ilia Evdokimov
a écrit :
>
> On 01.08.2023 23:29, Daniel Gustafsson wrote:
> >> On 3 Jul 2023, at 18:34, Daniel Gustafsson wrote:
> >>
> >>> On 8 Jun 2023, at 19:49, Ibrar Ahmed wrote:
> >>> On Mon, Mar 20, 2023 at 7:56 PM Gregory Stark (as CFM) <
> stark..
On 2025-Jan-10, Melanie Plageman wrote:
> Consolidate docs for vacuum-related GUCs in new subsection
Hmm, doesn't this need a corresponding rearrangement of the
postgresql.conf.sample file and the GUC grouping in guc_tables.c/h?
--
Álvaro Herrera PostgreSQL Developer — https://www.Ent
On Sat, Jan 11, 2025 at 4:57 PM Junwang Zhao wrote:
>
> On Fri, Jan 10, 2025 at 10:49 PM Vladlen Popolitov
> wrote:
> >
> > Amit Langote писал(а) 2025-01-10 18:22:
> > > On Fri, Jan 10, 2025 at 7:36 PM David Rowley
> > > wrote:
> > >> On Fri, 10 Jan 2025 at 22:53, Vladlen Popolitov
> > >> wrote
On Fri, Jan 10, 2025 at 10:49 PM Vladlen Popolitov
wrote:
>
> Amit Langote писал(а) 2025-01-10 18:22:
> > On Fri, Jan 10, 2025 at 7:36 PM David Rowley
> > wrote:
> >> On Fri, 10 Jan 2025 at 22:53, Vladlen Popolitov
> >> wrote:
> >> > In case of query
> >> > select count(*) from test_table wher
Hmm, this patch adds a function connectDatabase() to pg_restore, but a
function that's almost identical already exists in pg_dumpall. I
suggest they should be unified. Maybe create a new file for connection
management routines? (since this clearly doesn't fit common.c nor
dumputils.c).
--
Álvar
42 matches
Mail list logo
