| Time |
Nick |
Message |
| 07:40 |
|
collum joined #evergreen |
| 08:57 |
|
Dyrcona joined #evergreen |
| 12:01 |
|
jihpringle joined #evergreen |
| 12:28 |
|
collum joined #evergreen |
| 12:32 |
eby |
https://event-driven.io/en/how-soon-is-now-in-postgresql/ ( now() is a synonym for transaction_timestamp(): it returns the time the transaction began, and keeps returning that value for every statement inside the same transaction) |
| 12:35 |
csharp_ |
eby++ |
| 12:35 |
csharp_ |
yeah, I've seen that before when trying to see how long DB upgrades take |
| 12:36 |
csharp_ |
didn't know about clock_timestamp(), so that's useful |
| 13:43 |
|
jvwoolf joined #evergreen |
| 16:19 |
goood |
FWIW, that fact is something we depend on. we don't generally have long-running transactions, and we want them to behave as if they happened at one instant WRT any record of action time. also, it's much faster than clock_timestamp(). |
| 16:22 |
goood |
(IOW, we have different constraints and assumptions than Emmet -- they need to (but didn't, before) depend on real time, we explicitly do not) |
| 16:30 |
eby |
yeah like they summarize. now() is the right tool when you want every row touched in the same transaction to share a timestamp. now() is the wrong tool when you want to ask “has time moved on?” from inside a transaction. which I could see some accidentally presuming when doing certain maintenance things like c sharp mentioned |
| 16:56 |
|
jvwoolf left #evergreen |
