New VACUUM FULL
in [PgSql]
|
From: Josh Berkus on 4 Jan 2010 15:05 >> What I should have said, in addition: VFI will be kept as a non-default >> option, in case it is required. We will document that use of VFI will >> not work correctly with HS and that its use is deprecated and should be >> in emergencies only in any case. I will enjoy removing VFI when that >> eventually occurs, but its not a priority. (And if you think, why keep >> it? I'll say - how else can we run a VFI - not by a stored proc, >> certainly). Isn't there some way we can tell if a server is an HS master, and prevent VFI from being run? --Josh Berkus -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 4 Jan 2010 15:51 On Mon, 2010-01-04 at 12:05 -0800, Josh Berkus wrote: > >> What I should have said, in addition: VFI will be kept as a non-default > >> option, in case it is required. We will document that use of VFI will > >> not work correctly with HS and that its use is deprecated and should be > >> in emergencies only in any case. I will enjoy removing VFI when that > >> eventually occurs, but its not a priority. (And if you think, why keep > >> it? I'll say - how else can we run a VFI - not by a stored proc, > >> certainly). > > Isn't there some way we can tell if a server is an HS master, and > prevent VFI from being run? I'm proposing that VFI is only accessible by explicit request using new syntax; no existing code would call VFI. The VFI problems would only apply to system relations anyway, not to all tables. I propose we have a WARNING if VFI being run when recovery_connections = on, since I probably know what I'm doing if I go out of my way to use new syntax after presumably having read the manual. Just as a point of note, I'm worried that the act of removing VFI would introduce more bugs than leaving it alone; if its there we may as well keep it runnable. Changes required to remove it are at least these places * most of vacuum.c * visibility checks * heap tuple flags and xvac * nontransactional validation * minor points and follow up in >7 files, >12 places -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 4 Jan 2010 16:41 On Mon, Jan 4, 2010 at 3:51 PM, Simon Riggs <simon(a)2ndquadrant.com> wrote: > On Mon, 2010-01-04 at 12:05 -0800, Josh Berkus wrote: >> >> What I should have said, in addition: VFI will be kept as a non-default >> >> option, in case it is required. We will document that use of VFI will >> >> not work correctly with HS and that its use is deprecated and should be >> >> in emergencies only in any case. I will enjoy removing VFI when that >> >> eventually occurs, but its not a priority. (And if you think, why keep >> >> it? I'll say - how else can we run a VFI - not by a stored proc, >> >> certainly). >> >> Isn't there some way we can tell if a server is an HS master, and >> prevent VFI from being run? > > I'm proposing that VFI is only accessible by explicit request using new > syntax; no existing code would call VFI. > > The VFI problems would only apply to system relations anyway, not to all > tables. > > I propose we have a WARNING if VFI being run when recovery_connections = > on, since I probably know what I'm doing if I go out of my way to use > new syntax after presumably having read the manual. I think I'd vote for throwing an ERROR. By the time you see the WARNING it may be too late. Since this is only for emergencies, the user can shut off recovery_connections first if they really need it. > Just as a point of note, I'm worried that the act of removing VFI would > introduce more bugs than leaving it alone; if its there we may as well > keep it runnable. > > Changes required to remove it are at least these places > > * most of vacuum.c > * visibility checks > * heap tuple flags and xvac > * nontransactional validation > * minor points and follow up in >7 files, >12 places Doesn't sound trivial. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Josh Berkus on 4 Jan 2010 19:19 > I think I'd vote for throwing an ERROR. By the time you see the > WARNING it may be too late. Since this is only for emergencies, the > user can shut off recovery_connections first if they really need it. I'm with Robert on this one. If running VFI will cause unrecoverable failure on the slave, it should be prevented. If this is only an issue with system tables, then we only need to error on system tables. --Josh -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 4 Jan 2010 19:29
On Mon, 2010-01-04 at 16:41 -0500, Robert Haas wrote: > > I propose we have a WARNING if VFI being run when recovery_connections = > > on, since I probably know what I'm doing if I go out of my way to use > > new syntax after presumably having read the manual. > > I think I'd vote for throwing an ERROR. By the time you see the > WARNING it may be too late. Since this is only for emergencies, the > user can shut off recovery_connections first if they really need it. OK -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |