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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
>
> 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
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
>
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
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
>
пн, 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
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 not cover one
very important topic.
30 matches
Mail list logo
