Fix a nasty data loss/corruption bug from the sql_pop query.

It is not safe to assume that we can bulk-delete all entries from the
log table based on their "id" being less than the largest "id" we have
processed so far, as we may unintentionally delete some tuples from the
log which we haven't actually processed yet in the case of concurrent
transactions adding tuples into the log table.

Found and fixed by Josh Kupershmidt in the pg_repack development.
I have confirmed that this bug also appears in pg_reorg.