From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Nitin Motiani <nitinmotiani(at)google(dot)com> |
Cc: | vignesh C <vignesh21(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: long-standing data loss bug in initial sync of logical replication |
Date: | 2024-07-16 06:29:04 |
Message-ID: | CAA4eK1+nqdT2XgF9iPyDnJNMkeQiPVKkXuFhrzxT67Dy_=3-Sg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jul 16, 2024 at 9:29 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> One related comment:
> @@ -1219,8 +1219,14 @@ AlterPublicationTables(AlterPublicationStmt
> *stmt, HeapTuple tup,
> oldrel = palloc(sizeof(PublicationRelInfo));
> oldrel->whereClause = NULL;
> oldrel->columns = NIL;
> +
> + /*
> + * Data loss due to concurrency issues are avoided by locking
> + * the relation in ShareRowExclusiveLock as described atop
> + * OpenTableList.
> + */
> oldrel->relation = table_open(oldrelid,
> - ShareUpdateExclusiveLock);
> + ShareRowExclusiveLock);
>
> Isn't it better to lock the required relations in RemovePublicationRelById()?
>
On my CentOS VM, the test file '100_bugs.pl' takes ~11s without a
patch and ~13.3s with a patch. So, 2 to 2.3s additional time for newly
added tests. It isn't worth adding this much extra time for one bug
fix. Can we combine table and schema tests into one single test and
avoid inheritance table tests as the code for those will mostly follow
the same path as a regular table?
--
With Regards,
Amit Kapila.
From | Date | Subject | |
---|---|---|---|
Next Message | 김명준 | 2024-07-16 06:39:38 | [ pg_ctl ] Review Request for Adding Pre-check User Script Feature |
Previous Message | Ashutosh Sharma | 2024-07-16 05:55:36 | Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions |