public inbox for [email protected]help / color / mirror / Atom feed
Re: Logical replication in the same cluster 29+ messages / 6 participants [nested] [flat]
* Re: Logical replication in the same cluster @ 2017-05-01 18:22 Peter Geoghegan <[email protected]> 0 siblings, 1 reply; 29+ messages in thread From: Peter Geoghegan @ 2017-05-01 18:22 UTC (permalink / raw) To: Robert Haas <[email protected]>; +Cc: Petr Jelinek <[email protected]>; Tom Lane <[email protected]>; Peter Eisentraut <[email protected]>; Michael Paquier <[email protected]>; Bruce Momjian <[email protected]>; pgsql-hackers On Fri, Apr 28, 2017 at 9:28 AM, Robert Haas <[email protected]> wrote: > On Thu, Apr 27, 2017 at 4:08 AM, Petr Jelinek > <[email protected]> wrote: >> Back when writing the original patch set, I was also playing with the >> idea of having CREATE SUBSCRIPTION do multiple committed steps in >> similar fashion to CREATE INDEX CONCURRENTLY but that leaves mess behind >> on failure which also wasn't very popular outcome. There is no inherent reason why the CREATE INDEX CONCURRENTLY style of using multiple transactions makes it necessary to leave a mess behind in the event of an error or hard crash. Is someone going to get around to fixing the problem for CREATE INDEX CONCURRENTLY (e.g., having extra steps to drop the useless index during recovery)? IIRC, this was always the plan. -- Peter Geoghegan VMware vCenter Server https://www.vmware.com/ -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers ^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: Logical replication in the same cluster @ 2017-05-01 18:24 Andres Freund <[email protected]> parent: Peter Geoghegan <[email protected]> 0 siblings, 2 replies; 29+ messages in thread From: Andres Freund @ 2017-05-01 18:24 UTC (permalink / raw) To: Peter Geoghegan <[email protected]>; +Cc: Robert Haas <[email protected]>; Petr Jelinek <[email protected]>; Tom Lane <[email protected]>; Peter Eisentraut <[email protected]>; Michael Paquier <[email protected]>; Bruce Momjian <[email protected]>; pgsql-hackers On 2017-05-01 11:22:47 -0700, Peter Geoghegan wrote: > On Fri, Apr 28, 2017 at 9:28 AM, Robert Haas <[email protected]> wrote: > > On Thu, Apr 27, 2017 at 4:08 AM, Petr Jelinek > > <[email protected]> wrote: > >> Back when writing the original patch set, I was also playing with the > >> idea of having CREATE SUBSCRIPTION do multiple committed steps in > >> similar fashion to CREATE INDEX CONCURRENTLY but that leaves mess behind > >> on failure which also wasn't very popular outcome. > > There is no inherent reason why the CREATE INDEX CONCURRENTLY style of > using multiple transactions makes it necessary to leave a mess behind > in the event of an error or hard crash. Is someone going to get around > to fixing the problem for CREATE INDEX CONCURRENTLY (e.g., having > extra steps to drop the useless index during recovery)? IIRC, this was > always the plan. Doing catalog changes in recovery is frought with problems. Essentially requires starting one worker per database, before allowing access. - Andres -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers ^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: Logical replication in the same cluster @ 2017-05-01 18:31 Peter Geoghegan <[email protected]> parent: Andres Freund <[email protected]> 1 sibling, 1 reply; 29+ messages in thread From: Peter Geoghegan @ 2017-05-01 18:31 UTC (permalink / raw) To: Andres Freund <[email protected]>; +Cc: Robert Haas <[email protected]>; Petr Jelinek <[email protected]>; Tom Lane <[email protected]>; Peter Eisentraut <[email protected]>; Michael Paquier <[email protected]>; Bruce Momjian <[email protected]>; pgsql-hackers On Mon, May 1, 2017 at 11:24 AM, Andres Freund <[email protected]> wrote: > Doing catalog changes in recovery is frought with problems. Essentially > requires starting one worker per database, before allowing access. Do you think it's worth just covering the case where you get an error, such as a duplicate violation? I imagine that that's the much more common case. -- Peter Geoghegan VMware vCenter Server https://www.vmware.com/ -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers ^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: Logical replication in the same cluster @ 2017-05-01 18:37 Andres Freund <[email protected]> parent: Peter Geoghegan <[email protected]> 0 siblings, 1 reply; 29+ messages in thread From: Andres Freund @ 2017-05-01 18:37 UTC (permalink / raw) To: Peter Geoghegan <[email protected]>; +Cc: Robert Haas <[email protected]>; Petr Jelinek <[email protected]>; Tom Lane <[email protected]>; Peter Eisentraut <[email protected]>; Michael Paquier <[email protected]>; Bruce Momjian <[email protected]>; pgsql-hackers On 2017-05-01 11:31:53 -0700, Peter Geoghegan wrote: > On Mon, May 1, 2017 at 11:24 AM, Andres Freund <[email protected]> wrote: > > Doing catalog changes in recovery is frought with problems. Essentially > > requires starting one worker per database, before allowing access. > > Do you think it's worth just covering the case where you get an error, > such as a duplicate violation? I imagine that that's the much more > common case. What exactly are you proposing to do? You mean catching errors in the creating backend, if it didn't crash? That doesn't strike me as a good idea, because it'll push down the likelihood of the issue below where people will see it, but it'll still be likely enough for it to create problems. - Andres -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers ^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: Logical replication in the same cluster @ 2017-05-01 19:04 Peter Geoghegan <[email protected]> parent: Andres Freund <[email protected]> 0 siblings, 0 replies; 29+ messages in thread From: Peter Geoghegan @ 2017-05-01 19:04 UTC (permalink / raw) To: Andres Freund <[email protected]>; +Cc: Robert Haas <[email protected]>; Petr Jelinek <[email protected]>; Tom Lane <[email protected]>; Peter Eisentraut <[email protected]>; Michael Paquier <[email protected]>; Bruce Momjian <[email protected]>; pgsql-hackers On Mon, May 1, 2017 at 11:37 AM, Andres Freund <[email protected]> wrote: > What exactly are you proposing to do? You mean catching errors in the > creating backend, if it didn't crash? That is what I meant, though I'm not actually proposing to do anything. > That doesn't strike me as a good > idea, because it'll push down the likelihood of the issue below where > people will see it, but it'll still be likely enough for it to create > problems. I was concerned about that too. I have a hard time defending changes like this to myself, but it doesn't hurt to ask. -- Peter Geoghegan VMware vCenter Server https://www.vmware.com/ -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers ^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: Logical replication in the same cluster @ 2017-05-01 21:20 Greg Stark <[email protected]> parent: Andres Freund <[email protected]> 1 sibling, 0 replies; 29+ messages in thread From: Greg Stark @ 2017-05-01 21:20 UTC (permalink / raw) To: Andres Freund <[email protected]>; +Cc: Peter Geoghegan <[email protected]>; Robert Haas <[email protected]>; Petr Jelinek <[email protected]>; Tom Lane <[email protected]>; Peter Eisentraut <[email protected]>; Michael Paquier <[email protected]>; Bruce Momjian <[email protected]>; pgsql-hackers On 1 May 2017 at 19:24, Andres Freund <[email protected]> wrote: >> There is no inherent reason why the CREATE INDEX CONCURRENTLY style of >> using multiple transactions makes it necessary to leave a mess behind >> in the event of an error or hard crash. Is someone going to get around >> to fixing the problem for CREATE INDEX CONCURRENTLY (e.g., having >> extra steps to drop the useless index during recovery)? IIRC, this was >> always the plan. > > Doing catalog changes in recovery is frought with problems. Essentially > requires starting one worker per database, before allowing access. The "plan" was to add more layers PG_TRY and transactions so that if there was an error during building the index all the remnants of the failed index build got cleaned up. But when I went tried to actually do it the problem seemed to metastatize and it was going to require two or three layers of messy nested PG_TRY and extra transactions. Perhaps there's a cleaner way to structure it and I should look again. I don't recall ever having a plan to do anything in recovery. I think we did talk about why it was hard to mark hash indexes invalid during recovery which was probably the same problem. -- greg -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers ^ permalink raw reply [nested|flat] 29+ messages in thread
* [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple @ 2021-01-18 08:04 Japin Li <[email protected]> 0 siblings, 0 replies; 29+ messages in thread From: Japin Li @ 2021-01-18 08:04 UTC (permalink / raw) --- src/backend/replication/logical/proto.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/backend/replication/logical/proto.c b/src/backend/replication/logical/proto.c index 62275ebabe..f2c85cabb5 100644 --- a/src/backend/replication/logical/proto.c +++ b/src/backend/replication/logical/proto.c @@ -493,7 +493,6 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar HeapTuple typtup; Form_pg_type typclass; Form_pg_attribute att = TupleDescAttr(desc, i); - char *outputstr; if (att->attisdropped || att->attgenerated) continue; @@ -537,6 +536,8 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar } else { + char *outputstr; + pq_sendbyte(out, LOGICALREP_COLUMN_TEXT); outputstr = OidOutputFunctionCall(typclass->typoutput, values[i]); pq_sendcountedtext(out, outputstr, strlen(outputstr), false); -- 2.30.0 --=-=-=-- ^ permalink raw reply [nested|flat] 29+ messages in thread
* [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple @ 2021-01-18 08:04 Japin Li <[email protected]> 0 siblings, 0 replies; 29+ messages in thread From: Japin Li @ 2021-01-18 08:04 UTC (permalink / raw) --- src/backend/replication/logical/proto.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/backend/replication/logical/proto.c b/src/backend/replication/logical/proto.c index 62275ebabe..f2c85cabb5 100644 --- a/src/backend/replication/logical/proto.c +++ b/src/backend/replication/logical/proto.c @@ -493,7 +493,6 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar HeapTuple typtup; Form_pg_type typclass; Form_pg_attribute att = TupleDescAttr(desc, i); - char *outputstr; if (att->attisdropped || att->attgenerated) continue; @@ -537,6 +536,8 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar } else { + char *outputstr; + pq_sendbyte(out, LOGICALREP_COLUMN_TEXT); outputstr = OidOutputFunctionCall(typclass->typoutput, values[i]); pq_sendcountedtext(out, outputstr, strlen(outputstr), false); -- 2.30.0 --=-=-=-- ^ permalink raw reply [nested|flat] 29+ messages in thread
* [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple @ 2021-01-18 08:04 Japin Li <[email protected]> 0 siblings, 0 replies; 29+ messages in thread From: Japin Li @ 2021-01-18 08:04 UTC (permalink / raw) --- src/backend/replication/logical/proto.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/backend/replication/logical/proto.c b/src/backend/replication/logical/proto.c index 62275ebabe..f2c85cabb5 100644 --- a/src/backend/replication/logical/proto.c +++ b/src/backend/replication/logical/proto.c @@ -493,7 +493,6 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar HeapTuple typtup; Form_pg_type typclass; Form_pg_attribute att = TupleDescAttr(desc, i); - char *outputstr; if (att->attisdropped || att->attgenerated) continue; @@ -537,6 +536,8 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar } else { + char *outputstr; + pq_sendbyte(out, LOGICALREP_COLUMN_TEXT); outputstr = OidOutputFunctionCall(typclass->typoutput, values[i]); pq_sendcountedtext(out, outputstr, strlen(outputstr), false); -- 2.30.0 --=-=-=-- ^ permalink raw reply [nested|flat] 29+ messages in thread
* [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple @ 2021-01-18 08:04 Japin Li <[email protected]> 0 siblings, 0 replies; 29+ messages in thread From: Japin Li @ 2021-01-18 08:04 UTC (permalink / raw) --- src/backend/replication/logical/proto.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/backend/replication/logical/proto.c b/src/backend/replication/logical/proto.c index 62275ebabe..f2c85cabb5 100644 --- a/src/backend/replication/logical/proto.c +++ b/src/backend/replication/logical/proto.c @@ -493,7 +493,6 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar HeapTuple typtup; Form_pg_type typclass; Form_pg_attribute att = TupleDescAttr(desc, i); - char *outputstr; if (att->attisdropped || att->attgenerated) continue; @@ -537,6 +536,8 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar } else { + char *outputstr; + pq_sendbyte(out, LOGICALREP_COLUMN_TEXT); outputstr = OidOutputFunctionCall(typclass->typoutput, values[i]); pq_sendcountedtext(out, outputstr, strlen(outputstr), false); -- 2.30.0 --=-=-=-- ^ permalink raw reply [nested|flat] 29+ messages in thread
* [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple @ 2021-01-18 08:04 Japin Li <[email protected]> 0 siblings, 0 replies; 29+ messages in thread From: Japin Li @ 2021-01-18 08:04 UTC (permalink / raw) --- src/backend/replication/logical/proto.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/backend/replication/logical/proto.c b/src/backend/replication/logical/proto.c index 62275ebabe..f2c85cabb5 100644 --- a/src/backend/replication/logical/proto.c +++ b/src/backend/replication/logical/proto.c @@ -493,7 +493,6 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar HeapTuple typtup; Form_pg_type typclass; Form_pg_attribute att = TupleDescAttr(desc, i); - char *outputstr; if (att->attisdropped || att->attgenerated) continue; @@ -537,6 +536,8 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar } else { + char *outputstr; + pq_sendbyte(out, LOGICALREP_COLUMN_TEXT); outputstr = OidOutputFunctionCall(typclass->typoutput, values[i]); pq_sendcountedtext(out, outputstr, strlen(outputstr), false); -- 2.30.0 --=-=-=-- ^ permalink raw reply [nested|flat] 29+ messages in thread
* [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple @ 2021-01-18 08:04 Japin Li <[email protected]> 0 siblings, 0 replies; 29+ messages in thread From: Japin Li @ 2021-01-18 08:04 UTC (permalink / raw) --- src/backend/replication/logical/proto.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/backend/replication/logical/proto.c b/src/backend/replication/logical/proto.c index 62275ebabe..f2c85cabb5 100644 --- a/src/backend/replication/logical/proto.c +++ b/src/backend/replication/logical/proto.c @@ -493,7 +493,6 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar HeapTuple typtup; Form_pg_type typclass; Form_pg_attribute att = TupleDescAttr(desc, i); - char *outputstr; if (att->attisdropped || att->attgenerated) continue; @@ -537,6 +536,8 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar } else { + char *outputstr; + pq_sendbyte(out, LOGICALREP_COLUMN_TEXT); outputstr = OidOutputFunctionCall(typclass->typoutput, values[i]); pq_sendcountedtext(out, outputstr, strlen(outputstr), false); -- 2.30.0 --=-=-=-- ^ permalink raw reply [nested|flat] 29+ messages in thread
* [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple @ 2021-01-18 08:04 Japin Li <[email protected]> 0 siblings, 0 replies; 29+ messages in thread From: Japin Li @ 2021-01-18 08:04 UTC (permalink / raw) --- src/backend/replication/logical/proto.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/backend/replication/logical/proto.c b/src/backend/replication/logical/proto.c index 62275ebabe..f2c85cabb5 100644 --- a/src/backend/replication/logical/proto.c +++ b/src/backend/replication/logical/proto.c @@ -493,7 +493,6 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar HeapTuple typtup; Form_pg_type typclass; Form_pg_attribute att = TupleDescAttr(desc, i); - char *outputstr; if (att->attisdropped || att->attgenerated) continue; @@ -537,6 +536,8 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar } else { + char *outputstr; + pq_sendbyte(out, LOGICALREP_COLUMN_TEXT); outputstr = OidOutputFunctionCall(typclass->typoutput, values[i]); pq_sendcountedtext(out, outputstr, strlen(outputstr), false); -- 2.30.0 --=-=-=-- ^ permalink raw reply [nested|flat] 29+ messages in thread
* [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple @ 2021-01-18 08:04 Japin Li <[email protected]> 0 siblings, 0 replies; 29+ messages in thread From: Japin Li @ 2021-01-18 08:04 UTC (permalink / raw) --- src/backend/replication/logical/proto.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/backend/replication/logical/proto.c b/src/backend/replication/logical/proto.c index 62275ebabe..f2c85cabb5 100644 --- a/src/backend/replication/logical/proto.c +++ b/src/backend/replication/logical/proto.c @@ -493,7 +493,6 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar HeapTuple typtup; Form_pg_type typclass; Form_pg_attribute att = TupleDescAttr(desc, i); - char *outputstr; if (att->attisdropped || att->attgenerated) continue; @@ -537,6 +536,8 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar } else { + char *outputstr; + pq_sendbyte(out, LOGICALREP_COLUMN_TEXT); outputstr = OidOutputFunctionCall(typclass->typoutput, values[i]); pq_sendcountedtext(out, outputstr, strlen(outputstr), false); -- 2.30.0 --=-=-=-- ^ permalink raw reply [nested|flat] 29+ messages in thread
* [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple @ 2021-01-18 08:04 Japin Li <[email protected]> 0 siblings, 0 replies; 29+ messages in thread From: Japin Li @ 2021-01-18 08:04 UTC (permalink / raw) --- src/backend/replication/logical/proto.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/backend/replication/logical/proto.c b/src/backend/replication/logical/proto.c index 62275ebabe..f2c85cabb5 100644 --- a/src/backend/replication/logical/proto.c +++ b/src/backend/replication/logical/proto.c @@ -493,7 +493,6 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar HeapTuple typtup; Form_pg_type typclass; Form_pg_attribute att = TupleDescAttr(desc, i); - char *outputstr; if (att->attisdropped || att->attgenerated) continue; @@ -537,6 +536,8 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar } else { + char *outputstr; + pq_sendbyte(out, LOGICALREP_COLUMN_TEXT); outputstr = OidOutputFunctionCall(typclass->typoutput, values[i]); pq_sendcountedtext(out, outputstr, strlen(outputstr), false); -- 2.30.0 --=-=-=-- ^ permalink raw reply [nested|flat] 29+ messages in thread
* [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple @ 2021-01-18 08:04 Japin Li <[email protected]> 0 siblings, 0 replies; 29+ messages in thread From: Japin Li @ 2021-01-18 08:04 UTC (permalink / raw) --- src/backend/replication/logical/proto.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/backend/replication/logical/proto.c b/src/backend/replication/logical/proto.c index 62275ebabe..f2c85cabb5 100644 --- a/src/backend/replication/logical/proto.c +++ b/src/backend/replication/logical/proto.c @@ -493,7 +493,6 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar HeapTuple typtup; Form_pg_type typclass; Form_pg_attribute att = TupleDescAttr(desc, i); - char *outputstr; if (att->attisdropped || att->attgenerated) continue; @@ -537,6 +536,8 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar } else { + char *outputstr; + pq_sendbyte(out, LOGICALREP_COLUMN_TEXT); outputstr = OidOutputFunctionCall(typclass->typoutput, values[i]); pq_sendcountedtext(out, outputstr, strlen(outputstr), false); -- 2.30.0 --=-=-=-- ^ permalink raw reply [nested|flat] 29+ messages in thread
* [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple @ 2021-01-18 08:04 Japin Li <[email protected]> 0 siblings, 0 replies; 29+ messages in thread From: Japin Li @ 2021-01-18 08:04 UTC (permalink / raw) --- src/backend/replication/logical/proto.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/backend/replication/logical/proto.c b/src/backend/replication/logical/proto.c index 62275ebabe..f2c85cabb5 100644 --- a/src/backend/replication/logical/proto.c +++ b/src/backend/replication/logical/proto.c @@ -493,7 +493,6 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar HeapTuple typtup; Form_pg_type typclass; Form_pg_attribute att = TupleDescAttr(desc, i); - char *outputstr; if (att->attisdropped || att->attgenerated) continue; @@ -537,6 +536,8 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar } else { + char *outputstr; + pq_sendbyte(out, LOGICALREP_COLUMN_TEXT); outputstr = OidOutputFunctionCall(typclass->typoutput, values[i]); pq_sendcountedtext(out, outputstr, strlen(outputstr), false); -- 2.30.0 --=-=-=-- ^ permalink raw reply [nested|flat] 29+ messages in thread
* [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple @ 2021-01-18 08:04 Japin Li <[email protected]> 0 siblings, 0 replies; 29+ messages in thread From: Japin Li @ 2021-01-18 08:04 UTC (permalink / raw) --- src/backend/replication/logical/proto.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/backend/replication/logical/proto.c b/src/backend/replication/logical/proto.c index 62275ebabe..f2c85cabb5 100644 --- a/src/backend/replication/logical/proto.c +++ b/src/backend/replication/logical/proto.c @@ -493,7 +493,6 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar HeapTuple typtup; Form_pg_type typclass; Form_pg_attribute att = TupleDescAttr(desc, i); - char *outputstr; if (att->attisdropped || att->attgenerated) continue; @@ -537,6 +536,8 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar } else { + char *outputstr; + pq_sendbyte(out, LOGICALREP_COLUMN_TEXT); outputstr = OidOutputFunctionCall(typclass->typoutput, values[i]); pq_sendcountedtext(out, outputstr, strlen(outputstr), false); -- 2.30.0 --=-=-=-- ^ permalink raw reply [nested|flat] 29+ messages in thread
* [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple @ 2021-01-18 08:04 Japin Li <[email protected]> 0 siblings, 0 replies; 29+ messages in thread From: Japin Li @ 2021-01-18 08:04 UTC (permalink / raw) --- src/backend/replication/logical/proto.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/backend/replication/logical/proto.c b/src/backend/replication/logical/proto.c index 62275ebabe..f2c85cabb5 100644 --- a/src/backend/replication/logical/proto.c +++ b/src/backend/replication/logical/proto.c @@ -493,7 +493,6 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar HeapTuple typtup; Form_pg_type typclass; Form_pg_attribute att = TupleDescAttr(desc, i); - char *outputstr; if (att->attisdropped || att->attgenerated) continue; @@ -537,6 +536,8 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar } else { + char *outputstr; + pq_sendbyte(out, LOGICALREP_COLUMN_TEXT); outputstr = OidOutputFunctionCall(typclass->typoutput, values[i]); pq_sendcountedtext(out, outputstr, strlen(outputstr), false); -- 2.30.0 --=-=-=-- ^ permalink raw reply [nested|flat] 29+ messages in thread
* [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple @ 2021-01-18 08:04 Japin Li <[email protected]> 0 siblings, 0 replies; 29+ messages in thread From: Japin Li @ 2021-01-18 08:04 UTC (permalink / raw) --- src/backend/replication/logical/proto.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/backend/replication/logical/proto.c b/src/backend/replication/logical/proto.c index 62275ebabe..f2c85cabb5 100644 --- a/src/backend/replication/logical/proto.c +++ b/src/backend/replication/logical/proto.c @@ -493,7 +493,6 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar HeapTuple typtup; Form_pg_type typclass; Form_pg_attribute att = TupleDescAttr(desc, i); - char *outputstr; if (att->attisdropped || att->attgenerated) continue; @@ -537,6 +536,8 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar } else { + char *outputstr; + pq_sendbyte(out, LOGICALREP_COLUMN_TEXT); outputstr = OidOutputFunctionCall(typclass->typoutput, values[i]); pq_sendcountedtext(out, outputstr, strlen(outputstr), false); -- 2.30.0 --=-=-=-- ^ permalink raw reply [nested|flat] 29+ messages in thread
* [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple @ 2021-01-18 08:04 Japin Li <[email protected]> 0 siblings, 0 replies; 29+ messages in thread From: Japin Li @ 2021-01-18 08:04 UTC (permalink / raw) --- src/backend/replication/logical/proto.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/backend/replication/logical/proto.c b/src/backend/replication/logical/proto.c index 62275ebabe..f2c85cabb5 100644 --- a/src/backend/replication/logical/proto.c +++ b/src/backend/replication/logical/proto.c @@ -493,7 +493,6 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar HeapTuple typtup; Form_pg_type typclass; Form_pg_attribute att = TupleDescAttr(desc, i); - char *outputstr; if (att->attisdropped || att->attgenerated) continue; @@ -537,6 +536,8 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar } else { + char *outputstr; + pq_sendbyte(out, LOGICALREP_COLUMN_TEXT); outputstr = OidOutputFunctionCall(typclass->typoutput, values[i]); pq_sendcountedtext(out, outputstr, strlen(outputstr), false); -- 2.30.0 --=-=-=-- ^ permalink raw reply [nested|flat] 29+ messages in thread
* [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple @ 2021-01-18 08:04 Japin Li <[email protected]> 0 siblings, 0 replies; 29+ messages in thread From: Japin Li @ 2021-01-18 08:04 UTC (permalink / raw) --- src/backend/replication/logical/proto.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/backend/replication/logical/proto.c b/src/backend/replication/logical/proto.c index 62275ebabe..f2c85cabb5 100644 --- a/src/backend/replication/logical/proto.c +++ b/src/backend/replication/logical/proto.c @@ -493,7 +493,6 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar HeapTuple typtup; Form_pg_type typclass; Form_pg_attribute att = TupleDescAttr(desc, i); - char *outputstr; if (att->attisdropped || att->attgenerated) continue; @@ -537,6 +536,8 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar } else { + char *outputstr; + pq_sendbyte(out, LOGICALREP_COLUMN_TEXT); outputstr = OidOutputFunctionCall(typclass->typoutput, values[i]); pq_sendcountedtext(out, outputstr, strlen(outputstr), false); -- 2.30.0 --=-=-=-- ^ permalink raw reply [nested|flat] 29+ messages in thread
* [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple @ 2021-01-18 08:04 Japin Li <[email protected]> 0 siblings, 0 replies; 29+ messages in thread From: Japin Li @ 2021-01-18 08:04 UTC (permalink / raw) --- src/backend/replication/logical/proto.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/backend/replication/logical/proto.c b/src/backend/replication/logical/proto.c index 62275ebabe..f2c85cabb5 100644 --- a/src/backend/replication/logical/proto.c +++ b/src/backend/replication/logical/proto.c @@ -493,7 +493,6 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar HeapTuple typtup; Form_pg_type typclass; Form_pg_attribute att = TupleDescAttr(desc, i); - char *outputstr; if (att->attisdropped || att->attgenerated) continue; @@ -537,6 +536,8 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar } else { + char *outputstr; + pq_sendbyte(out, LOGICALREP_COLUMN_TEXT); outputstr = OidOutputFunctionCall(typclass->typoutput, values[i]); pq_sendcountedtext(out, outputstr, strlen(outputstr), false); -- 2.30.0 --=-=-=-- ^ permalink raw reply [nested|flat] 29+ messages in thread
* [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple @ 2021-01-18 08:04 Japin Li <[email protected]> 0 siblings, 0 replies; 29+ messages in thread From: Japin Li @ 2021-01-18 08:04 UTC (permalink / raw) --- src/backend/replication/logical/proto.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/backend/replication/logical/proto.c b/src/backend/replication/logical/proto.c index 62275ebabe..f2c85cabb5 100644 --- a/src/backend/replication/logical/proto.c +++ b/src/backend/replication/logical/proto.c @@ -493,7 +493,6 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar HeapTuple typtup; Form_pg_type typclass; Form_pg_attribute att = TupleDescAttr(desc, i); - char *outputstr; if (att->attisdropped || att->attgenerated) continue; @@ -537,6 +536,8 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar } else { + char *outputstr; + pq_sendbyte(out, LOGICALREP_COLUMN_TEXT); outputstr = OidOutputFunctionCall(typclass->typoutput, values[i]); pq_sendcountedtext(out, outputstr, strlen(outputstr), false); -- 2.30.0 --=-=-=-- ^ permalink raw reply [nested|flat] 29+ messages in thread
* [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple @ 2021-01-18 08:04 Japin Li <[email protected]> 0 siblings, 0 replies; 29+ messages in thread From: Japin Li @ 2021-01-18 08:04 UTC (permalink / raw) --- src/backend/replication/logical/proto.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/backend/replication/logical/proto.c b/src/backend/replication/logical/proto.c index 62275ebabe..f2c85cabb5 100644 --- a/src/backend/replication/logical/proto.c +++ b/src/backend/replication/logical/proto.c @@ -493,7 +493,6 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar HeapTuple typtup; Form_pg_type typclass; Form_pg_attribute att = TupleDescAttr(desc, i); - char *outputstr; if (att->attisdropped || att->attgenerated) continue; @@ -537,6 +536,8 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar } else { + char *outputstr; + pq_sendbyte(out, LOGICALREP_COLUMN_TEXT); outputstr = OidOutputFunctionCall(typclass->typoutput, values[i]); pq_sendcountedtext(out, outputstr, strlen(outputstr), false); -- 2.30.0 --=-=-=-- ^ permalink raw reply [nested|flat] 29+ messages in thread
* [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple @ 2021-01-18 08:04 Japin Li <[email protected]> 0 siblings, 0 replies; 29+ messages in thread From: Japin Li @ 2021-01-18 08:04 UTC (permalink / raw) --- src/backend/replication/logical/proto.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/backend/replication/logical/proto.c b/src/backend/replication/logical/proto.c index 62275ebabe..f2c85cabb5 100644 --- a/src/backend/replication/logical/proto.c +++ b/src/backend/replication/logical/proto.c @@ -493,7 +493,6 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar HeapTuple typtup; Form_pg_type typclass; Form_pg_attribute att = TupleDescAttr(desc, i); - char *outputstr; if (att->attisdropped || att->attgenerated) continue; @@ -537,6 +536,8 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar } else { + char *outputstr; + pq_sendbyte(out, LOGICALREP_COLUMN_TEXT); outputstr = OidOutputFunctionCall(typclass->typoutput, values[i]); pq_sendcountedtext(out, outputstr, strlen(outputstr), false); -- 2.30.0 --=-=-=-- ^ permalink raw reply [nested|flat] 29+ messages in thread
* [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple @ 2021-01-18 08:04 Japin Li <[email protected]> 0 siblings, 0 replies; 29+ messages in thread From: Japin Li @ 2021-01-18 08:04 UTC (permalink / raw) --- src/backend/replication/logical/proto.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/backend/replication/logical/proto.c b/src/backend/replication/logical/proto.c index 62275ebabe..f2c85cabb5 100644 --- a/src/backend/replication/logical/proto.c +++ b/src/backend/replication/logical/proto.c @@ -493,7 +493,6 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar HeapTuple typtup; Form_pg_type typclass; Form_pg_attribute att = TupleDescAttr(desc, i); - char *outputstr; if (att->attisdropped || att->attgenerated) continue; @@ -537,6 +536,8 @@ logicalrep_write_tuple(StringInfo out, Relation rel, HeapTuple tuple, bool binar } else { + char *outputstr; + pq_sendbyte(out, LOGICALREP_COLUMN_TEXT); outputstr = OidOutputFunctionCall(typclass->typoutput, values[i]); pq_sendcountedtext(out, outputstr, strlen(outputstr), false); -- 2.30.0 --=-=-=-- ^ permalink raw reply [nested|flat] 29+ messages in thread
* Updatable Views and INSERT INTO ... ON CONFLICT @ 2022-01-01 12:52 Joel Jacobson <[email protected]> 0 siblings, 1 reply; 29+ messages in thread From: Joel Jacobson @ 2022-01-01 12:52 UTC (permalink / raw) To: [email protected] Hi, I note it's not yet possible to INSERT INTO an Updatable View using the ON CONFLICT feature. One imaginable pattern is when a user wants to refactor by renaming a table, but for some reason cannot refactor some specific application and want to allow it to continue to use the table's old name. One approach to do so would be to create a an Updatable View (aka Simple view) [1], given the same name as the table's old name. This is ugly and not something I would do myself, but I've read about how others describe this pattern, not in the context of ON CONFLICT, but in general, when refactoring. Are there reasons why it would not be possible to develop support INSERT INTO ... ON CONFLICT for Updatable Views? Not saying it is desired, just trying to better understand the limits of Updatable Views. /Joel ^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: Updatable Views and INSERT INTO ... ON CONFLICT @ 2022-09-02 10:04 [email protected] parent: Joel Jacobson <[email protected]> 0 siblings, 0 replies; 29+ messages in thread From: [email protected] @ 2022-09-02 10:04 UTC (permalink / raw) To: Joel Jacobson <[email protected]>; [email protected] Joel Jacobson: > I note it's not yet possible to INSERT INTO an Updatable View using the > ON CONFLICT feature. To be clear, it seems to be supported for AUTO-updatable views and for views with manually created RULES, but not for views with INSTEAD OF triggers. > Not saying it is desired, just trying to better understand the limits of > Updatable Views. It's certainly desired. I tried to use it in the past. > Are there reasons why it would not be possible to develop support INSERT > INTO ... ON CONFLICT for Updatable Views? I think the main challenge is, that when a view has an INSTEAD OF insert trigger, the INSERT statement that is in the trigger function is not the same statement that is called on the view. Auto-updatable views rewrite the original query, so they can support this. For this to work, the outer INSERT would have to "catch" the error that the trigger function throws on a conflict - and then the outer INSERT would have to execute an UPDATE on the view instead. I don't know about the internals of INSERT .. ON CONFLICT, but I'd assume the conflict handling + update happens much later than calling the instead of trigger, so that makes it impossible to do it right now. Best Wolfgang ^ permalink raw reply [nested|flat] 29+ messages in thread
end of thread, other threads:[~2022-09-02 10:04 UTC | newest] Thread overview: 29+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2017-05-01 18:22 Re: Logical replication in the same cluster Peter Geoghegan <[email protected]> 2017-05-01 18:24 ` Andres Freund <[email protected]> 2017-05-01 18:31 ` Peter Geoghegan <[email protected]> 2017-05-01 18:37 ` Andres Freund <[email protected]> 2017-05-01 19:04 ` Peter Geoghegan <[email protected]> 2017-05-01 21:20 ` Greg Stark <[email protected]> 2021-01-18 08:04 [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple Japin Li <[email protected]> 2021-01-18 08:04 [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple Japin Li <[email protected]> 2021-01-18 08:04 [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple Japin Li <[email protected]> 2021-01-18 08:04 [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple Japin Li <[email protected]> 2021-01-18 08:04 [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple Japin Li <[email protected]> 2021-01-18 08:04 [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple Japin Li <[email protected]> 2021-01-18 08:04 [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple Japin Li <[email protected]> 2021-01-18 08:04 [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple Japin Li <[email protected]> 2021-01-18 08:04 [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple Japin Li <[email protected]> 2021-01-18 08:04 [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple Japin Li <[email protected]> 2021-01-18 08:04 [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple Japin Li <[email protected]> 2021-01-18 08:04 [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple Japin Li <[email protected]> 2021-01-18 08:04 [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple Japin Li <[email protected]> 2021-01-18 08:04 [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple Japin Li <[email protected]> 2021-01-18 08:04 [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple Japin Li <[email protected]> 2021-01-18 08:04 [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple Japin Li <[email protected]> 2021-01-18 08:04 [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple Japin Li <[email protected]> 2021-01-18 08:04 [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple Japin Li <[email protected]> 2021-01-18 08:04 [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple Japin Li <[email protected]> 2021-01-18 08:04 [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple Japin Li <[email protected]> 2021-01-18 08:04 [PATCH v2] Narrow the scope of the variable outputstr in logicalrep_write_tuple Japin Li <[email protected]> 2022-01-01 12:52 Updatable Views and INSERT INTO ... ON CONFLICT Joel Jacobson <[email protected]> 2022-09-02 10:04 ` Re: Updatable Views and INSERT INTO ... ON CONFLICT [email protected]
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox