Re: Extend compatibility of PostgreSQL::Test::Cluster

On Tue, Jan 18, 2022 at 06:35:39PM -0500, Andrew Dunstan wrote: > Here's a version that does that and removes some recent bitrot. I have been looking at the full set of features of Cluster.pm and the requirements behind v10 as minimal version supported, and nothing really stands out. + # old

RE: Skipping logical replication transactions on subscriber side

On Friday, January 21, 2022 2:30 PM Amit Kapila wrote: > On Fri, Jan 21, 2022 at 10:32 AM osumi.takami...@fujitsu.com > wrote: > > > > On Friday, January 21, 2022 12:08 PM Masahiko Sawada > wrote: > > > I've attached an updated patch that incorporated these commends as > > > well as other

Re: CREATE TABLE ( .. STORAGE ..)

HI For patch create_table_storage-v1 1 +ALTER opt_column ColId SET STORAGE name +opt_column_storage: + STORAGE ColId { $$ = $2; } Are they both set to name or ColId? Although they are the same. 2 For ColumnDef new

Re: MultiXact\SLRU buffers configuration

> 21 янв. 2022 г., в 05:19, Shawn Debnath написал(а): > > On Thu, Jan 20, 2022 at 09:21:24PM +0500, Andrey Borodin wrote: >> CAUTION: This email originated from outside of the organization. Do not >> click links or open attachments unless you can confirm the sender and know >> the content

Re: support for MERGE

On Fri, 21 Jan 2022 at 05:06, Alvaro Herrera wrote: > Here's v8 of this patch. I have fixed the problems pointed out by Jaime > and Erik, as well as incorporated Zhihong, Erik and Justin's > documentation fixes (typos and otherwise). > > Not yet included: a fix for Peter's suggestion to raise

Re: Multiple Query IDs for a rewritten parse tree

On 1/9/22 5:49 AM, Tom Lane wrote: The idea I'd been vaguely thinking about is to allow attaching a list of query-hash nodes to a Query, where each node would contain a "tag" identifying the specific hash calculation method, and also the value of the query's hash calculated according to that

Re: Null commitTS bug

On Thu, Jan 20, 2022 at 12:00:56PM +0900, Kyotaro Horiguchi wrote: > This is that. I think this is a separate issue from the actual > bug. This is applicable at least back to 9.6 and I think this should > be applied back to all supported versions to avoid future backptach > conflicts. Looks fine

RE: [Proposal] Add foreign-server health checks infrastructure

Dear Fujii-san, Zhihong, I attached the latest version. The biggest change is that callbacks are no longer un-registered at the end of transactions. FDW developer must enable or disable timeout instead, via new APIs. The timer will be turned on when: * new GUC is >= 0, and * anyone calls

Re: do only critical work during single-user vacuum?

On Thu, Jan 20, 2022 at 4:14 AM John Naylor wrote: > > On Wed, Jan 19, 2022 at 12:46 AM Masahiko Sawada > wrote: > > > > On Fri, Jan 14, 2022 at 7:04 AM Bossart, Nathan wrote: > > > > > > I guess I'm ultimately imagining the new options as replacing the > > > vacuumdb implementation. IOW

Re: Skipping logical replication transactions on subscriber side

On Fri, Jan 21, 2022 at 2:09 PM Masahiko Sawada wrote: > > I've attached an updated patch that incorporated these commends as > well as other comments I got so far. > src/backend/replication/logical/worker.c (1) Didn't you mean to say "check the" instead of "clear" in the following comment?

Re: Report checkpoint progress in server logs

> I think the right choice to solve the *general* problem is the > mentioned pg_stat_progress_checkpoints. > > We may want to *additionally* have the ability to log the progress > specifically for the special cases when we're not able to use that > view. And in those case, we can perhaps just use

Re: Synchronizing slots from primary to standby

On Wed, Dec 15, 2021 at 7:13 AM Peter Eisentraut wrote: > > On 31.10.21 11:08, Peter Eisentraut wrote: > > I want to reactivate $subject. I took Petr Jelinek's patch from [0], > > rebased it, added a bit of testing. It basically works, but as > > mentioned in [0], there are various issues to

