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.
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
53 matches
Mail list logo
