The thread for the recent change to allow setting the WAL segment size at
initdb time  included a bit of discussion regarding pg_upgrade ,
where it was suggested that relaxing an error check (presumably in
check_control_data()) might be enough to upgrade servers to a different
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
On 11/1/17, 9:33 PM, "Peter Eisentraut" <peter.eisentr...@2ndquadrant.com>
> 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
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
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.
> I took out most of the infrastructure
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
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
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
On 9/27/17, 7:41 AM, "Peter Eisentraut" <peter.eisentr...@2ndquadrant.com>
> 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
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
On 9/26/17, 2:38 AM, "Albe Laurenz" wrote:
> Nathan Bossart wrote:
>>> 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
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.
> On top of that I think that
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
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
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
+* Take a lock
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
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
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
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.
comment_on_current_database_no_pgdump_v4.1.patch:490: trailing whitespace.
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
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
On 9/4/17, 10:32 PM, "Simon Riggs" wrote:
> ISTM there is no difference between
> VACUUM a, b
> 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
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
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
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
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
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
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:
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
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
> so that we remember
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.
I believe you
Great, I’ll keep working on this patch and will update this thread with a more
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription:
Mail list logo