我是这个主题的新手，我所做的只是为一个用户连接到数据库，所以我不熟悉让多个用户访问数据库。
我的情况是：10 个设施将使用我的程序来记录工人进出的时间，数据库将在主服务器上，而我在编程/测试该程序时只创建了一个用户。我的问题是：多个远程位置是否可以使用一个用户进行数据库连接（应该没有冲突，因为它们都在写不同的东西，但在同一个表上）如果不是这样，我该怎么办？
【问题讨论】：
标签： postgresql connection psql
好的关系数据库处理得很好，就是关系数据库中事务的所谓ACID属性中的“我”；它代表隔离。
锁保护并发进程不会同时写入同一个表行，这些锁会阻塞其他事务，直到一个事务完成写入。
通过multiversion concurrency control (MVCC) 保护读者免受并发写入，它保留旧版本的数据以便为读者服务而不会阻塞任何人。
如果您将所有属于同一事务的数据修改包含在一个事务中，以便它们原子地发生（ACID 中的“A”），并且您的事务简单而简短，那么您的应用程序可能会工作得很好。
如果不满足这些条件，可能会出现问题：
如果您的数据修改不受事务保护，并发会话可能会看到不同会话的中间不完整结果，从而处理不一致的数据。
如果您的事务很复杂，事务中的后续语句可能会以间接方式依赖先前语句的结果。这种假设可能会被修改数据的并发活动打破。有以下三种方法：
悲观锁定：第一次使用时将所有数据锁定为SELECT ... FOR UPDATE，这样在您的事务完成之前没有人可以修改它们。
乐观锁定：不要锁定，但每当您第二次访问数据时，请检查在此期间没有其他人修改过它们。如果是这种情况，请回滚事务并重试。
使用像REPEATABLE READ 和SERIALIZABLE 这样的高事务隔离级别可以更好地保证您正在使用的数据不会被同时修改。如果数据库无法保持保证，您必须准备接收序列化错误，在这种情况下，您必须回滚事务并重试。
这些技术以不同的方式实现相同的目标。讨论何时使用哪个超出了此答案的范围。
如果您的事务很复杂和/或需要很长时间（要尽可能避免长时间的事务，因为它们会导致数据库中的各种问题），您可能会遇到死锁，这是两个交易相互锁定在一种“致命的拥抱”中。 数据库将检测到这种情况并中断其中一个事务并出现错误。
有两种处理方法：
通过始终以特定顺序锁定资源来避免死锁（例如，始终先更新具有较低帐号的帐户）。
当您遇到死锁时，您的代码必须重试事务。
与通常的看法相反，死锁不一定是错误。
我建议您阅读 PostgreSQL 文档中的 the chapter about concurrency control。
【讨论】：