Re: Locks on unlogged tables are locked?!

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Locks on unlogged tables are locked?!
Date: 2023-11-21 16:49:18
Message-ID: ZVzfjof_BL3Yn5K_@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Uh, was this ever addressed? I don't see the patch applied or the code
in this area modified.

---------------------------------------------------------------------------

On Thu, May 24, 2018 at 04:33:11PM +0200, Laurenz Albe wrote:
> While looking at this:
> https://stackoverflow.com/q/50413623/6464308
> I realized that "LOCK TABLE <unlogged table>" puts a
> Standby/LOCK into the WAL stream, which causes a log flush
> at COMMIT time.
>
> That hurts performance, and I doubt that it is necessary.
> At any rate, DROP TABLE on an unlogged table logs nothing.
>
> The attached patch would take care of it, but I'm not sure
> if that's the right place to check.
>
> Yours,
> Laurenz Albe

> From d474e7b41298944e43bb9141eb33adbdd9ea1098 Mon Sep 17 00:00:00 2001
> From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
> Date: Tue, 22 May 2018 18:13:31 +0200
> Subject: [PATCH] Don't log locks on unlogged tables
>
> ---
> src/backend/storage/lmgr/lock.c | 28 +++++++++++++++++++++-------
> 1 file changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/src/backend/storage/lmgr/lock.c b/src/backend/storage/lmgr/lock.c
> index dc3d8d9817..70cac47ab3 100644
> --- a/src/backend/storage/lmgr/lock.c
> +++ b/src/backend/storage/lmgr/lock.c
> @@ -37,6 +37,7 @@
> #include "access/twophase_rmgr.h"
> #include "access/xact.h"
> #include "access/xlog.h"
> +#include "catalog/pg_class.h"
> #include "miscadmin.h"
> #include "pg_trace.h"
> #include "pgstat.h"
> @@ -47,6 +48,7 @@
> #include "storage/standby.h"
> #include "utils/memutils.h"
> #include "utils/ps_status.h"
> +#include "utils/rel.h"
> #include "utils/resowner_private.h"
>
>
> @@ -1041,13 +1043,25 @@ LockAcquireExtended(const LOCKTAG *locktag,
> */
> if (log_lock)
> {
> - /*
> - * Decode the locktag back to the original values, to avoid sending
> - * lots of empty bytes with every message. See lock.h to check how a
> - * locktag is defined for LOCKTAG_RELATION
> - */
> - LogAccessExclusiveLock(locktag->locktag_field1,
> - locktag->locktag_field2);
> + bool unlogged_rel = false;
> +
> + if (locktag->locktag_type == LOCKTAG_RELATION)
> + {
> + Relation r = RelationIdGetRelation(locktag->locktag_field2);
> + unlogged_rel = r->rd_rel->relpersistence == RELPERSISTENCE_UNLOGGED;
> + RelationClose(r);
> + }
> +
> + if (!unlogged_rel)
> + {
> + /*
> + * Decode the locktag back to the original values, to avoid sending
> + * lots of empty bytes with every message. See lock.h to check how a
> + * locktag is defined for LOCKTAG_RELATION
> + */
> + LogAccessExclusiveLock(locktag->locktag_field1,
> + locktag->locktag_field2);
> + }
> }
>
> return LOCKACQUIRE_OK;
> --
> 2.14.3
>

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

Only you can decide what is important to you.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2023-11-21 16:51:38 Re: simplehash: SH_OPTIMIZE_REPEAT for optimizing repeated lookups of the same key
Previous Message Andres Freund 2023-11-21 16:41:09 Re: Add recovery to pg_control and remove backup_label