agora inbox for [email protected]  

help / color / mirror / Atom feed

Re: LATERAL
4850+ messages / 6 participants
[nested] [flat]

* Re: LATERAL
@ 2009-10-18 00:58 Robert Haas <[email protected]>
  2009-10-18 01:08 ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-18 02:09 ` Re: LATERAL Tom Lane <[email protected]>
  0 siblings, 2 replies; 4850+ messages in thread

From: Robert Haas @ 2009-10-18 00:58 UTC (permalink / raw)
  To: Tom Lane <[email protected]>; +Cc: Andrew Gierth <[email protected]>; David Fetter <[email protected]>; pgsql-hackers

On Tue, Sep 22, 2009 at 11:21 PM, Tom Lane <[email protected]> wrote:
>> Currently, however, we only consider this possibility when the inner
>> rel is NOT a joinrel.  It seems like it might be possible to change
>> this, but it doesn't look straightforward.
>
> Well, it's straightforward enough in theory, it's just the exponential
> growth in the number of join paths to consider that's a problem :-(.
> I think what we'd need is a heuristic to limit the paths considered.

[ picking this up again now that CommitFest is over ]

So that I don't have to keep referring to "this possibility" and
similar circumlocution, let's define an index-accelerated path (feel
free to suggest a different term) to be the generalization to joinrels
of what we now call a nested inner index-scan.  In other words, they
can only be usefully used on the inner side of a nested loop, where
they'll be rescanned with different parameters for each outer row, and
they can only ever win when some part of the path involves a *partial*
index scan that can used one of the passed parameters as an index
qual.

For a fixed a set of parameters to be pushed down from the outer side,
it seems to me that we could build up a set of index-accelerated paths
for a joinrel {A B} by considering the combination of (1) an
index-accelerated path for A joined to an index-accelerated path for
B, or (2) an index-accelerated path for A joined to the cheapest total
path for B.  I believe we don't need to worry about path keys because
this will only ever be used on the inner side of a nested loop, so the
pathkeys will be ignored anyway.  In other words, the first heuristic
is that you can't build up an index-accelerated path for the joinrel
unless there is an index-accelerated path for a least one of its
baserels.

That still leaves a lot of silly paths, though.  In many cases, if
you're thinking about joining A to {B C} using an index-accelerated
path, you'd be just as well off joining to B first and then to C.  So
it might be that we only need to consider index-accelerated paths when
there is no legal join between the LHS and a subset of the RHS.  But
I'm not completely sure that I'm right about this, nor whether it's
easy to check for.

The other problem I see here is that the bottom-up approach that we
use in general is going to be difficult to apply here, because the set
of paths will vary depending on what parameters are pushed down from
the outer side.

> I think Andrew was suggesting that we not attempt to consider this
> automatically, but only when the user writes the query in a way that
> exposes it directly via LATERAL.  While that goes against my normal
> instincts for the planner, it isn't unreasonable as a first step.

Possibly, but I'm not sure we have a good enough design sketch at this
point to even know whether such a restriction would be useful.

Another thought, only semi-related.  One of the big use cases for
LATERAL in general is to use a set-returning function in the FROM
clause that uses vars from a preceding FROM item.  I am idly wondering
if there's a reason why ExecProject is not its own node type.  It
seems that we have close to the same logic scattered through a whole
bunch of different node types...

...Robert



^ permalink  raw  reply  [nested|flat] 4850+ messages in thread

* Re: LATERAL
  2009-10-18 00:58 Re: LATERAL Robert Haas <[email protected]>
@ 2009-10-18 01:08 ` Tom Lane <[email protected]>
  1 sibling, 0 replies; 4850+ messages in thread

From: Tom Lane @ 2009-10-18 01:08 UTC (permalink / raw)
  To: Robert Haas <[email protected]>; +Cc: Andrew Gierth <[email protected]>; David Fetter <[email protected]>; pgsql-hackers

Robert Haas <[email protected]> writes:
> Another thought, only semi-related.  One of the big use cases for
> LATERAL in general is to use a set-returning function in the FROM
> clause that uses vars from a preceding FROM item.  I am idly wondering
> if there's a reason why ExecProject is not its own node type.

You generally need it everywhere.  Scan nodes need it because you don't
want unused columns propagating upwards, and join nodes need it because
the two input tuples have to be unified somehow.  We do skip projection
ability in a few node types, but I doubt it would be profitable to
remove it from the rest.

			regards, tom lane



^ permalink  raw  reply  [nested|flat] 4850+ messages in thread

* Re: LATERAL
  2009-10-18 00:58 Re: LATERAL Robert Haas <[email protected]>
@ 2009-10-18 02:09 ` Tom Lane <[email protected]>
  2009-10-18 11:01   ` Re: LATERAL Robert Haas <[email protected]>
  1 sibling, 1 reply; 4850+ messages in thread

From: Tom Lane @ 2009-10-18 02:09 UTC (permalink / raw)
  To: Robert Haas <[email protected]>; +Cc: Andrew Gierth <[email protected]>; David Fetter <[email protected]>; pgsql-hackers

Robert Haas <[email protected]> writes:
> That still leaves a lot of silly paths, though.  In many cases, if
> you're thinking about joining A to {B C} using an index-accelerated
> path, you'd be just as well off joining to B first and then to C.  So
> it might be that we only need to consider index-accelerated paths when
> there is no legal join between the LHS and a subset of the RHS.

Yeah.  If there are no join order constraints, it's always possible to
form a plan such that you join a given rel only once you have all the
rels needed (to provide values for the inner indexscan) on the lefthand
side.  I think this is probably the main reason why the issue was not
treated in the planner originally.  So maybe the way to think about
this is as a way of dealing with join order constraints without losing
the benefits of inner indexscans.

> The other problem I see here is that the bottom-up approach that we
> use in general is going to be difficult to apply here, because the set
> of paths will vary depending on what parameters are pushed down from
> the outer side.

