Телеграмм чат группы pgsql страница 10237

21:18пожаловаться #1

AS

Apurva Shinde in pgsql – PostgreSQL

Yaroslav Schekin

I suggested you two other PostgreSQL channels, did you miss it?
Also, if you want help with complex things, you could also try IRC (see https://www.postgresql.org/community/irc/ ). Quite a few of professional database developers, DBAs and even PostgreSQL developers are active there.

Yep

21:19пожаловаться #2

AS

Apurva Shinde in pgsql – PostgreSQL

Yaroslav Schekin

I suggested you two other PostgreSQL channels, did you miss it?
Also, if you want help with complex things, you could also try IRC (see https://www.postgresql.org/community/irc/ ). Quite a few of professional database developers, DBAs and even PostgreSQL developers are active there.

That's helpful ,thanks🙂

21:19пожаловаться #3

2_

2flower _ in pgsql – PostgreSQL

Darafei Praliaskouski

В россии их ещё не запретили?

тонко.

22:46пожаловаться #4

M

Murena in pgsql – PostgreSQL

Подскажите плиз правильно ли хранить дату в бд в таком формате ?
"timeCreatedAt": "2020-07-06T20:41:34.143Z",
"timeUpdatedAt": "2020-07-06T20:41:34.143Z",
потом не будет никаких подводных камней с поиском - выборкой диапазона дат по бд ?

🥓 Хамон Эврибади... in pgsql – PostgreSQL

23:47пожаловаться #5

🥓Э

Murena

Подскажите плиз правильно ли хранить дату в бд в таком формате ?
"timeCreatedAt": "2020-07-06T20:41:34.143Z",
"timeUpdatedAt": "2020-07-06T20:41:34.143Z",
потом не будет никаких подводных камней с поиском - выборкой диапазона дат по бд ?

Часовой пояс будет не лишним

23:56пожаловаться #6

M

Murena in pgsql – PostgreSQL

🥓 Хамон Эврибади

Часовой пояс будет не лишним

ну я все держу в UTC - а по каждому юзеру хранить часовой пояс нету надобности.

23:58пожаловаться #7

2020 July 07

2_

2flower _ in pgsql – PostgreSQL

нужно взять за правило использовать -v ON_ERROR_STOP=1

можно вопрос по pg_probackup
2.4.1 pg 12.3 выполняю show -B ... в столбце wal 0 после обновления, до обновления было 16MB, сами wal'ы в директории есть.
что может быть не так?

00:07пожаловаться #8

GS

2flower _

можно вопрос по pg_probackup
2.4.1 pg 12.3 выполняю show -B ... в столбце wal 0 после обновления, до обновления было 16MB, сами wal'ы в директории есть.
что может быть не так?

да, это баг, вызванный Issue #153, исправлен в 2.4.2

00:09пожаловаться #9

2_

2flower _ in pgsql – PostgreSQL

да, это баг, вызванный Issue #153, исправлен в 2.4.2

т.е. wal'ы не валидны или просто не отображается корректно?

00:10пожаловаться #10

GS

просто отображается некорректно

00:10пожаловаться #11

GS

поэтому оно и проскочило тесты

00:11пожаловаться #12

2_

2flower _ in pgsql – PostgreSQL

просто отображается некорректно

ясно. спасибо.

00:11пожаловаться #13

2_

2flower _ in pgsql – PostgreSQL

просто отображается некорректно

обновил до 2.4.2 картина аналогичная.

00:18пожаловаться #14

2_

2flower _ in pgsql – PostgreSQL

или он нормально будет отображать только в следующих копиях?

00:19пожаловаться #15

GS

2flower _

обновил до 2.4.2 картина аналогичная.

старые бэкапы это не исправит, это же не налету считается, а записывается в атрибут wal-bytes

00:19пожаловаться #16

2_

2flower _ in pgsql – PostgreSQL

старые бэкапы это не исправит, это же не налету считается, а записывается в атрибут wal-bytes

ясно.спасибо.

00:20пожаловаться #17

2_

2flower _ in pgsql – PostgreSQL

Murena

Подскажите плиз правильно ли хранить дату в бд в таком формате ?
"timeCreatedAt": "2020-07-06T20:41:34.143Z",
"timeUpdatedAt": "2020-07-06T20:41:34.143Z",
потом не будет никаких подводных камней с поиском - выборкой диапазона дат по бд ?

если вы про JSON, то такие вещи все же лучше хранить в реляционных полях особенно при хитрых фильтрах.

00:21пожаловаться #18

M

Murena in pgsql – PostgreSQL

2flower _

если вы про JSON, то такие вещи все же лучше хранить в реляционных полях особенно при хитрых фильтрах.

нет это не json - это поле типа timestamp в бд

00:22пожаловаться #19

2_

2flower _ in pgsql – PostgreSQL

Murena

нет это не json - это поле типа timestamp в бд

ну тогда timestamp with tz ваше все. уже неоднократно говорили выше.