Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

On 5/11/17, 6:32 PM, "Tom Lane" wrote: > You probably won't get much in the near term, because we're in > stabilize-the-release mode not develop-new-features mode. > Please add your patch to the pending commitfest > https://commitfest.postgresql.org/14/ > so that we remember

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

On 5/11/17, 7:20 PM, "Michael Paquier" wrote: > Browsing the code Thanks for taking a look. > It seems to me that you don't need those extra square brackets around > the column list. Same remark for vacuum.sgml. I’ll remove them. My intent was to ensure that we

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

On 5/10/17, 8:10 PM, "Masahiko Sawada" wrote: > I agree to report per-table information. Especially In case of one of > tables specified failed during vacuuming, I think we should report at > least information of tables that is done successfully so far. +1 I believe you

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

On 5/16/17, 11:21 PM, "Michael Paquier" <michael.paqu...@gmail.com> wrote: > On Wed, May 17, 2017 at 7:56 AM, Bossart, Nathan <bossa...@amazon.com> wrote: >> I think this issue already exists, as this comment in get_rel_oids(…) seems >> to indicate: >&

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

Great, I’ll keep working on this patch and will update this thread with a more complete implementation. Nathan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

On 5/18/17, 8:03 PM, "Tom Lane" <t...@sss.pgh.pa.us> wrote: >”Bossart, Nathan" <bossa...@amazon.com> writes: >> On 5/18/17, 6:12 PM, "Michael Paquier" <michael.paqu...@gmail.com> wrote: >>> Fine for me as well. I would suggest to split t

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

On 5/18/17, 6:12 PM, "Michael Paquier" wrote: > Fine for me as well. I would suggest to split the patch into two parts > to ease review then: > - Rework this error handling for one relation. > - The main patch. I’d be happy to do so, but I think part one would be

Re: [HACKERS] Support to COMMENT ON DATABASE CURRENT_DATABASE

A few general comments. While this patch applies, I am still seeing some whitespace errors: comment_on_current_database_no_pgdump_v4.1.patch:488: trailing whitespace. ColId comment_on_current_database_no_pgdump_v4.1.patch:490: trailing whitespace.

Re: [HACKERS] Rethinking autovacuum.c memory handling

On 9/23/17, 5:27 AM, "Michael Paquier" wrote: >On Sat, Sep 23, 2017 at 6:09 AM, Tom Lane wrote: >> I notice that autovacuum.c calls autovacuum_do_vac_analyze, and >> thereby vacuum(), in TopTransactionContext. This doesn't seem >> like a terribly

Re: [HACKERS] Rethinking autovacuum.c memory handling

On 9/23/17, 12:36 PM, "Tom Lane" <t...@sss.pgh.pa.us> wrote: >"Bossart, Nathan" <bossa...@amazon.com> writes: >> This looks reasonable to me as well. I haven't noticed any issues after >> a couple hours of pgbench with aggressive autovacuum setting

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

On 9/20/17, 2:29 PM, "Tom Lane" wrote: > I started to look at this... Thanks for taking a look. > I think that the way this ought to work is you process the VacuumRelation > structs purely sequentially, each in its own transaction, so you don't > need leaps of faith about

Re: [HACKERS] Additional logging for VACUUM and ANALYZE

On 10/5/17, 12:29 AM, "Michael Paquier" <michael.paqu...@gmail.com> wrote: > On Thu, Oct 5, 2017 at 1:23 AM, Bossart, Nathan <bossa...@amazon.com> wrote: >> Presently, there are a few edge cases in vacuum_rel() and analyze_rel() that >> I >

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

On 8/30/17, 5:37 PM, "Michael Paquier" wrote: > Yeah... Each approach has its cost and its advantages. It may be > better to wait for more opinions, no many people have complained yet > that for example a list of columns using twice the same one fails. Sounds good to

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

On 9/4/17, 8:16 PM, "Michael Paquier" wrote: > So vacuum_multiple_tables_v14.patch is good for a committer in my > opinion. With this patch, if the same relation is specified multiple > times, then it gets vacuum'ed that many times. Using the same column > multi-times

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

On 9/4/17, 10:32 PM, "Simon Riggs" wrote: > ISTM there is no difference between > VACUUM a, b > and > VACUUM a; VACUUM b; > > If we want to keep the code simple we must surely consider whether the > patch has any utility. Yes, this is true, but I think the convenience

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

On 9/9/17, 7:28 AM, "Michael Paquier" wrote: > In the duplicate patch, it seems to me that you can save one lookup at > the list of VacuumRelation items by checking for column duplicates > after checking that all the columns are defined. If you put the > duplicate check

Re: [HACKERS] Shaky coding for vacuuming partitioned relations

