Bug 302 - Slony functions unnecessarily lock pg_catalog tables for update
Summary: Slony functions unnecessarily lock pg_catalog tables for update
Status: NEW
Alias: None
Product: Slony-I
Classification: Unclassified
Component: stored procedures (show other bugs)
Version: devel
Hardware: PC Linux
: low enhancement
Assignee: Slony Bugs List
URL:
Depends on:
Blocks:
 
Reported: 2013-07-23 10:18 UTC by Kristopher
Modified: 2013-07-24 12:19 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kristopher 2013-07-23 10:18:02 UTC
Slony functions unnecessarily lock pg_catalog tables for update but don't actually directly update them. 

This prevents non-superuser users from calling functions such as adding a table to a set. 

See commit diff here: https://github.com/mrkrstphr/slony1-engine/commit/1773d09be6c5df0c9b89d9f5494df2eb9bac7f24

This is preventing us from automating replicating new tax tables that come in through an automated process in our organization.
Comment 1 Christopher Browne 2013-07-24 12:19:23 UTC
There appears to be a need to do the FOR UPDATE, in that this was introduced to prevent deadlocks that can occur due to needing to escalate locks on such tables.

A thought is to "hide" this query inside a security definer function, so that the permission could be granted to a more ordinary user.  That seems a bit thorny, requires more thought.