From an sqlite based tracker, I did a roundup-admin export of this form

roundup-admin -i $tr_temp export $tracker

where $tr_temp contains a directory with minimal tracker context 
suitable for an export, and $tracker is the name of a tracker to be 
exported (for example 'helpdesk'). In case you didn't know, this creates 
the subdirectory $tracker and puts csv files there containing the 
database contents.

The corresponding roundup-admin import was to a postgres database, using 
a command of the form:

roundup-admin -i $tracker_dest import /tmp/$tracker

Prior to doing that I tar'ed the files created by the import, copied the 
tar file to another host and 'un'tar'ed that file to /tmp/$tracker. The 
$tracker_dest is the 'dest' field for the tracker in the site_config.ini 
file. Note that the tracker was already installed and set up for 
postgres as the back end database.

After doing the roundup-admin import, the problem I noticed is that when 
I create a new issue in the tracker, the issue ID skips a value. For 
example, if there were 3 issues, roundup-admin import will set lastval 
for the sequence _issue_ids to 4. When the nextval function is called it 
will return 5, so the IDs go 1, 2, 3, 5, skipping 4.

For the postgres backend, the setid function is being called, which 
executes the following where classname is 'issue' and setid is 4 
(maxid+1).

SELECT setval(_issue_ids, 4) FROM dual

What this should be is this

SELECT setval(_issue_ids, 4, false) FROM dual

This cause nextval to return 4, and the next time nextval is called it 
will continue incrementing to 5, etc.

After a cursory investigation of the MySQL back end code, it appears 
that a roundup-admin import will exhibit the same behavior with MySQL - 
skipping an ID.

I can provide a patch file for Postgres. I'm not sure how to write a 
test case for this, exhibiting the problem and the fix.

I don't know if this was the desired behavior. Maybe this is a 'feature' 
and not a bug.