Re: Conflict detection for update_deleted in logical replication

On Fri, Apr 25, 2025 at 10:08 AM shveta malik wrote: > > On Thu, Apr 24, 2025 at 6:11 PM Zhijie Hou (Fujitsu) > wrote: > > > > Few comments for patch004: > > > Config.sgml: > > > 1) > > > + > > > +Maximum duration (in milliseconds) for which conflict > > > +information can

Re: Assertion failure in smgr.c when using pg_prewarm with partitioned tables

On Fri, May 16, 2025 at 11:51 AM Masahiro Ikeda wrote: > > Thank you for your comments! > > I updated the patch to use RELKIND_HAS_STORAGE() as done in > commit 4623d7144. Please see the v2-0001 patch for the changes. > > On 2025-05-15 19:57, Richard Guo wrote: > > +1. FWIW, not long ago we fixed

Re: Conflict detection for update_deleted in logical replication

On Fri, May 16, 2025 at 11:15 AM Amit Kapila wrote: > > On Fri, Apr 25, 2025 at 4:06 PM shveta malik wrote: > > > > 2) > > in wait_for_local_flush(), we have > > should_stop_conflict_info_retention() before 'AllTablesyncsReady' > > check. Should we give a discount for table-sync time and avoid do

Re: Assertion failure in smgr.c when using pg_prewarm with partitioned tables

Thank you for your comments! I updated the patch to use RELKIND_HAS_STORAGE() as done in commit 4623d7144. Please see the v2-0001 patch for the changes. On 2025-05-15 19:57, Richard Guo wrote: +1. FWIW, not long ago we fixed a similar Assert failure in contrib/pg_freespacemap by verifying RELK

Re: Conflict detection for update_deleted in logical replication

On Thu, May 15, 2025 at 6:02 PM Amit Kapila wrote: > > On Fri, Apr 25, 2025 at 4:06 PM shveta malik wrote: > > > > > > > > Here is V30 patch set includes the following changes: > > > > > > > Thank You for the patch, please find few concerns: > > > > 1) > > By looking at code of ApplyLauncherMain(

Re: Conflict detection for update_deleted in logical replication

On Fri, Apr 25, 2025 at 4:06 PM shveta malik wrote: > > 2) > in wait_for_local_flush(), we have > should_stop_conflict_info_retention() before 'AllTablesyncsReady' > check. Should we give a discount for table-sync time and avoid doing > stop-conflict-retention when table-sync is going on? This is

Re: POC: Parallel processing of indexes in autovacuum

Hi, On Fri, May 16, 2025 at 4:06 AM Matheus Alcantara wrote: > I've reviewed the v1-0001 patch, the build on MacOS using meson+ninja is > failing: > ❯❯❯ ninja -C build install > ninja: Entering directory `build' > [1/126] Compiling C object > src/backend/postgres_lib.a.p/utils_misc_guc_tables.c.o

Re: Virtual generated columns

Hello Richard, 22.02.2025 16:55, Richard Guo wrote: create table t (a int, b int); create table vt (a int, b int generated always as (a * 2)); insert into t values (1, 1); insert into vt values (1); # select 1 from t t1 where exists (select 1 from vt where exists (select t1.a from t t

Re: doc: Make logical replication examples executable in bulk and legal sgml.

On Thu, May 15, 2025, 19:28 Peter Smith wrote: > > > doesn't help bulk execution at all because the result gets in the way > so you'll still end up surgically copying each SELECT. Since it fixes > nothing I assumed you just commented the SELECT prompts for > consistency with the other ones, right

Re: doc: Make logical replication examples executable in bulk and legal sgml.

On Sun, May 4, 2025 at 2:03 AM David G. Johnston wrote: > > While responding to a "our documentation is buggy" complaint I got annoyed in > my attempt to reproduce the behavior by having to surgically copy > line-by-line the DDL and DML code involved. Let's strive for a more > copy-paste frien

Re: Proposal: Filter irrelevant change before reassemble transactions during logical decoding

Hi Ajin. One comment for the patch set v18-0003.. == 1. +$log_location = -s $node_publisher->logfile; +$node_publisher->safe_psql('postgres', "DELETE FROM insert_only_table WHERE id = 1"); +$node_publisher->wait_for_catchup('sub_all'); + +$logfile = slurp_file($node_publisher->logfile, $log_

Re: POC: Parallel processing of indexes in autovacuum

Hi, On 09/05/25 15:33, Daniil Davydov wrote: > Hi, > As I promised - meet parallel index autovacuum with bgworkers > (Parallel-index-autovacuum-with-bgworkers.patch). This is pretty > simple implementation : > 1) Added new table option `parallel_idx_autovac_enabled` that must be > set to `true` if

Re: PG 18 release notes draft committed

On 2025-May-13, Laurenz Albe wrote: > On the one hand, the catalogs don't promise to be a stable API, so there > would be no need to enumerate such changes as compatibility breaks. I think it might be useful to distinguish changes to views, which are intended to be user-facing, from changes to "i

Binary operators for cubes

Hi hackers! The "cube" extention is frequently used for vectors, but the current implementation lacks support for binary operators, such as +, -, *, /. The attached (fairly trivial) patch adds support for these with the required documentation and test changes. Best Regards, Kirill PaninFrom 9

Add comment explaining why queryid is int64 in pg_stat_statements

Hi Developers, In pg_stat_statements.c, the function pg_stat_statements_internal() declares the queryid variable as int64, but assigns it a value of type uint64. At first glance, this might appear to be an overflow issue. However, I think this is intentional - the queryid is cast to int64 to ma

Re: Consider explicit incremental sort for Append and MergeAppend

