Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7 8   вперед  Ctrl      все
 Re: PostgreSQL vs MySQL  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
ОКТОГЕН,

А это что по вашему было?
14 авг 09, 10:24    [7537466]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
упс. Не заметил.
14 авг 09, 11:36    [7538061]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
А какая это версия?
Просто с такой проблемой сталкивался не я один.
14 авг 09, 11:37    [7538072]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
Ух ты! 5.1.30-community проблемы нет, видимо, действительно, пофиксили.
Лучше поздно, чем никогда...
В версиях 5.0.20 - 5.0.30х я тестировал это под разными осями, под разными кодировками(и клиентов и серверов и осей) и разными либами. Дело было точно не в настройках,
потому, как перед созданием триггера в этом же сеансе создавалась процедура с комментарием, и там было всё в порядке. При этом русский текст отображался правильно.
14 авг 09, 13:05    [7538905]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Хрен пишет:

> Postgresql разрабатывается по принципу "вали все в кучу, потом
> разберемся", толпой у которой даже багтрекера нет - форумом обходятся.
> Поэтому там до фига фич, и те места, которые интересно писать -
> прописаны хорошо. А скучные - типа тех же collation - никого не
> вдохновляют.
>
> MySQL же разрабатывается одной командой, с вменяемой (платной)
> техподдержкой и возможностью решить вопросы на любом уровне, включая
> патчи специально под твои нужды. Не так давно к примеру видел такой
> патч, который позоляет держать 20 - 30 тыщщ соединений.

Ну, ну. Особенно про "MySQL же разрабатывается одной командой" здорово.

Кстати, на счёт соединений. PGSQL использует (вроде бы) свою многозадачность.
MySQL -- использует многозадачность операционной сисстемы, на каждый
коннект создаёт поток. Это -- ОЧЕНЬ ПЛОХО по большому счёту, но дёшево
(попсово) в реализации.

Posted via ActualForum NNTP Server 1.4

17 авг 09, 13:29    [7546080]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

ОКТОГЕН пишет:

> Почему же к несчастью? Наоборот, к счастью.

Потому что если бы он не работал, то люди не парили бы себе
и разработчикам мозг по использованию и поддержке этого Г.


А использовали бы либо нормальные платные СУБД (дешёвых не так мало),
либо нормальные бесплатные СУБД.

Posted via ActualForum NNTP Server 1.4

17 авг 09, 13:32    [7546095]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
MasterZiv

Кстати, на счёт соединений. PGSQL использует (вроде бы) свою многозадачность.

Не совсем. Слон использует процессы.
Под виндами в этом есть минусы, т.к. процессы тут тормозят.
Зато взаимодействие основанное на процессах значительно надёжнее,
чем на потоках.
Хрен
Если вы думаете, я никогда не видел sigsegv на нем, то ошибаетесь.

А я видел то же самое на oracle. Видел, как M$SQL умирает. Баги есть везде.
17 авг 09, 15:16    [7546934]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
MasterZiv

Кстати, на счёт соединений. PGSQL использует (вроде бы) свою многозадачность.
MySQL -- использует многозадачность операционной сисстемы, на каждый
коннект создаёт поток. Это -- ОЧЕНЬ ПЛОХО по большому счёту, но дёшево
(попсово) в реализации.


Во первых pgsql не использует "свою многозадачность". Он использует process per connect стратегию для соединений.
Во вторых "ОЧЕНЬ ПЛОХО" - нуждается в обосновании.
18 авг 09, 00:38    [7549061]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
ОКТОГЕН

Под виндами в этом есть минусы, т.к. процессы тут тормозят.
Зато взаимодействие основанное на процессах значительно надёжнее,
чем на потоках.


Не в случае с pgsql. Сервера, с process per connect считаются надежнее, так как процессы изолированы друг от друга, не имеют общей памяти, и не могут нагадить друг другу. Но pgsql имеет общую память для всех процессов в shared memory, которая синхронизируется семафорами. Поэтому нагадить друг другу - они могут точно также как threads в mysql.

Собственно - так и происходит в случае внезапной кончины одного из процессов в pgsql. В таком случае - семафоры и shared memory остаются в неопределенном состоянии, поэтому postmaster - управляющий процесс - просто убивает все остальные соединения, и ре-инициализирует семафоры и shared memory заново. То есть - pgsql просто не использует те advantages, которые дает архитектура process per connect.

А drawbacks такой архитектуры - более ресурсоемкие соединения - они остаются, их никуда не денешь..
18 авг 09, 00:47    [7549074]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Yo.!
Guest
2Хрен

