Moving to -hackers
Does this still obey stats_command_string? I think it'd be very handy to
either have autovac always report what it's doing (ignoring
stats_command_string), or to provide it with it's own option for it. I
doubt this should pose a performance issue, since unless you have a
whole l
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> This seems to work for me. I'd appreciate input, as I'm not sure how
> would other archs (or even my own) cope with the zeroed client address
> trick (note the memcmp ...)
AFAICS that should work; I can't imagine all-zeroes being a valid client
address
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > The problem is that pgstat_bestart (called in InitPostgres, which
> > autovac calls) deliberately ignores autovacuum, due to not having a
> > client address. We could create a fake client address (which doesn't
> > seem easy to do),
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> The problem is that pgstat_bestart (called in InitPostgres, which
> autovac calls) deliberately ignores autovacuum, due to not having a
> client address. We could create a fake client address (which doesn't
> seem easy to do), or we could change pg_stat
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >>> Hmm, autovacuum won't show up in pg_stat_activity because it never
> >>> calls pgstat_report_activity(). Seems like maybe it should, though.
>
> > Yep. I'll fix it. Should I backpatch to 8.1?
>
> Yeah, proba
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>>> Hmm, autovacuum won't show up in pg_stat_activity because it never
>>> calls pgstat_report_activity(). Seems like maybe it should, though.
> Yep. I'll fix it. Should I backpatch to 8.1?
Yeah, probably, because this is really a re
Alvaro Herrera wrote:
> Larry Rosenman wrote:
> > Bruce Momjian wrote:
> > > Tom Lane wrote:
> > >> Casey Duncan <[EMAIL PROTECTED]> writes:
> > >>> however, when I did "select * from pg_stat_activity" on the pg
> > >>> server, it showed no connection to that db. Then I looked at the
> > >>> proces
Larry Rosenman wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Casey Duncan <[EMAIL PROTECTED]> writes:
> >>> however, when I did "select * from pg_stat_activity" on the pg
> >>> server, it showed no connection to that db. Then I looked at the
> >>> processes: tmp0% ps ax | grep test_seg1
>
Bruce Momjian wrote:
> Tom Lane wrote:
>> Casey Duncan <[EMAIL PROTECTED]> writes:
>>> however, when I did "select * from pg_stat_activity" on the pg
>>> server, it showed no connection to that db. Then I looked at the
>>> processes: tmp0% ps ax | grep test_seg1
>>> 10317 ?D 0:36 postg
Tom Lane wrote:
> Casey Duncan <[EMAIL PROTECTED]> writes:
> > however, when I did "select * from pg_stat_activity" on the pg
> > server, it showed no connection to that db. Then I looked at the
> > processes:
> > tmp0% ps ax | grep test_seg1
> > 10317 ?D 0:36 postgres: autovacuum
On May 17, 2006, at 12:34 PM, Tom Lane wrote:
Casey Duncan <[EMAIL PROTECTED]> writes:
however, when I did "select * from pg_stat_activity" on the pg
server, it showed no connection to that db. Then I looked at the
processes:
tmp0% ps ax | grep test_seg1
10317 ?D 0:36 postgres: aut
Casey Duncan <[EMAIL PROTECTED]> writes:
> however, when I did "select * from pg_stat_activity" on the pg
> server, it showed no connection to that db. Then I looked at the
> processes:
> tmp0% ps ax | grep test_seg1
> 10317 ?D 0:36 postgres: autovacuum process test_seg1
Hmm, au
12 matches
Mail list logo