On Tue, Apr 16, 2019 at 08:50:31AM +0200, Peter Eisentraut wrote:
> Looks good to me.
Thanks, committed. If there are additional discussions on various
points of the feature, let's move to a new thread please. This one
has been already extensively used ;)
--
Michael
signature.asc
Description:
On 2019-04-16 08:19, Michael Paquier wrote:
> On Fri, Apr 12, 2019 at 12:11:12PM +0100, Dagfinn Ilmari Mannsåker wrote:
>> I don't have any comments on the code (but the test looks sensible, it's
>> the same trick I used to discover the issue in the first place).
>
> After thinking some more on it
On Fri, Apr 12, 2019 at 12:11:12PM +0100, Dagfinn Ilmari Mannsåker wrote:
> I don't have any comments on the code (but the test looks sensible, it's
> the same trick I used to discover the issue in the first place).
After thinking some more on it, this behavior looks rather sensible to
me. Are th
Michael Paquier writes:
> So... I am coming up with the patch attached. I have introduced some
> tests using a trick with CIC to have an invalid index to work on.
I don't have any comments on the code (but the test looks sensible, it's
the same trick I used to discover the issue in the first p
On Fri, Apr 12, 2019 at 08:44:18AM +0200, Peter Eisentraut wrote:
> Looks good, committed.
Thanks for committing!
--
Michael
signature.asc
Description: PGP signature
On 2019-04-11 05:59, Michael Paquier wrote:
> On Tue, Apr 09, 2019 at 03:50:27PM +0900, Michael Paquier wrote:
>> And here is the patch to address this issue. It happens that a bit
>> more than the dependency switch was lacking here:
>> - At swap time, we need to have the new index definition trac
On Thu, Apr 11, 2019 at 09:49:47AM -0400, Alvaro Herrera wrote:
> Hmm, I suppose that makes sense for REINDEX TABLE or anything that
> reindexes more than one index, but if you do REINDEX INDEX surely it
> is reasonable to allow the case?
Yes, we could revisit the REINDEX INDEX portion of the deci
On 2019-Apr-11, Michael Paquier wrote:
> > I was going to just remove the caveat, but then I discovered that
> > REINDEX CONCURRENTLY doesn't work on INVALID indexes (why?).
>
> This is a wanted choice. The index built in parallel of the existing
> one during a concurrent reindex is marked inval
On Thu, Apr 11, 2019 at 11:21:29AM +0100, Dagfinn Ilmari Mannsåker wrote:
> I noticed that the docs for how to recover from a failed CREATE INDEX
> CONCURRENTLY say that «REINDEX does not support concurrent builds»,
> which is no longer true.
Good catch. I'll apply that in a couple of hours.
> I
Peter Eisentraut writes:
> On 2019-03-28 09:07, Sergei Kornilov wrote:
>> Unfortunately patch does not apply due recent commits. Any chance
>> this can be fixed (and even committed in pg12)?
>
> Committed :)
I noticed that the docs for how to recover from a failed CREATE INDEX
CONCURRENTLY say t
On Tue, Apr 09, 2019 at 03:50:27PM +0900, Michael Paquier wrote:
> And here is the patch to address this issue. It happens that a bit
> more than the dependency switch was lacking here:
> - At swap time, we need to have the new index definition track
> relispartition from the old index.
> - Again
On Mon, Apr 01, 2019 at 03:43:43PM +0900, Michael Paquier wrote:
> And I would have expected concur_reindex_part1v1_c1_idx to still be
> part of the partition tree. I think that the issue is in
> index_concurrently_create_copy() where we create the new index with
> index_create() without setting p
On Sat, Mar 30, 2019 at 11:56:27AM +0100, Peter Eisentraut wrote:
> The attached patch fixes this. The issue was that we didn't move all
> dependencies from the index (only in the other direction). Maybe that
> was sufficient when the patch was originally written, before partitioned
> indexes.
H
On Sat, Mar 30, 2019 at 11:56:27AM +0100, Peter Eisentraut wrote:
> The attached patch fixes this. The issue was that we didn't move all
> dependencies from the index (only in the other direction). Maybe that
> was sufficient when the patch was originally written, before partitioned
> indexes.
H
On 2019-03-29 16:10, Shinoda, Noriyoshi (PN Japan A&PS Delivery) wrote:
> postgres=> CREATE TABLE part1(c1 INT) PARTITION BY RANGE(c1);
> CREATE TABLE
> postgres=> CREATE TABLE part1v1 PARTITION OF part1 FOR VALUES FROM (0) TO
> (100);
> CREATE TABLE
> postgres=> CREATE INDEX idx1_part1 ON part1(c
On Fri, Mar 29, 2019 at 08:48:03AM -0700, Andres Freund wrote:
> Yes, it increases the total runtime quite considerably. And it adds new
> failure modes with partially built invalid indexes hanging around that
> need to be dropped manually.
On top of that CONCURRENTLY needs multiple transactions t
On Fri, Mar 29, 2019 at 03:10:23PM +, Shinoda, Noriyoshi (PN Japan A&PS
Delivery) wrote:
> I tried this great feature for partition index.
> The first time the REINDEX TABLE CONCURRENTLY statement is executed
> to the partition, then an error occurs.
Yes, that's a problem. I am adding an op
On 2019-03-29 17:01, Justin Pryzby wrote:
> On Fri, Mar 29, 2019 at 03:53:05PM +, Bossart, Nathan wrote:
>> I noticed a very small typo in the documentation for this feature.
>
> I submit a bunch more changes for consideration, attached.
fixed, thanks
--
Peter Eisentraut http:/
On 2019-03-29 16:53, Bossart, Nathan wrote:
> I noticed a very small typo in the documentation for this feature.
fixed
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Fri, Mar 29, 2019 at 03:53:05PM +, Bossart, Nathan wrote:
> I noticed a very small typo in the documentation for this feature.
I submit a bunch more changes for consideration, attached.
>From dafdb15fb3e7c69de82a2206c9bf07588b5665ce Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Fri, 2
I noticed a very small typo in the documentation for this feature.
diff --git a/doc/src/sgml/ref/reindex.sgml b/doc/src/sgml/ref/reindex.sgml
index ccabb330cb..e45bf86c8d 100644
--- a/doc/src/sgml/ref/reindex.sgml
+++ b/doc/src/sgml/ref/reindex.sgml
@@ -349,7 +349,7 @@ REINDEX [ ( VERBOSE ) ] { IN
Hi,
On 2019-03-29 11:47:10 -0400, Robert Treat wrote:
> On Fri, Mar 29, 2019 at 3:28 AM Peter Eisentraut
> wrote:
> >
> > On 2019-03-28 09:07, Sergei Kornilov wrote:
> > > Unfortunately patch does not apply due recent commits. Any chance this
> > > can be fixed (and even committed in pg12)?
> >
On Fri, Mar 29, 2019 at 3:28 AM Peter Eisentraut
wrote:
>
> On 2019-03-28 09:07, Sergei Kornilov wrote:
> > Unfortunately patch does not apply due recent commits. Any chance this can
> > be fixed (and even committed in pg12)?
>
> Committed :)
>
Given this has been committed I've probably missed
ent: Friday, March 29, 2019 6:21 PM
To: Peter Eisentraut
Cc: Sergei Kornilov ; pgsql-hackers@lists.postgresql.org
Subject: Re: REINDEX CONCURRENTLY 2.0
On Fri, Mar 29, 2019 at 09:13:35AM +0100, Peter Eisentraut wrote:
> So, we're getting buildfarm failures, only with clang. I can
> reproduc
On Fri, Mar 29, 2019 at 09:13:35AM +0100, Peter Eisentraut wrote:
> So, we're getting buildfarm failures, only with clang. I can reproduce
> those (with clang).
Indeed, I can reproduce the failures using -O2 with clang. I am
wondering if we are not missing a volatile flag somewhere and that
some
On 2019-03-29 09:13, Peter Eisentraut wrote:
> On 2019-03-29 09:04, Michael Paquier wrote:
>> On Fri, Mar 29, 2019 at 10:39:23AM +0300, Sergei Kornilov wrote:
>>> wow! Congratulations! This was very long way
>>>
>>> my favorite pg12 feature
>>
>> So this has been committed, nice! Thanks a lot to a
On 2019-03-29 09:04, Michael Paquier wrote:
> On Fri, Mar 29, 2019 at 10:39:23AM +0300, Sergei Kornilov wrote:
>> wow! Congratulations! This was very long way
>>
>> my favorite pg12 feature
>
> So this has been committed, nice! Thanks a lot to all for keeping
> alive this patch over the ages, wit
On Fri, Mar 29, 2019 at 10:39:23AM +0300, Sergei Kornilov wrote:
> wow! Congratulations! This was very long way
>
> my favorite pg12 feature
So this has been committed, nice! Thanks a lot to all for keeping
alive this patch over the ages, with particular thanks to Andreas and
Peter.
--
Michael
>> Unfortunately patch does not apply due recent commits. Any chance this can
>> be fixed (and even committed in pg12)?
>
> Committed :)
wow! Congratulations! This was very long way
my favorite pg12 feature
regards, Sergei
On 2019-03-28 09:07, Sergei Kornilov wrote:
> Unfortunately patch does not apply due recent commits. Any chance this can be
> fixed (and even committed in pg12)?
Committed :)
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training
Hi
Unfortunately patch does not apply due recent commits. Any chance this can be
fixed (and even committed in pg12)?
>> And few questions:
>> - reindexdb has concurrently flag logic even in reindex_system_catalogs,
>> but "reindex concurrently" can not reindex system catalog. Is this expected
On Mon, Mar 25, 2019 at 04:23:34PM +0100, Peter Eisentraut wrote:
> Let's do it. :-)
I am pretty sure that this has been said at least once since 2012.
> I've gone over this patch a few more times. I've read all the
> discussion since 2012 again and made sure all the issues were addressed.
> I
Hello
Yet another review of this patch from me...
>An index build with the CONCURRENTLY option failed,
> leaving
>an invalid index. Such indexes are useless but it can be
> - convenient to use REINDEX to rebuild them. Note that
> - REINDEX will not perform a concurrent
On 2019-03-15 22:32, Michael Banck wrote:
> I had a quick look at some of the comments and noticed some possible
> nitpicky-level problems:
Thanks, I've integrated these changes into my local branch.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Suppor
Hi,
Am Mittwoch, den 13.03.2019, 23:10 +0100 schrieb Peter Eisentraut:
> Here is an updated patch.
I had a quick look at some of the comments and noticed some possible
nitpicky-level problems:
> +/*
> + * index_concurrently_set_dead
> + *
> + * Perform the last invalidation stage of DROP INDEX C
On 2019-03-13 15:13, Sergei Kornilov wrote:
> Patch is marked as target version 12, but is inactive few weeks long. I think
> many users want this feature and patch is in good shape. We have open
> questions on this thread?
>
> Latest patch still can be aplied cleanly; it builds and pass tests.
Hello
Patch is marked as target version 12, but is inactive few weeks long. I think
many users want this feature and patch is in good shape. We have open questions
on this thread?
Latest patch still can be aplied cleanly; it builds and pass tests.
regards, Sergei
On Thu, Feb 07, 2019 at 12:07:01PM -0300, Alvaro Herrera wrote:
> On 2019-Feb-07, Peter Eisentraut wrote:
>> Another thing I was thinking of: We need some database-global tests.
>> For example, at some point during development, I had broken some variant
>> of REINDEX DATABASE. Where could we put t
On 2019-Feb-07, Peter Eisentraut wrote:
> Another thing I was thinking of: We need some database-global tests.
> For example, at some point during development, I had broken some variant
> of REINDEX DATABASE. Where could we put those tests? Maybe with reindexdb?
What's wrong with a new reindex.
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:tested, passed
Hello
Sorry for late response. I review latest patch version.
I
On Thu, Feb 07, 2019 at 12:49:43PM +0100, Peter Eisentraut wrote:
> Anyway, that's all cosmetics. Are there any more functional or
> correctness issues to be addressed?
Not that I can think of. At least this evening.
> Another thing I was thinking of: We need some database-global tests.
> For e
On 30/01/2019 06:16, Michael Paquier wrote:
> On Tue, Jan 29, 2019 at 09:51:35PM +0100, Peter Eisentraut wrote:
>> On 16/01/2019 09:27, Michael Paquier wrote:
>>> index_create does not actually need its extra argument with the tuple
>>> descriptor. I think that we had better grab the column name l
On Tue, Jan 29, 2019 at 09:51:35PM +0100, Peter Eisentraut wrote:
> On 16/01/2019 09:27, Michael Paquier wrote:
>> index_create does not actually need its extra argument with the tuple
>> descriptor. I think that we had better grab the column name list from
>> indexInfo and just pass that down to
Here is an updated patch, which addresses some of your issues below as
well as the earlier reported issue that comments were lost during
REINDEX CONCURRENTLY.
On 16/01/2019 09:27, Michael Paquier wrote:
> On Fri, Jan 04, 2019 at 03:18:06PM +0300, Sergei Kornilov wrote:
>> NOTICE seems unnecessary
Hi,
On 2019-01-23 13:17:26 -0500, Robert Haas wrote:
> On Fri, Jan 18, 2019 at 9:01 PM Vik Fearing
> wrote:
> > I don't want a situation like this:
> > CREATE INDEX CONCURRENTLY ...
> > DROP INDEX CONCURRENTLY ...
> > REINDEX INDEX (CONCURRENTLY) ...
> >
> > All three should be the s
st 23. 1. 2019 19:17 odesílatel Robert Haas napsal:
> On Fri, Jan 18, 2019 at 9:01 PM Vik Fearing
> wrote:
> > I don't want a situation like this:
> > CREATE INDEX CONCURRENTLY ...
> > DROP INDEX CONCURRENTLY ...
> > REINDEX INDEX (CONCURRENTLY) ...
> >
> > All three should be the sa
On Fri, Jan 18, 2019 at 9:01 PM Vik Fearing wrote:
> I don't want a situation like this:
> CREATE INDEX CONCURRENTLY ...
> DROP INDEX CONCURRENTLY ...
> REINDEX INDEX (CONCURRENTLY) ...
>
> All three should be the same, and my suggestion is to add the
> parenthesized version to CREATE
On Sat, Jan 19, 2019 at 03:01:07AM +0100, Vik Fearing wrote:
> On 19/01/2019 02:33, Michael Paquier wrote:
>> On Fri, Jan 18, 2019 at 07:58:06PM +0100, Vik Fearing wrote:
>>> My vote is to have homogeneous syntax for all of this, and so put it in
>>> parentheses, but we should also allow CREATE IND
On January 19, 2019 7:32:55 AM PST, Stephen Frost wrote:
>Greetings,
>
>* Vik Fearing (vik.fear...@2ndquadrant.com) wrote:
>> My vote is to have homogeneous syntax for all of this, and so put it
>in
>> parentheses, but we should also allow CREATE INDEX and DROP INDEX to
>use
>> parentheses for
Greetings,
* Vik Fearing (vik.fear...@2ndquadrant.com) wrote:
> On 16/01/2019 18:59, Alvaro Herrera wrote:
> > On 2019-Jan-16, Michael Paquier wrote:
> >
> >> Regarding the grammar, we tend for the last couple of years to avoid
> >> complicating the main grammar and move on to parenthesized gramm
Hello
> I don't want a situation like this:
> CREATE INDEX CONCURRENTLY ...
> DROP INDEX CONCURRENTLY ...
> REINDEX INDEX (CONCURRENTLY) ...
>
> All three should be the same, and my suggestion is to add the
> parenthesized version to CREATE and DROP and not add the unparenthesized
> ve
On Thu, Jan 17, 2019 at 02:11:01PM +0900, Michael Paquier wrote:
> Okay, I have begun digging into the patch, and extracted for now two
> things which can be refactored first, giving a total of three patches:
> - 0001, which creates WaitForOlderSnapshots to snapmgr.c. I think
> that this can be us
On 19/01/2019 02:33, Michael Paquier wrote:
> On Fri, Jan 18, 2019 at 07:58:06PM +0100, Vik Fearing wrote:
>> My vote is to have homogeneous syntax for all of this, and so put it in
>> parentheses, but we should also allow CREATE INDEX and DROP INDEX to use
>> parentheses for it, too.
>
> That wou
On Fri, Jan 18, 2019 at 07:58:06PM +0100, Vik Fearing wrote:
> My vote is to have homogeneous syntax for all of this, and so put it in
> parentheses, but we should also allow CREATE INDEX and DROP INDEX to use
> parentheses for it, too.
That would be a new thing as these variants don't exist yet,
On 16/01/2019 18:59, Alvaro Herrera wrote:
> On 2019-Jan-16, Michael Paquier wrote:
>
>> Regarding the grammar, we tend for the last couple of years to avoid
>> complicating the main grammar and move on to parenthesized grammars
>> (see VACUUM, ANALYZE, EXPLAIN, etc). So in the same vein I think
On Wed, Jan 16, 2019 at 05:56:15PM +0100, Andreas Karlsson wrote:
> On 1/16/19 9:27 AM, Michael Paquier wrote:
>> Does somebody mind if I jump into the ship after so long? I was the
>> original author of the monster after all...
>
> Fine by me. Peter?
Okay, I have begun digging into the patch, a
On Wed, Jan 16, 2019 at 02:59:31PM -0300, Alvaro Herrera wrote:
> That's my opinion too, but I was outvoted in another subthread -- see
> https://postgr.es/m/20181214144529.wvmjwmy7wxgmgyb3@alvherre.pgsql
> Stephen Frost, Andrew Gierth and Andres Freund all voted to put
> CONCURRENTLY outside the p
On 2019-Jan-16, Michael Paquier wrote:
> Regarding the grammar, we tend for the last couple of years to avoid
> complicating the main grammar and move on to parenthesized grammars
> (see VACUUM, ANALYZE, EXPLAIN, etc). So in the same vein I think that
> it would make sense to only support CONCURR
On 1/16/19 9:27 AM, Michael Paquier wrote:> Regarding the grammar, we
tend for the last couple of years to avoid
complicating the main grammar and move on to parenthesized grammars
(see VACUUM, ANALYZE, EXPLAIN, etc). So in the same vein I think that
it would make sense to only support CONCURREN
On Fri, Jan 04, 2019 at 03:18:06PM +0300, Sergei Kornilov wrote:
> NOTICE seems unnecessary here.
>
> Unfortunally concurrently reindex loses comments, reproducer:
Yes, the NOTICE message makes little sense.
I am getting back in touch with this stuff. It has been some time but
the core of the p
> About syntax: i vote for current syntax "reindex table CONCURRENTLY
> tablename". This looks consistent with existed CREATE INDEX CONCURRENTLY
> and REFRESH MATERIALIZED VIEW CONCURRENTLY.
>
+1
Pavel
> regards, Sergei
>
> [1]:
> https://www.postgresql.org/message-id/CAB7nPqT%2B6igqbUb59y04NEg
Hello
Thank you! I review new patch version. It applied, builds and pass tests. Code
looks good, but i notice new behavior notes:
> postgres=# reindex (verbose) table CONCURRENTLY measurement ;
> WARNING: REINDEX of partitioned tables is not yet implemented, skipping
> "measurement"
> NOTICE:
Updated patch for some merge conflicts and addressing most of your
comments. (I did not do anything about the syntax.)
On 09/12/2018 19:55, Sergei Kornilov wrote:
> I found one error in phase 4. Simple reproducer:
>
>> create table test (i int);
>> create index this_is_very_large_exactly_maxname
Greetings,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> On 2018-Dec-14, Stephen Frost wrote:
>
> > > My vote goes to put the keyword inside of and exclusively in the
> > > parenthesized option list.
> >
> > I disagree with the idea of exclusively having concurrently be in the
> > parenth
On 2018-12-31 21:35:57 +, Andrew Gierth wrote:
> > "Alvaro" == Alvaro Herrera writes:
>
> Alvaro> After looking at the proposed grammar again today and in danger
> Alvaro> of repeating myself, IMO allowing the concurrency keyword to
> Alvaro> appear outside the parens would be a mistak
> "Alvaro" == Alvaro Herrera writes:
Alvaro> After looking at the proposed grammar again today and in danger
Alvaro> of repeating myself, IMO allowing the concurrency keyword to
Alvaro> appear outside the parens would be a mistake. Valid commands:
Alvaro> REINDEX (VERBOSE, CONCURRENTLY
On 2018-Dec-14, Stephen Frost wrote:
> > My vote goes to put the keyword inside of and exclusively in the
> > parenthesized option list.
>
> I disagree with the idea of exclusively having concurrently be in the
> parentheses. 'explain buffers' is a much less frequently used option
> (though that
On Thu, Dec 27, 2018 at 11:04:09AM +0100, Peter Eisentraut wrote:
> The current patch prevents REINDEX CONCURRENTLY of invalid indexes, but
> I wonder why that is so. Anyone remember?
It should be around this time:
https://www.postgresql.org/message-id/cab7npqrwvtqchweruf9o0hrrgfyq9xark7k7jclxqkl
On 09/12/2018 19:55, Sergei Kornilov wrote:
>>
>> An index build with the CONCURRENTLY option failed,
>> leaving
>> an invalid index. Such indexes are useless but it can be
>> - convenient to use REINDEX to rebuild them. Note
>> that
>> - REINDEX will not perform a co
On Fri, Dec 14, 2018 at 09:00:58AM -0300, Alvaro Herrera wrote:
> On 2018-Dec-14, Peter Eisentraut wrote:
>> Do you happen to have a link for that? I didn't find anything.
The message I was thinking about is close to here:
https://www.postgresql.org/message-id/20121210152856.gc16...@awork2.anaraz
Greetings,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> On 2018-Dec-14, Stephen Frost wrote:
>
> > That wasn't what was asked and I don't think I see a problem with having
> > concurrently be allowed in the parentheses. For comparison, it's not
> > like "explain analyze select ..." or "e
On 2018-Dec-14, Stephen Frost wrote:
> That wasn't what was asked and I don't think I see a problem with having
> concurrently be allowed in the parentheses. For comparison, it's not
> like "explain analyze select ..." or "explain buffers select" is
> terribly good grammatical form.
... and we d
Greetings,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 14/12/2018 01:14, Stephen Frost wrote:
> reindex table CONCURRENTLY test;
> >>
> >> By the way, does this syntax make sense? I haven't seen a discussion on
> >> this anywhere in the various threads. I keep thinking
On 2018-Dec-14, Peter Eisentraut wrote:
> On 14/12/2018 01:23, Michael Paquier wrote:
> > On Thu, Dec 13, 2018 at 07:14:57PM -0500, Stephen Frost wrote:
> >> Based on at least a quick looking around, the actual grammar rule seems
> >> to match my recollection[1], adverbs should typically go AFTER
On 14/12/2018 01:23, Michael Paquier wrote:
> On Thu, Dec 13, 2018 at 07:14:57PM -0500, Stephen Frost wrote:
>> Based on at least a quick looking around, the actual grammar rule seems
>> to match my recollection[1], adverbs should typically go AFTER the
>> verb + object, and the adverb shouldn't ev
On 14/12/2018 01:14, Stephen Frost wrote:
reindex table CONCURRENTLY test;
>>
>> By the way, does this syntax make sense? I haven't seen a discussion on
>> this anywhere in the various threads. I keep thinking that
>>
>> reindex concurrently table test;
>>
>> would make more sense. How
On Thu, Dec 13, 2018 at 07:14:57PM -0500, Stephen Frost wrote:
> Based on at least a quick looking around, the actual grammar rule seems
> to match my recollection[1], adverbs should typically go AFTER the
> verb + object, and the adverb shouldn't ever be placed between the verb
> and the object.
Greetings,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 09/12/2018 19:55, Sergei Kornilov wrote:
> >> reindex table CONCURRENTLY test;
>
> By the way, does this syntax make sense? I haven't seen a discussion on
> this anywhere in the various threads. I keep thinking that
>
On 09/12/2018 19:55, Sergei Kornilov wrote:
>> reindex table CONCURRENTLY test;
By the way, does this syntax make sense? I haven't seen a discussion on
this anywhere in the various threads. I keep thinking that
reindex concurrently table test;
would make more sense. How about in combinati
Hello
I review code and documentation and i have few notes. Did you register this
patch in CF app?
I found one error in phase 4. Simple reproducer:
> create table test (i int);
> create index this_is_very_large_exactly_maxnamelen_index_name_wink_wink_wink
> on test (i);
> create index this_is_
On 07/12/2018 17:40, Sergei Kornilov wrote:
> I perform some tests and think behavior with partition tables is slightly
> inconsistent.
>
> postgres=# reindex table measurement;
> WARNING: REINDEX of partitioned tables is not yet implemented, skipping
> "measurement"
> NOTICE: table "measureme
Hello
Thank you for working on this patch!
I perform some tests and think behavior with partition tables is slightly
inconsistent.
postgres=# reindex table measurement;
WARNING: REINDEX of partitioned tables is not yet implemented, skipping
"measurement"
NOTICE: table "measurement" has no in
Here is a revival of this patch. This is Andreas Karlsson's v4 patch
(2017-11-01) with some updates for conflicts and changed APIs.
AFAICT from the discussions, there were no more conceptual concerns with
this approach. Recall that with this patch REINDEX CONCURRENTLY creates
a new index (with a
On Wed, Jan 31, 2018 at 01:48:00AM +0100, Andreas Karlsson wrote:
> I too like the concept, but have not had the time to look into it.
This may happen at some point, for now I am marking the patch as
returned with feedback.
--
Michael
signature.asc
Description: PGP signature
On 01/26/2018 03:28 AM, Stephen Frost wrote:
I'm a big fan of this patch but it doesn't appear to have made any
progress in quite a while. Is there any chance we can get an updated
patch and perhaps get another review before the end of this CF...?
Sorry, as you may have guessed I do not have t
Craig, Michael, all,
* Craig Ringer (cr...@2ndquadrant.com) wrote:
> On 21 December 2017 at 11:31, Michael Paquier
> wrote:
>
> > On Thu, Dec 21, 2017 at 11:46 AM, Alvaro Herrera
> > wrote:
> > > Michael Paquier wrote:
> > >> Well, the idea is really to get rid of that as there are already
> >
On 21 December 2017 at 11:31, Michael Paquier
wrote:
> On Thu, Dec 21, 2017 at 11:46 AM, Alvaro Herrera
> wrote:
> > Michael Paquier wrote:
> >> Well, the idea is really to get rid of that as there are already
> >> facilities of this kind for CREATE TABLE LIKE in the parser and ALTER
> >> TABLE
On Thu, Dec 21, 2017 at 11:46 AM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
>> Well, the idea is really to get rid of that as there are already
>> facilities of this kind for CREATE TABLE LIKE in the parser and ALTER
>> TABLE when rewriting a relation. It is not really attractive to have a
>>
Michael Paquier wrote:
> Well, the idea is really to get rid of that as there are already
> facilities of this kind for CREATE TABLE LIKE in the parser and ALTER
> TABLE when rewriting a relation. It is not really attractive to have a
> 3rd method in the backend code to do the same kind of things,
Andreas Karlsson wrote:
> Here is a rebased version of the patch.
Is anybody working on rebasing this patch?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Wed, Nov 1, 2017 at 1:20 PM, Andreas Karlsson wrote:
> Here is a rebased version of the patch.
The patch does not apply, and needs a rebase. I am moving it to next
CF with waiting on author as status.
--
Michael
91 matches
Mail list logo
