postgresql - 如何在Postgresql中使用postgres_fdw从另一个数据库获取记录

Question

我的案例我已经连接到另一个GP DB，将数据导入到PostgreSQL表中，并编写Java调度程序来每天刷新它。但当我每天试图使用SQL函数获取记录时，它会给我一个错误Greenplum Database does not support REPEATABLE READ transactions。所以，有谁能给我建议一下，我如何能从GP到postgres频繁地加载数据，而不需要隔离。
我知道执行刷新表

START TRANSACTION ISOLATION LEVEL SERIALIZABLE;

但是，由于事务块的原因，我不能在函数中使用相同的函数。

Answer 1

与Oracle数据库使用锁和闩锁进行并发控制不同，Greenplum数据库（PostgreSQL也是）通过使用多版本模型（多版本并发控制，MVCC）来维护数据一致性。这意味着在查询数据库时，每个事务都会看到一个数据快照，该快照可保护事务不查看由同一数据行上的（其他）并发更新引起的不一致数据。这为每个数据库会话提供事务隔离。简言之，读者不会阻挡作家，作家也不会阻挡读者。每个事务都会看到数据库的快照，而不是锁定表。
事务隔离级别
SQL标准定义了四个事务隔离级别。在Greenplum数据库中，您可以请求四个标准事务隔离级别中的任何一个。但在内部，只有两个不同的隔离级别—读提交和可序列化：
read committed-当事务在此隔离级别上运行时，SELECT查询只看到查询开始之前提交的数据。它从不看到未提交的数据或并发事务在查询执行期间提交的更改。但是，SELECT确实可以看到以前在其自己的事务中执行的更新的效果，即使这些更新尚未提交。实际上，SELECT查询在查询开始运行时看到数据库的快照。请注意，如果其他事务在执行第一个SELECT期间提交更改，则两个连续的SELECT命令可以看到不同的数据，即使它们位于单个事务中。在搜索目标行方面，UPDATE和DELETE命令的行为与SELECT相同。它们将只找到在命令启动时提交的目标行。但是，这样的目标行在找到时可能已经被另一个并发事务更新（或删除或锁定）。read-committed模式提供的部分事务隔离对于许多应用程序来说已经足够了，而且这种模式使用起来既快捷又简单。但是，对于执行复杂查询和更新的应用程序，可能需要确保数据库的视图比read committed模式提供的视图更加严格一致。
可序列化-这是最严格的事务隔离。这个级别模拟串行事务的执行，就好像事务是一个接一个地串行执行的，而不是并发执行的。由于序列化失败，使用此级别的应用程序必须准备好重试事务。当事务处于可序列化级别时，SELECT查询只看到事务开始之前提交的数据。它永远不会看到未提交的数据或在事务执行期间由并发事务提交的更改。但是，SELECT确实可以看到以前在其自己的事务中执行的更新的效果，即使这些更新尚未提交。单个事务中的连续SELECT命令总是看到相同的数据。在搜索目标行方面，UPDATE和DELETE命令的行为与SELECT相同。它们将只找到在事务开始时提交的目标行。但是，这样的目标行在找到时可能已经被另一个并发事务更新（或删除或锁定）。在这种情况下，可序列化事务将等待第一个更新事务提交或回滚（如果它仍在进行中）。如果第一个更新程序回滚，那么它的效果是否定的，可序列化事务可以继续更新最初找到的行。但是，如果第一个更新程序提交（并且实际更新或删除了行，而不仅仅是锁定了行），那么可序列化事务将回滚。
read uncommitted-处理方式与Greenplum数据库中的read committed相同。
可重复读取-与Greenplum数据库中的可串行化处理相同。
Greenplum数据库中的默认事务隔离级别为read committed。要更改事务的隔离级别，可以在开始事务时声明隔离级别，或者在事务启动后使用SET transaction命令。
enter link description here