On Thu, Mar 19, 2015 at 2:44 AM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
>
>> I had a look at your modified version, and it looks good to me.
>
> Thanks, pushed. (Without the va_cols change proposed downthread.)
Thanks a lot! I will shortly work on the rebase for the other patch.
--
Mich
Michael Paquier wrote:
> I had a look at your modified version, and it looks good to me.
Thanks, pushed. (Without the va_cols change proposed downthread.)
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Se
On Wed, Mar 18, 2015 at 10:51 AM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
>> On Wed, Mar 18, 2015 at 2:22 AM, Alvaro Herrera wrote:
>
>> > 1. ordered the argument list to vacuum(), hopefully it's more sensible
>> > now.
>>
>> Fine for me.
>
> Actually, why don't we move va_cols to VacuumPar
Michael Paquier wrote:
> On Wed, Mar 18, 2015 at 2:22 AM, Alvaro Herrera wrote:
> > 1. ordered the argument list to vacuum(), hopefully it's more sensible
> > now.
>
> Fine for me.
Actually, why don't we move va_cols to VacuumParams too?
--
Álvaro Herrerahttp://www.2ndQuadrant.
On Wed, Mar 18, 2015 at 2:22 AM, Alvaro Herrera wrote:
> Here's an updated patch. I took your latest version and made some extra
> changes:
Thanks for taking the time to look at it!
> 1. ordered the argument list to vacuum(), hopefully it's more sensible
> now.
Fine for me.
> 2. changed struct
On Tue, Mar 17, 2015 at 6:31 PM, Stephen Frost wrote:
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > I went to change this patch status in the commitfest app, and the app
> > told me I cannot change the status in the current commitfest. Please
> > somebody with commitfest mace superpow
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> I went to change this patch status in the commitfest app, and the app
> told me I cannot change the status in the current commitfest. Please
> somebody with commitfest mace superpowers set it as ready for committer.
I'm afraid the issue is a bu
I went to change this patch status in the commitfest app, and the app
told me I cannot change the status in the current commitfest. Please
somebody with commitfest mace superpowers set it as ready for committer.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development,
On 3/11/15 3:57 PM, Tom Lane wrote:
Alvaro Herrera writes:
But autovacuum is still manufacturing a VacuumStmt by hand. If we want
to get rid of that, I think it'd work to have a new
ExecVacuum(VacuumStmt, params) function which is called from
standard_ProcessUtility and does just vacuum(rel, r
Alvaro Herrera writes:
> But autovacuum is still manufacturing a VacuumStmt by hand. If we want
> to get rid of that, I think it'd work to have a new
> ExecVacuum(VacuumStmt, params) function which is called from
> standard_ProcessUtility and does just vacuum(rel, relid, params).
> Autovacuum o
On Wed, Mar 11, 2015 at 3:09 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> On Fri, Mar 6, 2015 at 1:39 AM, Michael Paquier
>> wrote:
>
>> > - 0001 is the previous one
>> > - 0002 removes VacuumStmt from the call stack of ANALYZE and VACUUM
>> > routines
>> > - 0003 moves for_wraparound in Va
Robert Haas wrote:
> On Fri, Mar 6, 2015 at 1:39 AM, Michael Paquier
> wrote:
> > - 0001 is the previous one
> > - 0002 removes VacuumStmt from the call stack of ANALYZE and VACUUM routines
> > - 0003 moves for_wraparound in VacuumParams.
>
> Yeah, I think something like this could be a sensible
On Fri, Mar 6, 2015 at 1:39 AM, Michael Paquier
wrote:
>> Do you mean removing totally VacuumStmt from the stack? We would then
>> need to add relation and va_cols as additional arguments of things
>> like vacuum_rel, analyze_rel, do_analyze_rel or similar.
>>
>> FWIW, adding do_toast and for_wrap
On Fri, Mar 6, 2015 at 12:42 AM, Robert Haas wrote:
> On Thu, Mar 5, 2015 at 9:58 AM, Alvaro Herrera wrote:
>> Here's a simple idea to improve the patch: make VacuumParams include
>> VacuumStmt and the for_wraparound and do_toast flags. ISTM that reduces
>> the number of arguments to be passed dow
On Thu, Mar 5, 2015 at 9:58 AM, Alvaro Herrera wrote:
> Robert Haas wrote:
>> On Sun, Mar 1, 2015 at 6:58 AM, Michael Paquier
>> wrote:
>> > Hm, why not. That would remove all inconsistencies between the parser
>> > and the autovacuum code path. Perhaps something like the attached
>> > makes sens
Alvaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Robert Haas wrote:
> > On Sun, Mar 1, 2015 at 6:58 AM, Michael Paquier
> > wrote:
> > > Hm, why not. That would remove all inconsistencies between the parser
> > > and the autovacuum code path. Perhaps something like the attached
> > >
Robert Haas wrote:
> On Sun, Mar 1, 2015 at 6:58 AM, Michael Paquier
> wrote:
> > Hm, why not. That would remove all inconsistencies between the parser
> > and the autovacuum code path. Perhaps something like the attached
> > makes sense then?
>
> I really don't see this patch, or any of the prev
On Thu, Mar 5, 2015 at 12:54 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Sun, Mar 1, 2015 at 6:58 AM, Michael Paquier
>> wrote:
>> > Hm, why not. That would remove all inconsistencies between the parser
>> > and the autovacuum code path. Perhaps something like th
* Robert Haas (robertmh...@gmail.com) wrote:
> On Sun, Mar 1, 2015 at 6:58 AM, Michael Paquier
> wrote:
> > Hm, why not. That would remove all inconsistencies between the parser
> > and the autovacuum code path. Perhaps something like the attached
> > makes sense then?
>
> I really don't see this
On Sun, Mar 1, 2015 at 6:58 AM, Michael Paquier
wrote:
> Hm, why not. That would remove all inconsistencies between the parser
> and the autovacuum code path. Perhaps something like the attached
> makes sense then?
I really don't see this patch, or any of the previous ones, as solving
any actual
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Sat, Feb 28, 2015 at 2:45 PM, Stephen Frost wrote:
> > So, basically, this feels like it's not really the right place
> > for these checks and if there is an existing problem then it's probably
> > with the grammar... Does that m
On Sat, Feb 28, 2015 at 2:45 PM, Stephen Frost wrote:
> I'm trying to wrap my head around the reasoning for this also and not
> sure I'm following. In general, I don't think we protect all that hard
> against functions being called with tokens that aren't allowed by the
> parse.
Check.
> So, ba
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Wed, Feb 18, 2015 at 12:09 AM, Robert Haas wrote:
> > I think it's right the way it is. The parser constructs a VacuumStmt
> > for either a VACUUM or an ANALYZE command. That statement is checking
> > that if you are doing an AN
On Fri, Feb 20, 2015 at 5:41 AM, Peter Eisentraut wrote:
> That's cool if you want to add those assertions, but please make them
> separate statements each, like
>
> Assert(vacstmt->options & (VACOPT_FULL | VACOPT_FREEZE) ||
> vacstmt->freeze_min_age == -1);
> Assert(vacstmt->options & (VACOPT_FUL
On 2/18/15 1:26 AM, Michael Paquier wrote:
> On Wed, Feb 18, 2015 at 10:06 AM, Michael Paquier wrote:
>> Yes, the existing assertion is right. My point is that it is strange
>> that we do not check the values of freeze parameters for an ANALYZE
>> query, which should be set to -1 all the time. If t
On Wed, Feb 18, 2015 at 10:06 AM, Michael Paquier wrote:
> Yes, the existing assertion is right. My point is that it is strange
> that we do not check the values of freeze parameters for an ANALYZE
> query, which should be set to -1 all the time. If this is thought as
> not worth checking, I'll dro
On Wed, Feb 18, 2015 at 12:09 AM, Robert Haas wrote:
> On Thu, Feb 12, 2015 at 11:54 PM, Michael Paquier
> wrote:
>> Hi all,
>>
>> When calling vacuum(), there is the following assertion using VACOPT_FREEZE:
>> Assert((vacstmt->options & VACOPT_VACUUM) ||
>> !(vacstmt->options & (VACOPT_FULL
On Thu, Feb 12, 2015 at 11:54 PM, Michael Paquier
wrote:
> Hi all,
>
> When calling vacuum(), there is the following assertion using VACOPT_FREEZE:
> Assert((vacstmt->options & VACOPT_VACUUM) ||
> !(vacstmt->options & (VACOPT_FULL | VACOPT_FREEZE)));
> I think that this should be changed with
On Sat, Feb 14, 2015 at 8:10 AM, Jim Nasby wrote:
>
> On 2/12/15 10:54 PM, Michael Paquier wrote:
>>
>> Hi all,
>>
>> When calling vacuum(), there is the following assertion using VACOPT_FREEZE:
>> Assert((vacstmt->options & VACOPT_VACUUM) ||
>> !(vacstmt->options & (VACOPT_FULL | VACOPT_FREEZ
On 2/12/15 10:54 PM, Michael Paquier wrote:
Hi all,
When calling vacuum(), there is the following assertion using VACOPT_FREEZE:
Assert((vacstmt->options & VACOPT_VACUUM) ||
!(vacstmt->options & (VACOPT_FULL | VACOPT_FREEZE)));
I think that this should be changed with sanity checks based on
Hi all,
When calling vacuum(), there is the following assertion using VACOPT_FREEZE:
Assert((vacstmt->options & VACOPT_VACUUM) ||
!(vacstmt->options & (VACOPT_FULL | VACOPT_FREEZE)));
I think that this should be changed with sanity checks based on the
parameter values of freeze_* in VacuumStmt
31 matches
Mail list logo
