Re: [COMMITTERS] pgsql: Avoid having vacuum set reltuples to 0 on non-empty relations in
On Fri, Mar 17, 2017 at 10:00:17AM -0400, Tom Lane wrote: > Andrew Dunstan writes: > > On 03/17/2017 09:30 AM, Robert Haas wrote: > >> In the department of nitpicks, we usually try to write commit messages > >> so that the first line is a summary line which stands alone, and then > >> there's a blank line, and then more follows. a la > >> https://chris.beams.io/posts/git-commit/#separate > > > Yeah, In our case email subjects seem to be truncated at 64 chars, so > > it's best to stay under that limit if possible - 50 chars is sometimes > > pretty limiting. > > FWIW, I usually try to keep line length in commit messages to <= 75 > characters, as that is the wrap boundary in "git log" output. It's > nice if the summary line can be made shorter, but it's often damn > hard to cram an adequate summary into 75 chars, let alone fewer. > > (Links to mailing-list threads must ignore the length limit, sadly.) Here are the length limits I have found, and I display this in my email editor when I am creating a commit message: -- email subject limit - -- gitweb summary limit -- -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Avoid having vacuum set reltuples to 0 on non-empty relations in
Andrew Dunstan writes: > On 03/17/2017 09:30 AM, Robert Haas wrote: >> In the department of nitpicks, we usually try to write commit messages >> so that the first line is a summary line which stands alone, and then >> there's a blank line, and then more follows. a la >> https://chris.beams.io/posts/git-commit/#separate > Yeah, In our case email subjects seem to be truncated at 64 chars, so > it's best to stay under that limit if possible - 50 chars is sometimes > pretty limiting. FWIW, I usually try to keep line length in commit messages to <= 75 characters, as that is the wrap boundary in "git log" output. It's nice if the summary line can be made shorter, but it's often damn hard to cram an adequate summary into 75 chars, let alone fewer. (Links to mailing-list threads must ignore the length limit, sadly.) regards, tom lane -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Avoid having vacuum set reltuples to 0 on non-empty relations in
On 03/17/2017 09:30 AM, Robert Haas wrote: > > In the department of nitpicks, we usually try to write commit messages > so that the first line is a summary line which stands alone, and then > there's a blank line, and then more follows. a la > https://chris.beams.io/posts/git-commit/#separate > Yeah, In our case email subjects seem to be truncated at 64 chars, so it's best to stay under that limit if possible - 50 chars is sometimes pretty limiting. cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Avoid having vacuum set reltuples to 0 on non-empty relations in
On Thu, Mar 16, 2017 at 6:39 PM, Andrew Gierth wrote: > Avoid having vacuum set reltuples to 0 on non-empty relations in the > presence of page pins, which leads to serious estimation errors in the > planner. This particularly affects small heavily-accessed tables, > especially where locking (e.g. from FK constraints) forces frequent > vacuums for mxid cleanup. > > Fix by keeping separate track of pages whose live tuples were actually > counted vs. pages that were only scanned for freezing purposes. Thus, > reltuples can only be set to 0 if all pages of the relation were > actually counted. > > Backpatch to all supported versions. > > Per bug #14057 from Nicolas Baccelli, analyzed by me. > > Discussion: > https://postgr.es/m/20160331103739.8956.94...@wrigleys.postgresql.org In the department of nitpicks, we usually try to write commit messages so that the first line is a summary line which stands alone, and then there's a blank line, and then more follows. a la https://chris.beams.io/posts/git-commit/#separate -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Avoid having vacuum set reltuples to 0 on non-empty relations in
> "Andrew" == Andrew Gierth writes: Tom> I have not looked very closely, but I'm suspicious that the test Tom> case depends on no autovacuum transactions running concurrently Tom> with it. Disabling autovac on the table itself is not enough to Tom> control whether global xmin is being held back by some other Tom> autovac transaction somewhere. Andrew> Aren't vacuum transactions ignored for that? Andrew> vacuum_set_xid_limits is certainly passing ignoreVacuum=true to Andrew> GetOldestXmin. Answering my own question: vacuum transactions are ignored but analyze transactions aren't, and autovacuum will happily kick off an autoanalyze of pg_attribute during the test. Simplest fix seems to just be to remove the delete statement; I've verified that the problem can be reproduced without it, and that should make the result independent of OldestXmin. I'll commit that shortly unless I hear to the contrary. -- Andrew. -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Avoid having vacuum set reltuples to 0 on non-empty relations in
> "Tom" == Tom Lane writes: Tom> Hm, buildfarm results suggest this test is not entirely stable: I see it and will work on it. Tom> I have not looked very closely, but I'm suspicious that the test Tom> case depends on no autovacuum transactions running concurrently Tom> with it. Disabling autovac on the table itself is not enough to Tom> control whether global xmin is being held back by some other Tom> autovac transaction somewhere. Aren't vacuum transactions ignored for that? vacuum_set_xid_limits is certainly passing ignoreVacuum=true to GetOldestXmin. -- Andrew. -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Avoid having vacuum set reltuples to 0 on non-empty relations in
On 2017-03-16 23:37:06 -0400, Tom Lane wrote: > Andrew Gierth writes: > > Avoid having vacuum set reltuples to 0 on non-empty relations in the > > presence of page pins, which leads to serious estimation errors in the > > planner. > > Hm, buildfarm results suggest this test is not entirely stable: > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2017-03-17%2000%3A47%3A57 > > I have not looked very closely, but I'm suspicious that the test case > depends on no autovacuum transactions running concurrently with it. > Disabling autovac on the table itself is not enough to control whether > global xmin is being held back by some other autovac transaction > somewhere. Yea, brought it up on IRC too - he's gone for the night (Europe). I suspect changing things > might do the trick. - Andres -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Avoid having vacuum set reltuples to 0 on non-empty relations in
Andrew Gierth writes: > Avoid having vacuum set reltuples to 0 on non-empty relations in the > presence of page pins, which leads to serious estimation errors in the > planner. Hm, buildfarm results suggest this test is not entirely stable: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2017-03-17%2000%3A47%3A57 I have not looked very closely, but I'm suspicious that the test case depends on no autovacuum transactions running concurrently with it. Disabling autovac on the table itself is not enough to control whether global xmin is being held back by some other autovac transaction somewhere. regards, tom lane -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Avoid having vacuum set reltuples to 0 on non-empty relations in
On Thu, Mar 16, 2017 at 11:39 PM, Andrew Gierth wrote: > Avoid having vacuum set reltuples to 0 on non-empty relations in the > presence of page pins, which leads to serious estimation errors in the > planner. This particularly affects small heavily-accessed tables, > especially where locking (e.g. from FK constraints) forces frequent > vacuums for mxid cleanup. > > Fix by keeping separate track of pages whose live tuples were actually > counted vs. pages that were only scanned for freezing purposes. Thus, > reltuples can only be set to 0 if all pages of the relation were > actually counted. > > Backpatch to all supported versions. > > Per bug #14057 from Nicolas Baccelli, analyzed by me. > > Discussion: https://postgr.es/m/20160331103739.8956.94469@ > wrigleys.postgresql.org > Congrats on your first commit!
[COMMITTERS] pgsql: Avoid having vacuum set reltuples to 0 on non-empty relations in
Avoid having vacuum set reltuples to 0 on non-empty relations in the presence of page pins, which leads to serious estimation errors in the planner. This particularly affects small heavily-accessed tables, especially where locking (e.g. from FK constraints) forces frequent vacuums for mxid cleanup. Fix by keeping separate track of pages whose live tuples were actually counted vs. pages that were only scanned for freezing purposes. Thus, reltuples can only be set to 0 if all pages of the relation were actually counted. Backpatch to all supported versions. Per bug #14057 from Nicolas Baccelli, analyzed by me. Discussion: https://postgr.es/m/20160331103739.8956.94...@wrigleys.postgresql.org Branch -- REL9_4_STABLE Details --- http://git.postgresql.org/pg/commitdiff/269efd052922489cf91fd0bc5a80c2008f553b49 Modified Files -- src/backend/commands/vacuumlazy.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Avoid having vacuum set reltuples to 0 on non-empty relations in
Avoid having vacuum set reltuples to 0 on non-empty relations in the presence of page pins, which leads to serious estimation errors in the planner. This particularly affects small heavily-accessed tables, especially where locking (e.g. from FK constraints) forces frequent vacuums for mxid cleanup. Fix by keeping separate track of pages whose live tuples were actually counted vs. pages that were only scanned for freezing purposes. Thus, reltuples can only be set to 0 if all pages of the relation were actually counted. Backpatch to all supported versions. Per bug #14057 from Nicolas Baccelli, analyzed by me. Discussion: https://postgr.es/m/20160331103739.8956.94...@wrigleys.postgresql.org Branch -- REL9_3_STABLE Details --- http://git.postgresql.org/pg/commitdiff/8f8a5aefc73524658f989f3abd929afa5e7d3ff7 Modified Files -- src/backend/commands/vacuumlazy.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Avoid having vacuum set reltuples to 0 on non-empty relations in
Avoid having vacuum set reltuples to 0 on non-empty relations in the presence of page pins, which leads to serious estimation errors in the planner. This particularly affects small heavily-accessed tables, especially where locking (e.g. from FK constraints) forces frequent vacuums for mxid cleanup. Fix by keeping separate track of pages whose live tuples were actually counted vs. pages that were only scanned for freezing purposes. Thus, reltuples can only be set to 0 if all pages of the relation were actually counted. Backpatch to all supported versions. Per bug #14057 from Nicolas Baccelli, analyzed by me. Discussion: https://postgr.es/m/20160331103739.8956.94...@wrigleys.postgresql.org Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/9b626f6c334f95f1052b22b13d9ddbcc4de5fc4f Modified Files -- src/backend/commands/vacuumlazy.c| 15 -- src/test/isolation/expected/vacuum-reltuples.out | 62 src/test/isolation/isolation_schedule| 1 + src/test/isolation/specs/vacuum-reltuples.spec | 45 + 4 files changed, 119 insertions(+), 4 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Avoid having vacuum set reltuples to 0 on non-empty relations in
Avoid having vacuum set reltuples to 0 on non-empty relations in the presence of page pins, which leads to serious estimation errors in the planner. This particularly affects small heavily-accessed tables, especially where locking (e.g. from FK constraints) forces frequent vacuums for mxid cleanup. Fix by keeping separate track of pages whose live tuples were actually counted vs. pages that were only scanned for freezing purposes. Thus, reltuples can only be set to 0 if all pages of the relation were actually counted. Backpatch to all supported versions. Per bug #14057 from Nicolas Baccelli, analyzed by me. Discussion: https://postgr.es/m/20160331103739.8956.94...@wrigleys.postgresql.org Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/1914c5ea7dba4420f65c991256af5d4a9813 Modified Files -- src/backend/commands/vacuumlazy.c| 15 -- src/test/isolation/expected/vacuum-reltuples.out | 62 src/test/isolation/isolation_schedule| 1 + src/test/isolation/specs/vacuum-reltuples.spec | 45 + 4 files changed, 119 insertions(+), 4 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Avoid having vacuum set reltuples to 0 on non-empty relations in
Avoid having vacuum set reltuples to 0 on non-empty relations in the presence of page pins, which leads to serious estimation errors in the planner. This particularly affects small heavily-accessed tables, especially where locking (e.g. from FK constraints) forces frequent vacuums for mxid cleanup. Fix by keeping separate track of pages whose live tuples were actually counted vs. pages that were only scanned for freezing purposes. Thus, reltuples can only be set to 0 if all pages of the relation were actually counted. Backpatch to all supported versions. Per bug #14057 from Nicolas Baccelli, analyzed by me. Discussion: https://postgr.es/m/20160331103739.8956.94...@wrigleys.postgresql.org Branch -- REL9_2_STABLE Details --- http://git.postgresql.org/pg/commitdiff/a494ff4b012b5ce89b2549d5dab6b66604083bf0 Modified Files -- src/backend/commands/vacuumlazy.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Avoid having vacuum set reltuples to 0 on non-empty relations in
Avoid having vacuum set reltuples to 0 on non-empty relations in the presence of page pins, which leads to serious estimation errors in the planner. This particularly affects small heavily-accessed tables, especially where locking (e.g. from FK constraints) forces frequent vacuums for mxid cleanup. Fix by keeping separate track of pages whose live tuples were actually counted vs. pages that were only scanned for freezing purposes. Thus, reltuples can only be set to 0 if all pages of the relation were actually counted. Backpatch to all supported versions. Per bug #14057 from Nicolas Baccelli, analyzed by me. Discussion: https://postgr.es/m/20160331103739.8956.94...@wrigleys.postgresql.org Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/ee78ad5bc0d2b905fdfcee997c76e98292f65fbb Modified Files -- src/backend/commands/vacuumlazy.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
