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