Does READ COMMITTED always start over after serialization failures while SERIALIZABLE simply fails?

On the PostgreSQL Concurrency With MVCC page, it says:

know what you’re thinking though: what about a two transactions updating the same row at the same time? This is where transaction isolation levels come in. Postgres basically supports two models that allow you to control how this situation should be handled. The default, READ COMMITTED, reads the row after the inital transaction has completed and then executes the statement. It basically starts over if the row changed while it was waiting. For instance, if you issue an UPDATE with a WHERE clause, the WHERE clause will rerun after the initial transaction commits, and the UPDATE takes place if the WHERE clause is still satisfied.

The docs seem to suggest that READ COMMITTED is still subject to failures and should be retried.

Can READ COMMITTED be set to indefinitely retry with the same atomicity as SERIAZLIZABLE?