Возвращаются неодинаковые результаты (данные) по запросу

Oleg07

Новичок
Возвращаются неодинаковые результаты (данные) по запросу

Отлаживаю программный комплекс сильно использующую PostgreSQL.
Очередная программа пока только (такой этап её разработки) запрашивает (через SELECT) данные из 2-х таблиц одной БД.
В любом случае в эти 2-е таблицы записи ни в какой форме тут (в рамках этой программы) и не будет.

И такая вот засада - при повторных прогонах получаю различающиеся данные!!!????

Причём с таблицами всё в порядке - после того, как перезапускаю postgresql всё повторяется однозначно - при первом после перезапуска прогоне. Но это же не дело!!!

Сопутствующие обстоятельства - работаю из-под АльтЛинукс 5.0, Postgresql версии postgresql-8.3eter, программирую на Python (ну виноват, не сайтовая у мя задача, а шибко вычислительная, но форум-то вроде как Postgre-ссовый, а не только php-йный, да и проблема могла и тут встретиться).
Кто-нить с таким встречался?
Хоть какие-то можно привести соображения?
 

С.

Продвинутый новичок
За любым неожиданным результатом стоят какие-то определеные причины. Процесс нахождение этих причин называется программная отладка. Программист обязан уметь самостоятельно отлаживаться и находить источник проблем. Гадание на кофейной гуще, которяя здесь предоставлена, не являтся достойным программиста занятием.
 

Sad Spirit

мизантроп (Старожил PHPClub)
Команда форума
Автор оригинала: Oleg07
Хоть какие-то можно привести соображения?
Немного соображений: если бы вместо словесной диареи были приведены тексты запросов, возвращающих "различающиеся данные", то можно было бы подумать. А так могу порекомендовать постучать в шаманский бубен и принести в жертву чёрного козла.
 

Oleg07