On 9/25/17, 6:51 PM, "Michael Paquier" wrote: >> +* Take a lock here for the relation lookup. If ANALYZE or >> VACUUM spawn >> +* multiple transactions, the lock taken here will be gone >> once the >> +* current

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

On 9/25/17, 12:42 AM, "Michael Paquier" wrote: > + if (!IsAutoVacuumWorkerProcess()) > + ereport(WARNING, > + (errmsg("skipping \"%s\" --- relation no longer exists", > + relation->relname))); > I like the use of

Re: [HACKERS] Enhancements to passwordcheck

On 9/25/17, 8:31 PM, "Michael Paquier" wrote: > Yes, I have developped a couple of years back a fork of passwordcheck > which had much similar enhancements, so getting something more modular > in upstream would be really welcome. Awesome. > On top of that I think that

Re: [HACKERS] Enhancements to passwordcheck

On 9/26/17, 2:38 AM, "Albe Laurenz" wrote: > Nathan Bossart wrote: passwordcheck.force_new_password >>> Does it mean a password different from the old one? +1. It could be >>> different from the last 3 passwords but we don't store a password >>> history.

Re: [HACKERS] Use of RangeVar for partitioned tables in autovacuum

On 9/26/17, 9:28 PM, "Michael Paquier" wrote: > In conclusion, I think that the open item of $subject should be > removed from the list, and we should try to get the multi-VACUUM patch > in to cover any future problems. I'll do so if there are no > objections. If

Re: [HACKERS] Shaky coding for vacuuming partitioned relations

On 9/29/17, 11:18 AM, "Robert Haas" wrote: > I don't think I understand problem #2. I think the concern is about > reporting the proper relation name when VACUUM cascades from a > partitioned table to its children and then some kind of concurrent DDL > happens, but I don't

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

On 9/28/17, 8:46 PM, "Michael Paquier" <michael.paqu...@gmail.com> wrote: > On Fri, Sep 29, 2017 at 10:44 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Michael Paquier <michael.paqu...@gmail.com> writes: >>> On Fri, Sep 29, 2017 at 2:44 AM, Bo

Re: [HACKERS] Shaky coding for vacuuming partitioned relations

On 9/24/17, 10:12 PM, "Michael Paquier" wrote: > Attached is a proposal of patch. The patch seems reasonable to me, and I haven't encountered any issues in my tests, even after applying the vacuum-multiple-relations patch on top of it. +* Take a lock

[HACKERS] Enhancements to passwordcheck

Hi hackers, Currently, the passwordcheck module provides a few basic checks to strengthen passwords. However, any configuration must be ready at compile time, and many common password requirements cannot be enforced without creating a custom version of this module. I think there are a number of

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

On 8/23/17, 11:59 PM, "Michael Paquier" wrote: > Robert, Amit and other folks working on extending the existing > partitioning facility would be in better position to answer that, but > I would think that we should have something as flexible as possible, > and storing a

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

On 9/3/17, 11:46 PM, "Michael Paquier" wrote: > I did not consider first that the list portion also needed to be > modified, perhaps because I am not coding that myself... So now that > it is becoming more complicated what about just using AutovacMemCxt? > This would

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

On 10/3/17, 5:59 PM, "Tom Lane" wrote: > I thought it would be a good idea to get this done before walking away > from the commitfest and letting all this info get swapped out of my > head. So I've reviewed and pushed this. Thanks! > I took out most of the infrastructure

Re: [HACKERS] Enhancements to passwordcheck

On 9/27/17, 7:41 AM, "Peter Eisentraut" <peter.eisentr...@2ndquadrant.com> wrote: > On 9/25/17 23:10, Bossart, Nathan wrote: >> One interesting design challenge will be how to handle pre-hashed >> passwords, since the number of checks we can do on those is pr

[HACKERS] pg_upgrade to clusters with a different WAL segment size

Hi hackers, The thread for the recent change to allow setting the WAL segment size at initdb time [0] included a bit of discussion regarding pg_upgrade [1], where it was suggested that relaxing an error check (presumably in check_control_data()) might be enough to upgrade servers to a different

Re: [HACKERS] Enhancements to passwordcheck

On 11/1/17, 9:33 PM, "Peter Eisentraut" <peter.eisentr...@2ndquadrant.com> wrote: > On 9/25/17 14:04, Bossart, Nathan wrote: >> I'd like to use this thread to gauge community interest in adding this >> functionality to this module. If there is interest, I'll a

Re: [HACKERS] Support to COMMENT ON DATABASE CURRENT_DATABASE

On 10/5/17, 11:53 PM, "Jing Wang" wrote: > The patch has been updated according to Nathan's comments.  > Thanks Nathan's review. Thanks for the new versions of the patches. I apologize for the long delay for this new review. It looks like the no-pgdump patch needs a