On Thu, May 23, 2024 at 08:12:07AM +, Ilyasov Ian wrote:
> > It seems to me that we should keep the 'for replication target relation
> "public.tbl" in transaction \d+,', before the "finished at" so as it
> is possible to make a difference with the context that has a column
> name and the contex
> It seems to me that we should keep the 'for replication target relation
"public.tbl" in transaction \d+,', before the "finished at" so as it
is possible to make a difference with the context that has a column
name and the context where there is no target relation.
I agree. Attached the updated p
On Wed, May 22, 2024 at 02:24:37PM +, Ilyasov Ian wrote:
> I corrected my patch according to what I think
> Michael wanted. I attached the new patch to the letter.
Thanks for compiling this patch. Yes, that's the idea.
- qr/processing remote data for replication origin \"pg_\d+\" dur
Dear Michael, Amit, Hayato
I corrected my patch according to what I think
Michael wanted. I attached the new patch to the letter.
--
Kind regards,
Ian Ilyasov.
Junior Software Developer at Postgres Professional
0002-Fix-subscription-029_on_error.pl-test-when-wal_debug.patch
Description: 0002-
On Fri, May 17, 2024 at 5:25 AM Michael Paquier wrote:
>
> On Thu, May 16, 2024 at 09:00:47AM +0530, Amit Kapila wrote:
> > This can only be a problem if the apply worker generates more LOG
> > entries with the required context but it won't do that unless there is
> > an operation on the publisher
On Thu, May 16, 2024 at 09:00:47AM +0530, Amit Kapila wrote:
> This can only be a problem if the apply worker generates more LOG
> entries with the required context but it won't do that unless there is
> an operation on the publisher to replicate. If we see any such danger
> then I agree this can b
On Thu, May 16, 2024 at 3:43 AM Michael Paquier wrote:
>
> On Wed, May 15, 2024 at 05:58:18PM +0530, Amit Kapila wrote:
> > I guess it could be more work if we want to enhance the test for
> > ERRORs other than the primary key violation.
>
> And? You could pass the ERROR string expected as argume
On Wed, May 15, 2024 at 05:58:18PM +0530, Amit Kapila wrote:
> I guess it could be more work if we want to enhance the test for
> ERRORs other than the primary key violation.
And? You could pass the ERROR string expected as argument of the
function if more flexibility is wanted at some point, no?
Dear Hayato,
> I made a patch for confirmation purpose. This worked well on my environment.
> Ian, how about you?
I checked this patch on my environment. It also works well.
I like this change, but as I see it makes a different approach from Michael's
advice.
Honesly, I do not know what would be
Dear Amit, Ian,
> I guess it could be more work if we want to enhance the test for
> ERRORs other than the primary key violation. One simple fix is to
> update the log_offset to the location of the LOG after successful
> replication of un-conflicted data. For example, the Log location after
> we e
On Wed, May 15, 2024 at 9:26 AM Michael Paquier wrote:
>
> On Tue, May 14, 2024 at 10:22:29AM +, Ilyasov Ian wrote:
> > Hello, hackers!
> >
> > Recently I've been building postgres with different cflags and cppflags.
> > And suddenly on REL_15_STABLE, REL_16_STABLE and master
> > I faced a fai
On Tue, May 14, 2024 at 10:22:29AM +, Ilyasov Ian wrote:
> Hello, hackers!
>
> Recently I've been building postgres with different cflags and cppflags.
> And suddenly on REL_15_STABLE, REL_16_STABLE and master
> I faced a failure of a src/test/subscription/t/029_on_error.pl test when
> C
12 matches
Mail list logo
