Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX.

Thomas Munro writes: > I'll move it when committing. I'll let this patch sit for another day > to see if any other objections show up. FWIW, I remain fairly strongly against this, precisely because of the point that it requires us to start using a randomly different feature-probing technology

Re: Replication slot stats misgivings

Hi, On 2021-03-30 10:13:29 +0530, vignesh C wrote: > On Tue, Mar 30, 2021 at 6:28 AM Andres Freund wrote: > > Any chance you could write a tap test exercising a few of these cases? > > I can try to write a patch for this if nobody objects. Cool! > > E.g. things like: > > > > - create a few

Re: [HACKERS] logical decoding of two-phase transactions

On Tue, Mar 30, 2021 at 5:34 AM Peter Smith wrote: > > Please find attached the latest patch set v68* > > Differences from v67* are: > > * Rebased to HEAD @ today. > > * v68 fixes an issue reported by Vignesh [1] where a scenario was > found which still was able to cause a generated GID clash.

Re: [PATCH] add concurrent_abort callback for output plugin

On Mon, Mar 29, 2021 at 10:09 PM Markus Wanner < markus.wan...@enterprisedb.com> wrote: > On 29.03.21 13:02, Ajin Cherian wrote: > > Nice catch, Markus. > > Interesting suggestion Amit. Let me try and code this. > > Thanks, Ajin. Please consider this concurrent_abort callback as well. > I think

Re: Replication slot stats misgivings

On Tue, Mar 30, 2021 at 6:28 AM Andres Freund wrote: > > Hi, > > On 2021-03-26 07:58:58 +0530, Amit Kapila wrote: > > On Fri, Mar 26, 2021 at 1:17 AM Andres Freund wrote: > > > I suggest we wait doing anything about this until we know if the shared > > > stats patch gets in or not (I'd give it

Redundant errdetail prefix "The error was:" in some logical replication messages

There are a couple of error messages within the logical replication code where the errdetail text includes a prefix of "The error was:" I could not find any other examples in all the PG src which have a similar errdetail prefix like this. The text seems not only redundant, but "The error was:

Re: Obsolete comment in postgres_fdw.c

On Mon, Mar 29, 2021 at 7:15 PM Etsuro Fujita wrote: > While working on async execution, I noticed $subject. Attached is a > small patch for that. Applied to all supported branches. Best regards, Etsuro Fujita

RE: Copyright update for nbtsearch.c

On Tue, Mar 30, 2021 at 11:09:47AM +0800, Julien Rouhaud wrote: > This is actually gistfuncs.c. Thanks, you are right. There's typo in the mail title. Sorry for your confusion. On Tuesday, March 30, 2021 12:08 PM, Michael Paquier wrote: >Thanks. If I look at the top of HEAD, it is not the only

Re: Copyright update for nbtsearch.c

On Tue, Mar 30, 2021 at 11:09:47AM +0800, Julien Rouhaud wrote: > This is actually gistfuncs.c. There are other files impacted > (jsonbsubs, hex, sha1, pg_iovec and rewriteSearchCycle) see > https://www.postgresql.org/message-id/20210323143438.gb...@momjian.us. Ah, thanks. I did not notice this

Re: Copyright update for nbtsearch.c

Hi, On Tue, Mar 30, 2021 at 10:51 AM tanghy.f...@fujitsu.com wrote: > > Hi > > Found one code committed at 2021.01.13 with copyright 2020. > Fix it in the attached patch. This is actually gistfuncs.c. There are other files impacted (jsonbsubs, hex, sha1, pg_iovec and rewriteSearchCycle) see

Re: Copyright update for nbtsearch.c

On Tue, Mar 30, 2021 at 02:51:26AM +, tanghy.f...@fujitsu.com wrote: > Found one code committed at 2021.01.13 with copyright 2020. > Fix it in the attached patch. Thanks. If I look at the top of HEAD, it is not the only place. I am to blame for some of them like src/common/sha1. Will fix

Re: Extensions not dumped when --schema is used

On Mon, Mar 15, 2021 at 11:37:02AM +0100, Guillaume Lelarge wrote: > Anyways. Yeah, I know we're near feature freeze. This feature would be nice > to have, but I don't feel strongly about it. I think this feature is > currently lacking in PostgreSQL but I don't much care if it makes it to 14 > or

Copyright update for nbtsearch.c

Hi Found one code committed at 2021.01.13 with copyright 2020. Fix it in the attached patch. Regards, Tang 0001-Update-copyright-for-2021.patch Description: 0001-Update-copyright-for-2021.patch

Re: Autovacuum on partitioned table (autoanalyze)

Hi, I took a look at this patch. It does not apply because of 5f8727f5a67, so a rebase is needed. But I want to talk about the general approach in general, so it does not matter. The thread is fairly long, both in terms of number of messages and time (started in 2019), so let me restate my

Re: TRUNCATE on foreign table

2021年3月30日(火) 3:45 Fujii Masao : > > On 2021/03/28 2:37, Kazutaka Onishi wrote: > > Fujii-san, > > > > Thank you for your review! > > Now I prepare v5 patch and I'll answer to your each comment. please > > check this again. > > m(_ _)m > > > > 1. In postgres-fdw.sgml, "and truncatable" should be

Re: Allow matching whole DN from a client certificate

On Mon, Mar 29, 2021 at 10:57:00AM +0900, Michael Paquier wrote: > + switch (port->hba->clientcertname) > + { > + case clientCertDN: > + peer_username = port->peer_dn; > + break; > + default: > + peer_username = port->peer_cn; > + } > > This does

Re: Add missing function abs (interval)

On Mon, Mar 29, 2021 at 07:15:19PM -0400, John Naylor wrote: > Looking in the archives, I see this attempt that you can build upon: > https://www.postgresql.org/message-id/flat/CAHE3wggpj%2Bk-zXLUdcBDRe3oahkb21pSMPDm-HzPjZxJn4vMMw%40mail.gmail.com I see no problem with doing something more here.

Re: Replication slot stats misgivings

Hi, On 2021-03-26 07:58:58 +0530, Amit Kapila wrote: > On Fri, Mar 26, 2021 at 1:17 AM Andres Freund wrote: > > I suggest we wait doing anything about this until we know if the shared > > stats patch gets in or not (I'd give it 50% maybe). If it does get in > > things get a good bit easier,

Re: Proposal: Save user's original authenticated identity for logging

On Mon, Mar 29, 2021 at 11:53:03PM +, Jacob Champion wrote: > It's not a matter of the tests being stable, but of the tests needing > to change and evolve as the implementation changes. A big part of that > is visibility into what the tests are doing, so that you can debug > them. Sure, but I

Re: make the stats collector shutdown without writing the statsfiles if the immediate shutdown is requested.

On 2021/03/27 2:14, Andres Freund wrote: > Hi, > > On 2021-03-26 09:27:19 +0900, Masahiro Ikeda wrote: >> On 2021/03/25 19:48, Fujii Masao wrote: >>> Yes. So we should wait for the shared memory stats patch to be >>> committed before working on walreceiver stats patch more? >> >> Yes, I

Re: UniqueKey on Partitioned table.

On Tue, Mar 30, 2021 at 4:16 AM David Rowley wrote: > On Tue, 30 Mar 2021 at 02:27, Ashutosh Bapat > wrote: > > > > On Sat, Mar 27, 2021 at 11:44 AM Andy Fan > wrote: > > > > > > On Sat, Mar 27, 2021 at 3:07 AM Dmitry Dolgov <9erthali...@gmail.com> > wrote: > > >> Thanks for the patch. After a

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

Hi, I'd like to point out two less obvious things, about how this relates to Tom's proposal [1] and patch [2] from 2015. Tom approached the problem from a different direction, essentially allowing Var to be associated with a list of statistics instead of just one. So it's a somewhat orthogonal

Re: wal stats questions

I update the patch since there were my misunderstanding points. On 2021/03/26 16:20, Masahiro Ikeda wrote: > Thanks for many your suggestions! > I made the patch to handle the issues. > >> 1) What is the motivation to have both prevWalUsage and pgWalUsage, >>instead of just accumulating the

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

On 3/29/21 9:24 PM, Tomas Vondra wrote: > > > On 3/29/21 8:36 PM, Justin Pryzby wrote: >> Thanks for taking a fresh look at this. >> >> As you've written it, this can apply to either/both partitioned or >> inheritence. >> I imagine when "MERGE" goes away, this should apply only to

Re: TRUNCATE on foreign table

2021年3月30日(火) 2:54 Fujii Masao : > > On 2021/03/29 13:55, Michael Paquier wrote: > > On Mon, Mar 29, 2021 at 10:53:14AM +0900, Fujii Masao wrote: > >> I understand the motivation of this. But the other DMLs like UPDATE also > >> do the same thing for foreign tables? That is, when those DML

Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX.

On Tue, Mar 30, 2021 at 12:32 PM James Hilliard wrote: > Should I resend with that changed or can it just be fixed when applied? I'll move it when committing. I'll let this patch sit for another day to see if any other objections show up.

Re: Proposal: Save user's original authenticated identity for logging

On Mon, 2021-03-29 at 16:50 +0900, Michael Paquier wrote: > On Fri, Mar 26, 2021 at 10:41:03PM +, Jacob Champion wrote: > > For a few of the bugs I was tracking down, it was imperative. The tests > > aren't isolated enough (or at all) to keep one from affecting the > > others. > > If the

Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX.

On Mon, Mar 29, 2021 at 4:10 PM Thomas Munro wrote: > > On Tue, Mar 30, 2021 at 6:37 AM James Hilliard > wrote: > > Should it work if I just attach it to the thread like this? > > Yes. It automatically tries patches that are attached to threads that > are registered on commitfest.postgresql.org

Re: pg_amcheck contrib application

> On Mar 29, 2021, at 1:06 PM, Robert Haas wrote: > > Hmm, so this got ~10x bigger from my version. Could you perhaps > separate it out into a series of patches for easier review? Say, one > that just fixes the visibility logic, and then a second to avoid doing > the TOAST check with a buffer

Re: making update/delete of inheritance trees scale better

On Mon, Mar 29, 2021 at 11:41 PM Tom Lane wrote: > Amit Langote writes: > > On Sun, Mar 28, 2021 at 1:30 AM Tom Lane wrote: > >> I wanted to give a data dump of where I am. I've reviewed and > >> nontrivially modified 0001 and the executor parts of 0002, and > >> I'm fairly happy with the

Flaky vacuum truncate test in reloptions.sql

Hi, I rarely observe failure of vacuum with truncation test in reloptions.sql, i.e. the truncation doesn't happen: --- ../../src/test/regress/expected/reloptions.out 2020-04-16 12:37:17.749547401 +0300 +++ ../../src/test/regress/results/reloptions.out 2020-04-17 00:14:58.999211750

Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX.

On Tue, Mar 30, 2021 at 6:37 AM James Hilliard wrote: > Should it work if I just attach it to the thread like this? Yes. It automatically tries patches that are attached to threads that are registered on commitfest.postgresql.org on 4 OSes, and we can see that it succeeded, and we can inspect

Re: psql lacking clearerr()

On 2021-Mar-29, Alvaro Herrera wrote: > (And, yes, I'm to remove the %m too, because clearly that was a mistake.) Re-reading the other thread, I think the %m should stay. -- Álvaro Herrera Valdivia, Chile "I think my standards have lowered enough that now I think 'good design' is when

Re: Getting better results from valgrind leak tracking

On Tue, 30 Mar 2021 at 06:38, Andres Freund wrote: > On 2021-03-29 11:48:47 +1300, David Rowley wrote: > > I've done that in the attached. I added the > > ParallelBlockTableScanWorkerData as a pointer field in > > HeapScanDescData and change it so we only allocate memory for it for > > just

Re: psql lacking clearerr()

On 2021-Mar-25, Kyotaro Horiguchi wrote: > That worked for me:p And the following steps always raises that error. > > postgres=# select 1; (just to let it into history). > postgres=# C-s -> C-p -> C-m -> C-c > postgres=# select 1; > ... > could not print result table: Success Ah, thanks!

Re: Add client connection check during the execution of the query

On Tue, Mar 30, 2021 at 6:25 AM Maksim Milyutin wrote: > > Hi Thomas! Thanks for working on this patch. > > I have attached a new version with some typo corrections of doc entry, > removing of redundant `include` entries and trailing whitespaces. Also I > added in doc the case when single query

Re: Idea: Avoid JOINs by using path expressions to follow FKs

On Mon, Mar 29, 2021, at 20:53, Vik Fearing wrote: > On 3/29/21 7:55 PM, Joel Jacobson wrote: > > Do you know if REF is meant to be a replacement for foreign keys? > > > > Are they a different thing meant to co-exist with foreign keys, > > or are they actually foreign keys "under the hood" > > or

"box" type description

I believe the "box" type description is slightly incorrect: # \dT box Liste der Datentypen Schema │ Name │ Beschreibung ┼──┼── pg_catalog │ box │ geometric box '(lower left,upper right)' While the

Re: UniqueKey on Partitioned table.

On Tue, 30 Mar 2021 at 02:27, Ashutosh Bapat wrote: > > On Sat, Mar 27, 2021 at 11:44 AM Andy Fan wrote: > > > > On Sat, Mar 27, 2021 at 3:07 AM Dmitry Dolgov <9erthali...@gmail.com> wrote: > >> Thanks for the patch. After a short look through it I'm a bit confused > >> and wanted to clarify,

Re: pg_amcheck contrib application

On Mon, Mar 29, 2021 at 1:45 PM Mark Dilger wrote: > Thanks! The attached patch addresses your comments here and in your prior > email. In particular, this patch changes the tuple visibility logic to not > check tuples for which the inserting transaction aborted or is still in > progress,

Add missing function abs (interval)

On a newly set up system there are 7 types with a unary minus operator defined, but only 6 of them have an abs function: postgres=# \df abs List of functions Schema | Name | Result data type | Argument data types | Type

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

On 3/29/21 8:36 PM, Justin Pryzby wrote: > Thanks for taking a fresh look at this. > > As you've written it, this can apply to either/both partitioned or > inheritence. > I imagine when "MERGE" goes away, this should apply only to partitioned > tables. > (Actually, personally I would

Re: Idea: Avoid JOINs by using path expressions to follow FKs

On 3/29/21 7:55 PM, Joel Jacobson wrote: > On Mon, Mar 29, 2021, at 16:17, Vik Fearing wrote: >> CREATE TABLE order_details ( >> "order" REF(orders), >> product REF(products), >> quantity integer, >> PRIMARY KEY ("order", product) >> ); >> >> >> And the query would be: >> >> SELECT

Re: TRUNCATE on foreign table

On 2021/03/28 2:37, Kazutaka Onishi wrote: Fujii-san, Thank you for your review! Now I prepare v5 patch and I'll answer to your each comment. please check this again. m(_ _)m 1. In postgres-fdw.sgml, "and truncatable" should be appended into the above first description? 2. truncate.sgml

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

Thanks for taking a fresh look at this. As you've written it, this can apply to either/both partitioned or inheritence. I imagine when "MERGE" goes away, this should apply only to partitioned tables. (Actually, personally I would advocate to consider applying it to *both*, but I don't think

Re: [PATCH] Add --create-only option to pg_dump/pg_dumpall

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:not tested Hi I have tried the patch and the new option is able to control

Re: Idea: Avoid JOINs by using path expressions to follow FKs

On Mon, Mar 29, 2021, at 16:17, Vik Fearing wrote: > CREATE TABLE order_details ( > "order" REF(orders), > product REF(products), > quantity integer, > PRIMARY KEY ("order", product) > ); > > > And the query would be: > > SELECT DISTINCT

Re: TRUNCATE on foreign table

On 2021/03/29 13:55, Michael Paquier wrote: On Mon, Mar 29, 2021 at 10:53:14AM +0900, Fujii Masao wrote: I understand the motivation of this. But the other DMLs like UPDATE also do the same thing for foreign tables? That is, when those DML commands are executed on foreign tables, their

Re: TRUNCATE on foreign table

On 2021/03/28 2:37, Kazutaka Onishi wrote: Fujii-san, Thank you for your review! Now I prepare v5 patch and I'll answer to your each comment. please check this again. Thanks a lot! 5. For example, we can easily do that by truncate foreign tables before local ones. Thought? Umm... yeah,

Fix detection of preadv/pwritev support for OSX.

This fixes an issue where preadv and pwritev detection does not properly respect the OSX deployment target version symbol availability. James v3-0001-Fix-detection-of-preadv-pwritev-support-for-OSX.patch Description: Binary data

Re: row filtering for logical replication

Hi, > > While running some tests on v13 patches, I noticed that, in case the > published table data > already exists on the subscriber database before creating the > subscription, at the time of > CREATE subscription/table synchronization, an error as seen as follows > > With the patch: > >

Re: pg_amcheck contrib application

> On Mar 24, 2021, at 1:46 PM, Robert Haas wrote: > > Mark, > > Here's a quick and very dirty sketch of what I think perhaps this > logic could look like. This is pretty much untested and it might be > buggy, but at least you can see whether we're thinking at all in the > same direction.

Re: Getting better results from valgrind leak tracking

Hi, On 2021-03-29 11:48:47 +1300, David Rowley wrote: > I've done that in the attached. I added the > ParallelBlockTableScanWorkerData as a pointer field in > HeapScanDescData and change it so we only allocate memory for it for > just parallel scans. The field is left as NULL for non-parallel >

Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX.

Should it work if I just attach it to the thread like this? On Mon, Mar 29, 2021 at 7:52 AM David Steele wrote: > > Hi James, > > On 1/31/21 1:59 AM, James Hilliard wrote: > > On Fri, Jan 22, 2021 at 12:32 PM James Hilliard > > wrote: > >> > >> Fixes: > >> gcc -Wall -Wmissing-prototypes

Re: Get memory contexts of an arbitrary backend process

On 2021/03/29 11:59, torikoshia wrote: On 2021-03-26 14:08, Kyotaro Horiguchi wrote: At Fri, 26 Mar 2021 14:02:49 +0900, Fujii Masao wrote in On 2021/03/26 13:28, Kyotaro Horiguchi wrote: >> "some contexts are omitted" >> "n child contexts: total_bytes = ..." > Sorry I missed that is

Re: Add client connection check during the execution of the query

Hi Thomas! Thanks for working on this patch. I have attached a new version with some typo corrections of doc entry, removing of redundant `include` entries and trailing whitespaces. Also I added in doc the case when single query transaction with disconnected client might be eventually

Re: Pgsql Google Summer of Code

Greetings! * Zi Yi Xu (jennyziyi...@mail.utoronto.ca) wrote: > I am a third-year undergrad student at University of Toronto. I am very > interested to do a project in the context of Google Summer of Code with > mentors from PostgreSQL. I am mostly interested in working on improving >

Pgsql Google Summer of Code

Dear mentors, I am a third-year undergrad student at University of Toronto. I am very interested to do a project in the context of Google Summer of Code with mentors from PostgreSQL. I am mostly interested in working on improving pgeu-system for Conference Management. I would like to gain

Merging statistics from children instead of re-sampling everything

Hi, While reviewing the thread about issues with auto-analyze on partitioned tables [1] I remembered that the way we build statistics on the parent is somewhat expensive, because it samples rows from the children again. It's true we sample much smaller amounts of rows from each partition

Re: Idea: Avoid JOINs by using path expressions to follow FKs

On Mon, Mar 29, 2021, at 16:17, Vik Fearing wrote: > If you write your schema like this, then it becomes standards compliant: > ... > CREATE TABLE order_details ( > "order" REF(orders), > product REF(products), > quantity integer, > PRIMARY KEY ("order", product) > ); > > > And

Re: Walsender may fail to send wal to the end.

Greetings, * Kyotaro Horiguchi (horikyota@gmail.com) wrote: > At Mon, 29 Mar 2021 14:47:33 +0900, Michael Paquier > wrote in > > On Fri, Mar 26, 2021 at 10:16:40AM -0700, Andres Freund wrote: > > > On 2021-03-26 18:20:14 +0900, Kyotaro Horiguchi wrote: > > > > This is because

Re: Rename of triggers for partitioned tables

On 2021-Mar-29, Arne Roland wrote: > Alvaro Herrera wrote: > > I think this is not what we want to do. What you're doing here as I > > understand is traversing the inheritance hierarchy down using the > > trigger name, and then fail if the trigger with that name has a > > different parent or if

Re: Calendar support in localization

Hi Daniel, On Fri, Mar 26, 2021 at 8:51 PM Daniel Verite wrote: > Thomas Munro wrote: > > > Right, so if this is done by trying to extend Daniel Verite's icu_ext > > extension (link given earlier) and Robert's idea of a fast-castable > > type, I suppose you might want now()::icu_date +

Re: making update/delete of inheritance trees scale better

Amit Langote writes: > On Sun, Mar 28, 2021 at 1:30 AM Tom Lane wrote: >> I wanted to give a data dump of where I am. I've reviewed and >> nontrivially modified 0001 and the executor parts of 0002, and >> I'm fairly happy with the state of that much of the code now. > Thanks a lot for that

Re: pgbench stopped supporting large number of client connections on Windows

On 2/1/21 8:18 AM, Masahiko Sawada wrote: This patch on Commitfest has been "Waiting on Author" for almost 2 months. Could you share the current status? Are you updating the patch? Status update for a commitfest entry. Since this is a bug fix, I've moved this patch to the next commitfest. I

Re: Idea: Avoid JOINs by using path expressions to follow FKs

On 3/29/21 11:59 AM, Joel Jacobson wrote: > On Sun, Mar 28, 2021, at 16:04, Tom Lane wrote: >> I'm imagining a syntax in which >> you give the constraint name instead of the column name. Thought >> experiment: how could the original syntax proposal make any use of >> a multi-column foreign key? >

Re: Rename of triggers for partitioned tables

Thank you for the quick reply! Alvaro Herrera wrote: > I think this is not what we want to do. What you're doing here as I > understand is traversing the inheritance hierarchy down using the > trigger name, and then fail if the trigger with that name has a > different parent or if no trigger

Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX.

Hi James, On 1/31/21 1:59 AM, James Hilliard wrote: On Fri, Jan 22, 2021 at 12:32 PM James Hilliard wrote: Fixes: gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing

Re: [PATCH] Provide more information to filter_prepare

On Mon, Mar 29, 2021 at 5:40 PM Markus Wanner wrote: > > On 29.03.21 14:00, vignesh C wrote: > > Have you intentionally not > > written any tests as it will be difficult to predict the xid. I just > > wanted to confirm my understanding. > > Yeah, that's the reason this is hard to test this with a

Re: parallel distinct union and aggregate support patch

On 1/25/21 9:14 AM, bu...@sohu.com wrote: Now, I rewrite batch hashagg and sort, add some comment and combin too patches. base on master 2ad78a87f018260d4474eee63187e1cc73c9b976. They are support rescan and change GUC enable_batch_hashagg/enable_batch_sort to

Re: UniqueKey on Partitioned table.

On Sat, Mar 27, 2021 at 11:44 AM Andy Fan wrote: > > > > On Sat, Mar 27, 2021 at 3:07 AM Dmitry Dolgov <9erthali...@gmail.com> wrote: >> >> > On Sat, Feb 20, 2021 at 10:25:59AM +0800, Andy Fan wrote: >> > >> > The attached is a UnqiueKey with EquivalenceClass patch, I just complete >> > the >> >

Re: Rename of triggers for partitioned tables

On 2021-Mar-29, Arne Roland wrote: > @@ -1475,7 +1467,12 @@ renametrig(RenameStmt *stmt) > tuple = heap_copytuple(tuple); /* need a modifiable copy */ > trigform = (Form_pg_trigger) GETSTRUCT(tuple); > tgoid = trigform->oid; > - > + if

Re: Calendar support in localization

On Mon, 29 Mar 2021 at 14:33, Daniel Verite wrote: > > Matthias van de Meent wrote: > > > The results for the Japanese locale should be "0003 Reiwa" instead of > > "0033 Heisei", as the era changed in 2019. ICU releases have since > > implemented this and other corrections; this specific

Re: row filtering for logical replication

On Mon, Mar 29, 2021, at 6:45 AM, Rahila Syed wrote: > While running some tests on v13 patches, I noticed that, in case the > published table data > already exists on the subscriber database before creating the subscription, > at the time of > CREATE subscription/table synchronization, an error

Re: making update/delete of inheritance trees scale better

On Sun, Mar 28, 2021 at 1:30 AM Tom Lane wrote: > Amit Langote writes: > > Attached updated version of the patch. I have forgotten to mention in > > my recent posts on this thread one thing about 0001 that I had > > mentioned upthread back in June. That it currently fails a test in > >

Re: Calendar support in localization

Matthias van de Meent wrote: > The results for the Japanese locale should be "0003 Reiwa" instead of > "0033 Heisei", as the era changed in 2019. ICU releases have since > implemented this and other corrections; this specific change was > implemented in the batched release of ICU versions

Re: [PATCH] Provide more information to filter_prepare

On 29.03.21 14:00, vignesh C wrote: Have you intentionally not written any tests as it will be difficult to predict the xid. I just wanted to confirm my understanding. Yeah, that's the reason this is hard to test this with a regression test. It might be possible to come up with a TAP test

Re: [PATCH] Provide more information to filter_prepare

On Mon, Mar 29, 2021 at 4:46 PM Markus Wanner wrote: > > On 29.03.21 13:04, vignesh C wrote: > > The above content looks sufficient to me. > > Good, thanks. Based on that, I'm adding v7 of the patch. > Thanks for the updated patch. @@ -440,7 +441,8 @@

Re: making update/delete of inheritance trees scale better

On Sun, Mar 28, 2021 at 3:11 AM Tom Lane wrote: > I wrote: > > ... which is what forced you to remove or lobotomize several regression > > test cases. Now admittedly, that just moves the state of play for > > cross-partition updates into postgres_fdw partitions from "works > > sometimes" to

Re: [Proposal] Global temporary tables

> 2021年3月29日 16:37，Pavel Stehule 写道： > > > > ne 28. 3. 2021 v 15:07 odesílatel Andrew Dunstan > napsal: > > On 3/17/21 7:59 AM, wenjing wrote: > > ok > > > > The cause of the problem is that the name of the dependent function > > (readNextTransactionID) has

Re: [Proposal] Global temporary tables

> 2021年3月28日 21:07，Andrew Dunstan 写道： > > > On 3/17/21 7:59 AM, wenjing wrote: >> ok >> >> The cause of the problem is that the name of the dependent function >> (readNextTransactionID) has changed. I fixed it. >> >> This patch(V43) is base on 9fd2952cf4920d563e9cea51634c5b364d57f71a >> >>

Re: [PATCH] Provide more information to filter_prepare

On 29.03.21 13:04, vignesh C wrote: The above content looks sufficient to me. Good, thanks. Based on that, I'm adding v7 of the patch. Regards Markus From: Markus Wanner Date: Tue, 2 Mar 2021 11:33:54 +0100 Subject: [PATCH] Add an xid argument to the filter_prepare callback for output

Re: [PATCH] add concurrent_abort callback for output plugin

On 29.03.21 13:02, Ajin Cherian wrote: Nice catch, Markus. Interesting suggestion Amit. Let me try and code this. Thanks, Ajin. Please consider this concurrent_abort callback as well. I think it provides more flexibility for the output plugin and I would therefore prefer it over a solution

Re: [PATCH] Provide more information to filter_prepare

On Mon, Mar 29, 2021 at 4:22 PM Markus Wanner wrote: > > On 29.03.21 12:18, vignesh C wrote: > > But in prepare_filter_cb callback, by stating "other systems ..." it is > > not very clear who will change the GID. Are we referring to > > publisher/subscriber decoding? > > Thanks for your feedback.

Re: [PATCH] add concurrent_abort callback for output plugin

On Mon, Mar 29, 2021 at 8:33 PM Amit Kapila wrote: > On Mon, Mar 29, 2021 at 12:36 PM Markus Wanner > wrote: > > > > On 27.03.21 07:37, Amit Kapila wrote: > > > Isn't it better to send prepare from the publisher in such a case so > > > that subscribers can know about it when rollback prepared

Re: Calendar support in localization

On Fri, 26 Mar 2021 at 18:51, Daniel Verite wrote: > [...] > -[ RECORD 2 ]--+--- > cal| japanese > now_str| 26/mars/0033 Heisei 18:22:07.566 UTC+1 > now_parsed | 2021-03-26 18:22:07.566+01 > plus_1m| 26/avril/0033

Re: [PATCH] Provide more information to filter_prepare

On 29.03.21 12:18, vignesh C wrote: But in prepare_filter_cb callback, by stating "other systems ..." it is not very clear who will change the GID. Are we referring to publisher/subscriber decoding? Thanks for your feedback. This is not about GIDs at all, but just about identifying a

Re: Idea: Avoid JOINs by using path expressions to follow FKs

po 29. 3. 2021 v 12:01 odesílatel Joel Jacobson napsal: > On Sun, Mar 28, 2021, at 16:04, Tom Lane wrote: > > I'm imagining a syntax in which > you give the constraint name instead of the column name. Thought > experiment: how could the original syntax proposal make any use of > a multi-column

Re: proposal: unescape_text function

po 29. 3. 2021 v 12:19 odesílatel Peter Eisentraut < peter.eisentr...@enterprisedb.com> napsal: > On 25.03.21 10:44, Peter Eisentraut wrote: > > > > On 10.03.21 14:52, David Steele wrote: > >>> I thought about it a little bit more, and the prefix specification > >>> has not too much sense (more

Re: proposal: unescape_text function

On 25.03.21 10:44, Peter Eisentraut wrote: On 10.03.21 14:52, David Steele wrote: I thought about it a little bit more, and  the prefix specification has not too much sense (more if we implement this functionality as function "unistr"). I removed the optional argument and renamed the

Re: [PATCH] Provide more information to filter_prepare

On Mon, Mar 29, 2021 at 3:30 PM Markus Wanner < markus.wan...@enterprisedb.com> wrote: > > On 29.03.21 11:53, Amit Kapila wrote: > > Okay, but just in the previous sentence ("However, reuse of the same > > gid for example by a downstream node using > > multiple subscriptions may lead to it not

Obsolete comment in postgres_fdw.c

While working on async execution, I noticed $subject. Attached is a small patch for that. Best regards, Etsuro Fujita fix-obsolete-comment.patch Description: Binary data

Re: Idea: Avoid JOINs by using path expressions to follow FKs

On Sun, Mar 28, 2021, at 16:04, Tom Lane wrote: > I'm imagining a syntax in which > you give the constraint name instead of the column name. Thought > experiment: how could the original syntax proposal make any use of > a multi-column foreign key? Thanks for coming up with this genius idea. At

Re: [PATCH] Provide more information to filter_prepare

On 29.03.21 11:53, Amit Kapila wrote: Okay, but just in the previous sentence ("However, reuse of the same gid for example by a downstream node using multiple subscriptions may lead to it not being a unique identifier."), you have explained how sending a GID identifier can lead to a non-unique

Re: [Proposal] Global temporary tables

> 2021年3月28日 15:27，Pavel Stehule 写道： > > Hi > > st 17. 3. 2021 v 12:59 odesílatel wenjing > napsal: > ok > > The cause of the problem is that the name of the dependent function > (readNextTransactionID) has changed. I fixed it. > > This patch(V43) is base on

Re: [PATCH] add concurrent_abort callback for output plugin

On 29.03.21 11:33, Amit Kapila wrote: You don't need an additional callback for that if we do what I am suggesting above. Ah, are you suggesting a different change, then? To make two-phase transactions always send PREPARE even if concurrently aborted? In that case, sorry, I misunderstood.

Re: [PATCH] Provide more information to filter_prepare

On Mon, Mar 29, 2021 at 3:11 PM Markus Wanner wrote: > > On 29.03.21 11:13, Amit Kapila wrote: > > This might or might not be valid for all logical replication solutions > > but in the publisher-subscriber model, it would easily lead to > > duplicate identifiers and block the replication. For

Re: row filtering for logical replication

Hi Euler, While running some tests on v13 patches, I noticed that, in case the published table data already exists on the subscriber database before creating the subscription, at the time of CREATE subscription/table synchronization, an error as seen as follows With the patch: 2021-03-29

Re: [PATCH] Provide more information to filter_prepare

On 29.03.21 11:13, Amit Kapila wrote: This might or might not be valid for all logical replication solutions but in the publisher-subscriber model, it would easily lead to duplicate identifiers and block the replication. For example, when there are multiple subscriptions (say - 2) for multiple

Re: Rename of triggers for partitioned tables

Attached a rebased patch with the suggested "ONLY ON" change. Regards Arne From: Arne Roland Sent: Monday, March 29, 2021 9:37:53 AM To: David Steele; Alvaro Herrera Cc: Pg Hackers Subject: Re: Rename of triggers for partitioned tables David Steele wrote: >

  1   2   >