Re: allow granting CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX

On Thu, Jun 15, 2023 at 04:57:00PM -0700, Nathan Bossart wrote: > Here's an attempt at adjusting the documentation as I proposed yesterday. > I think this is a good opportunity to simplify the privilege-related > sections for these maintenance commands. I noticed that it was possible to make the

Re: add non-option reordering to in-tree getopt_long

On Fri, Jun 16, 2023 at 10:30:09AM +0900, Michael Paquier wrote: > On Thu, Jun 15, 2023 at 05:09:59PM -0700, Nathan Bossart wrote: >> I've attached a new version of the patch that omits the >> POSIXLY_CORRECT stuff. > > This looks OK at quick glance, though you may want to document at the > top

Re: Add a perl function in Cluster.pm to generate WAL

Thanks for the comments. At Fri, 16 Jun 2023 11:30:15 +0900, Michael Paquier wrote in > > -$node_primary->safe_psql( > > -'postgres', "create table retain_test(a int); > > - select pg_switch_wal(); > > - insert into

Re: Support to define custom wait events for extensions

On 2023-06-16 01:13, Tristan Partin wrote: We had this on our list of things to do at Neon, so it is a nice surprise that you brought up an initial patchset :). It was also my first time looking up the word tranche. What a coincidence! I came up with the idea when I used Neon with

Re: Add a perl function in Cluster.pm to generate WAL

On Thu, Jun 15, 2023 at 01:40:15PM +0900, Kyotaro Horiguchi wrote: > + "CREATE TABLE tt (); DROP TABLE tt; SELECT > pg_switch_wal();"); > > At least since 11, we can utilize pg_logical_emit_message() for this > purpose. It's more lightweight and seems appropriate, not only

Re: Allow pg_archivecleanup to remove backup history files

At Fri, 16 Jun 2023 11:22:31 +0900 (JST), Kyotaro Horiguchi wrote in > ASAICS the main section of the "pg_rewind --help" fits within 80 > columns. However, "initdb --help" does output a few lines exceeding > the 80-column limit. Judging by the surrounding lines, I believe we're > still aiming

Re: Allow pg_archivecleanup to remove backup history files

