Forum OpenACS Q&A: Re: learn to debug an error

Collapse
4: Re: learn to debug an error (response to 1)
Posted by Yves Goldberg on 07/06/04 12:37 PM
ok Jeff,

I've edited the file category-synonyms-procs-postgresql.xql and changed in category_synonym::search_sweeper.delete_old_searches

from:

"where last_queried < current_timestamp - 1"

to:

"where last_queried < current_timestamp - '1 day'::INTERVAL"

I've restarted the server and find in the log what's below.

Does that mean I've corrected the former problem and this is a new one to debug or I made a mystake with the 'INTERVAL' syntax?

Thanks a lot for your help Jeff.

Yves.

==========================================
Errors since Tue Jul  6 01:38:52 2004

06/Jul/2004:05:23:03
    Error: Ns_PgExec: result status: 7 message: ERROR:  Function trunc(interval) does not exist
    Unable to identify a function that satisfies the given argument types
    You may need to add explicit typecasts

06/Jul/2004:05:23:04
    Error: Aborting transaction due to error:
Database operation "0or1row" failed (exception NSDB, "Query was not a statement returning rows.")

ERROR:  Function trunc(interval) does not exist
    Unable to identify a function that satisfies the given argument types
    You may need to add explicit typecasts

SQL:
        select trunc(current_timestamp - max(coalesce(modified_date, insertion_date))) from robots

=============================================

Collapse
5: Re: learn to debug an error (response to 4)
Posted by Jeff Davis on 07/06/04 01:04 PM
Yeah, that is a new (but somewhat related) bug; both of these are related to changes in postgres from 7.2 to 7.3 for timestamp handling and this package was never updated.

In this case, trunc on an interval used to return the number of days but that was removed in 7.3, now it should use date_part('days',...).

the other thing to do after you fix these is to submit a patch in bug tracker so everyone else can benefit from your bug fixing :)

There are some instructions for that here It's good if they are attached to a bug report but even if not submitting patches is the best way (short of committing directly) to make sure the fixes find their way into the release.