galaxy

Проще все же key было сделать serial.

insert into table_Number (key, tstamp)
select * from (
	select row_number() over () n, t
  	  from generate_series(NOW() - INTERVAL '90 days', NOW(),'1 min') t
  ) sq
 where n <= 300

https://www.db-fiddle.com/f/bzE1G4cQ8S6sCHHPFH64gx/0

Для простых вещей telnet сойдет:
> telnet address port

UDP сокеты не используют listen()/accept().
Сразу можно делать socket.recvfrom()

ALTER TABLE progress ADD COLUMN subject_id INT;

UPDATE progress p SET p.subject_id = s.subject_id 
  FROM subjects s
 WHERE p.subject = s.subject;

-- ALTER TABLE progress DROP COLUMN subject;

От СУБД зависит, везде разные инструменты и свои особенности.
Например, для PostgreSQL можно так:

select status, generate_series(
    date_trunc('hour', date_start),
    date_trunc('hour', date_end),
    interval '1 hour')
  from tab

sqlfiddle.com/#!17/81ba7/2

Вы несколько раз определяете фукнцию selected() внутри foreach, вот последняя и срабатывает.
Пишите свой url в value у option, функцию selected() вытащите за пределы foreach:

<select size="4" id="series_list" name="selection" onchange="selected(this)" disabled>

var videoPlayer = document.getElementById('video-player');
            
            function selected(sel){
                videoPlayer.src = sel.options[sel.selectedIndex].value;
                videoPlayer.play();
            }

Если храните строкой, используйте формат, который можно сравнивать:
strftime("%Y-%m-%d %H:%M");

$start = strftime("%Y-%m-%d");
$end = strftime("%Y-%m-%d", strtotitme("tomorrow"));
$db->query("SELECT * FROM tab WHERE time > ='$start' AND time < '$end'");

Текущее время - now()
date_trunc() - округление даты

-- date('now', 'start of day')
date_trunc('day', now())

-- date('now', 'start of month')
date_trunc('month', now())

-- date('now', '-6 days')
now() - INTERVAL '6 days'

Так работают переменные в питоне.
Если переменная только читается в локальной области видимости (в вашем случае - внутри функции login()), то она будет искаться последовательно локально, в области видимости на уровень выше и так до глобальной.
Если в переменную идет запись в локальном скоупе, то она становится локальной (причем сразу, а не в момент записи). Это поведение меняется объявлением переменной global или nonlocal. Надеюсь, понятно написал (если что, об этом в интернете полно материалов, например)

В вашем примере error_count в функции login() - локальная, т.к. внутри функции идет запись в нее. При этом вы пытаетесь читать из нее до записи (ибо error_count += 1 суть error_count = error_count+1).

Я бы не назвал себя специалистом в mysql, но вот что можно увидеть из документации, как минимум:

The WITH CONSISTENT SNAPSHOT modifier starts a consistent read for storage engines that are capable of it. This applies only to InnoDB. The effect is the same as issuing a START TRANSACTION followed by a SELECT from any InnoDB table. See Section 15.7.2.3, “Consistent Nonlocking Reads”. The WITH CONSISTENT SNAPSHOT modifier does not change the current transaction isolation level, so it provides a consistent snapshot only if the current isolation level is one that permits a consistent read. The only isolation level that permits a consistent read is REPEATABLE READ. For all other isolation levels, the WITH CONSISTENT SNAPSHOT clause is ignored. A warning is generated when the WITH CONSISTENT SNAPSHOT clause is ignored.

То бишь:
1. Все это касается только InnoDB
2. START TRANSACTION WITH CONSISTENT SNAPSHOT не отличается от START TRANSACTION + SELECT (точнее, как я понял, тот самый консистентный снепшот фиксируется в первом случае в момент START TRANSACTION, а во втором - в момент SELECT).
3. Суть одна и та же - транзакция видит данные на момент фиксации снепшота, независимо от того, что там делают параллельные транзакции (+ она, конечно, видит свои собственные изменения)
4. WITH CONSISTENT SNAPSHOT не меняет уровень изоляции
5. WITH CONSISTENT SNAPSHOT работает только с REPEATABLE READ и игнорируется для любых других уровней с выдачей предупреждения (блин, не имею возможности проверить: что, даже для SEIRALIZABLE?)

Короче, вывод: ставите REPEATABLE READ (он, впрочем, стоит по умолчанию) и нафиг не сдался этот WITH CONSISTENT SNAPSHOT.

я могу вообще не делать полную блокировку таблиц, чтобы не потерять незавершенные транзакции. Я правильно понимаю смысл использования?

Смысл: вы получаете снимок состояния БД на момент фиксации снепшота. Обычно, это то, что нужно для бекапа