At Thu, 15 Jun 2023 21:38:28 +0900, torikoshia wrote in > On 2023-06-15 15:20, Kyotaro Horiguchi wrote: > Thanks for your review! > > + printf(_(" -x, --strip-extension=EXT strip this extention before > > identifying files fo clean up\n")); > > + printf(_(" -?, --help show this help, then

Re: Support to define custom wait events for extensions

On 2023-06-15 22:21, Drouvot, Bertrand wrote: Hi, On 6/15/23 10:00 AM, Michael Paquier wrote: On Thu, Jun 15, 2023 at 03:06:01PM +0900, Masahiro Ikeda wrote: Currently, only one PG_WAIT_EXTENSION event can be used as a wait event for extensions. Therefore, in environments with multiple

Re: [PATCH] Slight improvement of worker_spi.c example

On Wed, Jun 14, 2023 at 02:08:03PM +0300, Aleksander Alekseev wrote: > > Unfortunately I'm not familiar with the problem in respect of naptime > Julien is referring to. If you know what this problem is and how to > fix it, go for it. I'll review and test the code then. I can write the > part of

Re: Support to define custom wait events for extensions

Thanks for replying and your kind advice! On 2023-06-15 17:00, Michael Paquier wrote: On Thu, Jun 15, 2023 at 03:06:01PM +0900, Masahiro Ikeda wrote: In the core, the requested wait events are dynamically registered in shared memory. The extension then obtains the wait event information with

Re: Non-superuser subscription owners

On Thu, Jun 15, 2023 at 11:18 PM Alvaro Herrera wrote: > > 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

Re: Consistent coding for the naming of LR workers

At Thu, 15 Jun 2023 12:42:33 +1000, Peter Smith wrote in > It is better to have a *single* point where these worker names are > defined, so then all output uses identical LR worker nomenclature. > > PSA a small patch to modify the code accordingly. This is not intended > to be a functional

Re: subscription/033_run_as_table_owner is not listed in the meson.build

On Fri, Jun 16, 2023 at 7:42 AM Michael Paquier wrote: > > On Fri, Jun 16, 2023 at 07:15:36AM +0900, Masahiko Sawada wrote: > > On Thu, Jun 15, 2023 at 5:32 PM Masahiko Sawada > > wrote: > >> Checking similar oversights, > >> src/bin/pg_basebackup/t/011_in_place_tablespace.pl seems not to be >

Re: Fix a typo in rewriteHandler.c

On Fri, Jun 16, 2023 at 10:25 AM Amit Langote wrote: > On Thu, Jun 15, 2023 at 5:07 PM Sho Kato (Fujitsu) > wrote: > > I've attached the patch for the following rewriteTargetView comments. > > > > s/rewriteQuery/RewriteQuery > > Good catch and thanks for the patch. Will push shortly. Done.

Re: add non-option reordering to in-tree getopt_long

On Thu, Jun 15, 2023 at 05:09:59PM -0700, Nathan Bossart wrote: > On Thu, Jun 15, 2023 at 02:30:34PM +0900, Kyotaro Horiguchi wrote: >> Hmm, the discussion seems to be based on the assumption that argv[0] >> can be safely redirected to a different memory location. If that's the >> case, we can

Re: [PATCH] Add loongarch native checksum implementation.

Updated the patch based on the comments. On 2023/6/15 18:30, John Naylor wrote: On Wed, Jun 14, 2023 at 9:20 AM YANG Xudong > wrote: > > Attached a new patch with fixes based on the comment below. Note: It's helpful to pass "-v" to git format-patch, to have

Re: Fix a typo in rewriteHandler.c

Hello, On Thu, Jun 15, 2023 at 5:07 PM Sho Kato (Fujitsu) wrote: > > Hi, > > I've attached the patch for the following rewriteTargetView comments. > > > Assert(parsetree->resultRelation == new_rt_index); > > /* > * For INSERT/UPDATE we must also update resnos in the targetlist to

Re: Do we want a hashset type?

On Thu, Jun 15, 2023, at 11:44, jian he wrote: > In hashset/test/sql/order.sql, can we add the following to test whether > the optimizer will use our index. > > CREATE INDEX ON test_int4hashset_order (int4hashset_col > int4hashset_btree_ops); > > -- to make sure that this work with just two

Re: add non-option reordering to in-tree getopt_long

On Thu, Jun 15, 2023 at 02:30:34PM +0900, Kyotaro Horiguchi wrote: > At Wed, 14 Jun 2023 15:46:08 -0700, Nathan Bossart > wrote in >> Hm. IIUC modifying the argv pointers on AIX will modify the process title, >> which could cause 'ps' to temporarily show duplicate/missing arguments >> during

Re: allow granting CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX

On Wed, Jun 14, 2023 at 09:10:44PM -0700, Nathan Bossart wrote: > IMO > we should update the docs and leave out the ownership checks since MAINTAIN > is now a grantable privilege like any other. WDYT? Here's an attempt at adjusting the documentation as I proposed yesterday. I think this is a

Re: Support to define custom wait events for extensions

On Thu, Jun 15, 2023 at 11:13:57AM -0500, Tristan Partin wrote: > What's the Postgres policy on the following? > > for (int i = 0; ...) > for (i = 0; ...) > > You are using 2 different patterns in WaitEventShmemInit() and > InitializeExtensionWaitEventTranches(). C99 style is OK since v12, so

Re: subscription/033_run_as_table_owner is not listed in the meson.build

On Fri, Jun 16, 2023 at 07:15:36AM +0900, Masahiko Sawada wrote: > On Thu, Jun 15, 2023 at 5:32 PM Masahiko Sawada wrote: >> Checking similar oversights, >> src/bin/pg_basebackup/t/011_in_place_tablespace.pl seems not to be >> listed in meson.build too. > > Here is the patch for that. Yes, good

Re: Memory leak in incremental sort re-scan

On 6/15/23 22:36, Tom Lane wrote: > Tomas Vondra writes: >> On 6/15/23 22:11, Tom Lane wrote: >>> I see zero leakage in that example after applying the attached quick >>> hack. (It might be better to make the check in the caller, or to just >>> move the call to ExecInitIncrementalSort.) > >>

Re: subscription/033_run_as_table_owner is not listed in the meson.build

On Thu, Jun 15, 2023 at 5:32 PM Masahiko Sawada wrote: > > On Thu, Jun 15, 2023 at 5:04 PM Michael Paquier wrote: > > > > On Thu, Jun 15, 2023 at 07:16:06AM +, Hayato Kuroda (Fujitsu) wrote: > > > I have noticed that the testcase subscription/033_run_as_table_owner in > > > the > > >

Re: Do we want a hashset type?

On Thu, Jun 15, 2023, at 06:29, jian he wrote: > I am not sure the following results are correct. > with cte as ( > select hashset(x) as x > ,hashset_capacity(hashset(x)) > ,hashset_count(hashset(x)) > from generate_series(1,10) g(x)) > select * > ,'|' as

Re: Memory leak in incremental sort re-scan

Tomas Vondra writes: > On 6/15/23 22:11, Tom Lane wrote: >> I see zero leakage in that example after applying the attached quick >> hack. (It might be better to make the check in the caller, or to just >> move the call to ExecInitIncrementalSort.) > Thanks for looking. Are you planning to work

Re: Memory leak in incremental sort re-scan

On 6/15/23 22:11, Tom Lane wrote: > Tomas Vondra writes: >> On 6/15/23 13:48, Laurenz Albe wrote: >>> ExecIncrementalSort() calls tuplesort_begin_common(), which creates the >>> "TupleSort main" >>> and "TupleSort sort" memory contexts, and ExecEndIncrementalSort() calls >>> tuplesort_end(),

Re: Memory leak in incremental sort re-scan

Tomas Vondra writes: > On 6/15/23 13:48, Laurenz Albe wrote: >> ExecIncrementalSort() calls tuplesort_begin_common(), which creates the >> "TupleSort main" >> and "TupleSort sort" memory contexts, and ExecEndIncrementalSort() calls >> tuplesort_end(), >> which destroys them. >> But

Re: Let's make PostgreSQL multi-threaded

On 15.06.2023 12:04 PM, Hannu Krosing wrote: So a fair bit of work but also a clearly defined benefits of 1) reduced memory usage 2) no need to rebuild caches for each new connection 3) no need to track PREPARE statements inside connection poolers. Shared plan cache (not only prepared

Re: Let's make PostgreSQL multi-threaded

On 15.06.2023 11:41 AM, James Addison wrote: On Thu, 15 Jun 2023 at 08:12, Konstantin Knizhnik wrote: On 15.06.2023 1:23 AM, James Addison wrote: On Tue, 13 Jun 2023 at 07:55, Konstantin Knizhnik wrote: On 12.06.2023 3:23 PM, Pavel Borisov wrote: Is the following true or not? 1. If

Re: [17] collation provider "builtin"

On 6/14/23 19:20, Thomas Munro wrote: On Thu, Jun 15, 2023 at 10:55 AM Jeff Davis wrote: The locale "C" (and equivalently, "POSIX") is not really a libc locale; it's implemented internally with memcmp for collation and pg_ascii_tolower, etc., for ctype. The attached patch implements a new

Re: psql: Add role's membership options to the \du+ command

Robert - can you please comment on what you are willing to commit in order to close out your open item here. My take is that the design for this, the tabular form a couple of emails ago (copied here), is ready-to-commit, just needing the actual (trivial) code changes to be made to accomplish it.

Re: Non-superuser subscription owners

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

Re: RFC: Logging plan of the running query

On Thu, Jun 15, 2023 at 9:00 AM torikoshia wrote: > > On 2023-06-15 01:48, James Coleman wrote: > > On Tue, Jun 13, 2023 at 11:53 AM James Coleman > > wrote: > >> > >> ... > >> I'm going to re-run tests with my patch version + resetting the flag > >> on SIGINT (and any other error condition) to

Re: When IMMUTABLE is not.

15.06.2023 17:49, Tom Lane пишет: "David G. Johnston" writes: The failure to find and execute the function code itself is not a failure mode that these markers need be concerned with. Assuming one can execute the function an immutable function will give the same answer for the same input

Re: Support to define custom wait events for extensions

We had this on our list of things to do at Neon, so it is a nice surprise that you brought up an initial patchset :). It was also my first time looking up the word tranche. >From 59a118402e5e59685fb9e0fb086872e25a405736 Mon Sep 17 00:00:00 2001 From: Masahiro Ikeda Date: Thu, 15 Jun 2023

Re: run pgindent on a regular basis / scripted manner

On 2023-06-15 Th 11:26, Jelte Fennema wrote: On Sat, 22 Apr 2023 at 13:42, Andrew Dunstan wrote: Perhaps we should start with a buildfarm module, which would run pg_indent --show-diff. That would only need to run on one animal, so a failure wouldn't send the whole buildfarm red. This would

Re: Do we want a hashset type?

On Thu, Jun 15, 2023, at 11:44, jian he wrote: > I didn't install the extension directly. I copied the > hashset--0.0.1.sql to another place, using gcc to compile these > functions. .. > Because even make > PG_CONFIG=/home/jian/postgres/2023_05_25_beta5421/bin/pg_config still > has an error.

Re: run pgindent on a regular basis / scripted manner

On Sat, 22 Apr 2023 at 13:42, Andrew Dunstan wrote: > Perhaps we should start with a buildfarm module, which would run pg_indent > --show-diff. That would only need to run on one animal, so a failure wouldn't > send the whole buildfarm red. This would be pretty easy to do. Just to be clear on

Re: When IMMUTABLE is not.

On Thu, 15 Jun 2023 at 10:49, Tom Lane wrote: In particular, we've never enforced that an immutable function can't > call non-immutable functions. While that would seem like a good idea > in the abstract, we've intentionally not tried to do it. (I'm pretty > sure there is more than one round

Re: When IMMUTABLE is not.

"David G. Johnston" writes: > The failure to find and execute the function code itself is not a failure > mode that these markers need be concerned with. Assuming one can execute > the function an immutable function will give the same answer for the same > input for all time. The viewpoint

Re: When IMMUTABLE is not.

On 2023-06-15 10:19, David G. Johnston wrote: The failure to find and execute the function code itself is not a failure mode that these markers need be concerned with. Assuming one can execute the function an immutable function will give the same answer for the same input for all time.

Re: When IMMUTABLE is not.

On Thursday, June 15, 2023, wrote: > > So one could take a strict view that "no PL/Java function should > ever be marked IMMUTABLE" because every one depends on fetching > something (once, at least). > The failure to find and execute the function code itself is not a failure mode that these

Re: When IMMUTABLE is not.

On 2023-06-15 09:58, c...@anastigmatix.net wrote: also influences what snapshot the function is looking at, and therefore what it can see, which has also struck me more as a tacked-on effect than something inherent in the declaration's meaning. I just re-read that and realized I should

Re: When IMMUTABLE is not.

c...@anastigmatix.net writes: > And also, isn't it the case that IMMUTABLE should mark a function, > not merely that "doesn't manipulate data", but whose return value > doesn't depend in any way on data (outside its own arguments)? Right. We can't realistically enforce that either, so it's up to

Re: When IMMUTABLE is not.

15.06.2023 16:58, c...@anastigmatix.net пишет: On 2023-06-15 09:21, Tom Lane wrote: Yura Sokolov writes: not enough to be sure function doesn't manipulate data. Of course not.  It is the user's responsibility to mark functions properly. And also, isn't it the case that IMMUTABLE should

Re: When IMMUTABLE is not.

On 2023-06-15 09:21, Tom Lane wrote: Yura Sokolov writes: not enough to be sure function doesn't manipulate data. Of course not. It is the user's responsibility to mark functions properly. And also, isn't it the case that IMMUTABLE should mark a function, not merely that "doesn't

Re: When IMMUTABLE is not.

15.06.2023 16:21, Tom Lane wrote: Yura Sokolov writes: I found, than declaration of function as IMMUTABLE/STABLE is not enough to be sure function doesn't manipulate data. Of course not. It is the user's responsibility to mark functions properly. Trying to enforce that completely is a

Re: obsolete filename reference in parser README

On Thu, Jun 15, 2023 at 10:48 PM Tristan Partin wrote: > Nice catch. Looks good. Thanks for checking. As just mentioned, I've pushed this moments ago. -- Thanks, Amit Langote EDB: http://www.enterprisedb.com

Re: obsolete filename reference in parser README

Nice catch. Looks good. -- Tristan Partin Neon (https://neon.tech)

Re: obsolete filename reference in parser README

On Thu, Jun 15, 2023 at 6:54 PM Amit Langote wrote: > I noticed that 2f2b18bd3f55 forgot to remove the mention of > parse_jsontable.c in src/backend/parser/README. > > Attached a patch to fix that. Will push that shortly to HEAD and v15. Pushed to HEAD only. 9853bf6ab0e that added

Re: Avoid unncessary always true test (src/backend/storage/buffer/bufmgr.c)

Em qua., 14 de jun. de 2023 às 13:32, Gurjeet Singh escreveu: > On Wed, Jun 14, 2023 at 5:12 AM Ranier Vilela wrote: > > > > Em qua., 14 de jun. de 2023 às 06:51, Richard Guo < > guofengli...@gmail.com> escreveu: > >> > >> > >> On Tue, Jun 13, 2023 at 3:39 PM Kyotaro Horiguchi < >

Re: BUG #17946: LC_MONETARY & DO LANGUAGE plperl - BUG

On Mon Jun 12, 2023 at 4:13 AM CDT, Heikki Linnakangas wrote: > There are a few uselocale() calls in ecpg, and they are protected by > HAVE_USELOCALE. Interestingly, the calls in pg_locale.c are not, but > they are protected by HAVE_LOCALE_T. Seems a little inconsistent. Patch is attached.

Re: Support to define custom wait events for extensions

Hi, On 6/15/23 10:00 AM, Michael Paquier wrote: On Thu, Jun 15, 2023 at 03:06:01PM +0900, Masahiro Ikeda wrote: Currently, only one PG_WAIT_EXTENSION event can be used as a wait event for extensions. Therefore, in environments with multiple extensions are installed, it could take time to

Re: When IMMUTABLE is not.

Yura Sokolov writes: > I found, than declaration of function as IMMUTABLE/STABLE is not enough to be > sure > function doesn't manipulate data. Of course not. It is the user's responsibility to mark functions properly. Trying to enforce that completely is a fool's errand; you soon get into

Re: Memory leak in incremental sort re-scan

Hi, On 6/15/23 13:48, Laurenz Albe wrote: > ExecIncrementalSort() calls tuplesort_begin_common(), which creates the > "TupleSort main" > and "TupleSort sort" memory contexts, and ExecEndIncrementalSort() calls > tuplesort_end(), > which destroys them. > But ExecReScanIncrementalSort() only

Re: RFC: Logging plan of the running query

On 2023-06-15 01:48, James Coleman wrote: On Tue, Jun 13, 2023 at 11:53 AM James Coleman wrote: ... I'm going to re-run tests with my patch version + resetting the flag on SIGINT (and any other error condition) to be certain that the issue you uncovered (where backends get stuck after a

Re: Allow pg_archivecleanup to remove backup history files

On 2023-06-15 15:20, Kyotaro Horiguchi wrote: Thanks for your review! At Wed, 14 Jun 2023 00:49:39 +0900, torikoshia wrote in On 2023-06-12 16:33, Michael Paquier wrote: > On Fri, Jun 09, 2023 at 12:32:15AM +0900, Fujii Masao wrote: Thanks for reviewing! >>printf(_(" -n, --dry-run

Re: When IMMUTABLE is not.

On Thu, 2023-06-15 at 13:22 +0300, Yura Sokolov wrote: > Good day, hackers. > > I found, than declaration of function as IMMUTABLE/STABLE is not enough to be > sure > function doesn't manipulate data. > > [...] > > + errmsg("Damn1! Update were done >

Memory leak in incremental sort re-scan

ExecIncrementalSort() calls tuplesort_begin_common(), which creates the "TupleSort main" and "TupleSort sort" memory contexts, and ExecEndIncrementalSort() calls tuplesort_end(), which destroys them. But ExecReScanIncrementalSort() only resets the memory contexts. Since the next call to

Re: Skip collecting decoded changes of already-aborted transactions

On Tue, Jun 13, 2023 at 2:06 PM Masahiko Sawada wrote: > > On Sun, Jun 11, 2023 at 5:31 AM Andres Freund wrote: > > > > A separate issue is that TransactionIdDidAbort() can end up being very slow > > if > > a lot of transactions are in progress concurrently. As soon as the clog > > buffers are

Re: When IMMUTABLE is not.

Sorry, previous message were smashed for some reason. I'll try to repeat I found, than declaration of function as IMMUTABLE/STABLE is not enough to be sure function doesn't manipulate data. In fact, SPI checks only direct function kind, but fails to check indirect call. Attached

Re: Consistent coding for the naming of LR workers

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

Re: [PATCH] Add loongarch native checksum implementation.

On Wed, Jun 14, 2023 at 9:20 AM YANG Xudong wrote: > > Attached a new patch with fixes based on the comment below. Note: It's helpful to pass "-v" to git format-patch, to have different versions. > > For x86 and Arm, if it fails to link without an -march flag, we allow > > for a runtime check.

When IMMUTABLE is not.

Good day, hackers. I found, than declaration of function as IMMUTABLE/STABLE is not enough to be sure function doesn't manipulate data. In fact, SPI checks only direct function kind, but fails to check indirect call. Attached immutable_not.sql creates 3 functions: - `immutable_direct` is

obsolete filename reference in parser README

Hi, I noticed that 2f2b18bd3f55 forgot to remove the mention of parse_jsontable.c in src/backend/parser/README. Attached a patch to fix that. Will push that shortly to HEAD and v15. -- Thanks, Amit Langote EDB: http://www.enterprisedb.com

Re: Do we want a hashset type?

In hashset/test/sql/order.sql, can we add the following to test whether the optimizer will use our index. CREATE INDEX ON test_int4hashset_order (int4hashset_col int4hashset_btree_ops); -- to make sure that this work with just two rows SET enable_seqscan TO off; explain(costs off) SELECT *

Re: Let's make PostgreSQL multi-threaded

One more unexpected benefit of having shared caches would be easing access to other databases. If the system caches are there for all databases anyway, then it becomes much easier to make queries using objects from multiple databases. Note that this does not strictly need threads, just shared

Re: Let's make PostgreSQL multi-threaded

On Thu, Jun 15, 2023 at 10:41 AM James Addison wrote: > > This is making me wonder about other performance/scalability areas > that might not have been considered due to focus on the details of the > existing codebase, but I'll save that for another thread and will try > to learn more first. A

Re: Making empty Bitmapsets always be NULL

Hello, On Tue, Jun 13, 2023 at 8:07 PM David Rowley wrote: > I've incorporated fixes for the bugs in the attached patch. I didn't > quite use the same approach as you did. I did the fix for 0003 > slightly differently and added two separate paths. We've no need to > track the last non-zero

Re: Let's make PostgreSQL multi-threaded

On Thu, Jun 15, 2023 at 9:12 AM Konstantin Knizhnik wrote: > There are three different but related directions of improving current > Postgres: > 1. Replacing processes with threads Here we could likely start with making parallel query multi-threaded. This would also remove the big blocker for

Re: Let's make PostgreSQL multi-threaded

On Thu, 15 Jun 2023 at 08:12, Konstantin Knizhnik wrote: > > > > On 15.06.2023 1:23 AM, James Addison wrote: > > On Tue, 13 Jun 2023 at 07:55, Konstantin Knizhnik wrote: > > > On 12.06.2023 3:23 PM, Pavel Borisov wrote: > > Is the following true or not? > > 1. If we switch processes to threads

Re: subscription/033_run_as_table_owner is not listed in the meson.build

On Thu, Jun 15, 2023 at 5:04 PM Michael Paquier wrote: > > On Thu, Jun 15, 2023 at 07:16:06AM +, Hayato Kuroda (Fujitsu) wrote: > > I have noticed that the testcase subscription/033_run_as_table_owner in the > > subscription is not executed when meson build system is chosen. The case is > >

MergeJoin beats HashJoin in the case of multiple hash clauses

Hi, all. Some of my clients use JOIN's with three - four clauses. Quite frequently, I see complaints on unreasonable switch of JOIN algorithm to Merge Join instead of Hash Join. Quick research have shown one weak place - estimation of an average bucket size in final_cost_hashjoin (see q2.sql

Re: Bypassing shared_buffers

On Thu, Jun 15, 2023 at 12:32 AM Konstantin Knizhnik wrote: > > > On 15.06.2023 4:37 AM, Vladimir Churyukin wrote: > > Ok, got it, thanks. > > Is there any alternative approach to measuring the performance as if > > the cache was empty? > > The goal is basically to calculate the max possible I/O

Re: Replace (GUC_UNIT_MEMORY | GUC_UNIT_TIME) with GUC_UNIT in guc.c

On Thu, Jun 15, 2023 at 11:02 AM Masahiko Sawada wrote: > > On Wed, Jun 14, 2023 at 4:47 PM Michael Paquier wrote: > > > > On Wed, Jun 14, 2023 at 03:38:10PM +0800, Richard Guo wrote: > > > +1. BTW, it seems that GUC_UNIT_TIME is not used anywhere except in > > > GUC_UNIT. I was wondering if

Fix a typo in rewriteHandler.c

Hi, I've attached the patch for the following rewriteTargetView comments. Assert(parsetree->resultRelation == new_rt_index); /* * For INSERT/UPDATE we must also update resnos in the targetlist to refer * to columns of the base relation, since those indicate the target *

Re: Do we want a hashset type?

On Thu, Jun 15, 2023, at 04:22, jian he wrote: > Attachments: > * temp.patch Thanks for good suggestions. New patch attached: Enhance parsing and reorder headers in hashset module Allow whitespaces in hashset input and reorder the inclusion of header files, placing PostgreSQL headers first.

Re: subscription/033_run_as_table_owner is not listed in the meson.build

On Thu, Jun 15, 2023 at 07:16:06AM +, Hayato Kuroda (Fujitsu) wrote: > I have noticed that the testcase subscription/033_run_as_table_owner in the > subscription is not executed when meson build system is chosen. The case is > not > listed in the meson.build. > > Do we have any reasons or

Re: Support to define custom wait events for extensions

On Thu, Jun 15, 2023 at 03:06:01PM +0900, Masahiro Ikeda wrote: > Currently, only one PG_WAIT_EXTENSION event can be used as a > wait event for extensions. Therefore, in environments with multiple > extensions are installed, it could take time to identify which > extension is the bottleneck.

Re: Consistent coding for the naming of LR workers

On Thu, Jun 15, 2023 at 8:13 AM Peter Smith wrote: > > There are different types of Logical Replication workers -- e.g. > tablesync workers, apply workers, and parallel apply workers. > > The logging and errors often name these worker types, but during a > recent code review, I noticed some

Re: generate syscache info automatically

On Wed, May 31, 2023 at 4:58 AM Peter Eisentraut wrote: > > I want to report on my on-the-plane-to-PGCon project. > > The idea was mentioned in [0]. genbki.pl already knows everything about > system catalog indexes. If we add a "please also make a syscache for > this one" flag to the catalog

Re: trying again to get incremental backup

On Thu, Jun 15, 2023 at 2:11 AM Andres Freund wrote: > > > I'm not really sure. I expect Dilip would be happy to post his patch, > > and if you'd be willing to have a look at it and express your concerns > > or lack thereof, that would be super valuable. > > Will do. Adding me to CC: might help,

New WAL record to detect the checkpoint redo location

As discussed [1 ][2] currently, the checkpoint-redo LSN can not be accurately detected while processing the WAL. Although we have a checkpoint WAL record containing the exact redo LSN, other WAL records may be inserted between the checkpoint-redo LSN and the actual checkpoint record. If we want to

Re: Bypassing shared_buffers

On 15.06.2023 4:37 AM, Vladimir Churyukin wrote: Ok, got it, thanks. Is there any alternative approach to measuring the performance as if the cache was empty? The goal is basically to calculate the max possible I/O time for a query, to get a range between min and max timing. It's ok if it's

Re: Initial Schema Sync for Logical Replication

On Thu, Jun 15, 2023 at 4:14 PM Peter Smith wrote: > > On Thu, Jun 8, 2023 at 1:24 PM Masahiko Sawada wrote: > > > ... > > > We also need to research how to integrate the initial schema > > synchronization with tablesync workers. We have a PoC patch[2]. > > > > Regards, > > > > [1] > >

subscription/033_run_as_table_owner is not listed in the meson.build

Dear hackers, I have noticed that the testcase subscription/033_run_as_table_owner in the subscription is not executed when meson build system is chosen. The case is not listed in the meson.build. Do we have any reasons or backgrounds about it? PSA the patch to add the case. It works well on my

Re: pg_collation.collversion for C.UTF-8

On Sun, Apr 23, 2023 at 5:22 AM Daniel Verite wrote: > I understand that my proposal to version C.* like any other collation > might be erring on the side of caution, but ignoring these collation > changes on at least one major OS does not feel right either. > Maybe we should consider doing

Re: Let's make PostgreSQL multi-threaded

On 15.06.2023 1:23 AM, James Addison wrote: On Tue, 13 Jun 2023 at 07:55, Konstantin Knizhnik wrote: On 12.06.2023 3:23 PM, Pavel Borisov wrote: Is the following true or not? 1. If we switch processes to threads but leave the amount of session local variables unchanged, there would be

Fix regression tests to work with REGRESS_OPTS=--no-locale

Hi all, While doing some tests with the tree, I have noticed that we don't do in the tests of unaccent the business that we have elsewhere (test_regex, fuzzystrmatch, now hstore, collation tests, etc.) to make the tests portable when these tests include UTF-8 characters but the regression

Re: Allow pg_archivecleanup to remove backup history files

At Wed, 14 Jun 2023 00:49:39 +0900, torikoshia wrote in > On 2023-06-12 16:33, Michael Paquier wrote: > > On Fri, Jun 09, 2023 at 12:32:15AM +0900, Fujii Masao wrote: > Thanks for reviewing! > > >>printf(_(" -n, --dry-run dry run, show the names of the files that > >>would be

Re: Initial Schema Sync for Logical Replication

On Thu, Jun 8, 2023 at 1:24 PM Masahiko Sawada wrote: > ... > We also need to research how to integrate the initial schema > synchronization with tablesync workers. We have a PoC patch[2]. > > Regards, > > [1] > https://wiki.postgresql.org/wiki/Logical_replication_of_DDLs#Initial_Schema_Sync >

Support to define custom wait events for extensions

Hi, Currently, only one PG_WAIT_EXTENSION event can be used as a wait event for extensions. Therefore, in environments with multiple extensions are installed, it could take time to identify which extension is the bottleneck. So, I'd like to support new APIs to define custom wait events for