Well, we deal with that already --- the set of possible inner indexscan
paths already varies depending on what the LHS is.  I think the point
here is that we'd be considering an inner path that's against an LHS
that it's not legal to join the inner rel to *directly*.  Such a path
would only be legal if we later join to that LHS at a higher join level.
So we'd be keeping around some tentative paths that might not ever form
a valid join plan.

Maybe we should turn around the way that inner indexscan paths are
made.  Currently we form them on-the-fly while considering a valid
join combination.  Maybe we should build them all at the first level
(driving this off the set of available join clauses for each base rel)
and mark each such path as "requires a join to this other set of rels
to be valid".  But then we'd go ahead and join such paths to *other*
rels, keeping the resulting join paths still marked as requiring the
same future join.  Once that join actually happens, the resulting path
becomes fully valid.  Only a join to a proper subset of the future-join
requirement would be disallowed meanwhile.

I'm not even sure this would be slower or more complicated than what we
do now --- if you look at the logic that caches potential inner
indexscan plans, it's almost doing this already.  It would result in
considering more join paths, but only ones that have some plausible use.

			regards, tom lane



^ permalink  raw  reply  [nested|flat] 4850+ messages in thread

* Re: LATERAL
  2009-10-18 00:58 Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 02:09 ` Re: LATERAL Tom Lane <[email protected]>
@ 2009-10-18 11:01   ` Robert Haas <[email protected]>
  2009-10-18 15:30     ` Re: LATERAL Tom Lane <[email protected]>
  0 siblings, 1 reply; 4850+ messages in thread

From: Robert Haas @ 2009-10-18 11:01 UTC (permalink / raw)
  To: Tom Lane <[email protected]>; +Cc: Andrew Gierth <[email protected]>; David Fetter <[email protected]>; pgsql-hackers

On Sat, Oct 17, 2009 at 10:09 PM, Tom Lane <[email protected]> wrote:
> Robert Haas <[email protected]> writes:
>> That still leaves a lot of silly paths, though.  In many cases, if
>> you're thinking about joining A to {B C} using an index-accelerated
>> path, you'd be just as well off joining to B first and then to C.  So
>> it might be that we only need to consider index-accelerated paths when
>> there is no legal join between the LHS and a subset of the RHS.
>
> Yeah.  If there are no join order constraints, it's always possible to
> form a plan such that you join a given rel only once you have all the
> rels needed (to provide values for the inner indexscan) on the lefthand
> side.  I think this is probably the main reason why the issue was not
> treated in the planner originally.  So maybe the way to think about
> this is as a way of dealing with join order constraints without losing
> the benefits of inner indexscans.
>
>> The other problem I see here is that the bottom-up approach that we
>> use in general is going to be difficult to apply here, because the set
>> of paths will vary depending on what parameters are pushed down from
>> the outer side.
>
> Well, we deal with that already --- the set of possible inner indexscan
> paths already varies depending on what the LHS is.  I think the point
> here is that we'd be considering an inner path that's against an LHS
> that it's not legal to join the inner rel to *directly*.  Such a path
> would only be legal if we later join to that LHS at a higher join level.
> So we'd be keeping around some tentative paths that might not ever form
> a valid join plan.
>
> Maybe we should turn around the way that inner indexscan paths are
> made.  Currently we form them on-the-fly while considering a valid
> join combination.  Maybe we should build them all at the first level
> (driving this off the set of available join clauses for each base rel)
> and mark each such path as "requires a join to this other set of rels
> to be valid".  But then we'd go ahead and join such paths to *other*
> rels, keeping the resulting join paths still marked as requiring the
> same future join.  Once that join actually happens, the resulting path
> becomes fully valid.  Only a join to a proper subset of the future-join
> requirement would be disallowed meanwhile.
>
> I'm not even sure this would be slower or more complicated than what we
> do now --- if you look at the logic that caches potential inner
> indexscan plans, it's almost doing this already.  It would result in
> considering more join paths, but only ones that have some plausible use.

Wow, that's pretty sneaky.  I had to read this email twice before I
understood what you were proposing.  It sounds to me like it will
work.  I'm not 100% sure what the impact on planner performance will
be, but it's at least plausible that it will be OK.

I think you should only ever join an incomplete inner-indexscan path
to (1) another inner-indexscan path or (2) the cheapest total path for
*exactly* the future-join requirement.  Anything else doesn't seem
productive.

...Robert



^ permalink  raw  reply  [nested|flat] 4850+ messages in thread

* Re: LATERAL
  2009-10-18 00:58 Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 02:09 ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-18 11:01   ` Re: LATERAL Robert Haas <[email protected]>
@ 2009-10-18 15:30     ` Tom Lane <[email protected]>
  2009-10-18 19:36       ` Re: LATERAL Robert Haas <[email protected]>
  0 siblings, 1 reply; 4850+ messages in thread

From: Tom Lane @ 2009-10-18 15:30 UTC (permalink / raw)
  To: Robert Haas <[email protected]>; +Cc: Andrew Gierth <[email protected]>; David Fetter <[email protected]>; pgsql-hackers

Robert Haas <[email protected]> writes:
> I think you should only ever join an incomplete inner-indexscan path
> to (1) another inner-indexscan path or (2) the cheapest total path for
> *exactly* the future-join requirement.  Anything else doesn't seem
> productive.

I don't see any reason to constrain the form of joins before the
future-join requirement.  Once you get to the join that satisfies
that requirement, obviously you must implement it as a nestloop
with the inner-indexscan path on the inside.  But there shouldn't
be any more constraint beyond that one for that join, either:
	* you might want a fast-start plan not cheapest total
	* sort orderings of the outer path might be useful

We know that sort ordering of the inner indexscan or its joins
won't be useful once we reach the future-join level, so it might
be possible to discard paths that are not cheapest total cost
below that level.  The problem is to distinguish sort orderings
that are useful within joins below that level.  You could avoid that
if you could convince yourself that there's no point in ever doing
a mergejoin at such a level, but I don't think I believe that.

It may well be that there's no point in being too tense about this issue
anyway.  The planner will only consider early joins to rels that have
join clauses to the rel with the inner-indexscan path.  There probably
won't be that many of them.

			regards, tom lane



^ permalink  raw  reply  [nested|flat] 4850+ messages in thread

