When I ran a test for PR #1613 , I discovered new PostgreSQL errors in my logs:

2017-08-15 14:15:22 CEST [4159-2] freshrss@freshrss DÉTAIL:  La clé « (id_feed, guid)=(67, http://www.geany.org/Main/20170717) » existe déjà.
2017-08-15 14:15:22 CEST [4159-3] freshrss@freshrss INSTRUCTION :  INSERT INTO "adrien_entrytmp" (id, guid, title, author, content, link, date, "lastSeen", hash, is_read, is_favorite, id_feed, tags) VALUES($1, $2, $3, $4, $5, $6, $7, $8, decode($9, 'hex'), $10, $11, $12, $13)
2017-08-15 14:15:22 CEST [4159-4] freshrss@freshrss ERREUR:  la transaction est annulée, les commandes sont ignorées jusqu'à la fin du bloc
	de la transaction

This erros appread, because FreshRSS computed same guid for two articles from geany RSS feed. They have both http://www.geany.org/Main/20170717 as guid.

As commented by @Alkarex this error shouldn't happen:

For the time being, I would suggest to add the same WHERE clause than the one you have made [ in PR #1613], for the initial insert into the temporary table.
It is not a problem to have entries with identical URL, IF they provide a GUID or equivalent (e.g. rdf:about). When they do not provide a GUID, then it is not trivial to make a good unique identifier (hashing is possible, but then it fails when articles are updated). So the behaviour right now should be to keep the newest article of a given URL when there is no GUID.