Новичок
Ну зачем же так-то?
Про отладку я малость знаю. И даже произвожу её, временами.
Просто тут мне неясно даже куда копать.
О запросах я ведь говорил - простейшие
SELECT.<имя поля 1>, <имя поля 2>,... FROM <имя таблицы>
ну ещё SELECT COUNT(.... и SELECT MAX(...
Единственно что у меня вызывает подозрение - в какой-то момент я (в целях той самой отладки) начал присобачивать к запросам (1-го вида из вышеперечисленных) ещё и ограничение LIMIT (всёж у меня там более 3000000 записей, трудновато просматривать врукопашную). Для более полной определённости - таковых запросов в тексте программы всего 2, они к разным таблицам, и использовались (поскольку отладка) только по одному разу за прогон программы.
Собственно мой вопрос ведь сводился к тому - наблюдал ли кто-нибудь подобное поведение - при повторных прогонах программы получать из неменяющейся таблицы различающиеся результаты. То есть ситуацию, когда меж прогонами программы что-то остаётся/запоминается в СОСТОЯНИИ СУБД (и может быть стёрто перезапуском её).
Неужели это содержание вопроса было неясно из первого текста? Извиняюсь, тогда.

Да, как только я всё это обнаружил, я понатыкал повсюду в программу команду <имя объекта БД>.comit(), т.е., насколько я понимаю, поназавершал транзакции. Не помогло.

Ну, и куда бы мне ещё полезть со своей отладкой?
Ну честно - не вижу куда и как копать.
Не запускать же отладчик на сам PostgreSQL.
 

dr-sm

Новичок
order by есть в запросе, порядок задан однозначно?, если нету то лимит выбирает случайные записи, точнее какие ему удобнее.
 

baev

‹°°¬•
Команда форума
Oleg07, я понимаю, что у Вас python, но всё равно почитайте:
http://phpfaq.ru/debug

Вы ни одного реального запроса к базе не привели — о чём тут можно серьёзно говорить?
Только о различных магических практиках…
 

Sad Spirit

мизантроп (Старожил PHPClub)
Команда форума
Автор оригинала: Oleg07
Собственно мой вопрос ведь сводился к тому - наблюдал ли кто-нибудь подобное поведение - при повторных прогонах программы получать из неменяющейся таблицы различающиеся результаты.
Как верно отметил коллега dr-sm, самый простой способ получить "различающиеся" результаты --- не указать в запросе order by (или указать, но недостаточный для однозначного порядка записей).

То есть ситуацию, когда меж прогонами программы что-то остаётся/запоминается в СОСТОЯНИИ СУБД (и может быть стёрто перезапуском её).
Неужели это содержание вопроса было неясно из первого текста? Извиняюсь, тогда.
Это "что-то" называется кэшем. Но кагбэ нормальные люди обычно борятся за то, чтобы кэш максимально использовался.
 

Oleg07

Новичок
Спасибо.
То, что тут сообщили насчёт привычки LIMIT-а выбирать по своему усмотрению, для меня абсолютная новость. Довольно неприятная, но и успокаивающая - ибо LIMIT-ом я пользовался исключительно в ходе отладки и потому егойная неоднозначность в рабочем прогоне программы для меня несущественна (за его, LIMIT-а, отсутствием).
И насчёт ORDER BY буду отныне держать в уме.
Только - я правильно понял, что он нужен лишь когда LIMIT-ом пользуюсь,
а когда "полный" SELECT (ограниченный только WHERE), то такого произвола ожидать не приходится? Для меня это вопрос не чисто академический - при трёхмиллионнострочных таблицах любые "довески" (даже ORDER BY) могут оказаться весьма недешевыми по времени.

Насчёт кэша-то - понятно. Я просто не мог предположить, что он так далеко заходит....
Придётся впредь быть повнимательнее с ним
 

dr-sm

Новичок
Oleg07, нет никаких неоднозначностей, оператор limit ограничивает выходное множество до Х элементов начиная с элемента с порядковым номером У.
подумай сам, что должна делать СУБД, если ее попросили сделать лимит по неупорядоченному множеству, коим является результат любой выборки без явно заданного или заданного неоднозначно ордер бай?

по поводу других случаев "произвола", надо смотреть конкретно,
в принципе, все описано в документации (поведение лимит тоже).
 

dimagolov

Новичок
при трёхмиллионнострочных таблицах любые "довески" (даже ORDER BY) могут оказаться весьма недешевыми по времени.
Oleg07, открой для себя индексы и отладку запросов с помощью EXPLAIN
 

Oleg07

Новичок
Автор оригинала: baev
— неправильно.
Чёрт, опять слишком положился на контекст.
Когда я про нужность ORDER BY спрашивал, я имел в в виду - для однозначности результата.
По прямому-то его назначению я и ранее использовал.
Прошу прощения за "экономность" (неуместную).

-~{}~ 16.07.10 20:41:

Автор оригинала: dr-sm
Oleg07, нет никаких неоднозначностей, оператор limit ограничивает выходное множество до Х элементов начиная с элемента с порядковым номером У.
подумай сам, что должна делать СУБД, если ее попросили сделать лимит по неупорядоченному множеству, коим является результат любой выборки без явно заданного или заданного неоднозначно ордер бай?

по поводу других случаев "произвола", надо смотреть конкретно,
в принципе, все описано в документации (поведение лимит тоже).
Вот до меня как-то и не могло дойти (хоть я именно LIMIT и заподозрил), что Y при запросе из разных источников (разные прогоны программы) могут как-то запоминаться, перекрёстно влиять на результаты друг друга. Как-то было внутреннее убеждение, что новому "запрашивателю" и отвечать надо с нуля, по-новой начиная все отсчёты и позиционирования. Ну типа как обработка прерываний в процессоре - контекст запоминается, потом восстанавливается.
Интересно, а в других "больших" СУБД (Oracle, скажем) тоже такая зависимость контекста от "посторонних" запросов наблюдается?
Насчёт LIMIT-а по неупорядоченному множеству - реально-то оно упорядоченное - там таблица в коей даже PRIMARY KEY имеется (хотя в данных запросах он, кроме как для COUNT и MAX не использовался)

Других случаев "произвола" замечать, слава Богу, не доводилось.

А в целом - спасибо.
 

Sad Spirit

мизантроп (Старожил PHPClub)
Команда форума
Автор оригинала: Oleg07
Когда я про нужность ORDER BY спрашивал, я имел в в виду - для однозначности результата.
По прямому-то его назначению я и ранее использовал.
В реляционной модели отношение --- неупорядоченное множество кортежей. Результат будет однозначный с точностью до сортировки.

Как-то было внутреннее убеждение, что новому "запрашивателю" и отвечать надо с нуля, по-новой начиная все отсчёты и позиционирования.
Внутреннее убеждение, извиняюсь, на чём основано-то было?
 

Mols

Новичок
Sad Spirit
Ну издеваться то зачем? ))) (это я про обоснование убеждений)
 

baev

‹°°¬•
Команда форума
Вот до меня как-то и не могло дойти (хоть я именно LIMIT и заподозрил), что Y при запросе из разных источников (разные прогоны программы) могут как-то запоминаться, перекрёстно влиять на результаты друг друга. Как-то было внутреннее убеждение, что новому "запрашивателю" и отвечать надо с нуля, по-новой начиная все отсчёты и позиционирования. Ну типа как обработка прерываний в процессоре - контекст запоминается, потом восстанавливается.
Интересно, а в других "больших" СУБД (Oracle, скажем) тоже такая зависимость контекста от "посторонних" запросов наблюдается?
— Вы бредите.
Ничего такого Вам не сказали.

До Вас хотели донести простую вещь:
данные в базе хранятся неупорядоченно
И выборка без «ORDER BY» происходит так же.

(Я понимаю — «пятничный вечер», но человек уже скоро до «теории всего» дойдёт, потом даст ответ на главный вопрос. И что тогда?..)
 

~WR~

Новичок
Я вам даже больше того скажу.
Если у вас есть ORDER BY + LIMIT, но ORDER BY составлен таким образом, что для двух и более записей получается одинаковая сортировка, то и в этом случае вы можете получить неожиданный результат.

В частности, такое можно увидеть, когда планировщик использует метод сортировки Top-N heapsort.

ORDER BY всегда должен быть составлен таким образом, чтобы отличаться для каждого ряда в таблице. Проще всего всегда добавлять последней сортировку по primary key.
 
Сверху