* Re: LATERAL
  2009-10-18 00:58 Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 02:09 ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-18 11:01   ` Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 15:30     ` Re: LATERAL Tom Lane <[email protected]>
@ 2009-10-18 19:36       ` Robert Haas <[email protected]>
  2009-10-18 19:57         ` Re: LATERAL Tom Lane <[email protected]>
  0 siblings, 1 reply; 4850+ messages in thread

From: Robert Haas @ 2009-10-18 19:36 UTC (permalink / raw)
  To: Tom Lane <[email protected]>; +Cc: Andrew Gierth <[email protected]>; David Fetter <[email protected]>; pgsql-hackers

On Sun, Oct 18, 2009 at 11:30 AM, Tom Lane <[email protected]> wrote:
> Robert Haas <[email protected]> writes:
>> I think you should only ever join an incomplete inner-indexscan path
>> to (1) another inner-indexscan path or (2) the cheapest total path for
>> *exactly* the future-join requirement.  Anything else doesn't seem
>> productive.
>
> I don't see any reason to constrain the form of joins before the
> future-join requirement.  Once you get to the join that satisfies
> that requirement, obviously you must implement it as a nestloop
> with the inner-indexscan path on the inside.  But there shouldn't
> be any more constraint beyond that one for that join, either:
>        * you might want a fast-start plan not cheapest total
>        * sort orderings of the outer path might be useful
>
> We know that sort ordering of the inner indexscan or its joins
> won't be useful once we reach the future-join level, so it might
> be possible to discard paths that are not cheapest total cost
> below that level.

Yeah, this was what I was driving at, but I got turned around in my
head and was explaining it incorrectly.

> The problem is to distinguish sort orderings
> that are useful within joins below that level.  You could avoid that
> if you could convince yourself that there's no point in ever doing
> a mergejoin at such a level, but I don't think I believe that.
>
> It may well be that there's no point in being too tense about this issue
> anyway.  The planner will only consider early joins to rels that have
> join clauses to the rel with the inner-indexscan path.  There probably
> won't be that many of them.

You could probably convince me that a merge join is not going to be
too useful (how often can you want a merge join on the inner side of a
nested loop?  ... especially when there are partial index scans
involved) but I think your last point here is well-taken.  We've
certainly turned a corner from "it's just the exponential growth in
the number of join paths to consider that's a problem".  :-)

...Robert



^ permalink  raw  reply  [nested|flat] 4850+ messages in thread

* Re: LATERAL
  2009-10-18 00:58 Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 02:09 ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-18 11:01   ` Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 15:30     ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-18 19:36       ` Re: LATERAL Robert Haas <[email protected]>
@ 2009-10-18 19:57         ` Tom Lane <[email protected]>
  2009-10-18 20:05           ` Re: LATERAL Robert Haas <[email protected]>
  2009-10-19 20:39           ` Re: LATERAL Greg Stark <[email protected]>
  2009-12-18 03:13           ` Re: LATERAL Robert Haas <[email protected]>
  0 siblings, 3 replies; 4850+ messages in thread

From: Tom Lane @ 2009-10-18 19:57 UTC (permalink / raw)
  To: Robert Haas <[email protected]>; +Cc: Andrew Gierth <[email protected]>; David Fetter <[email protected]>; pgsql-hackers

