On 12/15/16 3:46 AM, Petr Jelinek wrote:
>>> Okay in case we decide it's the right way to go attached patch does
>>> that. I also added some more tests based on your feedback while I am at it.
>>
>> This looks mostly reasonable to me, but the location and xid output from
>> pg_logical_slot_get_chan
On 14/12/16 15:35, Peter Eisentraut wrote:
> On 12/12/16 8:28 PM, Petr Jelinek wrote:
>> On 13/12/16 02:00, Andres Freund wrote:
>>> On 2016-12-13 01:57:01 +0100, Petr Jelinek wrote:
I mentioned that as possible solution upthread, I am only worried that
the failure scenario is basically i
On 12/12/16 8:28 PM, Petr Jelinek wrote:
> On 13/12/16 02:00, Andres Freund wrote:
>> On 2016-12-13 01:57:01 +0100, Petr Jelinek wrote:
>>> I mentioned that as possible solution upthread, I am only worried that
>>> the failure scenario is basically infinite loop.
>>
>> I don't see the problem with
On 13/12/16 02:00, Andres Freund wrote:
> On 2016-12-13 01:57:01 +0100, Petr Jelinek wrote:
>> I mentioned that as possible solution upthread, I am only worried that
>> the failure scenario is basically infinite loop.
>
> I don't see the problem with that. If you're really concerned you can
> set
On 13/12/16 02:08, Tom Lane wrote:
> Andres Freund writes:
>> On 2016-12-13 01:57:01 +0100, Petr Jelinek wrote:
>>> I mentioned that as possible solution upthread, I am only worried that
>>> the failure scenario is basically infinite loop.
>
>> I don't see the problem with that. If you're really
On 2016-12-12 20:08:01 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2016-12-13 01:57:01 +0100, Petr Jelinek wrote:
> >> I mentioned that as possible solution upthread, I am only worried that
> >> the failure scenario is basically infinite loop.
>
> > I don't see the problem with that. If
Andres Freund writes:
> On 2016-12-13 01:57:01 +0100, Petr Jelinek wrote:
>> I mentioned that as possible solution upthread, I am only worried that
>> the failure scenario is basically infinite loop.
> I don't see the problem with that. If you're really concerned you can
> set a statement timeout
On 2016-12-13 01:57:01 +0100, Petr Jelinek wrote:
> I mentioned that as possible solution upthread, I am only worried that
> the failure scenario is basically infinite loop.
I don't see the problem with that. If you're really concerned you can
set a statement timeout.
Andres
--
Sent via pgsql-
On 13/12/16 01:49, Andres Freund wrote:
> On 2016-12-13 01:42:48 +0100, Petr Jelinek wrote:
>> On 13/12/16 01:40, Tom Lane wrote:
>>> Petr Jelinek writes:
On 13/12/16 00:39, Tom Lane wrote:
> Hm, buildfarm says this didn't fix it. Where exactly does the dropping
> of the slot happen
On 2016-12-13 01:42:48 +0100, Petr Jelinek wrote:
> On 13/12/16 01:40, Tom Lane wrote:
> > Petr Jelinek writes:
> >> On 13/12/16 00:39, Tom Lane wrote:
> >>> Hm, buildfarm says this didn't fix it. Where exactly does the dropping
> >>> of the slot happen ... is it not complete by the time the back
On 2016-12-12 19:40:37 -0500, Tom Lane wrote:
> Petr Jelinek writes:
> > Yes, I've seen. The cleanup of slots is done in ProcKill(), I wonder,
> > since it's on_shmem_exit hook, and the pgstat_beshutdown_hook is as
> > well, maybe the pgstat_beshutdown_hook is called before ProcKill and the
> > qu
On 13/12/16 01:40, Tom Lane wrote:
> Petr Jelinek writes:
>> On 13/12/16 00:39, Tom Lane wrote:
>>> Hm, buildfarm says this didn't fix it. Where exactly does the dropping
>>> of the slot happen ... is it not complete by the time the backend exits?
>
>> Yes, I've seen. The cleanup of slots is don
Petr Jelinek writes:
> On 13/12/16 00:39, Tom Lane wrote:
>> Hm, buildfarm says this didn't fix it. Where exactly does the dropping
>> of the slot happen ... is it not complete by the time the backend exits?
> Yes, I've seen. The cleanup of slots is done in ProcKill(), I wonder,
> since it's on_
On 13/12/16 00:39, Tom Lane wrote:
> I wrote:
>> Petr Jelinek writes:
>>> Attached is the fixed test using the loop from test_extensions (and yes
>>> I would have missed the pg_stat_clear_snapshot() call without the hint,
>>> thanks :) ).
>
>> Pushed, thanks.
>
> Hm, buildfarm says this didn't f
I wrote:
> Petr Jelinek writes:
>> Attached is the fixed test using the loop from test_extensions (and yes
>> I would have missed the pg_stat_clear_snapshot() call without the hint,
>> thanks :) ).
> Pushed, thanks.
Hm, buildfarm says this didn't fix it. Where exactly does the dropping
of the s
Petr Jelinek writes:
> Yes you are correct, we tried naively to first drop another slot in
> hopes that it will give the other backend enough time to close, but
> apparently that wasn't robust enough for slower machines.
> Attached is the fixed test using the loop from test_extensions (and yes
>
On 12/12/16 16:55, Tom Lane wrote:
> I wrote:
>> Peter Eisentraut writes:
>>> Add support for temporary replication slots
>
>> Some of the slower buildfarm members are failing test-decoding-check since
>> this went in. At least on prairiedog, it looks like a race condition in
>> the test:
>
>
I wrote:
> Peter Eisentraut writes:
>> Add support for temporary replication slots
> Some of the slower buildfarm members are failing test-decoding-check since
> this went in. At least on prairiedog, it looks like a race condition in
> the test:
Having now looked a bit more closely, that's almo
Peter Eisentraut writes:
> Add support for temporary replication slots
Some of the slower buildfarm members are failing test-decoding-check since
this went in. At least on prairiedog, it looks like a race condition in
the test:
**
/Users/buildfarm/bf-data/HEAD/pgsql.build/contrib/test_decoding
Add support for temporary replication slots
This allows creating temporary replication slots that are removed
automatically at the end of the session or on error.
From: Petr Jelinek
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/a924c327e2793d2025b19e18de7917110dc
20 matches
Mail list logo
