[Bucardo-general] Possible areas for Bucardo modernization

[Michelle Sullivan]

If anything I’m a bucardo hacker rather than developer... I also use it a fair bit in a major project so I’ll add my own $0.02... (in-line)


> On 22 Oct 2020, at 16:04, Jon Jensen <jon at endpoint.com> wrote:
> 
> Bucardo developers,
> 
> I have been working on adding large object support for Bucardo, and along the way I made some notes of things we might want to discuss to keep the project alive and kicking, as a good goat should. 🐐

As far as I know it is...?

> 
> In no particular order:
> 
> Should we boost the minimum required Perl version? It's still at 5.8.3. It seems crazy not to be able to use the // operator that was introduced in 5.10 almost 13 years ago. The current oldest supported Perl version is 5.30, or in the LTS Linux distros, 5.16.3 in CentOS 7 (after CentOS 6 goes EOL next month). Not a big deal to work around missing // of course, but seems like a new major Bucardo release might be as good a time as any.

I use 5.16.3 across my infrastructure...  I don’t encourage use of operators that many have no idea about...  I can see good reason to go to 5.16, I don’t include the // operator one of them.  I see plenty of reason to keep as compatible with my Oder versions as possible... except where workarounds are *needed* ... I don’t recall what // does off the top of my head, I do remember a dev introducing it to my code when 5.10 came out and broke my infrastructure.. a minor change removed it.. when I later moved everything to 5.16 I didn’t readd it as I felt no need...  enlighten me why it’s important? (I am a fan of “if it ain’t broke, don’t fix it!” Just as a FYI)


> 
> Should we remove Drizzle support, since the Drizzle project is long dead?

Think this goes to a slightly different question (well questions)...   is anyone using it?  Does the code bass have a lot of unique code that would make it significantly lighter if removed?  Which basically leads to are there any benefits to removing it?

> 
> There are some workarounds for DBD::Pg < 2.18.1 that can go away once we require at least that version. It was released in May 2011, so seems like that could be done now.

This seems like a good idea.

> 
> The FAQ still uses the old terminology multi-master, master-slave: https://bucardo.org/Bucardo/FAQ.html - Any objection to replacing that?

What’s “old terminology “ about that?  Or do you mean let’s change it to something the PC zealots want?  

> 
> Are there any TODO comments we can get rid of in the code? Some have been there forever. If they should stay, that's fine, just looking for the case where time has made some no longer needed.

Some examples?

> 
> A little code question: Around line 7081 of Bucardo.pm this "binarycols" array seems unused, and bytea data is converted to base64, so is this needed?
> 
>> ## This is used to bind_param these as binary during inserts and updates
>> push @{$g->{binarycols}}, $colinfo->{$colname}{order};
> 
> Finally, old Postgres version support:
> 
> I was going to suggest we consider increasing the minimum Postgres version supported, but perhaps this is an area where we should be very conservative because a major use case for Bucardo is for upgrades, and old database that have been neglected is where it really shines and the latest Postgres features are not available.
> 
> But for the sake of discussion I saw:
> 
> * workaround for clock_timestamp() not existing until 8.2
> 
> * array_agg reimplemented for < 8.4
> 
> * a few checks for 8.3, 9.0, 9.2
> 
> Yet maybe we should leave most of those alone.
> 
> Please let me know if any of this resonates!

I personally would suggest any problem with going to 8.4 (I’m on 9.4/9.6) I’d hope 7.x would be long dead now but I can see people still using 8.4...

From my perspective (the if it ain’t broke.. above and..) one of the best things about bucardo is it pretty much works everywhere and anywhere... it should stay that way.. unless there are major reasons for changing support for a particular platform (eg a 2x speed difference in everything else etc.)

Regards,

Michelle

> 
> Thanks,
> Jon
> 
> 
> -- 
> Jon Jensen
> End Point Corporation
> https://www.endpoint.com/
> _______________________________________________
> Bucardo-general mailing list
> Bucardo-general at bucardo.org
> https://bucardo.org/mailman/listinfo/bucardo-general