Re: Skipping logical replication transactions on subscriber side

On Fri, Jan 21, 2022 at 10:32 AM osumi.takami...@fujitsu.com wrote: > > On Friday, January 21, 2022 12:08 PM Masahiko Sawada > wrote: > > I've attached an updated patch that incorporated these commends as well as > > other comments I got so far. > Thank you for your update ! > > Few minor

RE: row filtering for logical replication

On Thur, Jan 20, 2022 10:26 PM Alvaro Herrera wrote: > > On 2022-Jan-20, Amit Kapila wrote: > > > It returns an invalid column referenced in an RF if any but if not > > then it helps to form pubactions which is anyway required at a later > > point in the caller. The idea is that when we are

RE: Skipping logical replication transactions on subscriber side

On Friday, January 21, 2022 12:08 PM Masahiko Sawada wrote: > I've attached an updated patch that incorporated these commends as well as > other comments I got so far. Thank you for your update ! Few minor comments. (1) trivial question For the users, was it perfectly clear that in the

Re: Skipping logical replication transactions on subscriber side

On Fri, Jan 21, 2022 at 1:20 PM Amit Kapila wrote: > > On Tue, Jan 18, 2022 at 9:21 AM Masahiko Sawada wrote: > > > > On Tue, Jan 18, 2022 at 12:37 PM Amit Kapila > > wrote: > > > > > > On Tue, Jan 18, 2022 at 8:34 AM tanghy.f...@fujitsu.com > > > wrote: > > > > > > > > On Mon, Jan 17, 2022

Re: Skipping logical replication transactions on subscriber side

On Tue, Jan 18, 2022 at 9:21 AM Masahiko Sawada wrote: > > On Tue, Jan 18, 2022 at 12:37 PM Amit Kapila wrote: > > > > On Tue, Jan 18, 2022 at 8:34 AM tanghy.f...@fujitsu.com > > wrote: > > > > > > On Mon, Jan 17, 2022 2:18 PM Masahiko Sawada > > > wrote: > > > > > > > > > > 2) The following

Re: XLogReadRecord() error in XlogReadTwoPhaseData()

On Fri, Jan 21, 2022 at 08:34:22AM +1300, Thomas Munro wrote: > On Mon, Jan 17, 2022 at 10:02 AM Noah Misch wrote: > > - Report a Debian bug for the sparc64+ext4 zeros problem. > > I suspect that 027_stream_regress.pl hits this kernel bug with high > probability[1]. I wonder if the owner of

Re: Skipping logical replication transactions on subscriber side

On Fri, Jan 21, 2022 at 8:39 AM Masahiko Sawada wrote: > > On Fri, Jan 21, 2022 at 1:18 AM Peter Eisentraut > wrote: > > > > I think the superuser check in AlterSubscription() might no longer be > > appropriate. Subscriptions can now be owned by non-superusers. Please > > check that. > > IIUC

RE: row filtering for logical replication

On Thursday, January 20, 2022 9:14 PM Alvaro Herrera wrote: > > I was skimming this and the changes in CheckCmdReplicaIdentity caught my > attention. "Is this code running at the publisher side or the subscriber > side?" I > wondered -- because the new error messages being added look intended

Re: Skipping logical replication transactions on subscriber side

On Wed, Jan 19, 2022 at 5:58 PM Amit Kapila wrote: > > On Wed, Jan 19, 2022 at 12:46 PM Masahiko Sawada > wrote: > > > > On Wed, Jan 19, 2022 at 12:22 PM osumi.takami...@fujitsu.com > > wrote: > > > > > > (6) apply_handle_stream_abort > > > > > > @@ -1209,6 +1300,13 @@

Re: Skipping logical replication transactions on subscriber side

