RemoveSubscriptionRel uses simple_heap_delete

Started by Masahiko Sawadaover 8 years ago3 messages
#1Masahiko Sawada
sawada.mshk@gmail.com
1 attachment(s)

Hi,

Currently $subject but should we use CatalogTupleDelete() instead?
It's actually the same behavior though. Other functions use
CatalogTupleXXX(). Attached patch.

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

Attachments:

change_to_use_CatalogTupleDelete.patchapplication/octet-stream; name=change_to_use_CatalogTupleDelete.patchDownload
diff --git a/src/backend/catalog/pg_subscription.c b/src/backend/catalog/pg_subscription.c
index c5b2541..c69c461 100644
--- a/src/backend/catalog/pg_subscription.c
+++ b/src/backend/catalog/pg_subscription.c
@@ -401,7 +401,7 @@ RemoveSubscriptionRel(Oid subid, Oid relid)
 	scan = heap_beginscan_catalog(rel, nkeys, skey);
 	while (HeapTupleIsValid(tup = heap_getnext(scan, ForwardScanDirection)))
 	{
-		simple_heap_delete(rel, &tup->t_self);
+		CatalogTupleDelete(rel, &tup->t_self);
 	}
 	heap_endscan(scan);
 
#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Masahiko Sawada (#1)
Re: RemoveSubscriptionRel uses simple_heap_delete

Masahiko Sawada <sawada.mshk@gmail.com> writes:

Currently $subject but should we use CatalogTupleDelete() instead?
It's actually the same behavior though. Other functions use
CatalogTupleXXX(). Attached patch.

Yeah, evidently that patch failed to track the effects of commits
2f5c9d9c9 et al, since it wasn't in-tree yet. Poking around, at
least statscmds.c has got the same disease.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#3Masahiko Sawada
sawada.mshk@gmail.com
In reply to: Tom Lane (#2)
Re: RemoveSubscriptionRel uses simple_heap_delete

On Wed, Jun 14, 2017 at 10:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Masahiko Sawada <sawada.mshk@gmail.com> writes:

Currently $subject but should we use CatalogTupleDelete() instead?
It's actually the same behavior though. Other functions use
CatalogTupleXXX(). Attached patch.

Yeah, evidently that patch failed to track the effects of commits
2f5c9d9c9 et al, since it wasn't in-tree yet. Poking around, at
least statscmds.c has got the same disease.

Thank you for fixing it!

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers