On 27/03/2025 07:00, Alexander Lakhin wrote:
I've discovered that the following script:
export PGOPTIONS='-c lock_timeout=1s'
createdb regression
for i in {1..100}; do
echo "ITERATION: $i"
psql -c "CREATE TABLE t(i int);"
cat << 'EOF' | psql &
DO $$
DECLARE
i int;
BEGIN
FOR i IN 1 .. 500
Hello Heikki,
04.11.2024 18:08, Heikki Linnakangas wrote:
Committed, thanks for the review!
I've discovered that the following script:
export PGOPTIONS='-c lock_timeout=1s'
createdb regression
for i in {1..100}; do
echo "ITERATION: $i"
psql -c "CREATE TABLE t(i int);"
cat << 'EOF' | psql &
DO
On 10/09/2024 19:53, Maxim Orlov wrote:
I looked at the patch set and found it quite useful.
The first 7 patches are just refactoring and may be committed separately
if needed.
There were minor problems: patch #5 don't want to apply clearly and the
#8 is complained
about partitionLock is unuse
I looked at the patch set and found it quite useful.
The first 7 patches are just refactoring and may be committed separately if
needed.
There were minor problems: patch #5 don't want to apply clearly and the #8
is complained
about partitionLock is unused if we build without asserts. So, I add a
P
On 28/09/2023 12:58, Heikki Linnakangas wrote:
On 28/10/2022 06:56, Thomas Munro wrote:
One example is heavyweight lock wakeups. If you run BEGIN; LOCK TABLE
t; ... and then N other sessions wait in SELECT * FROM t;, and then
you run ... COMMIT;, you'll see the first session wake all the others
On 28/10/2022 06:56, Thomas Munro wrote:
One example is heavyweight lock wakeups. If you run BEGIN; LOCK TABLE
t; ... and then N other sessions wait in SELECT * FROM t;, and then
you run ... COMMIT;, you'll see the first session wake all the others
while it still holds the partition lock itself.
Hi,
> Maybe this is all ok, but it would be good to make the assumptions more
> explicit.
Here are my two cents.
```
static void
SetLatchV(Latch **latches, int nlatches)
{
/* Flush any other changes out to main memory just once. */
pg_memory_barrier();
/* Keep only latches that are
On 04.03.23 20:50, Thomas Munro wrote:
Subject: [PATCH v3 1/6] Allow palloc_extended(NO_OOM) in critical sections.
Commit 4a170ee9e0e banned palloc() and similar in critical sections, because an
allocation failure would produce a panic. Make an exception for allocation
with NULL on failure, for
On Sat, Jan 28, 2023 at 3:39 AM vignesh C wrote:
> On Tue, 1 Nov 2022 at 16:40, Thomas Munro wrote:
> > Here's an attempt at that. There aren't actually any cases of uses of
> > this stuff in critical sections here, so perhaps I shouldn't bother
> > with that part. The part I'd most like some f
On Tue, 1 Nov 2022 at 16:40, Thomas Munro wrote:
>
> On Fri, Oct 28, 2022 at 4:56 PM Thomas Munro wrote:
> > See attached sketch patches. I guess the main thing that may not be
> > good enough is the use of a fixed sized latch buffer. Memory
> > allocation in don't-throw-here environments like
On Fri, Oct 28, 2022 at 4:56 PM Thomas Munro wrote:
> See attached sketch patches. I guess the main thing that may not be
> good enough is the use of a fixed sized latch buffer. Memory
> allocation in don't-throw-here environments like the guts of lock code
> might be an issue, which is why it j
Hi,
We usually want to release lwlocks, and definitely spinlocks, before
calling SetLatch(), to avoid putting a system call into the locked
region so that we minimise the time held. There are a few places
where we don't do that, possibly because it's not just a simple latch
to hold a pointer to b
12 matches
Mail list logo
