Be more wary about partially-valid LOCALLOCK data in RemoveLocalLock().
RemoveLocalLock() must consider the possibility that LockAcquireExtended()
failed to palloc the initial space for a locallock's lockOwners array.
I had evidently meant to cope with this hazard when the code was originally
writ
Be more wary about partially-valid LOCALLOCK data in RemoveLocalLock().
RemoveLocalLock() must consider the possibility that LockAcquireExtended()
failed to palloc the initial space for a locallock's lockOwners array.
I had evidently meant to cope with this hazard when the code was originally
writ
Be more wary about partially-valid LOCALLOCK data in RemoveLocalLock().
RemoveLocalLock() must consider the possibility that LockAcquireExtended()
failed to palloc the initial space for a locallock's lockOwners array.
I had evidently meant to cope with this hazard when the code was originally
writ
Be more wary about partially-valid LOCALLOCK data in RemoveLocalLock().
RemoveLocalLock() must consider the possibility that LockAcquireExtended()
failed to palloc the initial space for a locallock's lockOwners array.
I had evidently meant to cope with this hazard when the code was originally
writ
Be more wary about partially-valid LOCALLOCK data in RemoveLocalLock().
RemoveLocalLock() must consider the possibility that LockAcquireExtended()
failed to palloc the initial space for a locallock's lockOwners array.
I had evidently meant to cope with this hazard when the code was originally
writ
Be more wary about partially-valid LOCALLOCK data in RemoveLocalLock().
RemoveLocalLock() must consider the possibility that LockAcquireExtended()
failed to palloc the initial space for a locallock's lockOwners array.
I had evidently meant to cope with this hazard when the code was originally
writ
Be more wary about partially-valid LOCALLOCK data in RemoveLocalLock().
RemoveLocalLock() must consider the possibility that LockAcquireExtended()
failed to palloc the initial space for a locallock's lockOwners array.
I had evidently meant to cope with this hazard when the code was originally
writ
Restrict file mode creation mask during tmpfile().
Per Coverity. Back-patch to 9.0 (all supported versions).
Michael Paquier, reviewed (in earlier versions) by Heikki Linnakangas.
Branch
--
REL9_3_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/ea218a2ba70d9f11f5a271728de264
Remove the SECURITY_ROW_LEVEL_DISABLED security context bit.
This commit's parent made superfluous the bit's sole usage. Referential
integrity checks have long run as the subject table's owner, and that
now implies RLS bypass. Safe use of the bit was tricky, requiring
strict control over the SQL
Restrict file mode creation mask during tmpfile().
Per Coverity. Back-patch to 9.0 (all supported versions).
Michael Paquier, reviewed (in earlier versions) by Heikki Linnakangas.
Branch
--
REL9_0_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/24aed2124a5273e4cb543b06d4b7bb
Restrict file mode creation mask during tmpfile().
Per Coverity. Back-patch to 9.0 (all supported versions).
Michael Paquier, reviewed (in earlier versions) by Heikki Linnakangas.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/8346218c029dc0db425e3bea20033f96e1543
Restrict file mode creation mask during tmpfile().
Per Coverity. Back-patch to 9.0 (all supported versions).
Michael Paquier, reviewed (in earlier versions) by Heikki Linnakangas.
Branch
--
REL9_4_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/7496aba8085a21f8296f19b2e8f07e
Remove the row_security=force GUC value.
Every query of a single ENABLE ROW SECURITY table has two meanings, with
the row_security GUC selecting between them. With row_security=force
available, every function author would have been advised to either set
the GUC locally or test both meanings. Non
Restrict file mode creation mask during tmpfile().
Per Coverity. Back-patch to 9.0 (all supported versions).
Michael Paquier, reviewed (in earlier versions) by Heikki Linnakangas.
Branch
--
REL9_5_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/1be9d65e17abc6215a6faae9bc3f71
Restrict file mode creation mask during tmpfile().
Per Coverity. Back-patch to 9.0 (all supported versions).
Michael Paquier, reviewed (in earlier versions) by Heikki Linnakangas.
Branch
--
REL9_2_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/c94b65f677875140b019bec1f7dc07
Restrict file mode creation mask during tmpfile().
Per Coverity. Back-patch to 9.0 (all supported versions).
Michael Paquier, reviewed (in earlier versions) by Heikki Linnakangas.
Branch
--
REL9_1_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/5dc49efe9012793110ef5dab9a9a1a
Remove the SECURITY_ROW_LEVEL_DISABLED security context bit.
This commit's parent made superfluous the bit's sole usage. Referential
integrity checks have long run as the subject table's owner, and that
now implies RLS bypass. Safe use of the bit was tricky, requiring
strict control over the SQL
Remove the row_security=force GUC value.
Every query of a single ENABLE ROW SECURITY table has two meanings, with
the row_security GUC selecting between them. With row_security=force
available, every function author would have been advised to either set
the GUC locally or test both meanings. Non
18 matches
Mail list logo
