public inbox for [email protected]
help / color / mirror / Atom feed[PATCH v1 01/12] jit: Instrument function purpose separately, add tracking of modules.
17+ messages / 5 participants
[nested] [flat]
* [PATCH v1 01/12] jit: Instrument function purpose separately, add tracking of modules.
@ 2019-09-26 18:44 Andres Freund <[email protected]>
0 siblings, 0 replies; 17+ messages in thread
From: Andres Freund @ 2019-09-26 18:44 UTC (permalink / raw)
Author:
Reviewed-By:
Discussion: https://postgr.es/m/
Backpatch:
---
src/backend/commands/explain.c | 24 +++++++++++++++++++++++-
src/backend/jit/jit.c | 3 +++
src/backend/jit/llvm/llvmjit.c | 2 ++
src/backend/jit/llvm/llvmjit_deform.c | 1 +
src/backend/jit/llvm/llvmjit_expr.c | 1 +
src/include/jit/jit.h | 11 ++++++++++-
6 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/src/backend/commands/explain.c b/src/backend/commands/explain.c
index 62fb3434a32..ef65035bfba 100644
--- a/src/backend/commands/explain.c
+++ b/src/backend/commands/explain.c
@@ -825,7 +825,26 @@ ExplainPrintJIT(ExplainState *es, int jit_flags,
appendStringInfoString(es->str, "JIT:\n");
es->indent += 1;
- ExplainPropertyInteger("Functions", NULL, ji->created_functions, es);
+ /* having to emit code more than once has performance consequences */
+ if (ji->created_modules > 1)
+ ExplainPropertyInteger("Modules", NULL, ji->created_modules, es);
+
+ appendStringInfoSpaces(es->str, es->indent * 2);
+ appendStringInfo(es->str, "Functions: %zu", ji->created_functions);
+ if (ji->created_expr_functions > 0 || ji->created_deform_functions)
+ {
+ appendStringInfoString(es->str, " (");
+ if (ji->created_expr_functions)
+ {
+ appendStringInfo(es->str, "%zu for expression evaluation", ji->created_expr_functions);
+ if (ji->created_deform_functions)
+ appendStringInfoString(es->str, ", ");
+ }
+ if (ji->created_deform_functions)
+ appendStringInfo(es->str, "%zu for tuple deforming", ji->created_deform_functions);
+ appendStringInfoChar(es->str, ')');
+ }
+ appendStringInfoChar(es->str, '\n');
appendStringInfoSpaces(es->str, es->indent * 2);
appendStringInfo(es->str, "Options: %s %s, %s %s, %s %s, %s %s\n",
@@ -851,7 +870,10 @@ ExplainPrintJIT(ExplainState *es, int jit_flags,
else
{
ExplainPropertyInteger("Worker Number", NULL, worker_num, es);
+ ExplainPropertyInteger("Modules", NULL, ji->created_modules, es);
ExplainPropertyInteger("Functions", NULL, ji->created_functions, es);
+ ExplainPropertyInteger("Expression Functions", NULL, ji->created_expr_functions, es);
+ ExplainPropertyInteger("Deforming Functions", NULL, ji->created_deform_functions, es);
ExplainOpenGroup("Options", "Options", true, es);
ExplainPropertyBool("Inlining", jit_flags & PGJIT_INLINE, es);
diff --git a/src/backend/jit/jit.c b/src/backend/jit/jit.c
index 43e65b1a543..63c709002d8 100644
--- a/src/backend/jit/jit.c
+++ b/src/backend/jit/jit.c
@@ -186,7 +186,10 @@ jit_compile_expr(struct ExprState *state)
void
InstrJitAgg(JitInstrumentation *dst, JitInstrumentation *add)
{
+ dst->created_modules += add->created_modules;
dst->created_functions += add->created_functions;
+ dst->created_expr_functions += add->created_expr_functions;
+ dst->created_deform_functions += add->created_deform_functions;
INSTR_TIME_ADD(dst->generation_counter, add->generation_counter);
INSTR_TIME_ADD(dst->inlining_counter, add->inlining_counter);
INSTR_TIME_ADD(dst->optimization_counter, add->optimization_counter);
diff --git a/src/backend/jit/llvm/llvmjit.c b/src/backend/jit/llvm/llvmjit.c
index 82c4afb7011..5489e118041 100644
--- a/src/backend/jit/llvm/llvmjit.c
+++ b/src/backend/jit/llvm/llvmjit.c
@@ -212,6 +212,8 @@ llvm_mutable_module(LLVMJitContext *context)
context->module = LLVMModuleCreateWithName("pg");
LLVMSetTarget(context->module, llvm_triple);
LLVMSetDataLayout(context->module, llvm_layout);
+
+ context->base.instr.created_modules++;
}
return context->module;
diff --git a/src/backend/jit/llvm/llvmjit_deform.c b/src/backend/jit/llvm/llvmjit_deform.c
index 835aea83e97..80a85858524 100644
--- a/src/backend/jit/llvm/llvmjit_deform.c
+++ b/src/backend/jit/llvm/llvmjit_deform.c
@@ -101,6 +101,7 @@ slot_compile_deform(LLVMJitContext *context, TupleDesc desc,
mod = llvm_mutable_module(context);
funcname = llvm_expand_funcname(context, "deform");
+ context->base.instr.created_deform_functions++;
/*
* Check which columns have to exist, so we don't have to check the row's
diff --git a/src/backend/jit/llvm/llvmjit_expr.c b/src/backend/jit/llvm/llvmjit_expr.c
index 30133634c70..7efc8f23ee3 100644
--- a/src/backend/jit/llvm/llvmjit_expr.c
+++ b/src/backend/jit/llvm/llvmjit_expr.c
@@ -144,6 +144,7 @@ llvm_compile_expr(ExprState *state)
b = LLVMCreateBuilder();
funcname = llvm_expand_funcname(context, "evalexpr");
+ context->base.instr.created_expr_functions++;
/* Create the signature and function */
{
diff --git a/src/include/jit/jit.h b/src/include/jit/jit.h
index d879cef20f3..668f965cb0a 100644
--- a/src/include/jit/jit.h
+++ b/src/include/jit/jit.h
@@ -26,9 +26,18 @@
typedef struct JitInstrumentation
{
- /* number of emitted functions */
+ /* number of modules (i.e. separate optimize / link cycles) created */
+ size_t created_modules;
+
+ /* number of functions generated */
size_t created_functions;
+ /* number of expression evaluation functions generated */
+ size_t created_expr_functions;
+
+ /* number of tuple deforming functions generated */
+ size_t created_deform_functions;
+
/* accumulated time to generate code */
instr_time generation_counter;
--
2.23.0.162.gf1d4a28250
--kgppz6muakthis74
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v1-0002-Refactor-explain.c-to-pass-ExprState-down-to-show.patch"
^ permalink raw reply [nested|flat] 17+ messages in thread
* [PATCH v2 1/8] jit: Instrument function purpose separately, add tracking of modules.
@ 2019-09-26 18:44 Andres Freund <[email protected]>
0 siblings, 0 replies; 17+ messages in thread
From: Andres Freund @ 2019-09-26 18:44 UTC (permalink / raw)
Author:
Reviewed-By:
Discussion: https://postgr.es/m/
Backpatch:
---
src/backend/commands/explain.c | 24 +++++++++++++++++++++++-
src/backend/jit/jit.c | 3 +++
src/backend/jit/llvm/llvmjit.c | 2 ++
src/backend/jit/llvm/llvmjit_deform.c | 1 +
src/backend/jit/llvm/llvmjit_expr.c | 1 +
src/include/jit/jit.h | 11 ++++++++++-
6 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/src/backend/commands/explain.c b/src/backend/commands/explain.c
index 62fb3434a32..ef65035bfba 100644
--- a/src/backend/commands/explain.c
+++ b/src/backend/commands/explain.c
@@ -825,7 +825,26 @@ ExplainPrintJIT(ExplainState *es, int jit_flags,
appendStringInfoString(es->str, "JIT:\n");
es->indent += 1;
- ExplainPropertyInteger("Functions", NULL, ji->created_functions, es);
+ /* having to emit code more than once has performance consequences */
+ if (ji->created_modules > 1)
+ ExplainPropertyInteger("Modules", NULL, ji->created_modules, es);
+
+ appendStringInfoSpaces(es->str, es->indent * 2);
+ appendStringInfo(es->str, "Functions: %zu", ji->created_functions);
+ if (ji->created_expr_functions > 0 || ji->created_deform_functions)
+ {
+ appendStringInfoString(es->str, " (");
+ if (ji->created_expr_functions)
+ {
+ appendStringInfo(es->str, "%zu for expression evaluation", ji->created_expr_functions);
+ if (ji->created_deform_functions)
+ appendStringInfoString(es->str, ", ");
+ }
+ if (ji->created_deform_functions)
+ appendStringInfo(es->str, "%zu for tuple deforming", ji->created_deform_functions);
+ appendStringInfoChar(es->str, ')');
+ }
+ appendStringInfoChar(es->str, '\n');
appendStringInfoSpaces(es->str, es->indent * 2);
appendStringInfo(es->str, "Options: %s %s, %s %s, %s %s, %s %s\n",
@@ -851,7 +870,10 @@ ExplainPrintJIT(ExplainState *es, int jit_flags,
else
{
ExplainPropertyInteger("Worker Number", NULL, worker_num, es);
+ ExplainPropertyInteger("Modules", NULL, ji->created_modules, es);
ExplainPropertyInteger("Functions", NULL, ji->created_functions, es);
+ ExplainPropertyInteger("Expression Functions", NULL, ji->created_expr_functions, es);
+ ExplainPropertyInteger("Deforming Functions", NULL, ji->created_deform_functions, es);
ExplainOpenGroup("Options", "Options", true, es);
ExplainPropertyBool("Inlining", jit_flags & PGJIT_INLINE, es);
diff --git a/src/backend/jit/jit.c b/src/backend/jit/jit.c
index 43e65b1a543..63c709002d8 100644
--- a/src/backend/jit/jit.c
+++ b/src/backend/jit/jit.c
@@ -186,7 +186,10 @@ jit_compile_expr(struct ExprState *state)
void
InstrJitAgg(JitInstrumentation *dst, JitInstrumentation *add)
{
+ dst->created_modules += add->created_modules;
dst->created_functions += add->created_functions;
+ dst->created_expr_functions += add->created_expr_functions;
+ dst->created_deform_functions += add->created_deform_functions;
INSTR_TIME_ADD(dst->generation_counter, add->generation_counter);
INSTR_TIME_ADD(dst->inlining_counter, add->inlining_counter);
INSTR_TIME_ADD(dst->optimization_counter, add->optimization_counter);
diff --git a/src/backend/jit/llvm/llvmjit.c b/src/backend/jit/llvm/llvmjit.c
index 82c4afb7011..5489e118041 100644
--- a/src/backend/jit/llvm/llvmjit.c
+++ b/src/backend/jit/llvm/llvmjit.c
@@ -212,6 +212,8 @@ llvm_mutable_module(LLVMJitContext *context)
context->module = LLVMModuleCreateWithName("pg");
LLVMSetTarget(context->module, llvm_triple);
LLVMSetDataLayout(context->module, llvm_layout);
+
+ context->base.instr.created_modules++;
}
return context->module;
diff --git a/src/backend/jit/llvm/llvmjit_deform.c b/src/backend/jit/llvm/llvmjit_deform.c
index 835aea83e97..80a85858524 100644
--- a/src/backend/jit/llvm/llvmjit_deform.c
+++ b/src/backend/jit/llvm/llvmjit_deform.c
@@ -101,6 +101,7 @@ slot_compile_deform(LLVMJitContext *context, TupleDesc desc,
mod = llvm_mutable_module(context);
funcname = llvm_expand_funcname(context, "deform");
+ context->base.instr.created_deform_functions++;
/*
* Check which columns have to exist, so we don't have to check the row's
diff --git a/src/backend/jit/llvm/llvmjit_expr.c b/src/backend/jit/llvm/llvmjit_expr.c
index d09324637b9..4ba8c78cbc9 100644
--- a/src/backend/jit/llvm/llvmjit_expr.c
+++ b/src/backend/jit/llvm/llvmjit_expr.c
@@ -144,6 +144,7 @@ llvm_compile_expr(ExprState *state)
b = LLVMCreateBuilder();
funcname = llvm_expand_funcname(context, "evalexpr");
+ context->base.instr.created_expr_functions++;
/* Create the signature and function */
{
diff --git a/src/include/jit/jit.h b/src/include/jit/jit.h
index d879cef20f3..668f965cb0a 100644
--- a/src/include/jit/jit.h
+++ b/src/include/jit/jit.h
@@ -26,9 +26,18 @@
typedef struct JitInstrumentation
{
- /* number of emitted functions */
+ /* number of modules (i.e. separate optimize / link cycles) created */
+ size_t created_modules;
+
+ /* number of functions generated */
size_t created_functions;
+ /* number of expression evaluation functions generated */
+ size_t created_expr_functions;
+
+ /* number of tuple deforming functions generated */
+ size_t created_deform_functions;
+
/* accumulated time to generate code */
instr_time generation_counter;
--
2.23.0.385.gbc12974a89
--ga6shgqrocqphdjc
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v2-0002-Refactor-explain.c-to-pass-ExprState-down-to-show.patch"
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: Psql meta-command conninfo+
@ 2025-01-10 07:47 Hunaid Sohail <[email protected]>
2025-01-13 08:44 ` Re: Psql meta-command conninfo+ Alvaro Herrera <[email protected]>
0 siblings, 1 reply; 17+ messages in thread
From: Hunaid Sohail @ 2025-01-10 07:47 UTC (permalink / raw)
To: Sami Imseih <[email protected]>; +Cc: David G. Johnston <[email protected]>; Alvaro Herrera <[email protected]>; Maiquel Grassi <[email protected]>; pgsql-hackers; Jim Jones <[email protected]>; Tom Lane <[email protected]>; Nathan Bossart <[email protected]>; Imseih (AWS), Sami <[email protected]>; Peter Eisentraut <[email protected]>; Pavel Luzanov <[email protected]>; Erik Wienhold <[email protected]>
Hi,
On Fri, Jan 10, 2025 at 1:50 AM Sami Imseih <[email protected]> wrote:
> > If we go with the 3 column format, then we will just
> > have a bunch of repeated values for Category, which
> > looks cluttered, IMO.
>
> "cluttered" is maybe the wrong description. I meant the output
> will look overwhelming due to the repeated values :)
>
+1.
To summarize:
- Alvaro is not happy with \conninfo+ printing multiple tables and suggests
we continue with v35.
- Sami is ok with both approaches but thinks that \conninfo+ should also
print all parameters from PQparameterStatus in a dynamic way. Also, he
suggests to include "role" if we are showing is_superuser.
For that, we need two more patches:
1. Mark role as GUC_REPORT with necessary doc changes.
2. Add a new libpq function (perhaps PQparameterNames) to return the names
of parameters, so we can also display parameters added in the future,
along with doc updates.
- David wants category information included.
IMO, we should continue with v35 and add all parameters from
PQparameterStatus,
as Sami suggested. The names themselves are informative enough.
Looking forward to your feedback.
Regards,
Hunaid Sohail
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: Psql meta-command conninfo+
2025-01-10 07:47 Re: Psql meta-command conninfo+ Hunaid Sohail <[email protected]>
@ 2025-01-13 08:44 ` Alvaro Herrera <[email protected]>
2025-01-13 11:12 ` Re: Psql meta-command conninfo+ Dean Rasheed <[email protected]>
0 siblings, 1 reply; 17+ messages in thread
From: Alvaro Herrera @ 2025-01-13 08:44 UTC (permalink / raw)
To: Hunaid Sohail <[email protected]>; +Cc: Sami Imseih <[email protected]>; David G. Johnston <[email protected]>; Maiquel Grassi <[email protected]>; pgsql-hackers; Jim Jones <[email protected]>; Tom Lane <[email protected]>; Nathan Bossart <[email protected]>; Imseih (AWS), Sami <[email protected]>; Peter Eisentraut <[email protected]>; Pavel Luzanov <[email protected]>; Erik Wienhold <[email protected]>
On 2025-Jan-10, Hunaid Sohail wrote:
> IMO, we should continue with v35 and add all parameters from
> PQparameterStatus,
> as Sami suggested. The names themselves are informative enough.
IMO we need more opinions. Maybe enough other people are not as unhappy
about the three-table solution.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: Psql meta-command conninfo+
2025-01-10 07:47 Re: Psql meta-command conninfo+ Hunaid Sohail <[email protected]>
2025-01-13 08:44 ` Re: Psql meta-command conninfo+ Alvaro Herrera <[email protected]>
@ 2025-01-13 11:12 ` Dean Rasheed <[email protected]>
2025-01-14 07:57 ` Re: Psql meta-command conninfo+ Hunaid Sohail <[email protected]>
0 siblings, 1 reply; 17+ messages in thread
From: Dean Rasheed @ 2025-01-13 11:12 UTC (permalink / raw)
To: Alvaro Herrera <[email protected]>; +Cc: Hunaid Sohail <[email protected]>; Sami Imseih <[email protected]>; David G. Johnston <[email protected]>; Maiquel Grassi <[email protected]>; pgsql-hackers; Jim Jones <[email protected]>; Tom Lane <[email protected]>; Nathan Bossart <[email protected]>; Imseih (AWS), Sami <[email protected]>; Peter Eisentraut <[email protected]>; Pavel Luzanov <[email protected]>; Erik Wienhold <[email protected]>
On Mon, 13 Jan 2025 at 08:44, Alvaro Herrera <[email protected]> wrote:
>
> > IMO, we should continue with v35 and add all parameters from
> > PQparameterStatus,
> > as Sami suggested. The names themselves are informative enough.
>
> IMO we need more opinions. Maybe enough other people are not as unhappy
> about the three-table solution.
>
I don't like the 3-table format either. I think it should be a single table.
The trouble with v35 is that it produces 1 row with lots of columns,
which is pretty unreadable unless expanded mode is used. So I think we
should just do it that way round by default -- i.e., make it like
\dconfig and have 2 columns, "Parameter" and "Value", with lots of
rows.
Perhaps it could also have a "Description" column, which might help
with things like distinguishing between authenticated user and session
user.
Regards,
Dean
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: Psql meta-command conninfo+
2025-01-10 07:47 Re: Psql meta-command conninfo+ Hunaid Sohail <[email protected]>
2025-01-13 08:44 ` Re: Psql meta-command conninfo+ Alvaro Herrera <[email protected]>
2025-01-13 11:12 ` Re: Psql meta-command conninfo+ Dean Rasheed <[email protected]>
@ 2025-01-14 07:57 ` Hunaid Sohail <[email protected]>
2025-01-14 08:51 ` Re: Psql meta-command conninfo+ Alvaro Herrera <[email protected]>
0 siblings, 1 reply; 17+ messages in thread
From: Hunaid Sohail @ 2025-01-14 07:57 UTC (permalink / raw)
To: Dean Rasheed <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; Sami Imseih <[email protected]>; David G. Johnston <[email protected]>; Maiquel Grassi <[email protected]>; pgsql-hackers; Jim Jones <[email protected]>; Tom Lane <[email protected]>; Nathan Bossart <[email protected]>; Imseih (AWS), Sami <[email protected]>; Peter Eisentraut <[email protected]>; Pavel Luzanov <[email protected]>; Erik Wienhold <[email protected]>
Hi,
On Mon, Jan 13, 2025 at 4:12 PM Dean Rasheed <[email protected]>
wrote:
> I don't like the 3-table format either. I think it should be a single
> table.
>
> The trouble with v35 is that it produces 1 row with lots of columns,
> which is pretty unreadable unless expanded mode is used. So I think we
> should just do it that way round by default -- i.e., make it like
> \dconfig and have 2 columns, "Parameter" and "Value", with lots of
> rows.
>
> Perhaps it could also have a "Description" column, which might help
> with things like distinguishing between authenticated user and session
> user.
>
I've tried the approach and attached the output.
I'm not attaching the patch as it requires some formatting. Does this look
good?
I have added a one liner description that is consistent with libpq docs.
postgres=# \conninfo+
Connection Information
Parameter | Value |
Description
----------------------+------------------------+--------------------------------------------------------------------------------
Database | postgres | Displays the database name
of the connection.
Client User | hunaid | Displays the name of the
user connected to the database as returned by PQuser.
Host | localhost | Displays the server host
name of the active connection.
Host Address | 127.0.0.1 | Displays the server IP
address of the active connection.
Port | 5430 | Displays the port number
used for the database connection.
Options | | Displays any command-line
options passed in the connection request.
Protocol Version | 3 | Displays the
frontend/backend protocol being used.
Password Used | false | Indicates whether a
password was used during authentication.
GSSAPI Authenticated | false | Indicates if GSSAPI
authentication was used for the connection.
Backend PID | 43465 | Displays the process ID of
the backend for the connection.
SSL Connection | true | Indicates whether SSL
encryption is in use for the connection.
SSL Protocol | TLSv1.3 | Displays the SSL protocol
used for the connection.
SSL Cipher | TLS_AES_256_GCM_SHA384 | Displays the SSL cipher
used for the connection.
SSL Compression | off | Indicates whether SSL
compression is enabled.
ALPN | postgresql | Displays the ALPN protocol
used in the SSL connection.
(15 rows)
I was wondering how we can show the descriptions of parameters
from PQparameterStatus. We can create an array of descriptions,
but if the order changes somehow, it can mess things up.
Looking forward to your opinions. Can we continue with this approach?
Regards,
Hunaid Sohail
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: Psql meta-command conninfo+
2025-01-10 07:47 Re: Psql meta-command conninfo+ Hunaid Sohail <[email protected]>
2025-01-13 08:44 ` Re: Psql meta-command conninfo+ Alvaro Herrera <[email protected]>
2025-01-13 11:12 ` Re: Psql meta-command conninfo+ Dean Rasheed <[email protected]>
2025-01-14 07:57 ` Re: Psql meta-command conninfo+ Hunaid Sohail <[email protected]>
@ 2025-01-14 08:51 ` Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 17+ messages in thread
From: Alvaro Herrera @ 2025-01-14 08:51 UTC (permalink / raw)
To: Hunaid Sohail <[email protected]>; +Cc: Dean Rasheed <[email protected]>; Sami Imseih <[email protected]>; David G. Johnston <[email protected]>; Maiquel Grassi <[email protected]>; pgsql-hackers; Jim Jones <[email protected]>; Tom Lane <[email protected]>; Nathan Bossart <[email protected]>; Imseih (AWS), Sami <[email protected]>; Peter Eisentraut <[email protected]>; Pavel Luzanov <[email protected]>; Erik Wienhold <[email protected]>
On 2025-Jan-14, Hunaid Sohail wrote:
> I'm not attaching the patch as it requires some formatting.
Remember pgindent formats code in bulk. A quick useful workflow is to
do that first, apply manual adjustments next, run pgindent again
afterwards.
> I've tried the approach and attached the output. Does this look good?
Hmm, I'm not sure I like the third column particularly; it's noisy to
have on all the time. I'd leave that for \conninfo++ maybe :-)
_If_ we keep the descriptions, I suggest that the majority need to be
very short, say three words tops, with exceptions allowed for egregious
cases (if any). We should get rid of filler words such as "Displays
the" or "Indicates whether". For instance, I'd turn "Indicates if
GSSAPI authentication was used for the connection" into "GSSAPI
authenticated?" which conveys exactly the same; the ending "?" matches
things like "Key?" in \d of an index or the "Default?" column in \dc.
It's a boolean, so people know how to read it.
> I was wondering how we can show the descriptions of parameters
> from PQparameterStatus. We can create an array of descriptions,
> but if the order changes somehow, it can mess things up.
Definitely avoid writing code that can easily be broken by later changes
(future parameter additions and so on).
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"The problem with the facetime model is not just that it's demoralizing, but
that the people pretending to work interrupt the ones actually working."
-- Paul Graham, http://www.paulgraham.com/opensource.html
^ permalink raw reply [nested|flat] 17+ messages in thread
* [PATCH v44b 2/4] Do not dereference varattrib_4b in VARSIZE_4B.
@ 2026-03-11 13:53 Antonin Houska <[email protected]>
0 siblings, 0 replies; 17+ messages in thread
From: Antonin Houska @ 2026-03-11 13:53 UTC (permalink / raw)
Since VARSIZE_ANY() may call VARSIZE_4B(), it's possible that the compiler
(when invoked with -Warray-bounds) complains if the argument of VARSIZE_ANY()
is actually smaller than what VARSIZE_4B() expects. This patch adjusts the
VARSIZE_4B() macro so that it does not have to dereference the varattrib_4b
structure. We assume that varlena value always starts with the length word.
The problem does not exist in the tree at the moment since the current users
of VARSIZE_ANY() pass a pointer to a dynamically allocated memory, so the
compiler has no idea about the memory available. However, in an upcoming
patch, it makes sense to pass a pointer to a local variable of "varlena"
type. In such a case, the compiler warning might appear because
sizeof(varlena) is lower than sizeof(varattrib_4b).
---
src/include/varatt.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/include/varatt.h b/src/include/varatt.h
index 000bdf33b92..31063e5d4f1 100644
--- a/src/include/varatt.h
+++ b/src/include/varatt.h
@@ -207,7 +207,7 @@ typedef struct
/* VARSIZE_4B() should only be used on known-aligned data */
#define VARSIZE_4B(PTR) \
- (((const varattrib_4b *) (PTR))->va_4byte.va_header & 0x3FFFFFFF)
+ (*((const uint32 *) (PTR)) & 0x3FFFFFFF)
#define VARSIZE_1B(PTR) \
(((const varattrib_1b *) (PTR))->va_header & 0x7F)
#define VARTAG_1B_E(PTR) \
@@ -240,7 +240,7 @@ typedef struct
/* VARSIZE_4B() should only be used on known-aligned data */
#define VARSIZE_4B(PTR) \
- ((((const varattrib_4b *) (PTR))->va_4byte.va_header >> 2) & 0x3FFFFFFF)
+ ((*((const uint32 *) (PTR)) >> 2) & 0x3FFFFFFF)
#define VARSIZE_1B(PTR) \
((((const varattrib_1b *) (PTR))->va_header >> 1) & 0x7F)
#define VARTAG_1B_E(PTR) \
--
2.47.3
--fot5plqmb33ey33c
Content-Type: text/x-diff; charset=utf-8
Content-Disposition: attachment;
filename="v44b-0003-Add-CONCURRENTLY-option-to-REPACK-command.patch"
^ permalink raw reply [nested|flat] 17+ messages in thread
* [PATCH v45 2/8] Do not dereference varattrib_4b in VARSIZE_4B.
@ 2026-03-11 13:53 Antonin Houska <[email protected]>
0 siblings, 0 replies; 17+ messages in thread
From: Antonin Houska @ 2026-03-11 13:53 UTC (permalink / raw)
Since VARSIZE_ANY() may call VARSIZE_4B(), it's possible that the compiler
(when invoked with -Warray-bounds) complains if the argument of VARSIZE_ANY()
is actually smaller than what VARSIZE_4B() expects. This patch adjusts the
VARSIZE_4B() macro so that it does not have to dereference the varattrib_4b
structure. We assume that varlena value always starts with the length word.
The problem does not exist in the tree at the moment since the current users
of VARSIZE_ANY() pass a pointer to a dynamically allocated memory, so the
compiler has no idea about the memory available. However, in an upcoming
patch, it makes sense to pass a pointer to a local variable of "varlena"
type. In such a case, the compiler warning might appear because
sizeof(varlena) is lower than sizeof(varattrib_4b).
---
src/include/varatt.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/include/varatt.h b/src/include/varatt.h
index 000bdf33b92..31063e5d4f1 100644
--- a/src/include/varatt.h
+++ b/src/include/varatt.h
@@ -207,7 +207,7 @@ typedef struct
/* VARSIZE_4B() should only be used on known-aligned data */
#define VARSIZE_4B(PTR) \
- (((const varattrib_4b *) (PTR))->va_4byte.va_header & 0x3FFFFFFF)
+ (*((const uint32 *) (PTR)) & 0x3FFFFFFF)
#define VARSIZE_1B(PTR) \
(((const varattrib_1b *) (PTR))->va_header & 0x7F)
#define VARTAG_1B_E(PTR) \
@@ -240,7 +240,7 @@ typedef struct
/* VARSIZE_4B() should only be used on known-aligned data */
#define VARSIZE_4B(PTR) \
- ((((const varattrib_4b *) (PTR))->va_4byte.va_header >> 2) & 0x3FFFFFFF)
+ ((*((const uint32 *) (PTR)) >> 2) & 0x3FFFFFFF)
#define VARSIZE_1B(PTR) \
((((const varattrib_1b *) (PTR))->va_header >> 1) & 0x7F)
#define VARTAG_1B_E(PTR) \
--
2.47.3
--cldir6umqisr673d
Content-Type: text/x-diff; charset=utf-8
Content-Disposition: attachment;
filename="v45-0003-Add-CONCURRENTLY-option-to-REPACK-command.patch"
^ permalink raw reply [nested|flat] 17+ messages in thread
* [PATCH v44b 2/4] Do not dereference varattrib_4b in VARSIZE_4B.
@ 2026-03-11 13:53 Antonin Houska <[email protected]>
0 siblings, 0 replies; 17+ messages in thread
From: Antonin Houska @ 2026-03-11 13:53 UTC (permalink / raw)
Since VARSIZE_ANY() may call VARSIZE_4B(), it's possible that the compiler
(when invoked with -Warray-bounds) complains if the argument of VARSIZE_ANY()
is actually smaller than what VARSIZE_4B() expects. This patch adjusts the
VARSIZE_4B() macro so that it does not have to dereference the varattrib_4b
structure. We assume that varlena value always starts with the length word.
The problem does not exist in the tree at the moment since the current users
of VARSIZE_ANY() pass a pointer to a dynamically allocated memory, so the
compiler has no idea about the memory available. However, in an upcoming
patch, it makes sense to pass a pointer to a local variable of "varlena"
type. In such a case, the compiler warning might appear because
sizeof(varlena) is lower than sizeof(varattrib_4b).
---
src/include/varatt.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/include/varatt.h b/src/include/varatt.h
index 000bdf33b92..31063e5d4f1 100644
--- a/src/include/varatt.h
+++ b/src/include/varatt.h
@@ -207,7 +207,7 @@ typedef struct
/* VARSIZE_4B() should only be used on known-aligned data */
#define VARSIZE_4B(PTR) \
- (((const varattrib_4b *) (PTR))->va_4byte.va_header & 0x3FFFFFFF)
+ (*((const uint32 *) (PTR)) & 0x3FFFFFFF)
#define VARSIZE_1B(PTR) \
(((const varattrib_1b *) (PTR))->va_header & 0x7F)
#define VARTAG_1B_E(PTR) \
@@ -240,7 +240,7 @@ typedef struct
/* VARSIZE_4B() should only be used on known-aligned data */
#define VARSIZE_4B(PTR) \
- ((((const varattrib_4b *) (PTR))->va_4byte.va_header >> 2) & 0x3FFFFFFF)
+ ((*((const uint32 *) (PTR)) >> 2) & 0x3FFFFFFF)
#define VARSIZE_1B(PTR) \
((((const varattrib_1b *) (PTR))->va_header >> 1) & 0x7F)
#define VARTAG_1B_E(PTR) \
--
2.47.3
--fot5plqmb33ey33c
Content-Type: text/x-diff; charset=utf-8
Content-Disposition: attachment;
filename="v44b-0003-Add-CONCURRENTLY-option-to-REPACK-command.patch"
^ permalink raw reply [nested|flat] 17+ messages in thread
* [PATCH 2/7] Do not dereference varattrib_4b in VARSIZE_4B.
@ 2026-03-11 13:53 Antonin Houska <[email protected]>
0 siblings, 0 replies; 17+ messages in thread
From: Antonin Houska @ 2026-03-11 13:53 UTC (permalink / raw)
Since VARSIZE_ANY() may call VARSIZE_4B(), it's possible that the compiler
(when invoked with -Warray-bounds) complains if the argument of VARSIZE_ANY()
is actually smaller than what VARSIZE_4B() expects. This patch adjusts the
VARSIZE_4B() macro so that it does not have to dereference the varattrib_4b
structure. We assume that varlena value always starts with the length word.
The problem does not exist in the tree at the moment since the current users
of VARSIZE_ANY() pass a pointer to a dynamically allocated memory, so the
compiler has no idea about the memory available. However, in an upcoming
patch, it makes sense to pass a pointer to a local variable of "varlena"
type. In such a case, the compiler warning might appear because
sizeof(varlena) is lower than sizeof(varattrib_4b).
---
src/include/varatt.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/include/varatt.h b/src/include/varatt.h
index 000bdf33b92..31063e5d4f1 100644
--- a/src/include/varatt.h
+++ b/src/include/varatt.h
@@ -207,7 +207,7 @@ typedef struct
/* VARSIZE_4B() should only be used on known-aligned data */
#define VARSIZE_4B(PTR) \
- (((const varattrib_4b *) (PTR))->va_4byte.va_header & 0x3FFFFFFF)
+ (*((const uint32 *) (PTR)) & 0x3FFFFFFF)
#define VARSIZE_1B(PTR) \
(((const varattrib_1b *) (PTR))->va_header & 0x7F)
#define VARTAG_1B_E(PTR) \
@@ -240,7 +240,7 @@ typedef struct
/* VARSIZE_4B() should only be used on known-aligned data */
#define VARSIZE_4B(PTR) \
- ((((const varattrib_4b *) (PTR))->va_4byte.va_header >> 2) & 0x3FFFFFFF)
+ ((*((const uint32 *) (PTR)) >> 2) & 0x3FFFFFFF)
#define VARSIZE_1B(PTR) \
((((const varattrib_1b *) (PTR))->va_header >> 1) & 0x7F)
#define VARTAG_1B_E(PTR) \
--
2.47.3
--=-=-=
Content-Type: text/plain
Content-Disposition: attachment;
filename=v42-0003-Add-CONCURRENTLY-option-to-REPACK-command.patch
^ permalink raw reply [nested|flat] 17+ messages in thread
* [PATCH v44 02/10] Do not dereference varattrib_4b in VARSIZE_4B.
@ 2026-03-11 13:53 Antonin Houska <[email protected]>
0 siblings, 0 replies; 17+ messages in thread
From: Antonin Houska @ 2026-03-11 13:53 UTC (permalink / raw)
Since VARSIZE_ANY() may call VARSIZE_4B(), it's possible that the compiler
(when invoked with -Warray-bounds) complains if the argument of VARSIZE_ANY()
is actually smaller than what VARSIZE_4B() expects. This patch adjusts the
VARSIZE_4B() macro so that it does not have to dereference the varattrib_4b
structure. We assume that varlena value always starts with the length word.
The problem does not exist in the tree at the moment since the current users
of VARSIZE_ANY() pass a pointer to a dynamically allocated memory, so the
compiler has no idea about the memory available. However, in an upcoming
patch, it makes sense to pass a pointer to a local variable of "varlena"
type. In such a case, the compiler warning might appear because
sizeof(varlena) is lower than sizeof(varattrib_4b).
---
src/include/varatt.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/include/varatt.h b/src/include/varatt.h
index 000bdf33b92..31063e5d4f1 100644
--- a/src/include/varatt.h
+++ b/src/include/varatt.h
@@ -207,7 +207,7 @@ typedef struct
/* VARSIZE_4B() should only be used on known-aligned data */
#define VARSIZE_4B(PTR) \
- (((const varattrib_4b *) (PTR))->va_4byte.va_header & 0x3FFFFFFF)
+ (*((const uint32 *) (PTR)) & 0x3FFFFFFF)
#define VARSIZE_1B(PTR) \
(((const varattrib_1b *) (PTR))->va_header & 0x7F)
#define VARTAG_1B_E(PTR) \
@@ -240,7 +240,7 @@ typedef struct
/* VARSIZE_4B() should only be used on known-aligned data */
#define VARSIZE_4B(PTR) \
- ((((const varattrib_4b *) (PTR))->va_4byte.va_header >> 2) & 0x3FFFFFFF)
+ ((*((const uint32 *) (PTR)) >> 2) & 0x3FFFFFFF)
#define VARSIZE_1B(PTR) \
((((const varattrib_1b *) (PTR))->va_header >> 1) & 0x7F)
#define VARTAG_1B_E(PTR) \
--
2.47.3
--gwom7bl7ogtszo4k
Content-Type: text/x-diff; charset=utf-8
Content-Disposition: attachment;
filename="v44-0003-Add-CONCURRENTLY-option-to-REPACK-command.patch"
^ permalink raw reply [nested|flat] 17+ messages in thread
* [PATCH v45 2/8] Do not dereference varattrib_4b in VARSIZE_4B.
@ 2026-03-11 13:53 Antonin Houska <[email protected]>
0 siblings, 0 replies; 17+ messages in thread
From: Antonin Houska @ 2026-03-11 13:53 UTC (permalink / raw)
Since VARSIZE_ANY() may call VARSIZE_4B(), it's possible that the compiler
(when invoked with -Warray-bounds) complains if the argument of VARSIZE_ANY()
is actually smaller than what VARSIZE_4B() expects. This patch adjusts the
VARSIZE_4B() macro so that it does not have to dereference the varattrib_4b
structure. We assume that varlena value always starts with the length word.
The problem does not exist in the tree at the moment since the current users
of VARSIZE_ANY() pass a pointer to a dynamically allocated memory, so the
compiler has no idea about the memory available. However, in an upcoming
patch, it makes sense to pass a pointer to a local variable of "varlena"
type. In such a case, the compiler warning might appear because
sizeof(varlena) is lower than sizeof(varattrib_4b).
---
src/include/varatt.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/include/varatt.h b/src/include/varatt.h
index 000bdf33b92..31063e5d4f1 100644
--- a/src/include/varatt.h
+++ b/src/include/varatt.h
@@ -207,7 +207,7 @@ typedef struct
/* VARSIZE_4B() should only be used on known-aligned data */
#define VARSIZE_4B(PTR) \
- (((const varattrib_4b *) (PTR))->va_4byte.va_header & 0x3FFFFFFF)
+ (*((const uint32 *) (PTR)) & 0x3FFFFFFF)
#define VARSIZE_1B(PTR) \
(((const varattrib_1b *) (PTR))->va_header & 0x7F)
#define VARTAG_1B_E(PTR) \
@@ -240,7 +240,7 @@ typedef struct
/* VARSIZE_4B() should only be used on known-aligned data */
#define VARSIZE_4B(PTR) \
- ((((const varattrib_4b *) (PTR))->va_4byte.va_header >> 2) & 0x3FFFFFFF)
+ ((*((const uint32 *) (PTR)) >> 2) & 0x3FFFFFFF)
#define VARSIZE_1B(PTR) \
((((const varattrib_1b *) (PTR))->va_header >> 1) & 0x7F)
#define VARTAG_1B_E(PTR) \
--
2.47.3
--cldir6umqisr673d
Content-Type: text/x-diff; charset=utf-8
Content-Disposition: attachment;
filename="v45-0003-Add-CONCURRENTLY-option-to-REPACK-command.patch"
^ permalink raw reply [nested|flat] 17+ messages in thread
* [PATCH v43 2/7] Do not dereference varattrib_4b in VARSIZE_4B.
@ 2026-03-11 13:53 Antonin Houska <[email protected]>
0 siblings, 0 replies; 17+ messages in thread
From: Antonin Houska @ 2026-03-11 13:53 UTC (permalink / raw)
Since VARSIZE_ANY() may call VARSIZE_4B(), it's possible that the compiler
(when invoked with -Warray-bounds) complains if the argument of VARSIZE_ANY()
is actually smaller than what VARSIZE_4B() expects. This patch adjusts the
VARSIZE_4B() macro so that it does not have to dereference the varattrib_4b
structure. We assume that varlena value always starts with the length word.
The problem does not exist in the tree at the moment since the current users
of VARSIZE_ANY() pass a pointer to a dynamically allocated memory, so the
compiler has no idea about the memory available. However, in an upcoming
patch, it makes sense to pass a pointer to a local variable of "varlena"
type. In such a case, the compiler warning might appear because
sizeof(varlena) is lower than sizeof(varattrib_4b).
---
src/include/varatt.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/include/varatt.h b/src/include/varatt.h
index 000bdf33b92..31063e5d4f1 100644
--- a/src/include/varatt.h
+++ b/src/include/varatt.h
@@ -207,7 +207,7 @@ typedef struct
/* VARSIZE_4B() should only be used on known-aligned data */
#define VARSIZE_4B(PTR) \
- (((const varattrib_4b *) (PTR))->va_4byte.va_header & 0x3FFFFFFF)
+ (*((const uint32 *) (PTR)) & 0x3FFFFFFF)
#define VARSIZE_1B(PTR) \
(((const varattrib_1b *) (PTR))->va_header & 0x7F)
#define VARTAG_1B_E(PTR) \
@@ -240,7 +240,7 @@ typedef struct
/* VARSIZE_4B() should only be used on known-aligned data */
#define VARSIZE_4B(PTR) \
- ((((const varattrib_4b *) (PTR))->va_4byte.va_header >> 2) & 0x3FFFFFFF)
+ ((*((const uint32 *) (PTR)) >> 2) & 0x3FFFFFFF)
#define VARSIZE_1B(PTR) \
((((const varattrib_1b *) (PTR))->va_header >> 1) & 0x7F)
#define VARTAG_1B_E(PTR) \
--
2.47.3
--nzintiedl6o4kcyp
Content-Type: text/x-diff; charset=utf-8
Content-Disposition: attachment;
filename="v43-0003-Add-CONCURRENTLY-option-to-REPACK-command.patch"
^ permalink raw reply [nested|flat] 17+ messages in thread
* [PATCH 2/7] Do not dereference varattrib_4b in VARSIZE_4B.
@ 2026-03-11 13:53 Antonin Houska <[email protected]>
0 siblings, 0 replies; 17+ messages in thread
From: Antonin Houska @ 2026-03-11 13:53 UTC (permalink / raw)
Since VARSIZE_ANY() may call VARSIZE_4B(), it's possible that the compiler
(when invoked with -Warray-bounds) complains if the argument of VARSIZE_ANY()
is actually smaller than what VARSIZE_4B() expects. This patch adjusts the
VARSIZE_4B() macro so that it does not have to dereference the varattrib_4b
structure. We assume that varlena value always starts with the length word.
The problem does not exist in the tree at the moment since the current users
of VARSIZE_ANY() pass a pointer to a dynamically allocated memory, so the
compiler has no idea about the memory available. However, in an upcoming
patch, it makes sense to pass a pointer to a local variable of "varlena"
type. In such a case, the compiler warning might appear because
sizeof(varlena) is lower than sizeof(varattrib_4b).
---
src/include/varatt.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/include/varatt.h b/src/include/varatt.h
index 000bdf33b92..31063e5d4f1 100644
--- a/src/include/varatt.h
+++ b/src/include/varatt.h
@@ -207,7 +207,7 @@ typedef struct
/* VARSIZE_4B() should only be used on known-aligned data */
#define VARSIZE_4B(PTR) \
- (((const varattrib_4b *) (PTR))->va_4byte.va_header & 0x3FFFFFFF)
+ (*((const uint32 *) (PTR)) & 0x3FFFFFFF)
#define VARSIZE_1B(PTR) \
(((const varattrib_1b *) (PTR))->va_header & 0x7F)
#define VARTAG_1B_E(PTR) \
@@ -240,7 +240,7 @@ typedef struct
/* VARSIZE_4B() should only be used on known-aligned data */
#define VARSIZE_4B(PTR) \
- ((((const varattrib_4b *) (PTR))->va_4byte.va_header >> 2) & 0x3FFFFFFF)
+ ((*((const uint32 *) (PTR)) >> 2) & 0x3FFFFFFF)
#define VARSIZE_1B(PTR) \
((((const varattrib_1b *) (PTR))->va_header >> 1) & 0x7F)
#define VARTAG_1B_E(PTR) \
--
2.47.3
--=-=-=
Content-Type: text/plain
Content-Disposition: attachment;
filename=v42-0003-Add-CONCURRENTLY-option-to-REPACK-command.patch
^ permalink raw reply [nested|flat] 17+ messages in thread
* [PATCH v44 02/10] Do not dereference varattrib_4b in VARSIZE_4B.
@ 2026-03-11 13:53 Antonin Houska <[email protected]>
0 siblings, 0 replies; 17+ messages in thread
From: Antonin Houska @ 2026-03-11 13:53 UTC (permalink / raw)
Since VARSIZE_ANY() may call VARSIZE_4B(), it's possible that the compiler
(when invoked with -Warray-bounds) complains if the argument of VARSIZE_ANY()
is actually smaller than what VARSIZE_4B() expects. This patch adjusts the
VARSIZE_4B() macro so that it does not have to dereference the varattrib_4b
structure. We assume that varlena value always starts with the length word.
The problem does not exist in the tree at the moment since the current users
of VARSIZE_ANY() pass a pointer to a dynamically allocated memory, so the
compiler has no idea about the memory available. However, in an upcoming
patch, it makes sense to pass a pointer to a local variable of "varlena"
type. In such a case, the compiler warning might appear because
sizeof(varlena) is lower than sizeof(varattrib_4b).
---
src/include/varatt.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/include/varatt.h b/src/include/varatt.h
index 000bdf33b92..31063e5d4f1 100644
--- a/src/include/varatt.h
+++ b/src/include/varatt.h
@@ -207,7 +207,7 @@ typedef struct
/* VARSIZE_4B() should only be used on known-aligned data */
#define VARSIZE_4B(PTR) \
- (((const varattrib_4b *) (PTR))->va_4byte.va_header & 0x3FFFFFFF)
+ (*((const uint32 *) (PTR)) & 0x3FFFFFFF)
#define VARSIZE_1B(PTR) \
(((const varattrib_1b *) (PTR))->va_header & 0x7F)
#define VARTAG_1B_E(PTR) \
@@ -240,7 +240,7 @@ typedef struct
/* VARSIZE_4B() should only be used on known-aligned data */
#define VARSIZE_4B(PTR) \
- ((((const varattrib_4b *) (PTR))->va_4byte.va_header >> 2) & 0x3FFFFFFF)
+ ((*((const uint32 *) (PTR)) >> 2) & 0x3FFFFFFF)
#define VARSIZE_1B(PTR) \
((((const varattrib_1b *) (PTR))->va_header >> 1) & 0x7F)
#define VARTAG_1B_E(PTR) \
--
2.47.3
--gwom7bl7ogtszo4k
Content-Type: text/x-diff; charset=utf-8
Content-Disposition: attachment;
filename="v44-0003-Add-CONCURRENTLY-option-to-REPACK-command.patch"
^ permalink raw reply [nested|flat] 17+ messages in thread
* [PATCH v43 2/7] Do not dereference varattrib_4b in VARSIZE_4B.
@ 2026-03-11 13:53 Antonin Houska <[email protected]>
0 siblings, 0 replies; 17+ messages in thread
From: Antonin Houska @ 2026-03-11 13:53 UTC (permalink / raw)
Since VARSIZE_ANY() may call VARSIZE_4B(), it's possible that the compiler
(when invoked with -Warray-bounds) complains if the argument of VARSIZE_ANY()
is actually smaller than what VARSIZE_4B() expects. This patch adjusts the
VARSIZE_4B() macro so that it does not have to dereference the varattrib_4b
structure. We assume that varlena value always starts with the length word.
The problem does not exist in the tree at the moment since the current users
of VARSIZE_ANY() pass a pointer to a dynamically allocated memory, so the
compiler has no idea about the memory available. However, in an upcoming
patch, it makes sense to pass a pointer to a local variable of "varlena"
type. In such a case, the compiler warning might appear because
sizeof(varlena) is lower than sizeof(varattrib_4b).
---
src/include/varatt.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/include/varatt.h b/src/include/varatt.h
index 000bdf33b92..31063e5d4f1 100644
--- a/src/include/varatt.h
+++ b/src/include/varatt.h
@@ -207,7 +207,7 @@ typedef struct
/* VARSIZE_4B() should only be used on known-aligned data */
#define VARSIZE_4B(PTR) \
- (((const varattrib_4b *) (PTR))->va_4byte.va_header & 0x3FFFFFFF)
+ (*((const uint32 *) (PTR)) & 0x3FFFFFFF)
#define VARSIZE_1B(PTR) \
(((const varattrib_1b *) (PTR))->va_header & 0x7F)
#define VARTAG_1B_E(PTR) \
@@ -240,7 +240,7 @@ typedef struct
/* VARSIZE_4B() should only be used on known-aligned data */
#define VARSIZE_4B(PTR) \
- ((((const varattrib_4b *) (PTR))->va_4byte.va_header >> 2) & 0x3FFFFFFF)
+ ((*((const uint32 *) (PTR)) >> 2) & 0x3FFFFFFF)
#define VARSIZE_1B(PTR) \
((((const varattrib_1b *) (PTR))->va_header >> 1) & 0x7F)
#define VARTAG_1B_E(PTR) \
--
2.47.3
--nzintiedl6o4kcyp
Content-Type: text/x-diff; charset=utf-8
Content-Disposition: attachment;
filename="v43-0003-Add-CONCURRENTLY-option-to-REPACK-command.patch"
^ permalink raw reply [nested|flat] 17+ messages in thread
end of thread, other threads:[~2026-03-11 13:53 UTC | newest]
Thread overview: 17+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2019-09-26 18:44 [PATCH v1 01/12] jit: Instrument function purpose separately, add tracking of modules. Andres Freund <[email protected]>
2019-09-26 18:44 [PATCH v2 1/8] jit: Instrument function purpose separately, add tracking of modules. Andres Freund <[email protected]>
2025-01-10 07:47 Re: Psql meta-command conninfo+ Hunaid Sohail <[email protected]>
2025-01-13 08:44 ` Re: Psql meta-command conninfo+ Alvaro Herrera <[email protected]>
2025-01-13 11:12 ` Re: Psql meta-command conninfo+ Dean Rasheed <[email protected]>
2025-01-14 07:57 ` Re: Psql meta-command conninfo+ Hunaid Sohail <[email protected]>
2025-01-14 08:51 ` Re: Psql meta-command conninfo+ Alvaro Herrera <[email protected]>
2026-03-11 13:53 [PATCH v44b 2/4] Do not dereference varattrib_4b in VARSIZE_4B. Antonin Houska <[email protected]>
2026-03-11 13:53 [PATCH v45 2/8] Do not dereference varattrib_4b in VARSIZE_4B. Antonin Houska <[email protected]>
2026-03-11 13:53 [PATCH v44b 2/4] Do not dereference varattrib_4b in VARSIZE_4B. Antonin Houska <[email protected]>
2026-03-11 13:53 [PATCH 2/7] Do not dereference varattrib_4b in VARSIZE_4B. Antonin Houska <[email protected]>
2026-03-11 13:53 [PATCH v44 02/10] Do not dereference varattrib_4b in VARSIZE_4B. Antonin Houska <[email protected]>
2026-03-11 13:53 [PATCH v45 2/8] Do not dereference varattrib_4b in VARSIZE_4B. Antonin Houska <[email protected]>
2026-03-11 13:53 [PATCH v43 2/7] Do not dereference varattrib_4b in VARSIZE_4B. Antonin Houska <[email protected]>
2026-03-11 13:53 [PATCH 2/7] Do not dereference varattrib_4b in VARSIZE_4B. Antonin Houska <[email protected]>
2026-03-11 13:53 [PATCH v44 02/10] Do not dereference varattrib_4b in VARSIZE_4B. Antonin Houska <[email protected]>
2026-03-11 13:53 [PATCH v43 2/7] Do not dereference varattrib_4b in VARSIZE_4B. Antonin Houska <[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