меня терзают смутные сомнения. о каких семофорах идет речь, операционной системы ? что за ОСь такая у которой остаются болтаться семофоры ? но больше заинтриговало shared memory - что там такого может оставить юзерский процесс, чего там такого чего нет в оракле ?
18 авг 09, 01:31    [7549112]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Ёш
Member

Откуда:
Сообщений: 2892
Хрен
Не в случае с pgsql. Сервера, с process per connect считаются надежнее, так как процессы изолированы друг от друга, не имеют общей памяти, и не могут нагадить друг другу. Но pgsql имеет общую память для всех процессов в shared memory, которая синхронизируется семафорами. Поэтому нагадить друг другу - они могут точно также как threads в mysql.

Собственно - так и происходит в случае внезапной кончины одного из процессов в pgsql. В таком случае - семафоры и shared memory остаются в неопределенном состоянии, поэтому postmaster - управляющий процесс - просто убивает все остальные соединения, и ре-инициализирует семафоры и shared memory заново. То есть - pgsql просто не использует те advantages, которые дает архитектура process per connect.
Вы как-то сами себе противоречите, возможность отследить разрушение данных в общей памяти, падение процесса и произвести после этого корректный перезапуск как раз и есть то самое использование преимуществ раздельных процессов в pg.
18 авг 09, 01:35    [7549117]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
Хрен, эксперимент показывает, что убийства процессов не происходит.
На остальных сеансах это не отражается(8.4)
18 авг 09, 10:22    [7549809]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7008
ОКТОГЕН,
а как именно ты заставил коннект умереть лютой смертью?
18 авг 09, 12:05    [7550522]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Yo.!
Guest
dimitr
а как именно ты заставил коннект умереть лютой смертью?

кому-то известно более одного способа "убийства процессов" ?
18 авг 09, 12:19    [7550628]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
ОКТОГЕН
Хрен, эксперимент показывает, что убийства процессов не происходит.
На остальных сеансах это не отражается(8.4)


Это интересно, надо попробовать. Быстрая проба на 8.3:

В двух окнах открываем 2 соединения psql
потом убиваем один из процессов:
root@home:~# kill -11 20204

Потом в каждом из соединений делаем скажем select 1;

$ psql
Welcome to psql 8.3.7, the PostgreSQL interactive terminal.

Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit

walrus=#
walrus=# select 1;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
Соединение с сервером было потеряно. Попытка переустановить: Успешно.

и во втором
$ psql 
Welcome to psql 8.3.7, the PostgreSQL interactive terminal.

Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit

walrus=#
walrus=# select 1;
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and repeat your command.
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
Соединение с сервером было потеряно. Попытка переустановить: Успешно.

В логе:

2009-08-18 16:33:20 EST LOG: server process (PID 20204) was terminated by signal 11: Segmentation fault
2009-08-18 16:33:20 EST LOG: terminating any other active server processes
2009-08-18 16:33:20 EST WARNING: terminating connection because of crash of another server process
2009-08-18 16:33:20 EST DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2009-08-18 16:33:20 EST HINT: In a moment you should be able to reconnect to the database and repeat your command.
2009-08-18 16:33:20 EST LOG: all server processes terminated; reinitializing
2009-08-18 16:33:20 EST LOG: database system was interrupted; last known up at 2009-08-18 16:32:37 EST
2009-08-18 16:33:20 EST LOG: database system was not properly shut down; automatic recovery in progress
2009-08-18 16:33:20 EST LOG: record with zero length at 0/3C7F17AC
2009-08-18 16:33:20 EST LOG: redo is not required
2009-08-18 16:33:20 EST LOG: autovacuum launcher started
2009-08-18 16:33:20 EST LOG: database system is ready to accept connections

То есть по крайней мере, в 8-3 происходит именно так, как я описывал.. А в 8-4 надо будет обязательно попробовать, как только руки дойдут
18 авг 09, 12:28    [7550676]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Yo.!
Guest
интересно, а если 8.3 именно убивать, kill -9 ?
18 авг 09, 12:42    [7550756]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
Yo.!, под вендой завершались через диспетчер задач-завершение процесса.
И 8.3.7 и 8.4 другие клиентские процессы при этом не завершались.
Особенности системы?
18 авг 09, 12:56    [7550866]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Yo.!
Guest
скорее segfault постгрес решает обрабатывать перегрузкой сервера, нужно под линуксом 8.3 попробовать прибить по -9, тогда можно будет делать выводы ...
18 авг 09, 13:08    [7550952]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7008
Yo.!
кому-то известно более одного способа "убийства процессов" ?

более интересна была бы реакция на AV/SEGV в одном из рабочих процессов
18 авг 09, 13:14    [7550982]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
Yo.!
скорее segfault постгрес решает обрабатывать перегрузкой сервера, нужно под линуксом 8.3 попробовать прибить по -9, тогда можно будет делать выводы ...


