Postgres 10.14 中的触发器功能未按预期运行

如何解决Postgres 10.14 中的触发器功能未按预期运行

我正在使用胶水将 3 个数据集从 S3 加载到 aurora Postgres Serverless。由于 spark 和 jdbc 不允许我直接将 json stings 转换为 jsonb 数据类型，因此我在 Postgres 端创建了 3 个“暂存”表。我有一个第四个表 - etl_log - 我附加了一个触发函数，见下文，写入时触发。

该函数基本上采用每个这些暂存表中的任何内容并将其放入目标数据类型中的目标，并为下一次 etl 加载截断暂存表。 ETL 日志会跟踪写入的内容和时间。

到目前为止一切都很好。当任何一个临时表中有数据并被调用时，此函数按预期工作。但是，如果一个以上的表中有记录，那么它似乎表现出两种行为中的一种：

将数据加载到目标表之一，同时截断两个临时表或
它会从所有临时表中加载数据，即使只有一个被调用。（第二个表可能正在加载过程中，所有执行程序尚未完成，因此在暂存时留下了一些记录）。

如何在它们相互独立运行的函数中隔离这些不同的块。我不太担心第二种情况，我已经编写了一个脚本（在 etlside -glue 上）来计算所有 3 个临时表并写入计数（即使在任何临时表中为零）但非常感谢输入第一个场景

尽管有效 [时间戳存在且至少初始或联系人 ID 存在] 记录在暂存中但函数在暂存被截断的情况下执行，但未发生加载到目标的问题。具有以下代码的联系流表：

INSERT INTO contact_flow_logs (
    id,message,timestamp,initialcontactid,contactflowmodule_type,weeknum,contactid
)
SELECT
    cfl.id,cfl.message::jsonb,cfl.timestamp::timestamptz,cfl.message::jsonb ->> 'InitialContactId' AS initialcontactid,cfl.message::jsonb ->> 'ContactFlowModuleType' AS contactflowmodule_type,date_part('week',cfl.timestamp::timestamptz) AS weeknum,cfl.message::jsonb ->> 'ContactId' AS contactid
FROM contact_flow_logs_staging AS cfl
WHERE COALESCE(cfl.message::jsonb ->> 'InitialContactId',cfl.message::jsonb ->> 'ContactId') IS NOT NULL AND cfl.timestamp is not null;

查看下面的完整功能。

提前致谢。

BEGIN

INSERT INTO agents (
    currentagentsnapshot,prevIoUsagentsnapshot,agentarn,eventid,eventtimestamp,eventtype,instancearn)
SELECT 
    agent_stg.currentagentsnapshot::jsonb AS currentagentsnapshot,agent_stg.prevIoUsagentsnapshot::jsonb AS prevIoUsagentsnapshot,agent_stg.agentarn::text AS agentarn,agent_stg.eventid::text AS eventid,agent_stg.eventtimestamp::timestamptz AS eventtimestamp,agent_stg.eventtype::text AS eventtype,agent_stg.instancearn::text AS instancearn
FROM agents_staging AS agent_stg
WHERE agent_stg.agentarn IS NOT NULL;

TruncATE agents_staging;

INSERT INTO contact_flow_logs (
    id,cfl.message::jsonb ->> 'ContactId') IS NOT NULL AND cfl.timestamp is not null;

TruncATE contact_flow_logs_staging;

INSERT INTO contact_trace_records (
    agent,agentconnectionattempts,attributes,channel,connectedtosystemtimestamp,contactid,customerendpoint,disconnecttimestamp,initiationmethod,initiationtimestamp,instancearn,lastupdatetimestamp,nextcontactid,prevIoUscontactid,ctrqueue,recording,systemendpoint,transfercompletedtimestamp,transferredtoendpoint,attemptsmade,arrivaltimestamp,attemptendingtimestamp,contactdetails,ctrreferences,disconnectreason
)
SELECT
   ctrs.agent::jsonb,ctrs.agentconnectionattempts::TEXT,ctrs.attributes::jsonb,ctrs.channel::TEXT,ctrs.connectedtosystemtimestamp::TIMESTAMPTZ,ctrs.contactid::TEXT,ctrs.customerendpoint::jsonb,ctrs.disconnecttimestamp::TIMESTAMPTZ,ctrs.initialcontactid::TEXT,ctrs.initiationmethod::TEXT,ctrs.initiationtimestamp::TIMESTAMPTZ,ctrs.instancearn::TEXT,ctrs.lastupdatetimestamp::TIMESTAMPTZ,ctrs.nextcontactid::TEXT,ctrs.prevIoUscontactid::TEXT,ctrs.ctrqueue::jsonb,ctrs.recording::jsonb,ctrs.systemendpoint::jsonb,ctrs.transfercompletedtimestamp::TIMESTAMPTZ,ctrs.transferredtoendpoint::jsonb,ctrs.attemptsmade::TEXT,ctrs.arrivaltimestamp::TIMESTAMPTZ,ctrs.attemptendingtimestamp::TIMESTAMPTZ,ctrs.contactdetails::TEXT,ctrs.ctrreferences::TEXT,ctrs.disconnectreason::TEXT
FROM contact_trace_records_staging AS ctrs
WHERE NOT (ctrs.contactid IS NULL AND ctrs.initialcontactid IS NULL);

TruncATE contact_trace_records_staging;

RETURN new;

结束