On Sat, 9 Nov 2019 09:18:21 +0100
Peter Eisentraut wrote:
> On 2019-11-07 16:18, Jehan-Guillaume de Rorthais wrote:
> > On Thu, 7 Nov 2019 16:02:21 +0100
> > Peter Eisentraut wrote:
> >
> >> On 2019-11-05 17:05, Jehan-Guillaume de Rorthais wrote:
> I have simplified your reproduction s
On 2019-11-07 16:18, Jehan-Guillaume de Rorthais wrote:
On Thu, 7 Nov 2019 16:02:21 +0100
Peter Eisentraut wrote:
On 2019-11-05 17:05, Jehan-Guillaume de Rorthais wrote:
I have simplified your reproduction steps from the previous message to a
test case, and I can confirm that your proposed fi
On Thu, 7 Nov 2019 16:02:21 +0100
Peter Eisentraut wrote:
> On 2019-11-05 17:05, Jehan-Guillaume de Rorthais wrote:
> >> I have simplified your reproduction steps from the previous message to a
> >> test case, and I can confirm that your proposed fix addresses the issue.
> >
> > Thanks for the
On 2019-11-05 17:18, Andres Freund wrote:
On 2019-11-05 16:02:51 +0100, Peter Eisentraut wrote:
$node_publisher->stop('fast');
+
+
+# TODO:
https://www.postgresql.org/message-id/flat/a9139c29-7ddd-973b-aa7f-71fed9c38d75%40minerva.info
+
+$node_publisher = get_new_node('publisher3');
+$node_pu
On 2019-11-05 17:05, Jehan-Guillaume de Rorthais wrote:
I have simplified your reproduction steps from the previous message to a
test case, and I can confirm that your proposed fix addresses the issue.
Thanks for the feedback and the test case. I wonder if ALTER SUBSCRIPTION
DISABLE/ENABLE is u
Hi,
On 2019-11-05 16:02:51 +0100, Peter Eisentraut wrote:
> $node_publisher->stop('fast');
> +
> +
> +# TODO:
> https://www.postgresql.org/message-id/flat/a9139c29-7ddd-973b-aa7f-71fed9c38d75%40minerva.info
> +
> +$node_publisher = get_new_node('publisher3');
> +$node_publisher->init(allows_stre
On Tue, 5 Nov 2019 16:02:51 +0100
Peter Eisentraut wrote:
> On 2019-10-25 17:38, Jehan-Guillaume de Rorthais wrote:
> > On Thu, 10 Oct 2019 15:15:46 +0200
> > Jehan-Guillaume de Rorthais wrote:
> >
> > [...]
> >> Here is a script to reproduce it under version 10, 11 and 12:
> >
> > I investiga
On 2019-10-25 17:38, Jehan-Guillaume de Rorthais wrote:
On Thu, 10 Oct 2019 15:15:46 +0200
Jehan-Guillaume de Rorthais wrote:
[...]
Here is a script to reproduce it under version 10, 11 and 12:
I investigated on this bug while coming back from pgconf.eu. Bellow what I found
so far.
I have
On Thu, 10 Oct 2019 15:15:46 +0200
Jehan-Guillaume de Rorthais wrote:
[...]
> Here is a script to reproduce it under version 10, 11 and 12:
I investigated on this bug while coming back from pgconf.eu. Bellow what I found
so far.
The message "negative bitmapset member not allowed" comes from
log
Hello,
On Thu, 4 Apr 2019 23:37:04 +0200
Peter Eisentraut wrote:
> On 2019-04-01 23:43, Alvaro Herrera wrote:
> > Maybe the replica identity of a table got set to a unique index on oid?
> > Or something else involving system columns? (If replication is
> > otherwise working, the I suppose there
On 04/04/2019 22:37, Peter Intrauterine wrote:
> On 2019-04-01 23:43, Alvaro Herrera wrote:
>> Maybe the replica identity of a table got set to a unique index on oid?
>> Or something else involving system columns? (If replication is
>> otherwise working, the I suppose there's a separate publicatio
On 2019-04-01 23:43, Alvaro Herrera wrote:
> Maybe the replica identity of a table got set to a unique index on oid?
> Or something else involving system columns? (If replication is
> otherwise working, the I suppose there's a separate publication that's
> having the error; the first thing to isol
On 02/04/2019 15:46, Tom Lane wrote:
> I'm glad you're out of the woods, but we still have a bug there
> waiting to bite the next person. I wonder if you'd be willing to
> spend some time trying to develop a reproduction sequence for this
> (obviously, working on a test setup not your live servers
Tim Clarke writes:
> I've cleared it by dropping the slave database, re-creating from the
> live schema then fully replicating. Its all running happily now.
I'm glad you're out of the woods, but we still have a bug there
waiting to bite the next person. I wonder if you'd be willing to
spend some
On 02/04/2019 14:59, Tom Lane wrote:
> Well, that's not much help :-(. Can you provide any info to narrow
> down where this is happening? I mean, you haven't even told us whether
> it's the primary or the slave that is complaining. Does it seem to
> be associated with any particular command? (T
Tim Clarke writes:
> Dang. I just replicated ~380 tables. One was missing an index so I
> paused replication, added a unique key on publisher and subscriber,
> re-enabled replication and refreshed the subscription.
Well, that's not much help :-(. Can you provide any info to narrow
down where thi
Dang. I just replicated ~380 tables. One was missing an index so I
paused replication, added a unique key on publisher and subscriber,
re-enabled replication and refreshed the subscription.
The table has only 7 columns, I added a primary key with a default value
from a new sequence.
Tim Clarke
IT
On 2019-Apr-01, Tom Lane wrote:
> Tim Clarke writes:
> > I'm getting this message every 5 seconds on a single-master,
> > single-slave replication of PG10.7->PG10.7 both on Centos. Its over the
> > 'net but otherwise seems to perform excellently. Any ideas what's
> > causing it and how to fix?
>
Tim Clarke writes:
> I'm getting this message every 5 seconds on a single-master,
> single-slave replication of PG10.7->PG10.7 both on Centos. Its over the
> 'net but otherwise seems to perform excellently. Any ideas what's
> causing it and how to fix?
That'd certainly be a bug, but we'd need to
19 matches
Mail list logo
