3a694bb0a1
Essentially, we shoehorn in a lockable-object-type field by taking a byte away from the lockmethodid, which can surely fit in one byte instead of two. This allows less artificial definitions of all the other fields of LOCKTAG; we can get rid of the special pg_xactlock pseudo-relation, and also support locks on individual tuples and general database objects (including shared objects). None of those possibilities are actually exploited just yet, however. I removed pg_xactlock from pg_class, but did not force initdb for that change. At this point, relkind 's' (SPECIAL) is unused and could be removed entirely.
13 lines
407 B
C
13 lines
407 B
C
#ifndef USER_LOCKS_H
|
|
#define USER_LOCKS_H
|
|
|
|
extern int user_lock(uint32 id1, uint32 id2, LOCKMODE lockmode);
|
|
extern int user_unlock(uint32 id1, uint32 id2, LOCKMODE lockmode);
|
|
extern int user_write_lock(uint32 id1, uint32 id2);
|
|
extern int user_write_unlock(uint32 id1, uint32 id2);
|
|
extern int user_write_lock_oid(Oid oid);
|
|
extern int user_write_unlock_oid(Oid oid);
|
|
extern int user_unlock_all(void);
|
|
|
|
#endif
|