我的情况是我已连接到另一个GP DB，以将数据导入到我的PostgreSQL表中，并编写了Java调度程序以每日刷新它。但是，当我尝试每天使用SQL函数来获取记录时，会给我一个错误Greenplum Database does not support REPEATABLE READ transactions。因此，有人可以建议我如何从GP频繁地将数据加载到postgres，而不会造成麻烦。
我知道要执行以刷新表
START TRANSACTION ISOLATION LEVEL SERIALIZABLE;
但是，由于交易障碍，我无法在功能中使用相同的功能。
答案 0 :(得分：0)
与使用锁和闩锁进行并发控制的Oracle数据库不同，Greenplum数据库（PostgreSQL也是如此）通过使用多版本模型（Multiversion Concurrency Control，MVCC）来维护数据一致性。这意味着在查询数据库时，每个事务都会看到数据的快照，这可以保护事务避免查看不一致的数据，该不一致的数据可能是由同一数据行上的（其他）并发更新引起的。这为每个数据库会话提供了事务隔离。简而言之，读者不会阻止作家，作家也不会阻止读者。每个事务都会看到数据库的快照，而不是锁定表。 交易隔离级别
SQL标准定义了四个事务隔离级别。在Greenplum数据库中，您可以请求四个标准事务隔离级别中的任何一个。但是在内部，只有两个不同的隔离级别-读取已提交和可序列化：
读取已提交-当事务在此隔离级别上运行时，SELECT查询仅查看在查询开始之前已提交的数据。它永远不会看到并发事务执行查询期间提交的数据或未提交的更改。但是，SELECT确实会看到先前更新在其自身事务中执行的效果，即使尚未提交也是如此。实际上，SELECT查询从查询开始运行时就可以看到数据库的快照。请注意，即使其他事务在执行第一个SELECT的过程中提交更改，即使两个连续的SELECT命令位于单个事务中，它们也可以看到不同的数据。在搜索目标行方面，UPDATE和DELETE命令的行为与SELECT相同。他们将仅查找从命令开始时间起已提交的目标行。但是，这样的目标行可能在被发现时已被另一个并发事务更新（或删除或锁定）。读提交模式提供的部分事务隔离足以满足许多应用程序的需求，并且该模式使用起来快速简便。但是，对于执行复杂查询和更新的应用程序，可能有必要保证比只读提交模式所提供的数据库视图更为严格的一致性。
serializable —这是最严格的事务隔离。此级别模拟串行事务执行，就好像事务是依次而不是并发执行的。由于序列化失败，使用该级别的应用程序必须准备重试事务。当事务处于可序列化级别时，SELECT查询将仅查看在事务开始之前提交的数据。它永远不会看到并发事务在事务执行过程中提交的未提交数据或更改。但是，SELECT确实会看到先前更新在其自身事务中执行的效果，即使尚未提交也是如此。单个事务中的连续SELECT命令始终会看到相同的数据。在搜索目标行方面，UPDATE和DELETE命令的行为与SELECT相同。他们将仅查找在事务开始时已提交的目标行。但是，这样的目标行可能在被发现时已被另一个并发事务更新（或删除或锁定）。在这种情况下，可序列化事务将等待第一个更新事务提交或回滚（如果仍在进行中）。如果第一个更新程序回滚，则其作用将被消除，可序列化事务可继续更新最初找到的行。但是，如果第一个更新程序提交（并实际上更新或删除了该行，而不仅仅是锁定了该行），那么可序列化的事务将被回滚。
未提交读取-与Greenplum数据库中已提交读取相同。
可重复读取-与Greenplum数据库中的可序列化处理相同。
Greenplum数据库中的默认事务隔离级别已提交。要更改事务的隔离级别，可以在开始事务时声明隔离级别，或者在事务启动后使用SET TRANSACTION命令。