On 05.04.2023 17:35, Tom Lane wrote:
"Anton A. Melnikov" writes:
On 03.04.2023 21:49, Tom Lane wrote:
I did not think this case was worth memorializing in a test before,
and I still do not. I'm inclined to reject this patch.
Could you help me to figure out, please.
The problem was an
"Anton A. Melnikov" writes:
> On 03.04.2023 21:49, Tom Lane wrote:
>> I did not think this case was worth memorializing in a test before,
>> and I still do not. I'm inclined to reject this patch.
> Could you help me to figure out, please.
The problem was an Assert that was speculative when it
Hello!
On 03.04.2023 21:49, Tom Lane wrote:
"Anton A. Melnikov" writes:
Now there are no any pending questions, so moved it to RFC.
I did not think this case was worth memorializing in a test before,
and I still do not. I'm inclined to reject this patch.
Earlier, when discussing this
"Anton A. Melnikov" writes:
> Now there are no any pending questions, so moved it to RFC.
I did not think this case was worth memorializing in a test before,
and I still do not. I'm inclined to reject this patch.
regards, tom lane
Hello!
On 15.03.2023 21:29, Gregory Stark (as CFM) wrote:
These patches that are "Needs Review" and have received no comments at
all since before March 1st are these. If your patch is amongst this
list I would suggest any of:
1) Move it yourself to the next CF (or withdraw it)
2) Post to the
Thanks for your remarks.
On 07.01.2023 15:27, vignesh C wrote:
Few suggestions:
1) There is a warning:
+# This would crash on the subscriber if not fixed
+$node_publisher->safe_psql('postgres', "INSERT INTO tab1 VALUES (3, 4)");
+
+my $result = $node_subscriber->wait_for_log(
+ "ERROR:
On Sun, 11 Dec 2022 at 09:21, Anton A. Melnikov wrote:
>
>
> On 07.12.2022 21:03, Andres Freund wrote:
>
> >
> > This CF entry causes tests to fail on all platforms:
> > https://cirrus-ci.com/build/5755408111894528
> >
> > E.g.
> >
On 07.12.2022 21:03, Andres Freund wrote:
This CF entry causes tests to fail on all platforms:
https://cirrus-ci.com/build/5755408111894528
E.g.
https://api.cirrus-ci.com/v1/artifact/task/5298457144459264/testrun/build/testrun/subscription/100_bugs/log/regress_log_100_bugs
Begin
Hi,
On 2022-11-16 17:52:50 +0300, Anton A. Melnikov wrote:
> Sorry, i didn't fully understand what is required and
> added some functions to the test that spend extra cpu time. But i found
> that it is possible to make a test according to previous remarks by adding
> only a few extra queries to
Thanks a lot for the fast reply!
On 03.11.2022 18:29, Tom Lane wrote:
If we were just adding a
query or two to an existing scenario, that could be okay; but spinning
up and syncing a whole new primary and standby database is *expensive*
when you multiply it by the number of times developers and
"Anton A. Melnikov" writes:
> On 02.11.2022 21:02, Tom Lane wrote:
>> I don't think the cost of that test case is justified by the tiny
>> probability that it'd ever catch anything.
> Seems it is possible to do a test without these remarks. The attached
> test uses existing nodes and checks the
Hello!
On 02.11.2022 21:02, Tom Lane wrote:
So I'm now good with the idea of just not failing. I don't like
the patch as presented though. First, the cfbot is quite rightly
complaining about the "uninitialized variable" warning it draws.
Second, I don't see a good reason to tie the change to
Amit Kapila writes:
> LGTM. I don't know if it is a good idea to omit the test case for this
> scenario. If required, we can reuse the test case from Sawada-San's
> patch in the email [1].
I don't think the cost of that test case is justified by the tiny
probability that it'd ever catch
On Wed, Nov 2, 2022 at 11:32 PM Tom Lane wrote:
>
> So I'm now good with the idea of just not failing. I don't like
> the patch as presented though. First, the cfbot is quite rightly
> complaining about the "uninitialized variable" warning it draws.
> Second, I don't see a good reason to tie
Michael Paquier writes:
> Yeah, the query string is not available in this context, but it surely
> looks wrong to me to assume that something as low-level as
> function_parse_error_transpose() needs to be updated for the sake of a
> logical worker, while we have other areas that would expect a
On Sun, Oct 09, 2022 at 12:24:23PM +0300, Anton A. Melnikov wrote:
> On the other hand, function_parse_error_transpose() tries to get
> the original query text (INSERT INTO test VALUES ('1') in our case) from
> the ActivePortal to clarify the location of the error.
> But in the logrep worker
On 2022-Sep-24, Tom Lane wrote:
> "Anton A. Melnikov" writes:
> > [ v4-0001-Fix-logical-replica-assert-on-func-error.patch ]
>
> I took a quick look at this. I think you're solving the
> problem in the wrong place. The real issue is why are
> we not setting up ActivePortal correctly when
Hello!
Thanks for reply!
On 24.09.2022 20:27, Tom Lane wrote:
I think you're solving the
problem in the wrong place. The real issue is why are
we not setting up ActivePortal correctly when running
user-defined code in a logrep worker?
During a common query from the backend ActivePortal
"Anton A. Melnikov" writes:
> [ v4-0001-Fix-logical-replica-assert-on-func-error.patch ]
I took a quick look at this. I think you're solving the
problem in the wrong place. The real issue is why are
we not setting up ActivePortal correctly when running
user-defined code in a logrep worker?
Hello!
Added a TAP test for this case.
On 30.08.2022 10:09, Anton A. Melnikov wrote:
Hello!
The patch was rebased on current master.
And here is a simplified crash reproduction:
1) On primary with 'wal_level = logical' execute:
CREATE TABLE public.test (id int NOT NULL, val integer);
Hello!
The patch was rebased on current master.
And here is a simplified crash reproduction:
1) On primary with 'wal_level = logical' execute:
CREATE TABLE public.test (id int NOT NULL, val integer);
CREATE PUBLICATION test_pub FOR TABLE test;
2) On replica replace in the repcmd.sql
Hello!
On 21.08.2022 17:33, Anton A. Melnikov wrote:
Hello!
Here is a fix for the bug first described in:
https://www.postgresql.org/message-id/flat/adf0452f-8c6b-7def-d35e-ab516c80088e%40inbox.ru
Sorry, there was a wrong patch in the first letter.
Here is a right version.
With best
Hello!
Here is a fix for the bug first described in:
https://www.postgresql.org/message-id/flat/adf0452f-8c6b-7def-d35e-ab516c80088e%40inbox.ru
Reproduction:
1) On master with 'wal_level = logical' execute mascmd.sql attached.
2) On replica substitute the correct port in repcmd.sql and execute
23 matches
Mail list logo
