On 6/23/17 20:58, Peter Eisentraut wrote:
> On 6/23/17 16:15, Andres Freund wrote:
>> On 2017-06-23 13:26:58 -0400, Alvaro Herrera wrote:
>>> Hmm, so for instance in LogicalIncreaseRestartDecodingForSlot() we have
>>> some elog(DEBUG1) calls with the slot spinlock held. That's probably
>>>
On 24/06/17 04:50, Tom Lane wrote:
> Peter Eisentraut writes:
>> Do you want to take a look at move those elog calls around a bit? That
>> should do it.
>
> It would be a good idea to have some clarity on *why* that should do it.
>
> Looking at the original
Peter Eisentraut writes:
> Do you want to take a look at move those elog calls around a bit? That
> should do it.
It would be a good idea to have some clarity on *why* that should do it.
Looking at the original report's log, but without having actually
On 6/23/17 16:15, Andres Freund wrote:
> On 2017-06-23 13:26:58 -0400, Alvaro Herrera wrote:
>> Hmm, so for instance in LogicalIncreaseRestartDecodingForSlot() we have
>> some elog(DEBUG1) calls with the slot spinlock held. That's probably
>> uncool.
>
> It definitely is not cool, rather daft
On 6/23/17 16:10, Peter Eisentraut wrote:
>> Hmm, so for instance in LogicalIncreaseRestartDecodingForSlot() we have
>> some elog(DEBUG1) calls with the slot spinlock held. That's probably
>> uncool.
> Removing the call you pointed out doesn't make a difference, but it's
> possibly something
Peter Eisentraut writes:
> On 6/23/17 13:26, Alvaro Herrera wrote:
>> Hmm, so for instance in LogicalIncreaseRestartDecodingForSlot() we have
>> some elog(DEBUG1) calls with the slot spinlock held. That's probably
>> uncool.
> I can reproduce the issue with
On 2017-06-23 13:26:58 -0400, Alvaro Herrera wrote:
> Hmm, so for instance in LogicalIncreaseRestartDecodingForSlot() we have
> some elog(DEBUG1) calls with the slot spinlock held. That's probably
> uncool.
It definitely is not cool, rather daft even (it's probably me who wrote
that). No idea
On 6/23/17 13:26, Alvaro Herrera wrote:
> Albe Laurenz wrote:
>> Peter Eisentraut wrote:
>>> On 6/21/17 09:02, Albe Laurenz wrote:
2017-06-21 14:55:12.033 CEST [23124] LOG: could not send data to client:
Broken pipe
2017-06-21 14:55:12.033 CEST [23124] FATAL: connection to client
Albe Laurenz wrote:
> Peter Eisentraut wrote:
> > On 6/21/17 09:02, Albe Laurenz wrote:
> >> 2017-06-21 14:55:12.033 CEST [23124] LOG: could not send data to client:
> >> Broken pipe
> >> 2017-06-21 14:55:12.033 CEST [23124] FATAL: connection to client lost
> >> 2017-06-21 14:55:17.032 CEST
Peter Eisentraut wrote:
> On 6/21/17 09:02, Albe Laurenz wrote:
>> 2017-06-21 14:55:12.033 CEST [23124] LOG: could not send data to client:
>> Broken pipe
>> 2017-06-21 14:55:12.033 CEST [23124] FATAL: connection to client lost
>> 2017-06-21 14:55:17.032 CEST [23133] LOG: logical replication
On 6/21/17 09:02, Albe Laurenz wrote:
> 2017-06-21 14:55:12.033 CEST [23124] LOG: could not send data to client:
> Broken pipe
> 2017-06-21 14:55:12.033 CEST [23124] FATAL: connection to client lost
> 2017-06-21 14:55:17.032 CEST [23133] LOG: logical replication apply worker
> for
While playing with HEAD as of d14c85ed,
I ran into the following:
CREATE DATABASE source;
CREATE DATABASE recipient;
\c source
CREATE TABLE repli(id integer PRIMARY KEY, val text NOT NULL);
INSERT INTO repli VALUES (1, 'one');
CREATE PUBLICATION repsend FOR TABLE repli;
SELECT
12 matches
Mail list logo