On Wed, Jan 19, 2022 at 4:14 PM Greg Nancarrow wrote: > > On Tue, Jan 18, 2022 at 5:05 PM Masahiko Sawada wrote: > > > > I've attached a rebased patch. > > A couple of comments for the v8 patch: Thank you for the comments! > > doc/src/sgml/logical-replication.sgml > > (1) > Strictly-speaking

Re: Skipping logical replication transactions on subscriber side

On Wed, Jan 19, 2022 at 3:32 PM vignesh C wrote: > > On Sat, Jan 15, 2022 at 3:58 PM Amit Kapila wrote: > > > > On Fri, Jan 14, 2022 at 5:35 PM vignesh C wrote: > > > > > > Thanks for the updated patch, few minor comments: > > > 1) Should "SKIP" be "SKIP (" here: > > > @@ -1675,7 +1675,7 @@

Re: Skipping logical replication transactions on subscriber side

On Fri, Jan 21, 2022 at 1:18 AM Peter Eisentraut wrote: > > On 18.01.22 07:05, Masahiko Sawada wrote: > > I've attached a rebased patch. > > I think this is now almost done. Attached I have a small fixup patch > with some documentation proof-reading, and removing some comments I felt > are

Re: row filtering for logical replication

On Thu, Jan 20, 2022 at 7:56 PM Alvaro Herrera wrote: > > > > Maybe this was meant to be "validate RF > > > expressions" and return, perhaps, a bitmapset of all invalid columns > > > referenced? > > > > Currently, we stop as soon as we find the first invalid column. > > That seems quite strange.

Re: A test for replay of regression tests

On Mon, Jan 17, 2022 at 6:53 PM Noah Misch wrote: > On Mon, Jan 17, 2022 at 05:25:19PM +1300, Thomas Munro wrote: > > Here's how it failed on fairywren, in case someone knowledgeable of > > MSYS path translation etc can spot the problem: > You likely need a PostgreSQL::Test::Utils::perl2host()

Re: Refactoring of compression options in pg_basebackup

On Thu, Jan 20, 2022 at 10:25:43AM -0500, Robert Haas wrote: > You don't need to test for gzip and none in two places each. Just make > the block with the "It does not match ..." comment the "else" clause > for this last part. Indeed, that looks better. I have done an extra pass on this stuff

Re: autovacuum prioritization

On Thu, Jan 20, 2022 at 6:54 PM Peter Geoghegan wrote: > I agree that it doesn't follow that table A should be more of a > priority than table B, either because it has a greater age, or because > its age happens to exceed some actually-arbitrary threshold. But I > will point out that my ongoing

Re: New developer papercut - Makefile references INSTALL

On Wed, Jan 19, 2022 at 4:58 PM Tim McNamara wrote: > Hello, > > I encountered a minor road bump when checking out the pg source today. The > Makefile's all target includes the following help message if GNUmakefile > isn't available: > > echo "You need to run the 'configure' program first. See

Re: row filtering for logical replication

On Fri, Jan 21, 2022 at 12:13 AM Alvaro Herrera wrote: > > And while wondering about that, I stumbled upon > GetRelationPublicationActions(), which has a very weird API that it > always returns a palloc'ed block -- but without saying so. And > therefore, its only caller leaks that memory. Maybe

Re: PoC: using sampling to estimate joins / complex conditions

On 1/5/22 00:58, Andres Freund wrote: > Hi, > > On 2021-06-27 19:55:24 +0200, Tomas Vondra wrote: >> estimating joins is one of the significant gaps related to extended >> statistics, and I've been regularly asked about what we might do about >> that. This is an early experimental patch that I

Re: PublicationActions - use bit flags.

