Recursive query to figure out record which creates circular dependency

Displaying as much as possible until reaching the loop

Instead of identifying the loops in a separate task,
you can get a failsafe walkthrough by remembering the path to reach each item, and stopping when you encounter an already seen employee.

PostgreSQL's array is the right structure to hold it:

WITH recursive tmp AS ( -- We're starting from the top, so no need of supervisor_id anymore: SELECT emp_id, array[emp_id] path -- ← Here init our path. FROM incoming_records WHERE supervisor_id IS NULL UNION ALL SELECT t.emp_id, path||t.emp_id -- ← Here append the current employee. FROM tmp INNER JOIN incoming_records AS t ON t.supervisor_id = tmp.emp_id WHERE t.supervisor_id = tmp.emp_id AND NOT t.emp_id = ANY(path) -- ← Here ensure the new employee is not a supervisor (already in the path) of this one. ) select * from tmp; 

(see it running in a fiddle)

A 2-steps job (first identifying the loops, then computing the tree when there is no more loop) would anyway require computing the path during the recursive CTE,
but would:

• block your tool until you manually delete one of the culprits
• hamper your diagnosis (if you start from the bottom as you tried, you will not be able to go up to the top and see where in the hierarchy your two candidates would approximately be)

With culprit display

You can even display the looping entry while tagging instead of filtering out (… and then on next iteration, stop the tagged entry of course):

WITH recursive tmp AS ( SELECT emp_id, array[emp_id] path, FALSE looping FROM incoming_records WHERE supervisor_id IS NULL UNION ALL SELECT t.emp_id, path||t.emp_id, t.emp_id = ANY(path) -- ← If detecting a loop, SELECT but tag. FROM tmp INNER JOIN incoming_records AS t ON t.supervisor_id = tmp.emp_id WHERE t.supervisor_id = tmp.emp_id AND NOT looping -- ← If last iteration was tagged, do not look for its subordinates anymore. ) select * from tmp; 

Then you can use it both in your production query (where you will filter out with a WHERE NOT looping to keep only one rt08) and in your manual diagnosing one.

Limits

Duplicates

Note that there still may be duplicates if you have two ways to enter the loop.

For example if both 8 and 9 are under 7, and one under another,
you'll get 9 both as 7 > 9 and 7 > 8 > 9 (which is not a loop, as 9 still isn't in the path; there will be a loop on next iteration, with 7 > 8 > 9 > 8).

But this isn't specific to loops, here it is a problem of graph.

You can prevent this by a choosing a DISTINCT ON (emp_id) ORDER BY ARRAY_LENGTH(path, 1) DESC (this elects the shortest path to the employee, but if 2 path lead to the same employee (for example if 3 > 5 and 4 > 5) one will be elected arbitrarily; and subordinates of this uncertain one will not necessarily choose the same path, thus you may end with 3 > 5 for 5 but 4 > 5 > 6 for 6).

No point of entry

This top-to-bottom requires your looping elements to have multiple parents, with at least one reachable from a no-supervisored employee.
A pure loop will never appear in the results. (e.g.: if 8 > 9 and 9 > 8 loop together with no 7 > 8 to connect them to the rest of the world).

In this case you will not have other choice than having a separate "pure loop detector", as seen in my dedicated answer.

pgr_connectedComponents()

Compared to roll-your-own recursive CTEs, functions that come in pgrouting extension run faster, using less memory, thanks to years of Boost C++ development behind it.

On sample sets with a few thousand rows it runs a few times faster than all alternatives here and it's the only one applicable above that size. The recursive CTEs run out of memory, leak to disk, then run out of space in the lower thousands. Here's a test on 7.5k rows where it takes 143ms, while pgrouting finishes in 31ms.
If you increase the sample size above that, db<>fiddle runs out of resources necessary to keep the recursive CTE example alive.

On 50k samples, pgrouting example below finds 3899 rows from groups with loops in 170ms:
_{demo at db<>fiddle}

with trees as( select supervisor_id , emp_id , every(supervisor_id is not null)over w1 as has_cycle from pgr_connectedComponents( $x$ select row_number()over() as id , coalesce(emp_id,supervisor_id,1e7::int) as source , coalesce(supervisor_id,emp_id,1e7::int) as target , 1 as cost , 1 as reverse_cost from incoming_records $x$) as c(seq,subgraph,emp_id) join incoming_records using(emp_id) window w1 as (partition by subgraph) ) select supervisor_id , emp_id from trees where has_cycle; 

Note that this assumes you can't make an employee their own supervisor and that each employee can have at most one supervisor at a time. In this scenario, it's enough to establish the top, null-pointing supervisor is missing to determine a tree contains a loop.

Detecting pure loops

If you have pure loops in closed circuit (with no way to go up to a head of hierarchy with no supervisor),
my display as much as possible approach won't work, because it requires a head of hierarchy as entry point.

In that case you can still use PostgreSQL arrays to construct the bottom-to-top path for each employee,
and stop as soon as you encounter an already seen employee:

WITH recursive tmp AS ( SELECT supervisor_id, emp_id, array[]::text[] path -- ← Start with an empty path beyond each employee. FROM incoming_records UNION ALL SELECT t.supervisor_id, t.emp_id, tmp.emp_id||path -- ← Append the employee where we came from to the path. FROM tmp INNER JOIN incoming_records AS t ON tmp.supervisor_id = t.emp_id AND NOT tmp.emp_id = ANY(path) -- ← Do not continue for entries having appeared in their own path. ) select * from tmp where emp_id = ANY(path); -- ← And show only those, not the intermediates who succeeded into reaching a head of hierarchy without loop.