AM Crazy: PostgreSQL у оператора с вложенным запросом Возвращение неожиданных результатов

Следующий запрос возвращает 2036 строк:

SELECT "FooUID" from "Foo" f
LEFT JOIN "Bar" b ON f."BarUID" = b."BarUID"
WHERE f."BarUID" IS NOT NULL AND b."BarUID" IS NULL

, но следующее заявление обновлено только 1870 строк:

UPDATE "Foo" f1 set "BarUID" = 'aNewUID'
WHERE f1."FooUID" IN (
   SELECT f2."FooUID" from "Foo" f2
   LEFT JOIN "Bar" b ON f2."BarUID" = b."BarUID"
   WHERE f2."BarUID" IS NOT NULL AND b."BarUID" IS NULL
)

Как это возможно?

Отредактируйте 1: Первый запрос продолжает возвращать 166 строк, а второй продолжает обновлять 0 строк.

Отредактируйте 2:

В следующем вложенном запрос возвращает строку, содержащую UID, но внешний запрос возвращает 0 строк.

SELECT * from "Foo" f1
WHERE f1."FooUID" = (
   SELECT f2."FooUID" FROM "Foo" f2
   LEFT JOIN "Bar" b ON f2."BarUID" = b."BarUID"
   WHERE f2."BarUID" IS NOT NULL AND b."BarUID" IS NULL
   LIMIT 1
)

Я сумасшедший?

Отредактируйте 3:

Следующее утверждение, предоставленное @WildPlasser , удалось обновлять оставшиеся 166 строк:

UPDATE "Foo" ff
SET "BarUID" = 'aNewUID'
WHERE ff."BarUID" IS NOT NULL
AND NOT EXISTS (
   SELECT * FROM "Bar" bb
   WHERE bb."BarUID"= ff."BarUID"
)

Однако я до сих пор не понимаю, почему Оригинал не забрал их. Если вложенный запрос выбрал 166 «Фоуид» S, почему они не сопоставляются со строками в таблице , используя в ?

редактировать 4: Чем больше я думаю об этом, этот фон может быть важен:

Это все происходило на сервере базы данных, который был недавно клонирован с другого. Я говорил с ИТ-парнем, который сделал клонирование, и оказывается, он не закрыл приложение, бегущую на оригинальной БД, прежде чем довести его, чтобы клонировать его. Это означает, что БД в основном может вызвать среднюю транзакцию (я не знаю, насколько бесчувственно). Возможно ли что-то в базе данных осталось в поврежденном состоянии, ведущим мне, чтобы увидеть эти призрачные ряды?

К сожалению, я больше не могу репроматывать, так как бегущий почерк дикогопластика. Оригинальная БД (вверх и обслуживание приложения снова) имеет ни одно из недействительных данных, которые я пытался исправить на копии, намного меньше любых следов шенаниганов, которые я был свидетелем.

Я должен упомянуть, что перед запуском исправления я сократил проблему на самую основную абсурдность: я впервые выбрал foouib из вложенного запроса в редактировании 2, скопировал его в буфер обмена, затем запустил Запрос, выбирающий из Foo , где , в котором призвано , равнилось приклеенному значению - это еще возвращено 0 строк.