Re: [BUGS] PD_ALL_VISIBLE flag error on 9.0 alpha 4
On 3/10/10 3:26 PM, Simon Riggs wrote: > OK, that's enough to not remove it. I was aware of more negative > thoughts and conscious of my own feelings about it being a kluge. Well, it *is* a kludge, but it may be the best one for people who want to use HS/SR to support web applications. So I think we should work on making it less kludgy. Ultimately we're going to need publish-XID-to-master, but that's not realistic for 9.0. --Josh Berkus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] PD_ALL_VISIBLE flag error on 9.0 alpha 4
On Wed, 2010-03-10 at 17:55 -0500, Tom Lane wrote: > Simon Riggs writes: > >>> Time to remove vacuum_defer_cleanup_age, I think. > >> > >> Umm, so what's the bug? > > > Whether you call it a bug or just an annoyance is debatable, but the > > source of it is clear. > > Maybe to you, but the rest of us would like to know. If vacuum_defer_cleanup_age is set higher this causes the xmin to go backwards, leading to the "PD_ALL_VISIBLE flag was incorrectly set" warning. Having this false xmin move backwards doesn't endanger the standby, since the xids arrive and are checked normally. If they stop arriving that is fine. Having the false xmin going backwards is not a serious issue on primary because the actual xmin does not go backwards. No observer loses information as a result of this, it is only about whether cleanup records are generated later than normal, or not. > > Given the lack of effectiveness, I propose > > removing it. > > I read Josh's recent report at > http://archives.postgresql.org/message-id/4b973c3f.9070...@agliodbs.com > to say that it's quite effective. I think you're being way too hasty to > decide that it can just be dropped. OK, that's enough to not remove it. I was aware of more negative thoughts and conscious of my own feelings about it being a kluge. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] PD_ALL_VISIBLE flag error on 9.0 alpha 4
Simon Riggs writes: >>> Time to remove vacuum_defer_cleanup_age, I think. >> >> Umm, so what's the bug? > Whether you call it a bug or just an annoyance is debatable, but the > source of it is clear. Maybe to you, but the rest of us would like to know. > Given the lack of effectiveness, I propose > removing it. I read Josh's recent report at http://archives.postgresql.org/message-id/4b973c3f.9070...@agliodbs.com to say that it's quite effective. I think you're being way too hasty to decide that it can just be dropped. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] PD_ALL_VISIBLE flag error on 9.0 alpha 4
On Wed, 2010-03-10 at 23:08 +0200, Heikki Linnakangas wrote: > > > > Time to remove vacuum_defer_cleanup_age, I think. > > Umm, so what's the bug? Whether you call it a bug or just an annoyance is debatable, but the source of it is clear. Given the lack of effectiveness, I propose removing it. Would you agree or disagree with the suggested removal? -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] PD_ALL_VISIBLE flag error on 9.0 alpha 4
Simon Riggs wrote: > On Tue, 2010-03-09 at 22:02 -0800, Josh Berkus wrote: > >> 1. Set up 9.0a4 doing SR replication with a 2nd 9.0a4 >> 2. Ran pgbench for a while. >> 3. Aborted pgbench with Ctl-C >> 4. Changed vacuum_defer_cleanup_age in postgresql.conf and reloaded >> 5. Ran pgbench again, and got: >> >> Sidney-Stratton:pg90 josh$ pgbench -c 2 -T 300 bench >> starting vacuum...WARNING: PD_ALL_VISIBLE flag was incorrectly set in >> relation "pgbench_branches" page 0 >> WARNING: PD_ALL_VISIBLE flag was incorrectly set in relation >> "pgbench_branches" page 1 >> WARNING: PD_ALL_VISIBLE flag was incorrectly set in relation >> "pgbench_tellers" page 0 >> WARNING: PD_ALL_VISIBLE flag was incorrectly set in relation >> "pgbench_tellers" page 1 > > Understandable. > > Time to remove vacuum_defer_cleanup_age, I think. Umm, so what's the bug? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] PD_ALL_VISIBLE flag error on 9.0 alpha 4
On Tue, 2010-03-09 at 22:02 -0800, Josh Berkus wrote: > 1. Set up 9.0a4 doing SR replication with a 2nd 9.0a4 > 2. Ran pgbench for a while. > 3. Aborted pgbench with Ctl-C > 4. Changed vacuum_defer_cleanup_age in postgresql.conf and reloaded > 5. Ran pgbench again, and got: > > Sidney-Stratton:pg90 josh$ pgbench -c 2 -T 300 bench > starting vacuum...WARNING: PD_ALL_VISIBLE flag was incorrectly set in > relation "pgbench_branches" page 0 > WARNING: PD_ALL_VISIBLE flag was incorrectly set in relation > "pgbench_branches" page 1 > WARNING: PD_ALL_VISIBLE flag was incorrectly set in relation > "pgbench_tellers" page 0 > WARNING: PD_ALL_VISIBLE flag was incorrectly set in relation > "pgbench_tellers" page 1 Understandable. Time to remove vacuum_defer_cleanup_age, I think. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Bug in triggers
On Wed, Mar 10, 2010 at 8:20 AM, Robert Haas wrote: > On Tue, Mar 9, 2010 at 11:02 AM, Tom Lane wrote: >> We may need to document it, but not like that; it's (a) incorrect and >> (b) unhelpful to the reader, who is left without any clear idea of what >> to avoid. I think that the real issue here doesn't have anything to do >> with NEW/OLD as such, but is related to the representational difference >> between record and row variables. > > I agree. That's precisely what I'm confused about. > - Show quoted text - On Wed, Mar 10, 2010 at 8:20 AM, Robert Haas wrote: > On Tue, Mar 9, 2010 at 11:02 AM, Tom Lane wrote: >> We may need to document it, but not like that; it's (a) incorrect and >> (b) unhelpful to the reader, who is left without any clear idea of what >> to avoid. I think that the real issue here doesn't have anything to do >> with NEW/OLD as such, but is related to the representational difference >> between record and row variables. > > I agree. That's precisely what I'm confused about. Additionally, plpgsql uses "record" seemingly to refer to row variables, so pointing folks to this conversation may not necessarily clear up confusion -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Bug in triggers
On Tue, Mar 9, 2010 at 11:02 AM, Tom Lane wrote: > We may need to document it, but not like that; it's (a) incorrect and > (b) unhelpful to the reader, who is left without any clear idea of what > to avoid. I think that the real issue here doesn't have anything to do > with NEW/OLD as such, but is related to the representational difference > between record and row variables. I agree. That's precisely what I'm confused about. ...Robert -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
