Tom Lane wrote:
> Petr Jelinek writes:
>> On 26/04/17 18:59, Bruce Momjian wrote:
>>> ... it just hangs. My server logs say:
>
>> Yes that's result of how logical replication slots work, the transaction
>> that needs to finish is your transaction. It can be worked around by
>> creating the slot
On 4/27/17 15:06, Peter Eisentraut wrote:
> On 4/27/17 04:08, Petr Jelinek wrote:
>> Note that the workaround for all of this is not all that complex, you do
>> same thing (create slot manually) you'd do for physical replication with
>> slots.
>
> Maybe we should just document this issue for now.
On 02/05/17 16:37, Andres Freund wrote:
> On 2017-05-02 09:17:27 +0200, Petr Jelinek wrote:
>> Yes because otherwise we risk leaving slot on the upstream if the
>> command fails downstream.
>
> Shouldn't temporary slots be able to solve that concern? Create it as
> temporary at the beginning, mar
On 2017-05-02 09:17:27 +0200, Petr Jelinek wrote:
> Yes because otherwise we risk leaving slot on the upstream if the
> command fails downstream.
Shouldn't temporary slots be able to solve that concern? Create it as
temporary at the beginning, mark it as permanent at the end?
Greetings,
Andres
On 02/05/17 04:14, Peter Eisentraut wrote:
> On 4/30/17 20:31, Andres Freund wrote:
>> On 2017-04-26 23:41:51 +0200, Petr Jelinek wrote:
>>> Yes that's result of how logical replication slots work, the transaction
>>> that needs to finish is your transaction. It can be worked around by
>>> creating
On 4/30/17 20:31, Andres Freund wrote:
> On 2017-04-26 23:41:51 +0200, Petr Jelinek wrote:
>> Yes that's result of how logical replication slots work, the transaction
>> that needs to finish is your transaction. It can be worked around by
>> creating the slot manually via the SQL interface for exam
On 1 May 2017 at 19:24, Andres Freund 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 CRE
On Mon, May 1, 2017 at 11:37 AM, Andres Freund 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
On 2017-05-01 11:31:53 -0700, Peter Geoghegan wrote:
> On Mon, May 1, 2017 at 11:24 AM, Andres Freund 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
On Mon, May 1, 2017 at 11:24 AM, Andres Freund 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
On 2017-05-01 11:22:47 -0700, Peter Geoghegan wrote:
> On Fri, Apr 28, 2017 at 9:28 AM, Robert Haas wrote:
> > On Thu, Apr 27, 2017 at 4:08 AM, Petr Jelinek
> > wrote:
> >> Back when writing the original patch set, I was also playing with the
> >> idea of having CREATE SUBSCRIPTION do multiple co
On Fri, Apr 28, 2017 at 9:28 AM, Robert Haas wrote:
> On Thu, Apr 27, 2017 at 4:08 AM, Petr Jelinek
> 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 CONCURRENTL
On 2017-04-26 23:41:51 +0200, Petr Jelinek wrote:
> Yes that's result of how logical replication slots work, the transaction
> that needs to finish is your transaction. It can be worked around by
> creating the slot manually via the SQL interface for example and create
> the subscription using WITH
On Thu, Apr 27, 2017 at 4:08 AM, Petr Jelinek
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
On 4/27/17 04:08, Petr Jelinek wrote:
> Note that the workaround for all of this is not all that complex, you do
> same thing (create slot manually) you'd do for physical replication with
> slots.
Maybe we should just document this issue for now.
--
Peter Eisentraut http://www.2ndQu
On 27/04/17 04:50, Tom Lane wrote:
> Peter Eisentraut writes:
If that's a predictable deadlock, I think a minimum expectation is that
the system should notice it and throw an error, not just hang.
>
>> We had some discussions early on about detecting connections to the same
>> server, b
Peter Eisentraut writes:
>>> If that's a predictable deadlock, I think a minimum expectation is that
>>> the system should notice it and throw an error, not just hang.
> We had some discussions early on about detecting connections to the same
> server, but it's not entirely clear how to do that a
On 4/26/17 19:18, Michael Paquier wrote:
>> If that's a predictable deadlock, I think a minimum expectation is that
>> the system should notice it and throw an error, not just hang. (Then
>> the error could give a hint about how to work around it.) But the case
>> Bruce has in mind doesn't seem l
On Wed, Apr 26, 2017 at 6:02 PM, Tom Lane wrote:
> Petr Jelinek writes:
>> On 26/04/17 18:59, Bruce Momjian wrote:
>>> ... it just hangs. My server logs say:
>
>> Yes that's result of how logical replication slots work, the transaction
>> that needs to finish is your transaction. It can be worke
On Thu, Apr 27, 2017 at 7:02 AM, Tom Lane wrote:
> Petr Jelinek writes:
>> On 26/04/17 18:59, Bruce Momjian wrote:
>>> ... it just hangs. My server logs say:
>
>> Yes that's result of how logical replication slots work, the transaction
>> that needs to finish is your transaction. It can be worke
Petr Jelinek writes:
> On 26/04/17 18:59, Bruce Momjian wrote:
>> ... it just hangs. My server logs say:
> Yes that's result of how logical replication slots work, the transaction
> that needs to finish is your transaction. It can be worked around by
> creating the slot manually via the SQL inte
On Wed, Apr 26, 2017 at 11:41:51PM +0200, Petr Jelinek wrote:
> On 26/04/17 18:59, Bruce Momjian wrote:
> > I tried setting up logical replication on the same server between two
> > different databases, and got, from database test:
> >
> > test=> CREATE TABLE test (x INT PRIMARY KEY);
> >
On 26/04/17 18:59, Bruce Momjian wrote:
> I tried setting up logical replication on the same server between two
> different databases, and got, from database test:
>
> test=> CREATE TABLE test (x INT PRIMARY KEY);
> CREATE TABLE
> test=>
> test=> INSERT INTO test VALUES (1)
I tried setting up logical replication on the same server between two
different databases, and got, from database test:
test=> CREATE TABLE test (x INT PRIMARY KEY);
CREATE TABLE
test=>
test=> INSERT INTO test VALUES (1);
INSERT 0 1
test=> CREATE PUB
24 matches
Mail list logo
