[Bacula-users] db_find_next_volume tweak, inChanger flag issue

[JML <jm...@le...>]

Greetings,

I'm playing with 1.33-30Jan04 + PostgreSQL and have noticed a couple
issues with changer slots and future tape selection.

For starters, db_find_next_volume() orders its search results using "ORDER
BY LastWritten ASC,MediaId", which (in PostgreSQL at least) lists first
those volumes with LastWritten set to null. So rather than choosing an
appendable tape, the scheduler prefers any remaining blank ones. Changing
the query to use "ORDER BY LastWritten is NULL, LastWritten DESC,MediaId"
does force appendable volumes to the top, but I doubt that this syntax is
portable to the other SQL dialects.

On a similar note, if I purge a tape or if the changer loads and labels
one, the inChanger flag gets reset to 0 and disqualifies the tape for
subsequent jobs. "update slots scan" doesn't seem to correct this, but
thanks to Pascal's patch, manual updates work. :)

best regards,

Jason