This was a combined patch including Matthew T. O'Connor's Patch.
Applied. Thanks.
---
Christopher Browne wrote:
> [EMAIL PROTECTED] ("Matthew T. O'Connor") writes:
> > OK, well as we wait on the fix for the stats system,
Patch applied as part of Christopher Browne's patch.
---
Matthew T. O'Connor wrote:
> On Fri, 2003-09-12 at 09:35, Bruce Momjian wrote:
> > Matthew T. O'Connor wrote:
> > > I made a patch to fix this, but in testing it I no
[EMAIL PROTECTED] ("Matthew T. O'Connor") writes:
> OK, well as we wait on the fix for the stats system, let me submit my
> patch for pg_autovacuum. This patch assumes that the stats system will
> be fixed so that all inserts, updates and deletes performed on shared
> tables reguardless of what da
[EMAIL PROTECTED] ("Matthew T. O'Connor") writes:
> So we would have a problem if commands that effect these tables are done
> from lots of different databases. In reality, I don't think these
> tables change that much (pg_database, pg_shadow, and pg_group), and most
> of commands that do effect t
On Fri, 2003-09-12 at 13:06, Tom Lane wrote:
> > I can hardwire in something to hedge this off like setting the threshold
> > for shared tables much much lower than normal thresholds. I could also
> > do something more complicated and try to aggregate all the activity seen
> > by all the databases
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> So we would have a problem if commands that effect these tables are done
> from lots of different databases. In reality, I don't think these
> tables change that much (pg_database, pg_shadow, and pg_group), and most
> of commands that do effect t
On Fri, 2003-09-12 at 12:46, Tom Lane wrote:
> How will it act with shared tables if the stats system isn't fixed?
> We may decide that tracking shared tables correctly will have to wait
> for 7.5.
The behavior in the patch will vacuum a shared table only from
template1, and only analyze from all
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> Even if this the stats system isn't fixed, this patch still is much
> better about monitoring system tables that aren't shared, so it's an
> improvement no matter what.
How will it act with shared tables if the stats system isn't fixed?
We may de
On Fri, 2003-09-12 at 09:35, Bruce Momjian wrote:
> Matthew T. O'Connor wrote:
> > I made a patch to fix this, but in testing it I noticed that the stats
> > system doesn't work on shared tables as I was expecting it too (as my
> > latest patch requires it too :-). It treats instances of shared tab
Tom Lane wrote:
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
I made a patch to fix this, but in testing it I noticed that the stats
system doesn't work on shared tables as I was expecting it too (as my
latest patch requires it too :-). It treats instances of shared tables
in separate databas
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> I made a patch to fix this, but in testing it I noticed that the stats
> system doesn't work on shared tables as I was expecting it too (as my
> latest patch requires it too :-). It treats instances of shared tables
> in separate databases as tota
Matthew T. O'Connor wrote:
> On Thu, 2003-09-11 at 18:25, Tom Lane wrote:
> > "Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> > > hrm OK. Patch forthcoming
> >
> > BTW, I am not sure it is a good idea to suppress "redundant" vacuuming
> > of shared tables in the first place. The trou
On Thu, 2003-09-11 at 18:25, Tom Lane wrote:
> "Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> > hrm OK. Patch forthcoming
>
> BTW, I am not sure it is a good idea to suppress "redundant" vacuuming
> of shared tables in the first place. The trouble with doing so is that
> if you only
On Thu, 2003-09-11 at 18:25, Tom Lane wrote:
> BTW, I am not sure it is a good idea to suppress "redundant" vacuuming
> of shared tables in the first place. The trouble with doing so is that
> if you only vacuum pg_shadow through template1, then only template1 will
> ever have up-to-date statistic
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> On Thu, 2003-09-11 at 17:11, Tom Lane wrote:
>> "Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
>>> I designed it that way. It was my understanding that all of the system
>>> tables pg_class etc... are shared tables, available in all databases,
On Thu, 2003-09-11 at 17:11, Tom Lane wrote:
> "Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> > I designed it that way. It was my understanding that all of the system
> > tables pg_class etc... are shared tables, available in all databases,
> > but actually stored as only one central set of r
[EMAIL PROTECTED] ("Matthew T. O'Connor") writes:
> On Thu, 2003-09-11 at 08:12, Christopher Browne wrote:
>> Something I am feeling a little suspicious of is that I haven't seen,
>> in the logs, pg_autovacuum looking at pg_ tables.
>>
>> I know that if we don't periodically vacuum such system t
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> On Thu, 2003-09-11 at 08:12, Christopher Browne wrote:
>> [Rummaging around...] These tables are being added for template1, but
>> apparently not for "main" databases. That looks like a bit of a fly
>> in the ointment...
> I designed it that wa
Matthew T. O'Connor wrote:
> On Thu, 2003-09-11 at 08:12, Christopher Browne wrote:
> > Something I am feeling a little suspicious of is that I haven't seen,
> > in the logs, pg_autovacuum looking at pg_ tables.
> >
> > I know that if we don't periodically vacuum such system tables as
> > pg_cla
On Thu, 2003-09-11 at 08:12, Christopher Browne wrote:
> Something I am feeling a little suspicious of is that I haven't seen,
> in the logs, pg_autovacuum looking at pg_ tables.
>
> I know that if we don't periodically vacuum such system tables as
> pg_class, pg_attribute, pg_statistic, and pg_
On Thu, 2003-09-11 at 15:02, Bruce Momjian wrote:
> Patch applied. You might want to look at pg_dump/dumputils.c::fmtId()
> for a function that does smart quoting.
OK, thanks.
---(end of broadcast)---
TIP 8: explain analyze is your friend
Patch applied. You might want to look at pg_dump/dumputils.c::fmtId()
for a function that does smart quoting.
---
Matthew T. O'Connor wrote:
> On Wed, 2003-09-10 at 15:57, Bruce Momjian wrote:
> > I assume the attached patc
At 12:03 AM 9/11/03 -0400, Matthew T. O'Connor wrote:
Adam, can you please give this a test as you are the person who caught
the bug in the first place.
Thanks,
Matthew T. O'Connor
I applied your patch and it works fine for me.
--- Adam Kavan
---(end of broadcast)---
[EMAIL PROTECTED] ("Matthew T. O'Connor") wrote:
> On Wed, 2003-09-10 at 15:57, Bruce Momjian wrote:
>> I assume the attached patch is what you want done to fix this. Applied.
>>
>> It quotes table names for vacuum and analyze, and uppercases the
>> keywords for clarity.
>
> Yeah, this is basical
On Wed, 2003-09-10 at 15:57, Bruce Momjian wrote:
> I assume the attached patch is what you want done to fix this. Applied.
>
> It quotes table names for vacuum and analyze, and uppercases the
> keywords for clarity.
Yeah, this is basically what I meant, sorry I didn't get to it quicker.
Howev
I assume the attached patch is what you want done to fix this. Applied.
It quotes table names for vacuum and analyze, and uppercases the
keywords for clarity.
---
Matthew T. O'Connor wrote:
> Ouch... sorry, my fault. I'll
On Thu, 2003-09-04 at 18:39, Adam Kavan wrote:
> Now that I have pg_autovacuum working I've bumped into another small
> bug. When pg_autovacuum goes to vacuum or analyze one of my tables it runs...
Also, has this been officially fixed? All I have heard so far is that
you commented out the check
Ouch... sorry, my fault. I'll fix this tomorrow (Friday) and submit a
patch, or if you want to submit a patch that would be fine. All you
have to do is change the the sql statements to put quotes around the
relation name.
Thanks for catching this.
Matthew T. O'Connor
On Thu, 2003-09-04 at 18:
Now that I have pg_autovacuum working I've bumped into another small
bug. When pg_autovacuum goes to vacuum or analyze one of my tables it runs...
analyze public.ConfigBackup
Because ConfigBackup is mixed case it cannot find the relation. I fixed
this by going to the function init_table_info
29 matches
Mail list logo
