4 ms·

> Transaction logs are an essential part of databases because they ensure that no data is lost even when a system failure occurs. They are a history log of all

> Transaction logs are an essential part of databases because they ensure that no data is lost even when a system failure occurs. They are a history log of all changes and actions in a database system. This ensures that no data is lost due to failures, such as a power failure or a server crash. The log contains sufficient information about each transaction that has already been executed, so the database server can recover the database cluster by replaying the changes and actions in the transaction log in the event of a server crash. The writing is horrendous

tasuki 2y ago
The author is Japanese, cut them some slack.
- xnickb 2y ago
  Or better yet, offer help
  - rrr_oh_man 2y ago
    In what way? First thought: If a sports team is not playing well, do you mail in coaching advice? I elaborated a bit here, though: https://news.ycombinator.com/item?id=43254469 https://news.ycombinator.com/item?id=43254469
- rrr_oh_man 2y ago
  Thanks for pointing this out. I probably should have, being a non-native speaker myself. Though, the core of my issue with this is not the language itself, but how the paragraphs are structured. Imho you might cut 50% of words and not lose any information. See here: https://news.ycombinator.com/item?id=43254469 https://news.ycombinator.com/item?id=43254469
paulddraper 2y ago
What makes the writing horrendous?
- shxx 2y ago
  If rrr_oh_man's profile is real (https://bit.ly/48d9o9P https://bit.ly/48d9o9P), his resume appears inconsistent and unprofessional. The emptier a person is, the more likely they are to criticize others.
  - deleted 2y ago
    [deleted]
  - rrr_oh_man 2y ago
    Ouch. Don't take it personally. :)
- jodrellblank 2y ago
  I won't comment on the OP using 'horrendous' as an adjective, but that quote seems misleading and unclear to me. Transactions (not transaction logs) are about maintaining [relational] database consistency, not directly about ensuring no data loss. A database engine would rather roll back a partially applied transaction and lose the data in it, than update one table and not update another, breaking the relation between them, and becoming inconsistent/corrupt. Transaction logs then, are a separate record of these transactions into a log file. The quote says they are 'essential' but three paragraphs later in the link[0] is this: "The [log] mechanism was first implemented in version 7.1"; transaction logs are not essential for RDBMSs and are not essential for ensuring against data loss, they are one part of one larger design for reducing the chance of data loss. (Having a separate log file does not ensure that no data is lost in the event of a crash because the log file could also be lost by the same crash). "so the database server can recover the database cluster" - the quote has switched from transaction logs as essential, to clustering-with-transaction-logs as essential, without clearly calling that out; there are clustering designs which don't need transaction logs so that isn't essential, and from the PostgreSQL documentation[1]: "It should be noted that log shipping is asynchronous, i.e., the [logs] are shipped after transaction commit. As a result, there is a window for data loss...". Neither transaction logs, nor log shipping clustering, are enough to ensure no data loss. It is possible to improve on that with synchronous_commit[2] (off by default in PostgreSQL) but that can still be designed badly to allow data loss to happen. The quote is misleading about what transaction logs are for, what situations they can/cannot help with, and what other concerns are involved in guarding against data loss. Given that data loss is a particularly important concern in relational databases compared to some other software and systems, and that there are so many details which need to be considered to reduce risks of data loss, the quote being at all vague or misleading seems worse than it would be if writing about other systems, and worse than it would be if written in the context of 'a high level overview of databases'. [0] http://www.interdb.jp/pg/pgsql09.html http://www.interdb.jp/pg/pgsql09.html [1] https://www.postgresql.org/docs/17/warm-standby.html https://www.postgresql.org/docs/17/warm-standby.html [2] https://www.postgresql.org/docs/17/warm-standby.html#SYNCHRONOUS-REPLICATION https://www.postgresql.org/docs/17/warm-standby.html#SYNCHRO...
gpvos 2y ago
A bit on the wordy side, but better than the average documentation.
datadrivenangel 2y ago
It's a little clipped, but very straightforward and easy to follow. Not horrendous.
skotobaza 2y ago
How would you rephrase it? I'm also a non-native English speaker, and the bit you provided sounds very easy to understand because of how it's phrased. There are minor redundancies, but that's all I noticed...
- rrr_oh_man 2y ago
  > How would you rephrase it? https://news.ycombinator.com/item?id=43254469 https://news.ycombinator.com/item?id=43254469 > I'm also a non-native English speaker, and the bit you provided sounds very easy to understand because of how it's phrased. Thanks for your point. It felt to me like reading overly verbose code. Not wrong, but not effective.
  - skotobaza 2y ago
    Thanks! Your edit is good, more concise in the first half, and even easier to understand in the second half, compared to original.

tasuki 2y ago

The author is Japanese, cut them some slack.

xnickb 2y ago
Or better yet, offer help
- rrr_oh_man 2y ago
  In what way? First thought: If a sports team is not playing well, do you mail in coaching advice? I elaborated a bit here, though: https://news.ycombinator.com/item?id=43254469 https://news.ycombinator.com/item?id=43254469
rrr_oh_man 2y ago
Thanks for pointing this out. I probably should have, being a non-native speaker myself. Though, the core of my issue with this is not the language itself, but how the paragraphs are structured. Imho you might cut 50% of words and not lose any information. See here: https://news.ycombinator.com/item?id=43254469 https://news.ycombinator.com/item?id=43254469

paulddraper 2y ago

What makes the writing horrendous?

shxx 2y ago
If rrr_oh_man's profile is real (https://bit.ly/48d9o9P https://bit.ly/48d9o9P), his resume appears inconsistent and unprofessional. The emptier a person is, the more likely they are to criticize others.
- deleted 2y ago
  [deleted]
- rrr_oh_man 2y ago
  Ouch. Don't take it personally. :)
jodrellblank 2y ago
I won't comment on the OP using 'horrendous' as an adjective, but that quote seems misleading and unclear to me. Transactions (not transaction logs) are about maintaining [relational] database consistency, not directly about ensuring no data loss. A database engine would rather roll back a partially applied transaction and lose the data in it, than update one table and not update another, breaking the relation between them, and becoming inconsistent/corrupt. Transaction logs then, are a separate record of these transactions into a log file. The quote says they are 'essential' but three paragraphs later in the link[0] is this: "The [log] mechanism was first implemented in version 7.1"; transaction logs are not essential for RDBMSs and are not essential for ensuring against data loss, they are one part of one larger design for reducing the chance of data loss. (Having a separate log file does not ensure that no data is lost in the event of a crash because the log file could also be lost by the same crash). "so the database server can recover the database cluster" - the quote has switched from transaction logs as essential, to clustering-with-transaction-logs as essential, without clearly calling that out; there are clustering designs which don't need transaction logs so that isn't essential, and from the PostgreSQL documentation[1]: "It should be noted that log shipping is asynchronous, i.e., the [logs] are shipped after transaction commit. As a result, there is a window for data loss...". Neither transaction logs, nor log shipping clustering, are enough to ensure no data loss. It is possible to improve on that with synchronous_commit[2] (off by default in PostgreSQL) but that can still be designed badly to allow data loss to happen. The quote is misleading about what transaction logs are for, what situations they can/cannot help with, and what other concerns are involved in guarding against data loss. Given that data loss is a particularly important concern in relational databases compared to some other software and systems, and that there are so many details which need to be considered to reduce risks of data loss, the quote being at all vague or misleading seems worse than it would be if writing about other systems, and worse than it would be if written in the context of 'a high level overview of databases'. [0] http://www.interdb.jp/pg/pgsql09.html http://www.interdb.jp/pg/pgsql09.html [1] https://www.postgresql.org/docs/17/warm-standby.html https://www.postgresql.org/docs/17/warm-standby.html [2] https://www.postgresql.org/docs/17/warm-standby.html#SYNCHRONOUS-REPLICATION https://www.postgresql.org/docs/17/warm-standby.html#SYNCHRO...

gpvos 2y ago

A bit on the wordy side, but better than the average documentation.

datadrivenangel 2y ago

It's a little clipped, but very straightforward and easy to follow. Not horrendous.

skotobaza 2y ago

How would you rephrase it? I'm also a non-native English speaker, and the bit you provided sounds very easy to understand because of how it's phrased. There are minor redundancies, but that's all I noticed...

rrr_oh_man 2y ago
> How would you rephrase it? https://news.ycombinator.com/item?id=43254469 https://news.ycombinator.com/item?id=43254469 > I'm also a non-native English speaker, and the bit you provided sounds very easy to understand because of how it's phrased. Thanks for your point. It felt to me like reading overly verbose code. Not wrong, but not effective.
- skotobaza 2y ago
  Thanks! Your edit is good, more concise in the first half, and even easier to understand in the second half, compared to original.