On 12/05/17 15:02, Peter Eisentraut wrote:
> On 5/9/17 11:43, Petr Jelinek wrote:
>> Here is rebased version of the other patch (the interface rework). I
>> also fixed the tab completion there.
>
> Committed.
>
> One small thing I changed, to make it look more like CREATE/ALTER TABLE,
> is that t
On 5/9/17 11:43, Petr Jelinek wrote:
> Here is rebased version of the other patch (the interface rework). I
> also fixed the tab completion there.
Committed.
One small thing I changed, to make it look more like CREATE/ALTER TABLE,
is that the CREATE commands use WITH (...) but the ALTER commands
On 09/05/17 16:28, Peter Eisentraut wrote:
> On 5/9/17 04:39, Petr Jelinek wrote:
What we want to simulate instead is an "auto" dependency of the slot on
the subscription. So you can drop the slot separately (subject to other
restrictions), and it is dropped automatically when the s
On 5/9/17 03:27, Masahiko Sawada wrote:
> I think we should change tab-completion support for that as well.
>
> diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
> index 183fc37..046fdd5 100644
> --- a/src/bin/psql/tab-complete.c
> +++ b/src/bin/psql/tab-complete.c
> @@ -2684,
On 5/9/17 04:39, Petr Jelinek wrote:
>>> What we want to simulate instead is an "auto" dependency of the slot on
>>> the subscription. So you can drop the slot separately (subject to other
>>> restrictions), and it is dropped automatically when the subscription is
>>> dropped. To avoid that, you
On 09/05/17 11:44, Masahiko Sawada wrote:
> On Tue, May 9, 2017 at 5:57 PM, Petr Jelinek
> wrote:
>> On 09/05/17 10:51, Masahiko Sawada wrote:
>>> On Tue, May 9, 2017 at 5:39 PM, Petr Jelinek
>>> wrote:
On 09/05/17 07:07, Peter Eisentraut wrote:
> On 5/8/17 23:23, Peter Eisentraut wrote:
On Tue, May 9, 2017 at 5:57 PM, Petr Jelinek
wrote:
> On 09/05/17 10:51, Masahiko Sawada wrote:
>> On Tue, May 9, 2017 at 5:39 PM, Petr Jelinek
>> wrote:
>>> On 09/05/17 07:07, Peter Eisentraut wrote:
On 5/8/17 23:23, Peter Eisentraut wrote:
> The way this uses RESTRICT and CASCADE appea
On 09/05/17 10:51, Masahiko Sawada wrote:
> On Tue, May 9, 2017 at 5:39 PM, Petr Jelinek
> wrote:
>> On 09/05/17 07:07, Peter Eisentraut wrote:
>>> On 5/8/17 23:23, Peter Eisentraut wrote:
The way this uses RESTRICT and CASCADE appears to be backwards from its
usual meaning. Normally, C
On Tue, May 9, 2017 at 5:39 PM, Petr Jelinek
wrote:
> On 09/05/17 07:07, Peter Eisentraut wrote:
>> On 5/8/17 23:23, Peter Eisentraut wrote:
>>> The way this uses RESTRICT and CASCADE appears to be backwards from its
>>> usual meaning. Normally, CASCADE when dropping an object that is still
>>> u
On 09/05/17 07:07, Peter Eisentraut wrote:
> On 5/8/17 23:23, Peter Eisentraut wrote:
>> The way this uses RESTRICT and CASCADE appears to be backwards from its
>> usual meaning. Normally, CASCADE when dropping an object that is still
>> used by others will cause those other objects to be dropped.
On Tue, May 9, 2017 at 2:07 PM, Peter Eisentraut
wrote:
> On 5/8/17 23:23, Peter Eisentraut wrote:
>> The way this uses RESTRICT and CASCADE appears to be backwards from its
>> usual meaning. Normally, CASCADE when dropping an object that is still
>> used by others will cause those other objects
On 5/8/17 23:23, Peter Eisentraut wrote:
> The way this uses RESTRICT and CASCADE appears to be backwards from its
> usual meaning. Normally, CASCADE when dropping an object that is still
> used by others will cause those other objects to be dropped. The
> equivalent here would be DROP REPLICATIO
On 5/8/17 17:55, Petr Jelinek wrote:
> On 08/05/17 22:55, Peter Eisentraut wrote:
>> On 5/5/17 13:01, Petr Jelinek wrote:
>>> What do you think of attached. I actually did add RESTRICT/CASCADE, in a
>>> way that if there is slot RESTRICT will refuse to drop subscription and
>>> CASCADE will try to
On 08/05/17 22:55, Peter Eisentraut wrote:
> On 5/5/17 13:01, Petr Jelinek wrote:
>> What do you think of attached. I actually did add RESTRICT/CASCADE, in a
>> way that if there is slot RESTRICT will refuse to drop subscription and
>> CASCADE will try to drop it. Still all errors.
>>
>> The new wa
On 5/5/17 13:01, Petr Jelinek wrote:
> What do you think of attached. I actually did add RESTRICT/CASCADE, in a
> way that if there is slot RESTRICT will refuse to drop subscription and
> CASCADE will try to drop it. Still all errors.
>
> The new way to not drop slot is to set slot_name to NONE wh
On 02/05/17 15:31, Tom Lane wrote:
> Petr Jelinek writes:
>> Let me expand, if we don't drop the slot by default when dropping
>> subscription, we'll have a lot of users with dead slots laying around
>> holding back WAL/catalog_xmin, that's really bad. If we do drop by
>> default like now, we need
On 04/05/17 23:29, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, May 3, 2017 at 12:38 AM, Petr Jelinek
>> wrote:
>>> Ok, Let me be clear, I actually happen to agree with your proposal. The
>>> reason I am moaning is that I always seem to find myself doing tons of
>>> mechanical work to rewrite
Robert Haas writes:
> On Wed, May 3, 2017 at 12:38 AM, Petr Jelinek
> wrote:
>> Ok, Let me be clear, I actually happen to agree with your proposal. The
>> reason I am moaning is that I always seem to find myself doing tons of
>> mechanical work to rewrite some cosmetic aspect of some patch based
On Wed, May 3, 2017 at 12:38 AM, Petr Jelinek
wrote:
> Ok, Let me be clear, I actually happen to agree with your proposal. The
> reason I am moaning is that I always seem to find myself doing tons of
> mechanical work to rewrite some cosmetic aspect of some patch based on
> which committer is payi
On 02/05/17 16:14, Petr Jelinek wrote:
> On 02/05/17 15:31, Tom Lane wrote:
>> Petr Jelinek writes:
>>> Let me expand, if we don't drop the slot by default when dropping
>>> subscription, we'll have a lot of users with dead slots laying around
>>> holding back WAL/catalog_xmin, that's really bad.
On 02/05/17 18:25, Alvaro Herrera wrote:
> Petr Jelinek wrote:
>> On 02/05/17 18:00, Robert Haas wrote:
>>> On Tue, May 2, 2017 at 11:49 AM, Alvaro Herrera
>>> wrote:
Petr Jelinek wrote:
> So the only way to fulfill the requirement you stated is to just not try
> to drop the slot, eve
On 02/05/17 22:40, Robert Haas wrote:
> On Tue, May 2, 2017 at 3:02 PM, Petr Jelinek
> wrote:
>> That sounds okay. I know PeterE didn't like the lower case and
>> underscore separated words for options in the original patch, so I'd
>> like to hear his opinion on this. I am not sure how much advant
On Tue, May 2, 2017 at 5:15 PM, Alvaro Herrera wrote:
> Robert Haas wrote:
>> On Tue, May 2, 2017 at 12:25 PM, Alvaro Herrera
>> wrote:
>> > 2) don't drop because we know it won't work. I see two options:
>> >c) ignore a drop slot failure, i.e. don't cause a transaction abort.
>> > An
Robert Haas wrote:
> On Tue, May 2, 2017 at 12:25 PM, Alvaro Herrera
> wrote:
> > 2) don't drop because we know it won't work. I see two options:
> >c) ignore a drop slot failure, i.e. don't cause a transaction abort.
> > An easy way to implement this is just add a PG_TRY block, but we
On Tue, May 2, 2017 at 3:02 PM, Petr Jelinek
wrote:
> That sounds okay. I know PeterE didn't like the lower case and
> underscore separated words for options in the original patch, so I'd
> like to hear his opinion on this. I am not sure how much advantage is
> there in removing the '=' in between
On 02/05/17 19:42, Robert Haas wrote:
> On Tue, May 2, 2017 at 8:45 AM, Petr Jelinek
> wrote:
>> I am happy to implement something different, it's quite trivial to
>> change. But I am not going to propose anything different as I can't
>> think of better syntax (if I could I would have done it). I
On Tue, May 2, 2017 at 8:45 AM, Petr Jelinek
wrote:
> I am happy to implement something different, it's quite trivial to
> change. But I am not going to propose anything different as I can't
> think of better syntax (if I could I would have done it). I don't like
> the OFF or FALSE (ie DROP SLOT O
On Tue, May 2, 2017 at 12:25 PM, Alvaro Herrera
wrote:
> 2) don't drop because we know it won't work. I see two options:
>c) ignore a drop slot failure, i.e. don't cause a transaction abort.
> An easy way to implement this is just add a PG_TRY block, but we
> dislike adding those
Petr Jelinek wrote:
> On 02/05/17 18:00, Robert Haas wrote:
> > On Tue, May 2, 2017 at 11:49 AM, Alvaro Herrera
> > wrote:
> >> Petr Jelinek wrote:
> >>> So the only way to fulfill the requirement you stated is to just not try
> >>> to drop the slot, ever, on DROP SUBSCRIPTION. That makes the defa
On 02/05/17 18:00, Robert Haas wrote:
> On Tue, May 2, 2017 at 11:49 AM, Alvaro Herrera
> wrote:
>> Petr Jelinek wrote:
>>> So the only way to fulfill the requirement you stated is to just not try
>>> to drop the slot, ever, on DROP SUBSCRIPTION. That makes the default
>>> behavior leave resources
On Tue, May 2, 2017 at 11:49 AM, Alvaro Herrera
wrote:
> Petr Jelinek wrote:
>> So the only way to fulfill the requirement you stated is to just not try
>> to drop the slot, ever, on DROP SUBSCRIPTION. That makes the default
>> behavior leave resources on upstream that will eventually cause that
>
Petr Jelinek wrote:
> So the only way to fulfill the requirement you stated is to just not try
> to drop the slot, ever, on DROP SUBSCRIPTION. That makes the default
> behavior leave resources on upstream that will eventually cause that
> server to stop unless user notices before. I think we bette
On 02/05/17 15:31, Tom Lane wrote:
> Petr Jelinek writes:
>> Let me expand, if we don't drop the slot by default when dropping
>> subscription, we'll have a lot of users with dead slots laying around
>> holding back WAL/catalog_xmin, that's really bad. If we do drop by
>> default like now, we need
On 05/02/2017 05:13 AM, Tom Lane wrote:
Robert Haas writes:
On Thu, Apr 20, 2017 at 7:46 AM, Petr Jelinek
wrote:
DROP SUBSCRIPTION mysub NODROP SLOT;
Having said that, I doubt that anyone would argue that CREATE USER is
anything but legacy syntax, or that our more recent syntax designs are
Petr Jelinek writes:
> Let me expand, if we don't drop the slot by default when dropping
> subscription, we'll have a lot of users with dead slots laying around
> holding back WAL/catalog_xmin, that's really bad. If we do drop by
> default like now, we need option to not do that, neither RESTRICT,
On 02/05/17 15:14, Petr Jelinek wrote:
> On 02/05/17 15:10, Tom Lane wrote:
>> Robert Haas writes:
On Thu, Apr 20, 2017 at 7:46 AM, Petr Jelinek
wrote:
> DROP SUBSCRIPTION mysub NODROP SLOT;
>>
I'm pretty uninspired by this choice of syntax.
>>
>> Actually, this command has got
On 02/05/17 15:10, Tom Lane wrote:
> Robert Haas writes:
>>> On Thu, Apr 20, 2017 at 7:46 AM, Petr Jelinek
>>> wrote:
DROP SUBSCRIPTION mysub NODROP SLOT;
>
>>> I'm pretty uninspired by this choice of syntax.
>
> Actually, this command has got much worse problems than whether you like
> th
Robert Haas writes:
>> On Thu, Apr 20, 2017 at 7:46 AM, Petr Jelinek
>> wrote:
>>> DROP SUBSCRIPTION mysub NODROP SLOT;
>> I'm pretty uninspired by this choice of syntax.
Actually, this command has got much worse problems than whether you like
the spelling of its option: it shouldn't have an op
On 02/05/17 14:13, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Apr 20, 2017 at 7:46 AM, Petr Jelinek
>> wrote:
>>> DROP SUBSCRIPTION mysub NODROP SLOT;
>
>> I'm pretty uninspired by this choice of syntax. Logical replication
>> seems to have added a whole bunch of syntax that involves pref
On 2 May 2017 at 12:55, Robert Haas wrote:
> On Thu, Apr 20, 2017 at 7:46 AM, Petr Jelinek
> wrote:
>> DROP SUBSCRIPTION mysub NODROP SLOT;
>
> I'm pretty uninspired by this choice of syntax. Logical replication
> seems to have added a whole bunch of syntax that involves prefixing
> words with "
Robert Haas writes:
> On Thu, Apr 20, 2017 at 7:46 AM, Petr Jelinek
> wrote:
>> DROP SUBSCRIPTION mysub NODROP SLOT;
> I'm pretty uninspired by this choice of syntax. Logical replication
> seems to have added a whole bunch of syntax that involves prefixing
> words with "no". In various places,
On Thu, Apr 20, 2017 at 7:46 AM, Petr Jelinek
wrote:
> DROP SUBSCRIPTION mysub NODROP SLOT;
I'm pretty uninspired by this choice of syntax. Logical replication
seems to have added a whole bunch of syntax that involves prefixing
words with "no". In various places, there's NODROP, NOREFRESH, NOCO
42 matches
Mail list logo