On 12/5/2025 11:29, Richard Guo wrote: For ordered Append or MergeAppend, it seems that incremental sort is currently not considered when injecting an explicit sort into subpaths that are not sufficiently ordered. For instance: Thanks for doing this job. I have reviewed your patch and want to p

Re: Update LDAP Protocol in fe-connect.c to v3

I applied your patch. I ran extended application tests relative to vanilla ones, which include various scenarios of working with LDAP and I think that we can safely apply the patch in the PG18. I did not see the need for additional LDAP tests, since compatibility is provided by the LDAP library

Re: Restrict publishing of partitioned table with a foreign table as partition

On Sun, May 11, 2025 at 6:53 AM Álvaro Herrera wrote: > > But the non-idiomatic locking of pg_partitioned_table appears to > continue to be the pain point of this patch. My impression is that > using a lock is the wrong approach to solve the concurrency problem. > Maybe we can use a ConditionVari

Re: Conflict detection for update_deleted in logical replication

On Fri, Apr 25, 2025 at 4:06 PM shveta malik wrote: > > > > > Here is V30 patch set includes the following changes: > > > > Thank You for the patch, please find few concerns: > > 1) > By looking at code of ApplyLauncherMain(), it appears that we stopped > advancing shared-slot's xmin if any of the

Re: [BUG] Skipped initialization of some xl_xact_parsed_prepare fields

On 2025/05/15 14:39, Daniil Davydov wrote: Hi, I noticed that inside ParsePrepareRecord function we are missing initialization of `nstats` and `nabortstats` fields of xl_xact_parsed_prepare structure: *** (current code in master) memset(parsed, 0, sizeof(*parsed)); parsed->xact_time = xlrec->

Re: Assertion failure in smgr.c when using pg_prewarm with partitioned tables

On Thu, May 15, 2025 at 6:50 PM Dilip Kumar wrote: > On Thu, May 15, 2025 at 3:14 PM Fujii Masao > wrote: > > How about adding a check to see whether the target relation has storage, > > using something like RELKIND_HAS_STORAGE()? > Yeah, that makes more sense. +1. FWIW, not long ago we fixed

Re: Assertion failure in smgr.c when using pg_prewarm with partitioned tables

On Thu, May 15, 2025 at 3:14 PM Fujii Masao wrote: > > > > On 2025/05/15 18:20, Dilip Kumar wrote: > > On Thu, May 15, 2025 at 2:22 PM Masahiro Ikeda > > wrote: > >> > >> Hi, > >> > >> I encountered an assertion failure when a partitioned table is specified > >> as an argument to pg_prewarm. Bel

Re: Assertion failure in smgr.c when using pg_prewarm with partitioned tables

On 2025/05/15 18:20, Dilip Kumar wrote: On Thu, May 15, 2025 at 2:22 PM Masahiro Ikeda wrote: Hi, I encountered an assertion failure when a partitioned table is specified as an argument to pg_prewarm. Below are the steps to reproduce the issue: Thanks for the report! This assertion fail

Re: Should we optimize the `ORDER BY random() LIMIT x` case?

On 15/5/2025 11:17, Aleksander Alekseev wrote: What kind of optimisation trick may the optimiser use here to provide an optimal plan? As I see it, it will need to think that all the tuples should be returned from the subquery. The only profit is to skip sorting the massive sample. Doesn't look

Re: Logical Replication of sequences

Hi Vignesh. Some minor review comments for the patches in set v20250514. == Patch 0001. 1.1 For function 'pg_sequence_state', the DOCS call the 2nd parameter 'sequence_name', but the pg_proc.dat file calls it 'seq_name'. Should these be made the same? Patch 0004. pg_

Re: Assertion failure in smgr.c when using pg_prewarm with partitioned tables

On Thu, May 15, 2025 at 2:22 PM Masahiro Ikeda wrote: > > Hi, > > I encountered an assertion failure when a partitioned table is specified > as an argument to pg_prewarm. Below are the steps to reproduce the > issue: > > $ pgbench -i -s 1 --partitions=3 > $ psql < CREATE EXTENSION pg_prewarm; > SE

Re: Should we optimize the `ORDER BY random() LIMIT x` case?

wenhui, Andrei, > if we can optimize the query, that would be great Thanks for the feedback! > I think I got your point, but just to be sure: > Do you want to have some random sampling from an arbitrary subquery with > the guarantee that N distinct (by tid) tuples will be produced or all > the t

Assertion failure in smgr.c when using pg_prewarm with partitioned tables

Hi, I encountered an assertion failure when a partitioned table is specified as an argument to pg_prewarm. Below are the steps to reproduce the issue: $ pgbench -i -s 1 --partitions=3 $ psql

Re: Assert failure in base_yyparse

On Thu, May 15, 2025 at 1:20 AM Alvaro Herrera wrote: > On 2025-May-14, Richard Guo wrote: > > Attached is a patch that implements this. It also renames the > > internally used option name and updates the error message. > LGTM. Thanks. I've pushed this patch and backpatched it through v15. I

Re: Should we optimize the `ORDER BY random() LIMIT x` case?

On 15/5/2025 01:41, Aleksander Alekseev wrote: One can do `SELECT (the query above) ORDER BY random() LIMIT x` but this produces an inefficient plan. Alternatively one could create temporary tables using `CREATE TEMP TABLE ... AS SELECT * FROM tbl TABLESAMPLE BERNOULLI(20)` but this is inconvenie

xlogrecovery.c:WaitForWALToBecomeAvailable() - make "switched WAL source" visible by default?

Hi, In presence of restore_command being configured, physical standby can either use it to restore archive logs to get WAL OR we can stream WAL from the primary. If we are streaming from primary we get: "started streaming WAL from primary" clear log message. In case of using restore_command we do