On Tue, Dec 21, 2021 at 12:55 PM Greg Nancarrow wrote: > > On Tue, Dec 21, 2021 at 11:56 AM Tom Lane wrote: > > > > Removing this is not good: > > > > if (relation->rd_pubactions) > > - { > > pfree(relation->rd_pubactions); > > -

Re: autovacuum prioritization

On Thu, Jan 20, 2022 at 11:24 AM Robert Haas wrote: > In my view, previous efforts in this area have been too simplistic. > For example, it's been proposed that a table that is perceived to be > in any kind of wraparound danger ought to get top priority, but I find > that implausible. I agree

Re: Poor performance PostgreSQL13/PostGIS 3.x

On Thu, Jan 20, 2022 at 10:31:15PM +, Lugosi, Jim wrote: > We are struggling to figure out what is going on. We are migrating from > PostgreSQL 9.6 to PostgreSQL 13 w/ PostGIS. Our 9.6 version was compiled > from source and the new version (13) was installed using Yum. BTW, the new >

Poor performance PostgreSQL13/PostGIS 3.x

Hi folks, We are struggling to figure out what is going on. We are migrating from PostgreSQL 9.6 to PostgreSQL 13 w/ PostGIS. Our 9.6 version was compiled from source and the new version (13) was installed using Yum. BTW, the new version is on a VM that has 16GB of memory, two cores, and

Re: slowest tap tests - split or accelerate?

On 1/19/22 21:18, Andres Freund wrote: > Hi, > > On 2022-01-19 09:42:31 -0800, Andres Freund wrote: >> Both ours have this. Unfortunately on windows cp doesn't natively >> exist. Although git does provide it. I tried a few things that appear to be >> natively available (time is best of three

Re: GSoC 2022

On Thu, 20 Jan 2022 at 14:32, Ilaria Battiston wrote: > Greetings -hackers, > > Our beloved Google Summer of Code is back for 2022! They have once again > changed some of how GSoC is going to work for this year, for a variety > of reasons, so please be sure to read this email and posts linked

Re: support for MERGE

On 2022-Jan-12, Jaime Casanova wrote: > I found two crashes, actually I found them on the original patch Álvaro > sent on november but just checked that those already exists. > > I configured with: > > CFLAGS="-ggdb -Og -g3 -fno-omit-frame-pointer" ./configure > --prefix=/opt/var/pgdg/15/merge

Re: support for MERGE

On 2022-Jan-17, Japin Li wrote: > So for NOT MATCHED, we are expected not use the target table columns. > > The code comes from execMerge.c says: > > /* > * Make source tuple available to ExecQual and ExecProject. We don't need > * the target tuple, since the WHEN quals and the

Re: Document atthasmissing default optimization avoids verification table scan

On Thu, Jan 20, 2022 at 3:31 PM Andrew Dunstan wrote: > > > On 1/20/22 12:25, Bossart, Nathan wrote: > > On 1/19/22, 5:15 PM, "James Coleman" wrote: > >> I'm open to the idea of wordsmithing here, of course, but I strongly > >> disagree that this is irrelevant data. There are plenty of > >>

Re: Document atthasmissing default optimization avoids verification table scan

On 1/20/22 12:25, Bossart, Nathan wrote: > On 1/19/22, 5:15 PM, "James Coleman" wrote: >> I'm open to the idea of wordsmithing here, of course, but I strongly >> disagree that this is irrelevant data. There are plenty of >> optimizations Postgres could theoretically implement but doesn't, so >>

Re: Merging statistics from children instead of re-sampling everything

On 6/30/21 17:15, Tomas Vondra wrote: > On 6/30/21 2:55 PM, Andrey Lepikhov wrote: >> Sorry, I forgot to send CC into pgsql-hackers. >> On 29/6/21 13:23, Tomas Vondra wrote: >>> Because sampling is fairly expensive, especially if you have to do it >>> for large number of child relations. And you'd

Re: Avoid erroring out when unable to remove or parse logical rewrite files to save checkpoint work

Thanks for your feedback. On 1/20/22, 11:47 AM, "Andres Freund" wrote: > It seems odd to change a bunch of things to not be errors anymore, but then > add new sources of errors. If we try to deal with concurrent deletions or > permission issues - otherwise what's the point of making unlink() not

Re: Avoid erroring out when unable to remove or parse logical rewrite files to save checkpoint work

Hi, On 2022-01-20 19:15:08 +, Bossart, Nathan wrote: > > * Why is it okay to ignore lstat failure? Seems like we might > > as well not even have the lstat. > > I added error checking for lstat(). It seems odd to change a bunch of things to not be errors anymore, but then add new sources of

Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)

On Thu, Jan 20, 2022 at 11:03 AM Shruthi Gowda wrote: > It is not required for PostgresObjectId. The unused_oids script > provides a list of unused oids in the manually-assignable OIDs range > (1-). Well, so ... why are we not treating the OIDs for these two databases the same? If there's a

Re: XLogReadRecord() error in XlogReadTwoPhaseData()

On Mon, Jan 17, 2022 at 10:02 AM Noah Misch wrote: > - Report a Debian bug for the sparc64+ext4 zeros problem. I suspect that 027_stream_regress.pl hits this kernel bug with high probability[1]. I wonder if the owner of kittiwake and tadarida would consider setting up an xfs file system? Or

Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations

On Thu, Jan 20, 2022 at 11:45 AM Peter Geoghegan wrote: > My thinking on vacuum_freeze_min_age has shifted very slightly. I now > think that I'll probably need to keep it around, just so things like > VACUUM FREEZE (which sets vacuum_freeze_min_age to 0 internally) > continue to work. So maybe

GSoC 2022

Greetings -hackers, Our beloved Google Summer of Code is back for 2022! They have once again changed some of how GSoC is going to work for this year, for a variety of reasons, so please be sure to read this email and posts linked for the updates if you're interested! In short, this year both

autovacuum prioritization

autovacuum, as it exists today, has some reasonable - though imperfect - heuristics for deciding which tables need to be vacuumed or analyzed. However, it has nothing to help it decide which tables need to be vacuumed or analyzed first. As a result, when it's configured aggressively enough, and

Re: Pluggable toaster

Hi, The patch provides assigning toaster to a data column separately. Assigning to a data type is considered worthy but is also a topic for further discussion and is not included in patch. We've been thinking how to integrate AMs and custom toasters, so any thoughts are welcome. Regards, On

Re: Document atthasmissing default optimization avoids verification table scan

On 1/19/22, 5:15 PM, "James Coleman" wrote: > I'm open to the idea of wordsmithing here, of course, but I strongly > disagree that this is irrelevant data. There are plenty of > optimizations Postgres could theoretically implement but doesn't, so > measuring what should happen by what you think

Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations

On Thu, Jan 20, 2022 at 6:55 AM Robert Haas wrote: > Great, I'm glad we agree on that much. I would be interested in > hearing what other people think about this scenario. Agreed. > I'm just being honest here when I say that I can't see any huge > reduction in risk. Nor a huge increase in risk.

Re: MultiXact\SLRU buffers configuration

> 20 янв. 2022 г., в 20:44, Shawn Debnath написал(а): > > If my test workload can be made better, please let me know. Happy to > re-run tests as needed. Shawn, thanks for the benchmarking! Can you please also test 2nd patch against a large multixact SLRUs? 2nd patch is not intended to do

Re: Skipping logical replication transactions on subscriber side

On 18.01.22 07:05, Masahiko Sawada wrote: I've attached a rebased patch. I think this is now almost done. Attached I have a small fixup patch with some documentation proof-reading, and removing some comments I felt are redundant. Some others have also sent you some documentation updates,

Re: refactoring basebackup.c

On Thu, Jan 20, 2022 at 8:00 AM Dipesh Pandit wrote: > Thanks for the feedback, I have incorporated the suggestions and > updated a new patch v2. Cool. I'll do a detailed review later, but I think this is going in a good direction. > I tried to add the test coverage for server side gzip

Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)

On Thu, Jan 20, 2022 at 7:57 PM Robert Haas wrote: > > On Thu, Jan 20, 2022 at 7:09 AM Shruthi Gowda wrote: > > > Here's an updated version in which I've reverted the changes to gram.y > > > and tried to improve the comments and documentation. Could you have a > > > look at implementing (2)

Re: Pluggable toaster

On Thu, Dec 30, 2021 at 11:40 AM Teodor Sigaev wrote: > We are working on custom toaster for JSONB [1], because current TOAST is > universal for any data type and because of that it has some disadvantages: > - "one toast fits all" may be not the best solution for particular > type

Re: Refactoring of compression options in pg_basebackup

On Thu, Jan 20, 2022 at 2:03 AM Michael Paquier wrote: > Well, if no colon is specified, we still need to check if optarg > is a pure integer if it does not match any of the supported methods, > as --compress=0 should be backward compatible with no compression and > --compress=1~9 should imply

Re: Replace uses of deprecated Python module distutils.sysconfig

On 1/18/22 19:18, Tom Lane wrote: > I wrote: >> Are we sure it's an issue within Python, rather than something we >> could dodge by invoking sysconfig differently? It's hard to believe >> that sysconfig could be totally unfit for the purpose of finding out >> the include path and would remain

Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations

On Wed, Jan 19, 2022 at 2:54 PM Peter Geoghegan wrote: > > On the other hand if that user is going to close that > > cursor after 10 minutes and open a new one in the same place 10 > > seconds later, the best thing to do is to keep FreezeLimit as low as > > possible, because the first time we

Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)

On Thu, Jan 20, 2022 at 7:09 AM Shruthi Gowda wrote: > > Here's an updated version in which I've reverted the changes to gram.y > > and tried to improve the comments and documentation. Could you have a > > look at implementing (2) above? > > Attached is the patch that implements comment (2).

Re: row filtering for logical replication

On 2022-Jan-20, Amit Kapila wrote: > It returns an invalid column referenced in an RF if any but if not > then it helps to form pubactions which is anyway required at a later > point in the caller. The idea is that when we are already traversing > publications we should store/gather as much info

Re: [PATCH] Add reloption for views to enable RLS

On Tue, 2022-01-18 at 16:16 +0100, Christoph Heiss wrote: > > I think that this should be a boolean reloption, for example > > "security_definer". > > If unset or set to "off", you would get the current behavior. > > A boolean option would have been indeed the better choice, I agree. > I haven't

Re: Document atthasmissing default optimization avoids verification table scan

On Wed, Jan 19, 2022 at 9:34 PM David G. Johnston wrote: > > On Wed, Jan 19, 2022 at 6:14 PM James Coleman wrote: >> >> I'm open to the idea of wordsmithing here, of course, but I strongly >> disagree that this is irrelevant data. > > > Ok, but wording aside, only changing a tip in the DDL - Add

Re: removing datlastsysoid

On Mon, Jan 17, 2022 at 3:43 PM Tom Lane wrote: > +1. Another reason to get rid of it is that it has nothing to do > with the system OID ranges defined in access/transam.h. Agreed. Thanks for looking. Committed. -- Robert Haas EDB: http://www.enterprisedb.com

Re: Push down time-related SQLValue functions to foreign server

Tom Lane писал 2022-01-18 23:01: I wrote: Alexander Pyhalov writes: This means we'll translate something like explain select * from t where d > now() - '1 day'::interval; to select * from t where d > $1; Right. After thinking about that a bit more, I see that this will result in a major

Re: row filtering for logical replication

On Thu, Jan 20, 2022 at 6:43 PM Alvaro Herrera wrote: > > And the actual reason I was looking at this code, is that I had stumbled > upon the new GetRelationPublicationInfo() function, which has an even > weirder API: > > > * Get the publication information for the given relation. > > * > > *

Re: Logical replication timeout problem

On Thu, Jan 20, 2022 at 2:35 PM wangw.f...@fujitsu.com wrote: > > On Wed, Jan 19, 2022 at 9:53 PM Fabrice Chapuis fabrice636...@gmail.com wrote: > > > Hello Amit, > > > If it takes little work for you, can you please send me a piece of code > > > with the change needed to do the test > > > > I

Re: Add last commit LSN to pg_last_committed_xact()

On Wed, Jan 19, 2022 at 10:12 PM Andres Freund wrote: > > Hi, > > On 2022-01-19 21:23:12 -0500, James Coleman wrote: > > { oid => '3537', descr => 'get identification of SQL object', > > diff --git a/src/include/storage/proc.h b/src/include/storage/proc.h > > index a5f9e9..2a026b0844 100644

Re: row filtering for logical replication

I was skimming this and the changes in CheckCmdReplicaIdentity caught my attention. "Is this code running at the publisher side or the subscriber side?" I wondered -- because the new error messages being added look intended to be thrown at the publisher side; but the existing error messages

Re: refactoring basebackup.c

Hi, Thanks for the feedback, I have incorporated the suggestions and updated a new patch v2. > I spent some time thinking about test coverage for the server-side > backup code today and came up with the attached (v12-0003). It does an > end-to-end test that exercises server-side backup and

Re: row filtering for logical replication

On Thu, Jan 20, 2022 at 5:03 PM tanghy.f...@fujitsu.com wrote: > > On Thu, Jan 20, 2022 9:13 AM houzj.f...@fujitsu.com > wrote: > > Attach the V68 patch set which addressed the above comments and changes. > > The version patch also fix the error message mentioned by Greg[1] > > > > I saw a

Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)

On Tue, Jan 18, 2022 at 2:34 AM Robert Haas wrote: > > On Mon, Jan 17, 2022 at 9:57 AM Shruthi Gowda wrote: > > I have rebased and generated the patches on top of PostgreSQL commit > > ID cf925936ecc031355cd56fbd392ec3180517a110. > > Kindly apply

RE: row filtering for logical replication

On Thu, Jan 20, 2022 9:13 AM houzj.f...@fujitsu.com wrote: > Attach the V68 patch set which addressed the above comments and changes. > The version patch also fix the error message mentioned by Greg[1] > I saw a problem about this patch, which is related to Replica Identity check. For

Re: row filtering for logical replication

On Thu, Jan 20, 2022 at 6:42 AM houzj.f...@fujitsu.com wrote: > > Attach the V68 patch set which addressed the above comments and changes. > Few comments and suggestions: == 1. /* + * For updates, if both the new tuple and old tuple are not null, then both + * of them

Re: pg_upgrade should truncate/remove its logs before running

On Thu, Jan 20, 2022 at 10:31:15AM +0100, Peter Eisentraut wrote: > I'm afraid that is too easily confused with the target directory. Generally, > a tool processes data from input to output or from source to target or > something like that, whereas a log is more clearly something separate from >

Re: Null commitTS bug

On Thu, Jan 20, 2022 at 12:00:56PM +0900, Kyotaro Horiguchi wrote: > This is that. I think this is a separate issue from the actual > bug. This is applicable at least back to 9.6 and I think this should > be applied back to all supported versions to avoid future backptach > conflicts. Thanks.

Re: pg_upgrade should truncate/remove its logs before running

On 19.01.22 09:13, Michael Paquier wrote: - Renaming of the option from --logdir to --outputdir, as this does not include only logs. That matches also better with default value assigned in previous patches, aka pg_upgrade_output.d. I'm afraid that is too easily confused with the target

RE: Logical replication timeout problem

On Wed, Jan 19, 2022 at 9:53 PM Fabrice Chapuis fabrice636...@gmail.com wrote: > Hello Amit, > If it takes little work for you, can you please send me a piece of code > with the change needed to do the test I wrote a patch(Send-keepalive.patch, please refer to

RE: [Proposal] Add foreign-server health checks infrastructure

Dear Fujii-san, Thank you for your interest! I'll post new version within several days. > > Yeah, remote-checking timeout will be enable even ifa local transaction is > opened. > > In my understanding, postgres cannot distinguish whether opening > > transactions > > are using only local object

Re: standby recovery fails (tablespace related) (tentative patch and discussion)

At Thu, 20 Jan 2022 15:07:22 +0900 (JST), Kyotaro Horiguchi wrote in > This version works for Unixen but still doesn't for Windows. I'm > searching for a fix for Windows. And this version works for Windows. Maybe I've took a wrong version to post. dir_readlink manipulated target file