On 25/10/2018 19:35, Fabrízio de Royes Mello wrote:
>> > OK, I can refine those descriptions/comments. Do you have any concerns
>> > about the underlying principle of this patch?
>>
>> Patch with updated comments to reflect your input.
> I didn't found any issue, so the patch looks in a very good
On Thu, Oct 25, 2018 at 4:41 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
>
> On 17/10/2018 23:11, Peter Eisentraut wrote:
> > On 13/10/2018 04:01, Andres Freund wrote:
> >> I don't see how this could be argued. It has to be a self-conflicting
> >> lockmode, otherwise you'd end up
On 17/10/2018 23:11, Peter Eisentraut wrote:
> On 13/10/2018 04:01, Andres Freund wrote:
>> I don't see how this could be argued. It has to be a self-conflicting
>> lockmode, otherwise you'd end up doing renames of tables where you
>> cannot see the previous state. And you'd get weird errors about
On 13/10/2018 04:01, Andres Freund wrote:
> I don't see how this could be argued. It has to be a self-conflicting
> lockmode, otherwise you'd end up doing renames of tables where you
> cannot see the previous state. And you'd get weird errors about updating
> invisible rows etc.
> I don't buy this
Hi,
On 2018-10-05 12:03:54 +0200, Peter Eisentraut wrote:
> From 37591a06901e2d694e3928b7e1cddfcfd84f6267 Mon Sep 17 00:00:00 2001
> From: Peter Eisentraut
> Date: Mon, 13 Aug 2018 22:38:36 +0200
> Subject: [PATCH v2] Lower lock level for renaming indexes
>
> Change lock level for renaming index
> Attached is an updated patch.
That's OK now, the patch applying is without any errors.
I have no more remarks.
>Пятница, 5 октября 2018, 13:04 +03:00 от Peter Eisentraut
>:
>
>On 03/10/2018 13:51, Andrey Klychkov wrote:
>> 1. Patch was applied without any errors except a part related to
>> d
On 03/10/2018 13:51, Andrey Klychkov wrote:
> 1. Patch was applied without any errors except a part related to
> documentation:
> error: patch failed: doc/src/sgml/ref/alter_index.sgml:50
> error: doc/src/sgml/ref/alter_index.sgml: patch does not apply
Attached is an updated patch.
> 2. The code
> Based on these assertions, here is my proposed patch. It lowers the
> lock level for index renaming to ShareUpdateExclusiveLock.
Hi, Peter
I made small review for your patch:
Server source code got from https://github.com/postgres/postgres.git
1. Patch was applied without any errors except a p
Hi,
On 2018-08-14 08:44:46 +0200, Peter Eisentraut wrote:
> On 03/08/2018 15:00, Robert Haas wrote:
> > On Thu, Aug 2, 2018 at 4:44 PM, Andres Freund wrote:
> >> ISTM, if you want to increase consistency in this area, you've to go
> >> further. E.g. processing invalidations in StartTransactionCom
On 03/08/2018 15:00, Robert Haas wrote:
> On Thu, Aug 2, 2018 at 4:44 PM, Andres Freund wrote:
>> ISTM, if you want to increase consistency in this area, you've to go
>> further. E.g. processing invalidations in StartTransactionCommand() in
>> all states, which'd give you a lot more consistency.
>
On 31/07/2018 23:10, Peter Eisentraut wrote:
> On 27/07/2018 16:16, Robert Haas wrote:
>> With respect to this particular patch, I don't know whether there are
>> any hazards of the second type. What I'd check, if it were me, is
>> what structures in the index's relcache entry are going to get reb
On Thu, Aug 2, 2018 at 4:44 PM, Andres Freund wrote:
> ISTM, if you want to increase consistency in this area, you've to go
> further. E.g. processing invalidations in StartTransactionCommand() in
> all states, which'd give you a lot more consistency.
Hmm, that seems like a pretty good idea.
--
On Thu, Aug 2, 2018 at 4:51 PM, Tom Lane wrote:
> Robert Haas writes:
>> [ reasons why DDL under less than AEL sucks ]
>
> Unfortunately, none of these problems are made to go away with an
> AcceptInvalidationMessages at statement start. That just makes the
> window smaller. But DDL effects cou
On 2018-08-02 16:51:10 -0400, Tom Lane wrote:
> Robert Haas writes:
> > [ reasons why DDL under less than AEL sucks ]
>
> Unfortunately, none of these problems are made to go away with an
> AcceptInvalidationMessages at statement start. That just makes the
> window smaller. But DDL effects coul
Robert Haas writes:
> [ reasons why DDL under less than AEL sucks ]
Unfortunately, none of these problems are made to go away with an
AcceptInvalidationMessages at statement start. That just makes the
window smaller. But DDL effects could still be seen - or not -
partway through a statement, wi
Hi,
On 2018-08-02 16:30:42 -0400, Robert Haas wrote:
> With this change, we'd be able to say that new statements will
> definitely see the results of concurrent DDL.
I don't think it really gets you that far. Because you're suggesting to
do it at the parse stage, you suddenly have issues with pre
On Thu, Aug 2, 2018 at 4:02 PM, Andres Freund wrote:
>> Inserting AcceptInvalidationMessages() in some location that
>> guarantees it will be executed at least once per SQL statement. I
>> tentatively propose the beginning of parse_analyze(), but I am open to
>> suggestions.
>
> I'm inclined to t
Robert Haas writes:
> On Wed, Aug 1, 2018 at 3:36 PM, Andres Freund wrote:
>> What precisely are you proposing?
> Inserting AcceptInvalidationMessages() in some location that
> guarantees it will be executed at least once per SQL statement. I
> tentatively propose the beginning of parse_analyze
Hi,
On 2018-08-02 15:57:13 -0400, Robert Haas wrote:
> On Wed, Aug 1, 2018 at 3:36 PM, Andres Freund wrote:
> >> Right. If nobody sees a reason not to change that, I think we should.
> >> It would make the behavior more predictable with, I hope, no real
> >> loss.
> >
> > What precisely are you
On Wed, Aug 1, 2018 at 3:36 PM, Andres Freund wrote:
>> Right. If nobody sees a reason not to change that, I think we should.
>> It would make the behavior more predictable with, I hope, no real
>> loss.
>
> What precisely are you proposing?
Inserting AcceptInvalidationMessages() in some locatio
On 2018-08-01 15:33:09 -0400, Robert Haas wrote:
> On Wed, Aug 1, 2018 at 3:04 AM, Peter Eisentraut
> wrote:
> > On 31/07/2018 23:25, Tom Lane wrote:
> >> Peter Eisentraut writes:
> >>> On 27/07/2018 16:16, Robert Haas wrote:
> I also suspect that an appropriate fix might be to ensure that
>
On Wed, Aug 1, 2018 at 3:04 AM, Peter Eisentraut
wrote:
> On 31/07/2018 23:25, Tom Lane wrote:
>> Peter Eisentraut writes:
>>> On 27/07/2018 16:16, Robert Haas wrote:
I also suspect that an appropriate fix might be to ensure that
AcceptInvalidationMessages() is run at least once at the
On 31/07/2018 23:25, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 27/07/2018 16:16, Robert Haas wrote:
>>> I also suspect that an appropriate fix might be to ensure that
>>> AcceptInvalidationMessages() is run at least once at the beginning of
>>> parse analysis.
>
>> Why don't we just do tha
Peter Eisentraut writes:
> On 27/07/2018 16:16, Robert Haas wrote:
>> I also suspect that an appropriate fix might be to ensure that
>> AcceptInvalidationMessages() is run at least once at the beginning of
>> parse analysis.
> Why don't we just do that?
Don't we do that already? Certainly it sh
On 27/07/2018 16:16, Robert Haas wrote:
> With respect to this particular patch, I don't know whether there are
> any hazards of the second type. What I'd check, if it were me, is
> what structures in the index's relcache entry are going to get rebuilt
> when the index name changes. If any of tho
On Wed, Jul 18, 2018 at 5:20 AM, Peter Eisentraut
wrote:
> In the 2012 thread, it was mentioned several times that some thought
> that renaming without an exclusive lock was unsafe, but without any
> further reasons. I think that was before MVCC catalog snapshots were
> implemented, so at that ti
>
> You appear to be saying that you think that renaming an index
> concurrently is not safe. In that case, this patch should be rejected.
> However, I don't think it necessarily is unsafe. What we need is some
> reasoning about the impact, not a bunch of different options that we
> don't underst
Понедельник, 23 июля 2018, 18:06 +03:00 от Peter Eisentraut <
peter.eisentr...@2ndquadrant.com >:
>
>You appear to be saying that you think that renaming an index
>concurrently is not safe
No, I didn't say it about renaming indexes.
I tried to say that it does not make sense exactly to rename a ta
On 23.07.18 15:14, Andrey Klychkov wrote:
> Moreover, if you rename Table without query locking, it may crushes your
> services that
> do queries at the same time, therefore, this is unlikely that someone
> will be do it
> with concurrent queries to renamed table, in other words, with running
> pro
>Среда, 18 июля 2018, 12:21 +03:00 от Peter Eisentraut
>:
>
>
>In your patch, the effect of the CONCURRENTLY keyword is just to change
>the lock level, without any further changes. That doesn't make much
>sense. If we think the lower lock level is OK, then we should just use
>it always.
I was
On 18.07.18 11:44, Andrey Klychkov wrote:
> If lower locking is safe and possible to be used by default in renaming
> it will be great.
> What stage is solving of this issue? Does anybody do it?
We wait to see if anyone has any concerns about this change.
--
Peter Eisentraut http://
>Среда, 18 июля 2018, 12:21 +03:00 от Peter Eisentraut
>:
>
>If we think the lower lock level is OK, then we should just use
>it always.
>
Hi, I absolutely agree with you.
If lower locking is safe and possible to be used by default in renaming it will
be great.
What stage is solving of this issu
On 17.07.18 13:48, Andrey Klychkov wrote:
> Please, have a look at previous discussions on the subject:
> - 2012
>
> https://www.postgresql.org/message-id/cab7npqtys6juqdxuczbjb0bnw0kprw8wdzuk11kaxqq6o98...@mail.gmail.com
> -
> 2013
> https://www.postgresql.org/message-id/cab7
> Понедельник, 16 июля 2018, 22:19 +03:00 от Andrey Borodin
> :
>
>Hi!
>
>> 16 июля 2018 г., в 22:58, Andrey Klychkov < aaklych...@mail.ru > написал(а):
>> Dear hackers!
>>
>> I have an idea to facilitate work with index rebuilding.
>>
>
>Понедельник, 16 июля 2018, 22:40 +03:00 от Victor Yegorov :
>
>пн, 16 июл. 2018 г. в 21:58, Andrey Klychkov < aaklych...@mail.ru >:
>>I made a patch to solve this issue (see the attachment).
>>It allows to avoid locks by a query like this:
>>“alter index re
пн, 16 июл. 2018 г. в 21:58, Andrey Klychkov :
> I made a patch to solve this issue (see the attachment).
> It allows to avoid locks by a query like this:
> “alter index rename CONCURRENTLY to ”.
>
Please, have a look at previous discussions on the subject:
- 2012
https://www.po
Hi!
> 16 июля 2018 г., в 22:58, Andrey Klychkov написал(а):
> Dear hackers!
>
> I have an idea to facilitate work with index rebuilding.
>
> "ALTER INDEX ... RENAME CONCURRENTLY TO ..."
The idea seems useful. I'm not an expert in CIC, but your post do no
execute renaming manually and interrupt it again and
again if it can’t execute in allowable time.
I made a patch to solve this issue (see the attachment).
It allows to avoid locks by a query like this:
“alter index rename CONCURRENTLY to ”.
Briefly, I did it by using similar way in the index_create
38 matches
Mail list logo