There are a number of reasons why an invalid geometry could result in your database; for example, rings composed of polygons must be closed and cannot self-intersect or share more than one point with another ring.

After importing the country shapefile using the ST_IsValid and ST_IsValidReason functions, you will have figured out that four of the imported geometries are invalid, all because their polygons have self-intersecting rings.

At this point, a good way to investigate the invalid multipolygon geometry is by decomposing the polygon in to its component rings and checking out the invalid ones. For this purpose, we have exported the geometry of the ring causing the invalidity, using the ST_GeometryN function, which is able to extract the n^th ring from the polygon. We coupled this function with the useful PostgreSQL generate_series function to iterate all of the rings composing the geometry, selecting the desired one using the ST_Intersects function.

As expected, the reason why this ring generates the invalidity is that it is self-intersecting and produces a hole in the polygon. While this adheres to the shapefile specification, it doesn't adhere to the OGC specification.

By running the ST_MakeValid function, PostGIS has been able to make the geometry valid, generating a second ring. Remember that the ST_MakeValid function is available only with the latest PostGIS compiled with the latest GEOS (3.3.0+). If that is not the setup for your working box and you cannot upgrade (upgrading is always recommended!), you can follow the techniques used in the past and discussed in a very popular, excellent presentation by Paul Ramsey at http://blog.opengeo.org/2010/09/08/tips-for-the-postgis-power-user/.