Robert Haas <[email protected]> writes:
> You could probably convince me that a merge join is not going to be
> too useful (how often can you want a merge join on the inner side of a
> nested loop?

Why not?  As Andrew pointed out, what we're really trying to accomplish
here is consider sub-join plans that are parameterized by a value
obtained from an outer relation.  I think we shouldn't artificially
limit what we consider.

But anyway I think we're on the same page here: what we ought to do is
try implementing this scheme without any extra restrictions on what it
considers, and see what the performance is like.  We can try to limit
what it considers if it turns out not to work well in the simplest
form.

			regards, tom lane



^ permalink  raw  reply  [nested|flat] 4850+ messages in thread

* Re: LATERAL
  2009-10-18 00:58 Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 02:09 ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-18 11:01   ` Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 15:30     ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-18 19:36       ` Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 19:57         ` Re: LATERAL Tom Lane <[email protected]>
@ 2009-10-18 20:05           ` Robert Haas <[email protected]>
  2 siblings, 0 replies; 4850+ messages in thread

From: Robert Haas @ 2009-10-18 20:05 UTC (permalink / raw)
  To: Tom Lane <[email protected]>; +Cc: Andrew Gierth <[email protected]>; David Fetter <[email protected]>; pgsql-hackers

On Sun, Oct 18, 2009 at 3:57 PM, Tom Lane <[email protected]> wrote:
> Robert Haas <[email protected]> writes:
>> You could probably convince me that a merge join is not going to be
>> too useful (how often can you want a merge join on the inner side of a
>> nested loop?
>
> Why not?  As Andrew pointed out, what we're really trying to accomplish
> here is consider sub-join plans that are parameterized by a value
> obtained from an outer relation.  I think we shouldn't artificially
> limit what we consider.
>
> But anyway I think we're on the same page here: what we ought to do is
> try implementing this scheme without any extra restrictions on what it
> considers, and see what the performance is like.  We can try to limit
> what it considers if it turns out not to work well in the simplest
> form.

And then when we get done we can consider implementing $SUBJECT, which
is no longer what this thread is about at all.  :-)

...Robert



^ permalink  raw  reply  [nested|flat] 4850+ messages in thread

* Re: LATERAL
  2009-10-18 00:58 Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 02:09 ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-18 11:01   ` Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 15:30     ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-18 19:36       ` Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 19:57         ` Re: LATERAL Tom Lane <[email protected]>
@ 2009-10-19 20:39           ` Greg Stark <[email protected]>
  2009-10-19 22:26             ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-19 22:38             ` Re: LATERAL Andrew Gierth <[email protected]>
  2 siblings, 2 replies; 4850+ messages in thread

From: Greg Stark @ 2009-10-19 20:39 UTC (permalink / raw)
  To: Tom Lane <[email protected]>; +Cc: Robert Haas <[email protected]>; Andrew Gierth <[email protected]>; David Fetter <[email protected]>; pgsql-hackers

On Sun, Oct 18, 2009 at 12:57 PM, Tom Lane <[email protected]> wrote:
> Robert Haas <[email protected]> writes:
>> You could probably convince me that a merge join is not going to be
>> too useful (how often can you want a merge join on the inner side of a
>> nested loop?
>
> Why not?  As Andrew pointed out, what we're really trying to accomplish
> here is consider sub-join plans that are parameterized by a value
> obtained from an outer relation.  I think we shouldn't artificially
> limit what we consider.

Am I understanding you right that a typical case of this might be something like

nested loop
    index scan expecting 1 record
    merge join
        index scan on partial index where col = outer.foo and col2
between a and b
        some other scan

or

nested loop
    index scan expecting 1 record
    merge join
        index scan on <col1,col2> where col1 = outer.foo and col2
between a and b
        some other scan

Ie, where the nested loop is a degenerate nested loop which only
expects a single value and provides a parameter which allows some
partial index to work or allows for some other index scan by providing
a higher order key element?

-- 
greg



^ permalink  raw  reply  [nested|flat] 4850+ messages in thread

* Re: LATERAL
  2009-10-18 00:58 Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 02:09 ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-18 11:01   ` Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 15:30     ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-18 19:36       ` Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 19:57         ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-19 20:39           ` Re: LATERAL Greg Stark <[email protected]>
@ 2009-10-19 22:26             ` Tom Lane <[email protected]>
  1 sibling, 0 replies; 4850+ messages in thread

From: Tom Lane @ 2009-10-19 22:26 UTC (permalink / raw)
  To: Greg Stark <[email protected]>; +Cc: Robert Haas <[email protected]>; Andrew Gierth <[email protected]>; David Fetter <[email protected]>; pgsql-hackers

Greg Stark <[email protected]> writes:
> nested loop
>     index scan expecting 1 record
>     merge join
>         index scan on <col1,col2> where col1 = outer.foo and col2
> between a and b
>         some other scan

> Ie, where the nested loop is a degenerate nested loop which only
> expects a single value and provides a parameter which allows some
> partial index to work or allows for some other index scan by providing
> a higher order key element?

Right.  I don't see any particular reason to assume the inner path
is iterated only once, either.  If the key value coming from the outer
path is sufficiently useful, this could be a win even with multiple
iterations, as compared to having to scan the whole of some large
relation or other ...

			regards, tom lane



^ permalink  raw  reply  [nested|flat] 4850+ messages in thread

* Re: LATERAL
  2009-10-18 00:58 Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 02:09 ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-18 11:01   ` Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 15:30     ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-18 19:36       ` Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 19:57         ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-19 20:39           ` Re: LATERAL Greg Stark <[email protected]>
@ 2009-10-19 22:38             ` Andrew Gierth <[email protected]>
  2009-12-19 17:49               ` Re: LATERAL Hitoshi Harada <[email protected]>
  1 sibling, 1 reply; 4850+ messages in thread

From: Andrew Gierth @ 2009-10-19 22:38 UTC (permalink / raw)
  To: Greg Stark <[email protected]>; Tom Lane <[email protected]>; Robert Haas <[email protected]>; David Fetter <[email protected]>; pgsql-hackers

>>>>> "Greg" == Greg Stark <[email protected]> writes:

 >> Why not?  As Andrew pointed out, what we're really trying to
 >> accomplish here is consider sub-join plans that are parameterized
 >> by a value obtained from an outer relation.  I think we shouldn't
 >> artificially limit what we consider.

 Greg> Am I understanding you right that a typical case of this might
 Greg> be something like

 Greg> nested loop
 Greg>     index scan expecting 1 record
 Greg>     merge join
 Greg>         index scan on partial index where col = outer.foo and col2
 Greg> between a and b
 Greg>         some other scan

no, because you could never pick the partial index at plan time.

 Greg> or

 Greg> nested loop
 Greg>     index scan expecting 1 record
 Greg>     merge join
 Greg>         index scan on <col1,col2> where col1 = outer.foo and col2
 Greg> between a and b
 Greg>         some other scan

 Greg> Ie, where the nested loop is a degenerate nested loop which
 Greg> only expects a single value and provides a parameter which
 Greg> allows some partial index to work or allows for some other
 Greg> index scan by providing a higher order key element?

The nested loop does NOT have to be degenerate. Consider queries of
this form:

select * from small
              left join (big1 join big2 on (big1.id=big2.id))
              on (small.id=big1.id);

Right now, the only way pg can plan this is to do a hashjoin or
mergejoin of the _entire content of big1 and big2_ and join the
result against "small" (again in a hashjoin or mergejoin plan).
This becomes excessively slow compared to the "ideal" plan:

  nested loop
      seqscan on small
      nested loop
         indexscan on big1 where id=small.id
         indexscan on big2 where id=small.id (or big1.id which is equiv)

(The same argument applies if "small" is not actually small but has
restriction clauses)

-- 
Andrew (irc:RhodiumToad)



^ permalink  raw  reply  [nested|flat] 4850+ messages in thread

* Re: LATERAL
  2009-10-18 00:58 Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 02:09 ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-18 11:01   ` Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 15:30     ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-18 19:36       ` Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 19:57         ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-19 20:39           ` Re: LATERAL Greg Stark <[email protected]>
  2009-10-19 22:38             ` Re: LATERAL Andrew Gierth <[email protected]>
@ 2009-12-19 17:49               ` Hitoshi Harada <[email protected]>
  2009-12-19 18:11                 ` Re: LATERAL Robert Haas <[email protected]>
  0 siblings, 1 reply; 4850+ messages in thread

From: Hitoshi Harada @ 2009-12-19 17:49 UTC (permalink / raw)
  To: Andrew Gierth <[email protected]>; +Cc: Greg Stark <[email protected]>; Tom Lane <[email protected]>; Robert Haas <[email protected]>; David Fetter <[email protected]>; pgsql-hackers

2009/10/20 Andrew Gierth <[email protected]>:
> Right now, the only way pg can plan this is to do a hashjoin or
> mergejoin of the _entire content of big1 and big2_ and join the
> result against "small" (again in a hashjoin or mergejoin plan).
> This becomes excessively slow compared to the "ideal" plan:
>
>  nested loop
>      seqscan on small
>      nested loop
>         indexscan on big1 where id=small.id
>         indexscan on big2 where id=small.id (or big1.id which is equiv)
>
> (The same argument applies if "small" is not actually small but has
> restriction clauses)

I have a similar issue on my mind, but is this the same as the topic?

SELECT ... FROM small INNER JOIN (SELECT ... FROM large GROUP BY
large.id) agged ON small.id = agged.id WHERE small.id IN (bla bla bla)

The ideal plan is SeqScan on small with filtering sub query aggregate
on large by small.id but the actual plan is full aggregate on large
since the planner doesn't push down outer qual to aggregate node. The
output will discard almost all of agged's output.


Regards,

-- 
Hitoshi Harada



^ permalink  raw  reply  [nested|flat] 4850+ messages in thread

* Re: LATERAL
  2009-10-18 00:58 Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 02:09 ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-18 11:01   ` Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 15:30     ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-18 19:36       ` Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 19:57         ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-19 20:39           ` Re: LATERAL Greg Stark <[email protected]>
  2009-10-19 22:38             ` Re: LATERAL Andrew Gierth <[email protected]>
  2009-12-19 17:49               ` Re: LATERAL Hitoshi Harada <[email protected]>
@ 2009-12-19 18:11                 ` Robert Haas <[email protected]>
  2009-12-19 18:40                   ` Re: LATERAL Hitoshi Harada <[email protected]>
  0 siblings, 1 reply; 4850+ messages in thread

From: Robert Haas @ 2009-12-19 18:11 UTC (permalink / raw)
  To: Hitoshi Harada <[email protected]>; +Cc: Andrew Gierth <[email protected]>; Greg Stark <[email protected]>; Tom Lane <[email protected]>; David Fetter <[email protected]>; pgsql-hackers

On Sat, Dec 19, 2009 at 12:49 PM, Hitoshi Harada <[email protected]> wrote:
> 2009/10/20 Andrew Gierth <[email protected]>:
>> Right now, the only way pg can plan this is to do a hashjoin or
>> mergejoin of the _entire content of big1 and big2_ and join the
>> result against "small" (again in a hashjoin or mergejoin plan).
>> This becomes excessively slow compared to the "ideal" plan:
>>
>>  nested loop
>>      seqscan on small
>>      nested loop
>>         indexscan on big1 where id=small.id
>>         indexscan on big2 where id=small.id (or big1.id which is equiv)
>>
>> (The same argument applies if "small" is not actually small but has
>> restriction clauses)
>
> I have a similar issue on my mind, but is this the same as the topic?
>
> SELECT ... FROM small INNER JOIN (SELECT ... FROM large GROUP BY
> large.id) agged ON small.id = agged.id WHERE small.id IN (bla bla bla)
>
> The ideal plan is SeqScan on small with filtering sub query aggregate
> on large by small.id but the actual plan is full aggregate on large
> since the planner doesn't push down outer qual to aggregate node. The
> output will discard almost all of agged's output.

I just tried this and it works for me.

create table foo (id serial, name varchar, primary key (id));
create table bar (id serial, foo_id integer references foo (id), name
varchar, primary key (id));
insert into foo (name) select random()::varchar from generate_series(1,1000);
insert into bar (foo_id, name) select (g%10)+1, random()::varchar from
generate_series(1,10000) g;
explain select * from foo inner join (select foo_id, sum(1) from bar
group by 1) x on foo.id = x.foo_id where x.foo_id = 1;

...Robert



^ permalink  raw  reply  [nested|flat] 4850+ messages in thread

* Re: LATERAL
  2009-10-18 00:58 Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 02:09 ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-18 11:01   ` Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 15:30     ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-18 19:36       ` Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 19:57         ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-19 20:39           ` Re: LATERAL Greg Stark <[email protected]>
  2009-10-19 22:38             ` Re: LATERAL Andrew Gierth <[email protected]>
  2009-12-19 17:49               ` Re: LATERAL Hitoshi Harada <[email protected]>
  2009-12-19 18:11                 ` Re: LATERAL Robert Haas <[email protected]>
@ 2009-12-19 18:40                   ` Hitoshi Harada <[email protected]>
  0 siblings, 0 replies; 4850+ messages in thread

From: Hitoshi Harada @ 2009-12-19 18:40 UTC (permalink / raw)
  To: Robert Haas <[email protected]>; +Cc: Andrew Gierth <[email protected]>; Greg Stark <[email protected]>; Tom Lane <[email protected]>; David Fetter <[email protected]>; pgsql-hackers

2009/12/20 Robert Haas <[email protected]>:
> On Sat, Dec 19, 2009 at 12:49 PM, Hitoshi Harada <[email protected]> wrote:
>> 2009/10/20 Andrew Gierth <[email protected]>:
>>> Right now, the only way pg can plan this is to do a hashjoin or
>>> mergejoin of the _entire content of big1 and big2_ and join the
>>> result against "small" (again in a hashjoin or mergejoin plan).
>>> This becomes excessively slow compared to the "ideal" plan:
>>>
>>>  nested loop
>>>      seqscan on small
>>>      nested loop
>>>         indexscan on big1 where id=small.id
>>>         indexscan on big2 where id=small.id (or big1.id which is equiv)
>>>
>>> (The same argument applies if "small" is not actually small but has
>>> restriction clauses)
>>
>> I have a similar issue on my mind, but is this the same as the topic?
>>
>> SELECT ... FROM small INNER JOIN (SELECT ... FROM large GROUP BY
>> large.id) agged ON small.id = agged.id WHERE small.id IN (bla bla bla)
>>
>> The ideal plan is SeqScan on small with filtering sub query aggregate
>> on large by small.id but the actual plan is full aggregate on large
>> since the planner doesn't push down outer qual to aggregate node. The
>> output will discard almost all of agged's output.
>
> I just tried this and it works for me.
>
> create table foo (id serial, name varchar, primary key (id));
> create table bar (id serial, foo_id integer references foo (id), name
> varchar, primary key (id));
> insert into foo (name) select random()::varchar from generate_series(1,1000);
> insert into bar (foo_id, name) select (g%10)+1, random()::varchar from
> generate_series(1,10000) g;
> explain select * from foo inner join (select foo_id, sum(1) from bar
> group by 1) x on foo.id = x.foo_id where x.foo_id = 1;
>
> ...Robert
>

Ah your example works for me, too. My issue is:

explain select * from foo inner join (select foo_id, sum(1) from bar
group by 1) x on foo.id = x.foo_id where foo.id = 1;

where foo.id = 1 (not where x.foo_id = 1).
And I now figured out it's another problem.

Regards,


-- 
Hitoshi Harada



^ permalink  raw  reply  [nested|flat] 4850+ messages in thread

* Re: LATERAL
  2009-10-18 00:58 Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 02:09 ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-18 11:01   ` Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 15:30     ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-18 19:36       ` Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 19:57         ` Re: LATERAL Tom Lane <[email protected]>
@ 2009-12-18 03:13           ` Robert Haas <[email protected]>
  2009-12-19 18:43             ` Re: LATERAL Robert Haas <[email protected]>
  2 siblings, 1 reply; 4850+ messages in thread

From: Robert Haas @ 2009-12-18 03:13 UTC (permalink / raw)
  To: Tom Lane <[email protected]>; +Cc: Andrew Gierth <[email protected]>; David Fetter <[email protected]>; pgsql-hackers

On Sun, Oct 18, 2009 at 2:57 PM, Tom Lane <[email protected]> wrote:
> Robert Haas <[email protected]> writes:
>> You could probably convince me that a merge join is not going to be
>> too useful (how often can you want a merge join on the inner side of a
>> nested loop?
>
> Why not?  As Andrew pointed out, what we're really trying to accomplish
> here is consider sub-join plans that are parameterized by a value
> obtained from an outer relation.  I think we shouldn't artificially
> limit what we consider.
>
> But anyway I think we're on the same page here: what we ought to do is
> try implementing this scheme without any extra restrictions on what it
> considers, and see what the performance is like.  We can try to limit
> what it considers if it turns out not to work well in the simplest
> form.

You mention what "we" ought to do here, so - is this something that
you're planning to have a go at?

Another question I have - while generalizing the inner-indexscan
machinery is an interesting join optimization technique, I'm thinking
that it actually has very little to do with LATERAL.  Is there any
reason to suppose that one or the other needs to be done first?

...Robert



^ permalink  raw  reply  [nested|flat] 4850+ messages in thread

* Re: LATERAL
  2009-10-18 00:58 Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 02:09 ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-18 11:01   ` Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 15:30     ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-18 19:36       ` Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 19:57         ` Re: LATERAL Tom Lane <[email protected]>
  2009-12-18 03:13           ` Re: LATERAL Robert Haas <[email protected]>
@ 2009-12-19 18:43             ` Robert Haas <[email protected]>
  2009-12-19 20:01               ` Re: LATERAL Tom Lane <[email protected]>
  0 siblings, 1 reply; 4850+ messages in thread

From: Robert Haas @ 2009-12-19 18:43 UTC (permalink / raw)
  To: Tom Lane <[email protected]>; +Cc: Andrew Gierth <[email protected]>; David Fetter <[email protected]>; pgsql-hackers

On Thu, Dec 17, 2009 at 10:13 PM, Robert Haas <[email protected]> wrote:
> Another question I have - while generalizing the inner-indexscan
> machinery is an interesting join optimization technique, I'm thinking
> that it actually has very little to do with LATERAL.  Is there any
> reason to suppose that one or the other needs to be done first?

And the winner is... yes.  Or at least, I think so.  One of the major
reasons why people want LATERAL() is for SRFs, but currently, even if
you beat the code into allowing a SRF with an outer reference, the
planner can easily be persuaded to run the SRF on the outer side of a
join with the dependency as the inner side, which ain't gonna work.
(Even you jigger the query so that the planner gets them on the
correct sides of the join, the executor fails, but that's a different
problem.)

The idea Tom came up with back in October is to allow paths to be
tagged with a set of rels to which they must in the future be joined
in order for the path to be allowable.  The point of that exercise was
to generalize the current inner-indexscan machinery so that we can
create that type of plan in match_unsorted_outer() even when the inner
side is a joinrel.  But, it strikes me that what we need to allow a
function scan with an outer reference is remarkably similar - the
function scan can only be used as the inner side of a nestloop with a
certain set of rels on the outer side.

On the other hand, it's not exactly the same, either.  In the case of
a construct like A LJ (B IJ C), partial-index scan paths for B and C
will require a subsequent nest-join to A to become fully valid, but
there will also be other paths that don't.  But for something like "A,
LATERAL (some_srf(A.x))", the ONLY path for the "rel" defined by
some_srf(A.x) has a future-join requirement of {A}.  It's not clear to
me whether there's anything useful that can be done with this
knowledge.

Incidentally, the reason why the executor chokes trying to execute a
SRF with an outer reference is because ExecEvalVar() craps out trying
to dereference a null TupleTableSlot.  If I'm understanding this
correctly, that, in turn, happens because the variable that we're
trying to deference is marked as neither INNER nor OUTER, so it's
assumed to be from a scan, but there's no scan node.  Going even
further from my area of actually understanding what's going on, I
think this needs to be fixed by adjusting setrefs.c.  Allowing
LATERAL(), or for that matter the generalized inner-index scan stuff,
will I think mean that set_inner_join_references() will need to handle
a lot more cases than it current does.  I don't understand this code
well enough to begin to speculate as to what should happen here.

...Robert



^ permalink  raw  reply  [nested|flat] 4850+ messages in thread

* Re: LATERAL
  2009-10-18 00:58 Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 02:09 ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-18 11:01   ` Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 15:30     ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-18 19:36       ` Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 19:57         ` Re: LATERAL Tom Lane <[email protected]>
  2009-12-18 03:13           ` Re: LATERAL Robert Haas <[email protected]>
  2009-12-19 18:43             ` Re: LATERAL Robert Haas <[email protected]>
@ 2009-12-19 20:01               ` Tom Lane <[email protected]>
  2009-12-19 21:38                 ` Re: LATERAL Robert Haas <[email protected]>
  0 siblings, 1 reply; 4850+ messages in thread

From: Tom Lane @ 2009-12-19 20:01 UTC (permalink / raw)
  To: Robert Haas <[email protected]>; +Cc: Andrew Gierth <[email protected]>; David Fetter <[email protected]>; pgsql-hackers

Robert Haas <[email protected]> writes:
> Incidentally, the reason why the executor chokes trying to execute a
> SRF with an outer reference is because ExecEvalVar() craps out trying
> to dereference a null TupleTableSlot.  If I'm understanding this
> correctly, that, in turn, happens because the variable that we're
> trying to deference is marked as neither INNER nor OUTER, so it's
> assumed to be from a scan, but there's no scan node.  Going even
> further from my area of actually understanding what's going on, I
> think this needs to be fixed by adjusting setrefs.c.

Well, no: we can't handle such references as OUTER vars because the
OUTER slot is likely to be in use already in the sub-join.  It would be
even messier if you wanted several references to different outer
relations.

I believe the correct approach is probably to treat values that need to
be propagated into the inner side as executor parameters.  This could
replace the existing, rather crocky, management of values passed into a
nestloop inner indexscan.  The mechanisms that deal with forcing rescans
of subplans affected by a changed parameter value would be very helpful
here too.

			regards, tom lane



^ permalink  raw  reply  [nested|flat] 4850+ messages in thread

* Re: LATERAL
  2009-10-18 00:58 Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 02:09 ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-18 11:01   ` Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 15:30     ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-18 19:36       ` Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 19:57         ` Re: LATERAL Tom Lane <[email protected]>
  2009-12-18 03:13           ` Re: LATERAL Robert Haas <[email protected]>
  2009-12-19 18:43             ` Re: LATERAL Robert Haas <[email protected]>
  2009-12-19 20:01               ` Re: LATERAL Tom Lane <[email protected]>
@ 2009-12-19 21:38                 ` Robert Haas <[email protected]>
  2009-12-19 21:46                   ` Re: LATERAL Tom Lane <[email protected]>
  0 siblings, 1 reply; 4850+ messages in thread

From: Robert Haas @ 2009-12-19 21:38 UTC (permalink / raw)
  To: Tom Lane <[email protected]>; +Cc: Andrew Gierth <[email protected]>; David Fetter <[email protected]>; pgsql-hackers

On Sat, Dec 19, 2009 at 3:01 PM, Tom Lane <[email protected]> wrote:
> Robert Haas <[email protected]> writes:
>> Incidentally, the reason why the executor chokes trying to execute a
>> SRF with an outer reference is because ExecEvalVar() craps out trying
>> to dereference a null TupleTableSlot.  If I'm understanding this
>> correctly, that, in turn, happens because the variable that we're
>> trying to deference is marked as neither INNER nor OUTER, so it's
>> assumed to be from a scan, but there's no scan node.  Going even
>> further from my area of actually understanding what's going on, I
>> think this needs to be fixed by adjusting setrefs.c.
>
> Well, no: we can't handle such references as OUTER vars because the
> OUTER slot is likely to be in use already in the sub-join.  It would be
> even messier if you wanted several references to different outer
> relations.

Oh.  Yeah.

> I believe the correct approach is probably to treat values that need to
> be propagated into the inner side as executor parameters.  This could
> replace the existing, rather crocky, management of values passed into a
> nestloop inner indexscan.  The mechanisms that deal with forcing rescans
> of subplans affected by a changed parameter value would be very helpful
> here too.

What is the best place to look for the existing, rather crocky code?
I have to admit that the whole mechanism by which paths get
transformed into plans and handed off to the executor is still rather
opaque to me.

...Robert



^ permalink  raw  reply  [nested|flat] 4850+ messages in thread

* Re: LATERAL
  2009-10-18 00:58 Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 02:09 ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-18 11:01   ` Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 15:30     ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-18 19:36       ` Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 19:57         ` Re: LATERAL Tom Lane <[email protected]>
  2009-12-18 03:13           ` Re: LATERAL Robert Haas <[email protected]>
  2009-12-19 18:43             ` Re: LATERAL Robert Haas <[email protected]>
  2009-12-19 20:01               ` Re: LATERAL Tom Lane <[email protected]>
  2009-12-19 21:38                 ` Re: LATERAL Robert Haas <[email protected]>
@ 2009-12-19 21:46                   ` Tom Lane <[email protected]>
  2009-12-20 04:01                     ` Re: LATERAL Robert Haas <[email protected]>
  0 siblings, 1 reply; 4850+ messages in thread

From: Tom Lane @ 2009-12-19 21:46 UTC (permalink / raw)
  To: Robert Haas <[email protected]>; +Cc: Andrew Gierth <[email protected]>; David Fetter <[email protected]>; pgsql-hackers

Robert Haas <[email protected]> writes:
> On Sat, Dec 19, 2009 at 3:01 PM, Tom Lane <[email protected]> wrote:
>> I believe the correct approach is probably to treat values that need to
>> be propagated into the inner side as executor parameters. �This could
>> replace the existing, rather crocky, management of values passed into a
>> nestloop inner indexscan.

> What is the best place to look for the existing, rather crocky code?

Follow the second argument of ExecReScan from nodeNestloop to
nodeIndexscan.

			regards, tom lane



^ permalink  raw  reply  [nested|flat] 4850+ messages in thread

* Re: LATERAL
  2009-10-18 00:58 Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 02:09 ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-18 11:01   ` Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 15:30     ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-18 19:36       ` Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 19:57         ` Re: LATERAL Tom Lane <[email protected]>
  2009-12-18 03:13           ` Re: LATERAL Robert Haas <[email protected]>
  2009-12-19 18:43             ` Re: LATERAL Robert Haas <[email protected]>
  2009-12-19 20:01               ` Re: LATERAL Tom Lane <[email protected]>
  2009-12-19 21:38                 ` Re: LATERAL Robert Haas <[email protected]>
  2009-12-19 21:46                   ` Re: LATERAL Tom Lane <[email protected]>
@ 2009-12-20 04:01                     ` Robert Haas <[email protected]>
  2009-12-20 04:06                       ` Re: LATERAL Robert Haas <[email protected]>
  0 siblings, 1 reply; 4850+ messages in thread

From: Robert Haas @ 2009-12-20 04:01 UTC (permalink / raw)
  To: Tom Lane <[email protected]>; +Cc: Andrew Gierth <[email protected]>; David Fetter <[email protected]>; pgsql-hackers

On Sat, Dec 19, 2009 at 4:46 PM, Tom Lane <[email protected]> wrote:
> Robert Haas <[email protected]> writes:
>> On Sat, Dec 19, 2009 at 3:01 PM, Tom Lane <[email protected]> wrote:
>>> I believe the correct approach is probably to treat values that need to
>>> be propagated into the inner side as executor parameters.  This could
>>> replace the existing, rather crocky, management of values passed into a
>>> nestloop inner indexscan.
>
>> What is the best place to look for the existing, rather crocky code?
>
> Follow the second argument of ExecReScan from nodeNestloop to
> nodeIndexscan.

Yeah, this is grotty.  It appears that the comment introducing
ExecReScan() is somewhat incorrect.  It asserts that exprCtxt is used
only



^ permalink  raw  reply  [nested|flat] 4850+ messages in thread

* Re: LATERAL
  2009-10-18 00:58 Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 02:09 ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-18 11:01   ` Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 15:30     ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-18 19:36       ` Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 19:57         ` Re: LATERAL Tom Lane <[email protected]>
  2009-12-18 03:13           ` Re: LATERAL Robert Haas <[email protected]>
  2009-12-19 18:43             ` Re: LATERAL Robert Haas <[email protected]>
  2009-12-19 20:01               ` Re: LATERAL Tom Lane <[email protected]>
  2009-12-19 21:38                 ` Re: LATERAL Robert Haas <[email protected]>
  2009-12-19 21:46                   ` Re: LATERAL Tom Lane <[email protected]>
  2009-12-20 04:01                     ` Re: LATERAL Robert Haas <[email protected]>
@ 2009-12-20 04:06                       ` Robert Haas <[email protected]>
  2009-12-20 05:45                         ` Re: LATERAL Tom Lane <[email protected]>
  0 siblings, 1 reply; 4850+ messages in thread

From: Robert Haas @ 2009-12-20 04:06 UTC (permalink / raw)
  To: Tom Lane <[email protected]>; +Cc: Andrew Gierth <[email protected]>; David Fetter <[email protected]>; pgsql-hackers

On Sat, Dec 19, 2009 at 11:01 PM, Robert Haas <[email protected]> wrote:
> On Sat, Dec 19, 2009 at 4:46 PM, Tom Lane <[email protected]> wrote:
>> Robert Haas <[email protected]> writes:
>>> On Sat, Dec 19, 2009 at 3:01 PM, Tom Lane <[email protected]> wrote:
>>>> I believe the correct approach is probably to treat values that need to
>>>> be propagated into the inner side as executor parameters.  This could
>>>> replace the existing, rather crocky, management of values passed into a
>>>> nestloop inner indexscan.
>>
>>> What is the best place to look for the existing, rather crocky code?
>>
>> Follow the second argument of ExecReScan from nodeNestloop to
>> nodeIndexscan.
>
> Yeah, this is grotty.  It appears that the comment introducing
> ExecReScan() is somewhat incorrect.  It asserts that exprCtxt is used
> only

Sigh.

...is used only for index scans.  However, it's actually also used for
bitmap scans (both heap and index) and TID scans.  Also, there appears
to be an effort by nodes that don't use exprCtxt directly to propagate
down through the node tree, which doesn't seem to make much sense if
this is only intended to be used on the inner side of a nestloop.

...Robert



^ permalink  raw  reply  [nested|flat] 4850+ messages in thread

* Re: LATERAL
  2009-10-18 00:58 Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 02:09 ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-18 11:01   ` Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 15:30     ` Re: LATERAL Tom Lane <[email protected]>
  2009-10-18 19:36       ` Re: LATERAL Robert Haas <[email protected]>
  2009-10-18 19:57         ` Re: LATERAL Tom Lane <[email protected]>
  2009-12-18 03:13           ` Re: LATERAL Robert Haas <[email protected]>
  2009-12-19 18:43             ` Re: LATERAL Robert Haas <[email protected]>
  2009-12-19 20:01               ` Re: LATERAL Tom Lane <[email protected]>
  2009-12-19 21:38                 ` Re: LATERAL Robert Haas <[email protected]>
  2009-12-19 21:46                   ` Re: LATERAL Tom Lane <[email protected]>
  2009-12-20 04:01                     ` Re: LATERAL Robert Haas <[email protected]>
  2009-12-20 04:06                       ` Re: LATERAL Robert Haas <[email protected]>
@ 2009-12-20 05:45                         ` Tom Lane <[email protected]>
  0 siblings, 0 replies; 4850+ messages in thread

From: Tom Lane @ 2009-12-20 05:45 UTC (permalink / raw)
  To: Robert Haas <[email protected]>; +Cc: Andrew Gierth <[email protected]>; David Fetter <[email protected]>; pgsql-hackers

Robert Haas <[email protected]> writes:
>> Yeah, this is grotty. �It appears that the comment introducing
>> ExecReScan() is somewhat incorrect. �It asserts that exprCtxt is used
>> only

> Sigh.

> ...is used only for index scans.  However, it's actually also used for
> bitmap scans (both heap and index) and TID scans.

Yeah, the comment was probably correct when written.

> Also, there appears
> to be an effort by nodes that don't use exprCtxt directly to propagate
> down through the node tree, which doesn't seem to make much sense if
> this is only intended to be used on the inner side of a nestloop.

That's just dead code, which is a good thing because the coverage is
pretty incomplete.

			regards, tom lane



^ permalink  raw  reply  [nested|flat] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ 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; 4850+ 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] 4850+ messages in thread