r waits on pg_subscription lock and restarts the worker instantly
after the rollback. If we tell users that the workers are stopped after
DROP SUBSCRIPTION rollback, we should also say that they will be
restarted soon.
--
Arseny Sher
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
no slot but still
enabled?
Besides, we can avoid stopping the workers if subscription has no
associated replication origin, though this probably means that
subscription was broken by user and is not worth it.
--
Arseny Sher
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
Peter Eisentraut writes:
> On 9/13/17 07:00, Arseny Sher wrote:
>> On the other hand, forbidding to execute disable sub and drop sub in one
>> transaction makes it impossible e.g. to drop subscription in trigger
>
> Disabling a subscription before dropping it isn't ve
Why launcher would restart the worker if we already destroyed the
subscription? Consider the sequence of actions:
* We check in DROP SUBSCRIPTION that worker alive and don't remove RO.
* DROP SUBSCRIPTION commits.
* Worker is killed by some villain before it had the chance to drop RO.
It
n in one transaction with DROP
SUBSCRIPTION seems natural to me.
--
Arseny Sher
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Arseny Sher writes:
> Attached patch fixes this by stopping workers before RO drop, as
> already done in case when we drop replication slot.
Sorry, here is the patch.
>From 008d54dfe2e8ba610bb7c897cfbb4ee7a700aa2e Mon Sep 17 00:00:00 2001
From: Arseny Sher
Date: Mon, 4 Sep 2017 16:55
start them, isn't it?
--
Arseny Sher
Postgres Professional: https://postgrespro.ru
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ded.
Besides, why not substitute "checked for extended formats" with "might
be recognized as a connection string" -- are there any other formats
than connstr?
The changes with point 3 chosen might look as in attached file.
>From 96d74f050724a8373c04e48205510a5a7e8
of this thread proves.
>From 09e3924501d219331b8b8fca12a9ea35a689ba10 Mon Sep 17 00:00:00 2001
From: Arseny Sher
Date: Thu, 27 Jul 2017 12:41:17 +0300
Subject: [PATCH] Allow 'dbname' option contain full-fledged connstring in
postgres_fdw
And if this is the case, validate that it doesn't contain any i
Hi,
Is there any particular reason why postgres_fdw forbids usage of
connection strings by passing expand_dbname = false to
PQconnectdbParams? Attached patch shows where this happens.
>From 6bf3741976b833379f5bb370aa41f73a51b99afd Mon Sep 17 00:00:00 2001
From: Arseny Sher
Date: Tue, 25
f the project,
"partial support of all TPC-H queries".
I am also CC'ing people who was mentioned in "Potential Mentors" section
on GSoC wiki page.
--
Arseny Sher
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscript
> While I admire your fearlessness, I think the chances of you being
> able to bring a project of this type to a successful conclusion are
> remote. Here is what I said about this topic previously:
>
> http://postgr.es/m/CA+Tgmoa=kzhj+twxyq+vku21nk3prkrjsdbhjubn7qvc8uk...@mail.gmail.com
Well, as
tgres C code doesn't give
significant improvement because of Volcano-style model. We expect that
after making a switch to push-based model in Postgres code we will
achieve speedup comparable to full-query JIT using runtime
specialization.
*About me*
My name is Arseny Sher. Currently, I am studyi
13 matches
Mail list logo
