Re: [PATCHES] pg_autovacuum patches
Bruce Momjian wrote: > Neil Conway wrote: > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > I am going to try to fill the queue tonight and apply it Monday. I > > > leave for Japan on Tuesday. > > > > Applying a load of patches and then promptly fleeing the country > > doesn't sound so wise -- it sounds mighty suspicious, in fact :-) > > > > (At the same time, I can certainly testify that a 3-month long patch > > queue makes life more difficult for people like myself. Is there > > anything that others could do to reduce the patch application > > workload? I'd be willing to volunteer...) > > Not sure. We can get others to apply them if they want, but I still > have to make sure everything is getting dealt with, unless someone wants > to do that too. Actually, most of the delay was from saving stuff until we branched CVS, but we did that about a month ago, so the month delay was mostly that I didn't want to start throwing patch discussions into the mailing lists while we were dealing with final release issue. The last two week delay was just that I was too busy. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] pg_autovacuum patches
Neil Conway wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > I am going to try to fill the queue tonight and apply it Monday. I > > leave for Japan on Tuesday. > > Applying a load of patches and then promptly fleeing the country > doesn't sound so wise -- it sounds mighty suspicious, in fact :-) > > (At the same time, I can certainly testify that a 3-month long patch > queue makes life more difficult for people like myself. Is there > anything that others could do to reduce the patch application > workload? I'd be willing to volunteer...) Not sure. We can get others to apply them if they want, but I still have to make sure everything is getting dealt with, unless someone wants to do that too. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] pg_autovacuum patches
Bruce Momjian <[EMAIL PROTECTED]> writes: > I am going to try to fill the queue tonight and apply it Monday. I > leave for Japan on Tuesday. Applying a load of patches and then promptly fleeing the country doesn't sound so wise -- it sounds mighty suspicious, in fact :-) (At the same time, I can certainly testify that a 3-month long patch queue makes life more difficult for people like myself. Is there anything that others could do to reduce the patch application workload? I'd be willing to volunteer...) -Neil ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] pg_autovacuum patches
Tom Lane wrote: > "Matthew T. O'Connor" <[EMAIL PROTECTED]> writes: > > I noticed that there have been a few patched submitted for pg_autovacuum > > that have not been applied, so I applied them locally and tested them on > > my Fedora box. I am resubmitting them as one single patch. > > Bruce seems to be vastly behind on tracking the patch queue. Not sure > why. But resubmitting existing patches in new combinations isn't gonna > make his life easier when he does start to catch up ... Yep. I am completing my Japan speech today. I thought I would finish earlier this week, but the xfig diagrams take more time than I thought. I am going to try to fill the queue tonight and apply it Monday. I leave for Japan on Tuesday. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] pg_autovacuum patches
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes: > I noticed that there have been a few patched submitted for pg_autovacuum > that have not been applied, so I applied them locally and tested them on > my Fedora box. I am resubmitting them as one single patch. Bruce seems to be vastly behind on tracking the patch queue. Not sure why. But resubmitting existing patches in new combinations isn't gonna make his life easier when he does start to catch up ... regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] pg_autovacuum patches
One more time... The last patch didn't have the unitialized variables
stuff in it. Please disregard the previous patch and apply this one.
On Sat, 2003-11-29 at 00:34, Matthew T. O'Connor wrote:
> ARRRGGHH ok, with patch this time...
>
> On Sat, 2003-11-29 at 00:17, Matthew T. O'Connor wrote:
> > Hello,
> >
> > I noticed that there have been a few patched submitted for pg_autovacuum
> > that have not been applied, so I applied them locally and tested them on
> > my Fedora box. I am resubmitting them as one single patch.
> >
> > Included in the attached patch:
> >
> > Brian Hurt's patch that fixed the truncate bug by referencing a table
> > oid rather than it's relfilenode.
> >
> > Craig Boston's patch that fixes crashes on FreeBSD related to
> > uninitialized variables.
> >
> > A quick patch by me to remove a log_entry call inside init_table_info()
> > that was used for debugging by me during development and I left in by
> > mistake.
> >
> > Please apply this patch to both HEAD and 7.4.
> >
> > Thanks much,
> >
> > Matthew O'Connor
> >
> >
> >
> > ---(end of broadcast)---
> > TIP 5: Have you checked our extensive FAQ?
> >
> >http://www.postgresql.org/docs/faqs/FAQ.html
> >
>
> __
> ---(end of broadcast)---
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
*** ./pg_autovacuum.c.orig 2003-11-28 23:27:46.0 -0500
--- ./pg_autovacuum.c 2003-11-28 23:27:21.0 -0500
***
*** 116,126
atol(PQgetvalue(res, row, PQfnumber(res, "n_tup_upd";
new_tbl->curr_vacuum_count = new_tbl->CountAtLastVacuum;
! new_tbl->relfilenode = atoi(PQgetvalue(res, row, PQfnumber(res, "relfilenode")));
new_tbl->reltuples = atoi(PQgetvalue(res, row, PQfnumber(res, "reltuples")));
new_tbl->relpages = atoi(PQgetvalue(res, row, PQfnumber(res, "relpages")));
- log_entry(PQgetvalue(res, row, PQfnumber(res, "relisshared")));
if (strcmp("t", PQgetvalue(res, row, PQfnumber(res, "relisshared"
new_tbl->relisshared = 0;
else
--- 116,125
atol(PQgetvalue(res, row, PQfnumber(res, "n_tup_upd";
new_tbl->curr_vacuum_count = new_tbl->CountAtLastVacuum;
! new_tbl->relid = atoi(PQgetvalue(res, row, PQfnumber(res, "oid")));
new_tbl->reltuples = atoi(PQgetvalue(res, row, PQfnumber(res, "reltuples")));
new_tbl->relpages = atoi(PQgetvalue(res, row, PQfnumber(res, "relpages")));
if (strcmp("t", PQgetvalue(res, row, PQfnumber(res, "relisshared"
new_tbl->relisshared = 0;
else
***
*** 154,160
if (dbi->conn != NULL)
{
! snprintf(query, sizeof(query), PAGES_QUERY, tbl->relfilenode);
res = send_query(query, dbi);
if (res != NULL)
{
--- 153,159
if (dbi->conn != NULL)
{
! snprintf(query, sizeof(query), PAGES_QUERY, tbl->relid);
res = send_query(query, dbi);
if (res != NULL)
{
***
*** 237,243
for (i = 0; i < t; i++)
{ /* loop through result set looking for a
* match */
! if (tbl->relfilenode == atoi(PQgetvalue(res, i, PQfnumber(res, "relfilenode"
{
found_match = 1;
break;
--- 236,242
for (i = 0; i < t; i++)
{ /* loop through result set looking for a
* match */
! if (tbl->relid == atoi(PQgetvalue(res, i, PQfnumber(res, "oid"
{
found_match = 1;
break;
***
*** 267,273
while (tbl_elem != NULL)
{
tbl = ((tbl_info *) DLE_VAL(tbl_elem));
! if (tbl->relfilenode == atoi(PQgetvalue(res, i, PQfnumber(res, "relfilenode"
{
found_match = 1;
break;
--- 266,272
while (tbl_elem != NULL)
{
tbl = ((tbl_info *) DLE_VAL(tbl_elem));
! if (tbl->relid == atoi(PQgetvalue(res, i, PQfnumber(res, "oid"
{
found_match = 1;
break;
***
*** 361,367
{
sprintf(logbuffer, " table name: %s.%s", tbl->dbi->dbname, tbl->table_name);
log_entry(logbuffer);
! sprintf(logbuffer, " relfilenode: %i; relisshared: %i", tbl->relfilenode, tbl->relisshared);
log_entry(logbuffer);
sprintf(logbuffer, " reltuples: %i; relpages: %i", tbl->reltuples, tbl->relpages);
log_entry(logbuffer);
--- 360,366
{
sprintf(logbuffer, " table name: %s.%s", tbl->dbi->dbname, tbl->table_name);
log_entry(logbuffer);
! sprintf(logbuffer, " relid: %i; relisshared: %i", tbl->relid, tbl->relisshared);
log_entry(logbuffer);
sprintf(logbuffer, " reltuples: %i; relpages: %i", tbl->reltuples, tbl->relpages);
log_entry(logbuffer);
***
*** 811,816
--- 810,820
args->analyze_scaling_factor = -1;
args->debug = AUTOVACUUM_DEBUG;
args->daemoniz
Re: [PATCHES] pg_autovacuum patches
ARRRGGHH ok, with patch this time...
On Sat, 2003-11-29 at 00:17, Matthew T. O'Connor wrote:
> Hello,
>
> I noticed that there have been a few patched submitted for pg_autovacuum
> that have not been applied, so I applied them locally and tested them on
> my Fedora box. I am resubmitting them as one single patch.
>
> Included in the attached patch:
>
> Brian Hurt's patch that fixed the truncate bug by referencing a table
> oid rather than it's relfilenode.
>
> Craig Boston's patch that fixes crashes on FreeBSD related to
> uninitialized variables.
>
> A quick patch by me to remove a log_entry call inside init_table_info()
> that was used for debugging by me during development and I left in by
> mistake.
>
> Please apply this patch to both HEAD and 7.4.
>
> Thanks much,
>
> Matthew O'Connor
>
>
>
> ---(end of broadcast)---
> TIP 5: Have you checked our extensive FAQ?
>
>http://www.postgresql.org/docs/faqs/FAQ.html
>
*** ./pg_autovacuum.c.orig 2003-11-29 00:03:54.0 -0500
--- ./pg_autovacuum.c 2003-11-29 00:04:36.0 -0500
***
*** 116,126
atol(PQgetvalue(res, row, PQfnumber(res, "n_tup_upd";
new_tbl->curr_vacuum_count = new_tbl->CountAtLastVacuum;
! new_tbl->relfilenode = atoi(PQgetvalue(res, row, PQfnumber(res, "relfilenode")));
new_tbl->reltuples = atoi(PQgetvalue(res, row, PQfnumber(res, "reltuples")));
new_tbl->relpages = atoi(PQgetvalue(res, row, PQfnumber(res, "relpages")));
- log_entry(PQgetvalue(res, row, PQfnumber(res, "relisshared")));
if (strcmp("t", PQgetvalue(res, row, PQfnumber(res, "relisshared"
new_tbl->relisshared = 0;
else
--- 116,125
atol(PQgetvalue(res, row, PQfnumber(res, "n_tup_upd";
new_tbl->curr_vacuum_count = new_tbl->CountAtLastVacuum;
! new_tbl->relid = atoi(PQgetvalue(res, row, PQfnumber(res, "oid")));
new_tbl->reltuples = atoi(PQgetvalue(res, row, PQfnumber(res, "reltuples")));
new_tbl->relpages = atoi(PQgetvalue(res, row, PQfnumber(res, "relpages")));
if (strcmp("t", PQgetvalue(res, row, PQfnumber(res, "relisshared"
new_tbl->relisshared = 0;
else
***
*** 154,160
if (dbi->conn != NULL)
{
! snprintf(query, sizeof(query), PAGES_QUERY, tbl->relfilenode);
res = send_query(query, dbi);
if (res != NULL)
{
--- 153,159
if (dbi->conn != NULL)
{
! snprintf(query, sizeof(query), PAGES_QUERY, tbl->relid);
res = send_query(query, dbi);
if (res != NULL)
{
***
*** 237,243
for (i = 0; i < t; i++)
{ /* loop through result set looking for a
* match */
! if (tbl->relfilenode == atoi(PQgetvalue(res, i, PQfnumber(res, "relfilenode"
{
found_match = 1;
break;
--- 236,242
for (i = 0; i < t; i++)
{ /* loop through result set looking for a
* match */
! if (tbl->relid == atoi(PQgetvalue(res, i, PQfnumber(res, "oid"
{
found_match = 1;
break;
***
*** 267,273
while (tbl_elem != NULL)
{
tbl = ((tbl_info *) DLE_VAL(tbl_elem));
! if (tbl->relfilenode == atoi(PQgetvalue(res, i, PQfnumber(res, "relfilenode"
{
found_match = 1;
break;
--- 266,272
while (tbl_elem != NULL)
{
tbl = ((tbl_info *) DLE_VAL(tbl_elem));
! if (tbl->relid == atoi(PQgetvalue(res, i, PQfnumber(res, "oid"
{
found_match = 1;
break;
***
*** 361,367
{
sprintf(logbuffer, " table name: %s.%s", tbl->dbi->dbname, tbl->table_name);
log_entry(logbuffer);
! sprintf(logbuffer, " relfilenode: %i; relisshared: %i", tbl->relfilenode, tbl->relisshared);
log_entry(logbuffer);
sprintf(logbuffer, " reltuples: %i; relpages: %i", tbl->reltuples, tbl->relpages);
log_entry(logbuffer);
--- 360,366
{
sprintf(logbuffer, " table name: %s.%s", tbl->dbi->dbname, tbl->table_name);
log_entry(logbuffer);
! sprintf(logbuffer, " relid: %i; relisshared: %i", tbl->relid, tbl->relisshared);
log_entry(logbuffer);
sprintf(logbuffer, " reltuples: %i; relpages: %i", tbl->reltuples, tbl->relpages);
log_entry(logbuffer);
***
*** 1072,1078
{ /* Loop through tables in list */
tbl = ((tbl_info *) DLE_VAL(tbl_elem)); /* set tbl_info =
* current_table */
! if (tbl->relfilenode == atoi(PQgetvalue(res, j, PQfnumber(res, "relfilenode"
{
tbl->curr_analyze_count =
(atol(PQgetvalue(res, j, PQfnumber(res, "n_tup_ins"))) +
--- 1071,1077
{ /* Loop through tables in list */
tbl = ((tbl_info *) DLE_VAL(tbl_elem)); /* set tbl_info =
* current_table */
! if (tbl->relid == atoi(PQgetvalue(res, j, PQfnumber(res, "oid"
{
tbl->curr_analyze_count =
[PATCHES] pg_autovacuum patches
Hello, I noticed that there have been a few patched submitted for pg_autovacuum that have not been applied, so I applied them locally and tested them on my Fedora box. I am resubmitting them as one single patch. Included in the attached patch: Brian Hurt's patch that fixed the truncate bug by referencing a table oid rather than it's relfilenode. Craig Boston's patch that fixes crashes on FreeBSD related to uninitialized variables. A quick patch by me to remove a log_entry call inside init_table_info() that was used for debugging by me during development and I left in by mistake. Please apply this patch to both HEAD and 7.4. Thanks much, Matthew O'Connor ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