то же самое при kill -9

Первое соединение:

walrus=# select 1;
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and repeat your command.
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
Соединение с сервером было потеряно. Попытка переустановить: Успешно.

Второе соединение:


walrus=# select 1;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
Соединение с сервером было потеряно. Попытка переустановить: Успешно.
walrus=#


в логе
2009-08-18 20:33:36 EST LOG:  server process (PID 20215) was terminated by signal 9: Killed
2009-08-18 20:33:36 EST LOG: terminating any other active server processes
2009-08-18 20:33:36 EST WARNING: terminating connection because of crash of another server process
2009-08-18 20:33:36 EST DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2009-08-18 20:33:36 EST HINT: In a moment you should be able to reconnect to the database and repeat your command.
2009-08-18 20:33:36 EST LOG: all server processes terminated; reinitializing
2009-08-18 20:33:36 EST LOG: database system was interrupted; last known up at 2009-08-18 16:33:20 EST
2009-08-18 20:33:36 EST LOG: database system was not properly shut down; automatic recovery in progress
2009-08-18 20:33:36 EST LOG: record with zero length at 0/3C7F17EC
2009-08-18 20:33:36 EST LOG: redo is not required
2009-08-18 20:33:36 EST LOG: autovacuum launcher started
2009-08-18 20:33:36 EST LOG: database system is ready to accept connections
18 авг 09, 14:40    [7551714]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Хрен пишет:

> Во первых pgsql *не* использует "свою многозадачность". Он использует
> process per connect стратегию для соединений.

Ну не знаю. Надо посмотреть как у них серверный процесс выглядит.

> Во вторых "ОЧЕНЬ ПЛОХО" - нуждается в обосновании.

Для всего-то вам обоснования нужны ...
В любой операционной системе создавать бесконечное число потоков
невозможно, и бессмысленно с точки зрения СУБД -- у неё все равно
5-20 процессоров только есть, больше потоков создавать бессмысленно --
это одна накладуха (в ОС). Лучше иметь 5-20 потоков и брать их
из пула и выполнять в них запросы, передавая им структуру контекста
выполнения серверного процесса. Последнюю структуру надо иметь
в любом случае, так зачем тогда 2000 потоков ?

Posted via ActualForum NNTP Server 1.4

18 авг 09, 15:53    [7552275]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Хрен пишет:

> Не в случае с pgsql. Сервера, с process per connect считаются надежнее,
> так как процессы изолированы друг от друга, не имеют общей памяти, и не
> могут нагадить друг другу.

Как процессы сервера БД могут не иметь общей памяти, скажи пожалуйста ?
Это что же, каждому коннекту свой кэш данных ?

Posted via ActualForum NNTP Server 1.4

18 авг 09, 15:55    [7552298]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Yo.! пишет:

> меня терзают смутные сомнения. о каких семофорах идет речь, операционной
> системы ? что за ОСь такая у которой остаются болтаться семофоры ? но
> больше заинтриговало shared memory - что там такого может оставить
> юзерский процесс, чего там такого чего нет в оракле ?

Да гонит он. Чепуху какую-то сморозил.

Posted via ActualForum NNTP Server 1.4

18 авг 09, 15:56    [7552307]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
MasterZiv

Хрен пишет:

> Во первых pgsql *не* использует "свою многозадачность". Он использует
> process per connect стратегию для соединений.

Ну не знаю. Надо посмотреть как у них серверный процесс выглядит.


Посмотрите, посмотрите.. прежде чем спорить.

MasterZiv

В любой операционной системе создавать бесконечное число потоков
невозможно, и бессмысленно с точки зрения СУБД -- у неё все равно
5-20 процессоров только есть, больше потоков создавать бессмысленно --
это одна накладуха (в ОС). Лучше иметь 5-20 потоков и брать их
из пула и выполнять в них запросы, передавая им структуру контекста
выполнения серверного процесса. Последнюю структуру надо иметь
в любом случае, так зачем тогда 2000 потоков ?


Вот то что вы привели - это модель mysql 6. А pgsql этого не делает.
18 авг 09, 17:50    [7553179]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
MasterZiv

Как процессы сервера БД могут не иметь общей памяти, скажи пожалуйста ?
Это что же, каждому коннекту свой кэш данных ?


Может быть и такое. interbase classic к примеру
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_ss_vs_classic
Classic architecture, the design in InterBase 4.0 and earlier, was process-based. For every client connection, a separate server process was started to execute the database engine, and each server process had a dedicated database cache.


А теперь сделайте еще один шаг и скажите, если shared data все равно нужна - в чем преимущество модели process per connection, которую использует postgres относительно mysql thread per connection?
18 авг 09, 17:54    [7553207]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить