PublicationActions - use bit flags.

On Mon, Dec 20, 2021 at 11:19 AM Peter Smith <smithpb2250@gmail.com> wrote:

For some reason the current HEAD PublicationActions is a struct of
boolean representing combinations of the 4 different "publication
actions".

I felt it is more natural to implement boolean flag combinations using
a bitmask instead of a struct of bools. IMO using the bitmask also
simplifies assignment and checking of said flags.

PSA a small patch for this.

Thoughts?

+1
I think the bit flags are a more natural fit, and also the patch
removes the unnecessary use of a palloc'd tiny struct to return the
PublicationActions (which also currently isn't explicitly pfree'd).

Regards,
Greg Nancarrow
Fujitsu Australia

On 20.12.21 01:18, Peter Smith wrote:

For some reason the current HEAD PublicationActions is a struct of
boolean representing combinations of the 4 different "publication
actions".

I felt it is more natural to implement boolean flag combinations using
a bitmask instead of a struct of bools. IMO using the bitmask also
simplifies assignment and checking of said flags.

I don't see why this is better. It just makes the code longer and adds
more punctuation and reduces type safety.

Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:

On 20.12.21 01:18, Peter Smith wrote:

I felt it is more natural to implement boolean flag combinations using
a bitmask instead of a struct of bools. IMO using the bitmask also
simplifies assignment and checking of said flags.

I don't see why this is better. It just makes the code longer and adds
more punctuation and reduces type safety.

It makes the code shorter in places where you need to process all the
flags at once, but I agree it's not really an improvement elsewhere.
Not sure if it's worth changing.

One thing I noted is that the duplicate PublicationActions typedefs
will certainly draw warnings, if not hard errors, from some compilers.
You could get around that by removing the typedefs altogether and just
using "int", which'd be more consistent with our usual practices anyway.
But it does play into Peter's objection about type safety.

regards, tom lane

On 2021-Dec-20, Peter Eisentraut wrote:

I don't see why this is better. It just makes the code longer and adds more
punctuation and reduces type safety.

Removing one palloc is I think the most important consequence ...
probably not a big deal though.

I think we could change the memcpy calls to struct assignment, as that
would look a bit cleaner, and call it a day.

One thing I would not like would be to change the catalog representation
from bools into an integer. We do that for pg_trigger.tgflags (IIRC)
and it is horrible.

--
Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/

On Tue, Dec 21, 2021 at 4:14 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:

On 2021-Dec-20, Peter Eisentraut wrote:

I don't see why this is better. It just makes the code longer and adds more
punctuation and reduces type safety.

Removing one palloc is I think the most important consequence ...
probably not a big deal though.

I think we could change the memcpy calls to struct assignment, as that
would look a bit cleaner, and call it a day.

I think we can all agree that returning PublicationActions as a
palloc'd struct is unnecessary.
I've attached a patch which addresses that and replaces a couple of
memcpy()s with struct assignment, as suggested.

Regards,
Greg Nancarrow
Fujitsu Australia

Greg Nancarrow <gregn4422@gmail.com> writes:

I've attached a patch which addresses that and replaces a couple of
memcpy()s with struct assignment, as suggested.

Removing this is not good:

if (relation->rd_pubactions)
- {
pfree(relation->rd_pubactions);
- relation->rd_pubactions = NULL;
- }

If the subsequent palloc fails, you've created a problem where
there was none before.

I do wonder why we have to palloc a constant-size substructure in
the first place, especially one that is likely smaller than the
pointer that points to it. Maybe the struct definition should be
moved so that we can just declare it in-line in the relcache entry?

regards, tom lane

On Tue, Dec 21, 2021 at 11:56 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Removing this is not good:

if (relation->rd_pubactions)
- {
pfree(relation->rd_pubactions);
- relation->rd_pubactions = NULL;
- }

If the subsequent palloc fails, you've created a problem where
there was none before.

Oops, yeah, I got carried away; if palloc() failed and called exit(),
then it would end up crashing when trying to use/pfree rd_pubactions
again.
Better leave that line in ...

I do wonder why we have to palloc a constant-size substructure in
the first place, especially one that is likely smaller than the
pointer that points to it. Maybe the struct definition should be
moved so that we can just declare it in-line in the relcache entry?

I think currently it's effectively using the rd_pubactions pointer as
a boolean flag to indicate whether the publication membership info has
been fetched (so the bool flags are valid).
I guess you'd need another bool flag if you wanted to make that struct
in-line in the relcache entry.

Regards,
Greg Nancarrow
Fujitsu Australia

On Tue, Dec 21, 2021 at 11:56 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Greg Nancarrow <gregn4422@gmail.com> writes:

I've attached a patch which addresses that and replaces a couple of
memcpy()s with struct assignment, as suggested.

Removing this is not good:

if (relation->rd_pubactions)
- {
pfree(relation->rd_pubactions);
- relation->rd_pubactions = NULL;
- }

If the subsequent palloc fails, you've created a problem where
there was none before.

I do wonder why we have to palloc a constant-size substructure in
the first place, especially one that is likely smaller than the
pointer that points to it. Maybe the struct definition should be
moved so that we can just declare it in-line in the relcache entry?

At the risk of flogging a dead horse, here is v2 of my original
bit-flag replacement for the PublicationActions struct.

This version introduces one more bit flag for the relcache status, and
by doing so means all that code for Relation cache PublicationActions
pointers and pallocs and context switches can just disappear...

------
Kind Regards,
Peter Smith.
Fujitsu Australia

On Mon, Dec 20, 2021 at 11:18:41AM +1100, Peter Smith wrote:

For some reason the current HEAD PublicationActions is a struct of
boolean representing combinations of the 4 different "publication
actions".

I felt it is more natural to implement boolean flag combinations using
a bitmask instead of a struct of bools. IMO using the bitmask also
simplifies assignment and checking of said flags.

Peter E made a suggestion to use a similar struct with bools last year for
REINDEX.
/messages/by-id/7ec67c56-2377-cd05-51a0-691104404abe@enterprisedb.com

Alvaro pointed out that the integer flags are better for ABI compatibility - it
would allow adding a new flag in backbranches, if that were needed for a
bugfix.

But that's not very compelling, since the bools have existed in v10...
Also, the booleans directly correspond with the catalog.

+ if (pubform->pubinsert) pub->pubactions |= PUBACTION_INSERT;

This is usually written like:

pub->pubactions |= (pubform->pubinsert ? PUBACTION_INSERT : 0)

--
Justin

On Thu, Dec 30, 2021 at 3:30 AM Justin Pryzby <pryzby@telsasoft.com> wrote:

On Mon, Dec 20, 2021 at 11:18:41AM +1100, Peter Smith wrote:

For some reason the current HEAD PublicationActions is a struct of
boolean representing combinations of the 4 different "publication
actions".

I felt it is more natural to implement boolean flag combinations using
a bitmask instead of a struct of bools. IMO using the bitmask also
simplifies assignment and checking of said flags.

Peter E made a suggestion to use a similar struct with bools last year for
REINDEX.
/messages/by-id/7ec67c56-2377-cd05-51a0-691104404abe@enterprisedb.com

Alvaro pointed out that the integer flags are better for ABI compatibility - it
would allow adding a new flag in backbranches, if that were needed for a
bugfix.

But that's not very compelling, since the bools have existed in v10...
Also, the booleans directly correspond with the catalog.

+ if (pubform->pubinsert) pub->pubactions |= PUBACTION_INSERT;

This is usually written like:

pub->pubactions |= (pubform->pubinsert ? PUBACTION_INSERT : 0)

Thanks for the info, I've modified those assignment styles as suggested.

------
Kind Regards,
Peter Smith.
Fujitsu Australia.

Peter Smith <smithpb2250@gmail.com> writes:

On Thu, Dec 30, 2021 at 3:30 AM Justin Pryzby <pryzby@telsasoft.com> wrote:

+ if (pubform->pubinsert) pub->pubactions |= PUBACTION_INSERT;
This is usually written like:
pub->pubactions |= (pubform->pubinsert ? PUBACTION_INSERT : 0)

Thanks for the info, I've modified those assignment styles as suggested.

FWIW, I think it's utter nonsense to claim that the second way is
preferred over the first. There may be some people who think
the second way is more legible, but I don't; and I'm pretty sure
that the first way is significantly more common in the PG codebase.

regards, tom lane

On Tue, Dec 21, 2021 at 12:55 PM Greg Nancarrow <gregn4422@gmail.com> wrote:

On Tue, Dec 21, 2021 at 11:56 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Removing this is not good:

if (relation->rd_pubactions)
- {
pfree(relation->rd_pubactions);
- relation->rd_pubactions = NULL;
- }

If the subsequent palloc fails, you've created a problem where
there was none before.

Oops, yeah, I got carried away; if palloc() failed and called exit(),
then it would end up crashing when trying to use/pfree rd_pubactions
again.
Better leave that line in ...

Attaching an updated patch to fix that oversight.
This patch thus fixes the original palloc issue in a minimal way,
keeping the same relcache structure.

Regards,
Greg Nancarrow
Fujitsu Australia

On 21.01.22 01:05, Greg Nancarrow wrote:

On Tue, Dec 21, 2021 at 12:55 PM Greg Nancarrow <gregn4422@gmail.com> wrote:

On Tue, Dec 21, 2021 at 11:56 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Removing this is not good:

if (relation->rd_pubactions)
- {
pfree(relation->rd_pubactions);
- relation->rd_pubactions = NULL;
- }

If the subsequent palloc fails, you've created a problem where
there was none before.

Oops, yeah, I got carried away; if palloc() failed and called exit(),
then it would end up crashing when trying to use/pfree rd_pubactions
again.
Better leave that line in ...

Attaching an updated patch to fix that oversight.
This patch thus fixes the original palloc issue in a minimal way,
keeping the same relcache structure.

Why can't GetRelationPublicationActions() have the PublicationActions as
a return value, instead of changing it to an output argument?

On Tue, Jan 25, 2022 at 7:31 AM Peter Eisentraut <
peter.eisentraut@enterprisedb.com> wrote:

Why can't GetRelationPublicationActions() have the PublicationActions as
a return value, instead of changing it to an output argument?

That would be OK too, for now, for the current (small size, typically
4-byte) PublicationActions struct.
But if that function was extended in the future to return more publication
information than just the PublicationActions struct (and I'm seeing that in
the filtering patches [1]/messages/by-id/OS0PR01MB5716B899A66D2997EF28A1B3945F9@OS0PR01MB5716.jpnprd01.prod.outlook.com), then using return-by-value won't be as
efficient as pass-by-reference, and I'd tend to stick with
pass-by-reference in that case.

[1]: /messages/by-id/OS0PR01MB5716B899A66D2997EF28A1B3945F9@OS0PR01MB5716.jpnprd01.prod.outlook.com
/messages/by-id/OS0PR01MB5716B899A66D2997EF28A1B3945F9@OS0PR01MB5716.jpnprd01.prod.outlook.com

Regards,
Greg Nancarrow
Fujitsu Australia

On 25.01.22 07:14, Greg Nancarrow wrote:

On Tue, Jan 25, 2022 at 7:31 AM Peter Eisentraut
<peter.eisentraut@enterprisedb.com
<mailto:peter.eisentraut@enterprisedb.com>> wrote:

Why can't GetRelationPublicationActions() have the PublicationActions as
a return value, instead of changing it to an output argument?

That would be OK too, for now, for the current (small size, typically
4-byte) PublicationActions struct.
But if that function was extended in the future to return more
publication information than just the PublicationActions struct (and I'm
seeing that in the filtering patches [1]), then using return-by-value
won't be as efficient as pass-by-reference, and I'd tend to stick with
pass-by-reference in that case.

[1]
/messages/by-id/OS0PR01MB5716B899A66D2997EF28A1B3945F9@OS0PR01MB5716.jpnprd01.prod.outlook.com
</messages/by-id/OS0PR01MB5716B899A66D2997EF28A1B3945F9@OS0PR01MB5716.jpnprd01.prod.outlook.com&gt;

By itself, this refactoring doesn't seem worth it. The code is actually
longer at the end, and we haven't made it any more extensible or
anything. And AFAICT, this is not called in a performance-sensitive way.

The proposed changes in [1] change this function more significantly, so
adopting the present change wouldn't really help there either except
create the need for one more rebase.

So I think we should leave this alone here and let [1] make the changes
it needs.