public inbox for [email protected]
help / color / mirror / Atom feedRe: Can we remove support for standard_conforming_strings = off yet?
5+ messages / 5 participants
[nested] [flat]
* Re: Can we remove support for standard_conforming_strings = off yet?
@ 2026-01-21 10:32 Julien Rouhaud <[email protected]>
0 siblings, 1 reply; 5+ messages in thread
From: Julien Rouhaud @ 2026-01-21 10:32 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: John Naylor <[email protected]>; Andrew Dunstan <[email protected]>; [email protected]
Hi,
On Tue, Jan 20, 2026 at 01:31:53PM -0500, Tom Lane wrote:
> So, nobody's actually spoken against this change. I think we should
> go forward with it, for the reasons I gave at the top of the thread
> and because "if not now, when?". I have little doubt that if there
> is anyone still running with standard_conforming_strings = off, they
> aren't going to change until forced to. So unless we want to live
> with the potential security hazard forever, we're going to have to
> make a breaking change sometime.
+1 from me. All of that is sensible, plus from an extension point of view it's
easy to write code that is broken with standard_conforming_strings = off so
it's one less thing to worry about.
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Can we remove support for standard_conforming_strings = off yet?
@ 2026-01-21 20:09 Tom Lane <[email protected]>
parent: Julien Rouhaud <[email protected]>
0 siblings, 2 replies; 5+ messages in thread
From: Tom Lane @ 2026-01-21 20:09 UTC (permalink / raw)
To: Julien Rouhaud <[email protected]>; +Cc: John Naylor <[email protected]>; Andrew Dunstan <[email protected]>; [email protected]
Julien Rouhaud <[email protected]> writes:
> On Tue, Jan 20, 2026 at 01:31:53PM -0500, Tom Lane wrote:
>> So, nobody's actually spoken against this change. I think we should
>> go forward with it, for the reasons I gave at the top of the thread
>> and because "if not now, when?". I have little doubt that if there
>> is anyone still running with standard_conforming_strings = off, they
>> aren't going to change until forced to. So unless we want to live
>> with the potential security hazard forever, we're going to have to
>> make a breaking change sometime.
> +1 from me. All of that is sensible, plus from an extension point of view it's
> easy to write code that is broken with standard_conforming_strings = off so
> it's one less thing to worry about.
Pushed.
regards, tom lane
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Can we remove support for standard_conforming_strings = off yet?
@ 2026-01-21 20:25 Bruce Momjian <[email protected]>
parent: Tom Lane <[email protected]>
1 sibling, 0 replies; 5+ messages in thread
From: Bruce Momjian @ 2026-01-21 20:25 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Julien Rouhaud <[email protected]>; John Naylor <[email protected]>; Andrew Dunstan <[email protected]>; [email protected]
On Wed, Jan 21, 2026 at 03:09:30PM -0500, Tom Lane wrote:
> Julien Rouhaud <[email protected]> writes:
> > On Tue, Jan 20, 2026 at 01:31:53PM -0500, Tom Lane wrote:
> >> So, nobody's actually spoken against this change. I think we should
> >> go forward with it, for the reasons I gave at the top of the thread
> >> and because "if not now, when?". I have little doubt that if there
> >> is anyone still running with standard_conforming_strings = off, they
> >> aren't going to change until forced to. So unless we want to live
> >> with the potential security hazard forever, we're going to have to
> >> make a breaking change sometime.
>
> > +1 from me. All of that is sensible, plus from an extension point of view it's
> > easy to write code that is broken with standard_conforming_strings = off so
> > it's one less thing to worry about.
>
> Pushed.
Great, thanks.
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Can we remove support for standard_conforming_strings = off yet?
@ 2026-01-30 10:10 jian he <[email protected]>
parent: Tom Lane <[email protected]>
1 sibling, 0 replies; 5+ messages in thread
From: jian he @ 2026-01-30 10:10 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Julien Rouhaud <[email protected]>; John Naylor <[email protected]>; Andrew Dunstan <[email protected]>; [email protected]
hi.
_allocAH is called by OpenArchive and CreateArchive. in _allocAH, we can set
AH->public.std_strings = true;
that would be more future-proof, otherwise after OpenArchive,
executing the query ``SET standard_conforming_strings = off;``
would result in an error.
--
jian
https://www.enterprisedb.com/
^ permalink raw reply [nested|flat] 5+ messages in thread
* [PATCH v1 8/8] convert FastPathStrongRelationLocks to atomics
@ 2026-07-09 20:38 Nathan Bossart <[email protected]>
0 siblings, 0 replies; 5+ messages in thread
From: Nathan Bossart @ 2026-07-09 20:38 UTC (permalink / raw)
---
src/backend/storage/lmgr/lock.c | 57 ++++++++++-----------------------
1 file changed, 17 insertions(+), 40 deletions(-)
diff --git a/src/backend/storage/lmgr/lock.c b/src/backend/storage/lmgr/lock.c
index 5ee80c7632e..035932197a4 100644
--- a/src/backend/storage/lmgr/lock.c
+++ b/src/backend/storage/lmgr/lock.c
@@ -40,11 +40,11 @@
#include "miscadmin.h"
#include "pg_trace.h"
#include "pgstat.h"
+#include "port/atomics.h"
#include "storage/lmgr.h"
#include "storage/proc.h"
#include "storage/procarray.h"
#include "storage/shmem.h"
-#include "storage/spin.h"
#include "storage/standby.h"
#include "storage/subsystems.h"
#include "utils/memutils.h"
@@ -306,13 +306,7 @@ static PROCLOCK *FastPathGetRelationLockEntry(LOCALLOCK *locallock);
#define FastPathStrongLockHashPartition(hashcode) \
((hashcode) % FAST_PATH_STRONG_LOCK_HASH_PARTITIONS)
-typedef struct
-{
- slock_t mutex;
- uint32 count[FAST_PATH_STRONG_LOCK_HASH_PARTITIONS];
-} FastPathStrongRelationLockData;
-
-static FastPathStrongRelationLockData *FastPathStrongRelationLocks;
+static pg_atomic_uint32 *FastPathStrongRelationLocks;
static void LockManagerShmemRequest(void *arg);
static void LockManagerShmemInit(void *arg);
@@ -484,7 +478,8 @@ LockManagerShmemRequest(void *arg)
);
ShmemRequestStruct(.name = "Fast Path Strong Relation Lock Data",
- .size = sizeof(FastPathStrongRelationLockData),
+ .size = mul_size(sizeof(pg_atomic_uint32),
+ FAST_PATH_STRONG_LOCK_HASH_PARTITIONS),
.ptr = (void **) (void *) &FastPathStrongRelationLocks,
);
}
@@ -492,7 +487,8 @@ LockManagerShmemRequest(void *arg)
static void
LockManagerShmemInit(void *arg)
{
- SpinLockInit(&FastPathStrongRelationLocks->mutex);
+ for (int i = 0; i < FAST_PATH_STRONG_LOCK_HASH_PARTITIONS; i++)
+ pg_atomic_init_u32(&FastPathStrongRelationLocks[i], 0);
}
/*
@@ -992,11 +988,11 @@ LockAcquireExtended(const LOCKTAG *locktag,
/*
* LWLockAcquire acts as a memory sequencing point, so it's safe
* to assume that any strong locker whose increment to
- * FastPathStrongRelationLocks->counts becomes visible after we
- * test it has yet to begin to transfer fast-path locks.
+ * FastPathStrongRelationLocks becomes visible after we test it
+ * has yet to begin to transfer fast-path locks.
*/
LWLockAcquire(&MyProc->fpInfoLock, LW_EXCLUSIVE);
- if (FastPathStrongRelationLocks->count[fasthashcode] != 0)
+ if (pg_atomic_read_u32(&FastPathStrongRelationLocks[fasthashcode]) != 0)
acquired = false;
else
acquired = FastPathGrantRelationLock(locktag->locktag_field2,
@@ -1501,11 +1497,9 @@ RemoveLocalLock(LOCALLOCK *locallock)
fasthashcode = FastPathStrongLockHashPartition(locallock->hashcode);
- SpinLockAcquire(&FastPathStrongRelationLocks->mutex);
- Assert(FastPathStrongRelationLocks->count[fasthashcode] > 0);
- FastPathStrongRelationLocks->count[fasthashcode]--;
+ Assert(pg_atomic_read_u32(&FastPathStrongRelationLocks[fasthashcode]) > 0);
+ pg_atomic_fetch_sub_u32(&FastPathStrongRelationLocks[fasthashcode], 1);
locallock->holdsStrongLockCount = false;
- SpinLockRelease(&FastPathStrongRelationLocks->mutex);
}
if (!hash_search(LockMethodLocalHash,
@@ -1834,20 +1828,9 @@ BeginStrongLockAcquire(LOCALLOCK *locallock, uint32 fasthashcode)
Assert(StrongLockInProgress == NULL);
Assert(locallock->holdsStrongLockCount == false);
- /*
- * Adding to a memory location is not atomic, so we take a spinlock to
- * ensure we don't collide with someone else trying to bump the count at
- * the same time.
- *
- * XXX: It might be worth considering using an atomic fetch-and-add
- * instruction here, on architectures where that is supported.
- */
-
- SpinLockAcquire(&FastPathStrongRelationLocks->mutex);
- FastPathStrongRelationLocks->count[fasthashcode]++;
+ pg_atomic_fetch_add_u32(&FastPathStrongRelationLocks[fasthashcode], 1);
locallock->holdsStrongLockCount = true;
StrongLockInProgress = locallock;
- SpinLockRelease(&FastPathStrongRelationLocks->mutex);
}
/*
@@ -1875,12 +1858,10 @@ AbortStrongLockAcquire(void)
fasthashcode = FastPathStrongLockHashPartition(locallock->hashcode);
Assert(locallock->holdsStrongLockCount == true);
- SpinLockAcquire(&FastPathStrongRelationLocks->mutex);
- Assert(FastPathStrongRelationLocks->count[fasthashcode] > 0);
- FastPathStrongRelationLocks->count[fasthashcode]--;
+ Assert(pg_atomic_read_u32(&FastPathStrongRelationLocks[fasthashcode]) > 0);
+ pg_atomic_fetch_sub_u32(&FastPathStrongRelationLocks[fasthashcode], 1);
locallock->holdsStrongLockCount = false;
StrongLockInProgress = NULL;
- SpinLockRelease(&FastPathStrongRelationLocks->mutex);
}
/*
@@ -3365,10 +3346,8 @@ LockRefindAndRelease(LockMethod lockMethodTable, PGPROC *proc,
{
uint32 fasthashcode = FastPathStrongLockHashPartition(hashcode);
- SpinLockAcquire(&FastPathStrongRelationLocks->mutex);
- Assert(FastPathStrongRelationLocks->count[fasthashcode] > 0);
- FastPathStrongRelationLocks->count[fasthashcode]--;
- SpinLockRelease(&FastPathStrongRelationLocks->mutex);
+ Assert(pg_atomic_read_u32(&FastPathStrongRelationLocks[fasthashcode]) > 0);
+ pg_atomic_fetch_sub_u32(&FastPathStrongRelationLocks[fasthashcode], 1);
}
}
@@ -4504,9 +4483,7 @@ lock_twophase_recover(FullTransactionId fxid, uint16 info,
{
uint32 fasthashcode = FastPathStrongLockHashPartition(hashcode);
- SpinLockAcquire(&FastPathStrongRelationLocks->mutex);
- FastPathStrongRelationLocks->count[fasthashcode]++;
- SpinLockRelease(&FastPathStrongRelationLocks->mutex);
+ pg_atomic_fetch_add_u32(&FastPathStrongRelationLocks[fasthashcode], 1);
}
LWLockRelease(partitionLock);
--
2.50.1 (Apple Git-155)
--Ot5x3ffkWEuxilWO--
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2026-07-09 20:38 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-01-21 10:32 Re: Can we remove support for standard_conforming_strings = off yet? Julien Rouhaud <[email protected]>
2026-01-21 20:09 ` Tom Lane <[email protected]>
2026-01-21 20:25 ` Bruce Momjian <[email protected]>
2026-01-30 10:10 ` jian he <[email protected]>
2026-07-09 20:38 [PATCH v1 8/8] convert FastPathStrongRelationLocks to atomics Nathan Bossart <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox