我们有一个使用 psycopg2 将记录写入 RDS Postgres 的应用程序。有时，当发生缩减事件并且容器在插入提交期间停止时，这会在表上造成死锁。我们正在使用具有一些标准超时的线程连接池，如下所示：
self._pool = pool.ThreadedConnectionPool(
mincount,
maxcount,
dsn,
cursor_factory=cursor_factory,
application_name=application_name or name,
keepalives_idle=1,
keepalives_interval=1,
keepalives_count=5,
options=f"-c statement_timeout={statement_timeout}s -c idle_in_transaction_session_timeout={idle_in_transaction_session_timeout}s",
事务超时空闲似乎是在抛出超时错误后发生的事务而不是静默等待，但我们仍然遇到锁定问题。我们应该使用不同的超时让 Postgres 终止这些事务吗？
问题更新：
我们有 2 个不同的应用程序。一个写入表，另一个读取表。我们看到写入应用程序中偶尔会弹出此错误：
deadlock detected
DETAIL: Process 31504 waits for ShareLock on transaction 33994594; blocked by process 28310.
Process 28310 waits for ShareLock on transaction 33994595; blocked by process 31504.
HINT: See server log for query details.
CONTEXT: while inserting
如果我为这些 pid 提取 pg_stat_activity，我会得到这个：
[
{
"datid": 262668,
"datname": "app_db",
"pid": 31504,
"usename": …我有一个火花作业，它只会从具有相同转换的多个表中提取数据。基本上是一个遍历表列表的 for 循环，查询目录表，添加时间戳，然后推送到 Redshift（下面的示例）。
完成这项工作大约需要 30 分钟。有没有办法在相同的火花/胶水环境下并行运行这些？如果可以避免的话，我不想创建单独的胶水作业。
import datetime
import os
from awsglue.transforms import *
from awsglue.utils import getResolvedOptions
from awsglue.dynamicframe import DynamicFrame
from awsglue.context import GlueContext
from awsglue.job import Job
from pyspark.context import SparkContext
from pyspark.sql.functions import *
# query the runtime arguments
args = getResolvedOptions(
sys.argv,
["JOB_NAME", "redshift_catalog_connection", "target_database", "target_schema"],
)
# build the job session and context
glueContext = GlueContext(SparkContext.getOrCreate())
spark = glueContext.spark_session
job = Job(glueContext)
job.init(args["JOB_NAME"], args)
# set the job execution timestamp
job_execution_timestamp = datetime.datetime.utcnow() …