Некропостить нехорошо, но и поднимать отдельную тему, неуверен что нужно. Есть простая таблица вида:
CREATE TABLE public.values (
id BIGSERIAL,
value VARCHAR(255) NOT NULL,
CONSTRAINT values_value_key UNIQUE(value),
CONSTRAINT values_pkey PRIMARY KEY(id)
) ;
т.е. строковое уникальное значение и его id. Сейчас, на таблицу с около 92млн строк, есть около 2000 неуникальных значений, которые повторяются от 2х до 6ти раз.
Работа с таблицей производнится одним клиентом, без транзакций, перед INSERT идет SELECT, т.е. если SELECT ничего не вернул, то идет INSERT. Первое из попавшихся дублирующихся значений имеет ID записией не подряд, остальные не смотрел ещё.
Я сперва подумал, что это у меня в глазах глючит, и символы одинаковые, а кода разные, но нет, построить ещё один, точно такой же, уникальный индекс по полю value невозможно из за дублирующихся записей. А тот что есть, он есть.
Версия 12.3.
Я бы ещё смог как-то понять глюк, если бы это были просто последовательные INSERT, но перед INSERT всегда есть ещё SELECT. Т.е. получается, что при каких-то условиях, postgres видит не всю таблицу. Ладно, возможно, если бы условия были серьезнее, множество клиентов, репликации... но тут! Один клиент! Который долбит базу: "дай ID для значения ххх", и если вернулся пустой набор, то "вставь значение ххх и верни его ID", и при такой простейшей логике postgresql допустил появление дублирующихся записей. Неоднократно.
Легко. Здесь узнаем тип аккумулятора:
KIN-325A | 12В / 4,5Ач | 1 штука | LONG WP4.5-12
Узнаем, как он выглядит.
А вот и где купить, выбирайте. При покупке смотрите, чтобы размеры (приблизительно) и тип крепления совпали. Если емкость будет чуть больше — ничего страшного.
Очень странный у Вас «местный радиорынок». Попробуйте посмотреть в интернет магазинах. Гугл подсказывает, что красная цена подобному аккумулятору $10-$20.
6ю версию не смотрел (сегодня узнал, что она есть). 5ю пробовал, пользуюсь 4й (по внутренним причинам).
1. Да/Да и много еще чего.
2. Начиная с 5й можно хранить проект в XML. Совместную работу не пробовал, но изменения при коммите хорошо видно.
5. Шаблоны есть. Базовый для PDF мне подошел, вполне профессионально получилось.
Разве что какой-то очень локальный сервис. Вот, например, варианты оплаты софта:
—
What payment methods are accepted?
Credit Cards (Visa, MasterCard, American Express, JCB, Discovery, Maestro, Solo/Switch)
PayPal
WebMoney
Paysafecard
Purchase Order
Mail Orders (Credit Card Details, Check, Cash, Money Order, Cashier Check, Bank Draft)
Fax Order
Phone Order
Purchase Orders can be paid using Mail (Credit Card Details, Check, Cash, Money Order, Cashier Check, Bank Draft), Phone (credit card), Fax (credit card), Wire Payment, Bank Transfer, PayPal or Payoneer.
—
Собственно, Вам не электронные деньги нужны, а процессор мелких платежей. Компания, которая будет принимать платежи, а потом Вам перечислять раз в месяц.
Hetzner использует KVM: QA8713. Умиляет всё же комментарий про настройки openvz. За три года сходных проблем не было, но причина в кривых настройках (в чем же еще?) openvz, которого вообще нет. Это пять!
CREATE TABLE public.values (
id BIGSERIAL,
value VARCHAR(255) NOT NULL,
CONSTRAINT values_value_key UNIQUE(value),
CONSTRAINT values_pkey PRIMARY KEY(id)
) ;
т.е. строковое уникальное значение и его id. Сейчас, на таблицу с около 92млн строк, есть около 2000 неуникальных значений, которые повторяются от 2х до 6ти раз.
Работа с таблицей производнится одним клиентом, без транзакций, перед INSERT идет SELECT, т.е. если SELECT ничего не вернул, то идет INSERT. Первое из попавшихся дублирующихся значений имеет ID записией не подряд, остальные не смотрел ещё.
Я сперва подумал, что это у меня в глазах глючит, и символы одинаковые, а кода разные, но нет, построить ещё один, точно такой же, уникальный индекс по полю value невозможно из за дублирующихся записей. А тот что есть, он есть.
Версия 12.3.
Я бы ещё смог как-то понять глюк, если бы это были просто последовательные INSERT, но перед INSERT всегда есть ещё SELECT. Т.е. получается, что при каких-то условиях, postgres видит не всю таблицу. Ладно, возможно, если бы условия были серьезнее, множество клиентов, репликации... но тут! Один клиент! Который долбит базу: "дай ID для значения ххх", и если вернулся пустой набор, то "вставь значение ххх и верни его ID", и при такой простейшей логике postgresql допустил появление дублирующихся записей. Неоднократно.