Re: Using Expanded Objects other than Arrays from plpgsql

Michel Pelletier writes: > On Sun, Oct 20, 2024 at 10:13 AM Tom Lane wrote: >> But it seems like we could get an easy win by adjusting >> plpgsql_exec_function along the lines of >> ... > I tried this change and couldn't get it to work, on the next line: > if (VARATT_IS_EXTERNAL_EXPANDED_RW(

Re: Using Expanded Objects other than Arrays from plpgsql

On Sun, Oct 20, 2024 at 10:13 AM Tom Lane wrote: > > I'm not sure. It seems certain that if the object is already expanded > (either R/W or R/O), the paths for that in plpgsql_exec_function could > be taken regardless of its specific type. > > But it seems like we could get an easy win by adju

Re: Help Resolving Compiler Errors With enable-dtrace Flag

> Now you tell us? > > If that's the case, I wonder whether probes.o is getting built > correctly and included in the link. The relevant bits are in > src/backend/Makefile ... they don't look that easy to mess up, > but maybe. I thought I mentioned it in my original message but it wasn't super cl

Re: Help Resolving Compiler Errors With enable-dtrace Flag

Barry Walker writes: > Yes it was. My thinking though is that I am getting this error with every > probe, not just the ones in xact.c Now you tell us? If that's the case, I wonder whether probes.o is getting built correctly and included in the link. The relevant bits are in src/backend/Makefil

Re: Help Resolving Compiler Errors With enable-dtrace Flag

>I'd read > > https://www.postgresql.org/docs/current/dynamic-trace.html#DEFINING-TRACE-POINTS > > >and then go see if those tracepoints are fully conforming to the >coding rules in the modified version. A plausible bet is that >their entries in probes.d don't entirely match up with the calls >in

Re: Basebackup fails without useful error message

On 10/20/24 14:03, Koen De Groote wrote: So I'm assuming the process of writing WAL files, if there is an archive_command set, is only considered to be finished after the archive is written, not just when the WAL file is written in pg_wal. https://www.postgresql.org/docs/current/continuous-ar

Re: Help Resolving Compiler Errors With enable-dtrace Flag

> Was the customization done under version control? Yes it was. My thinking though is that I am getting this error with every probe, not just the ones in xact.c so I suspect there is something more than just a code change to the file. I compared the common makefiles and don't see any changes that w

Re: Basebackup fails without useful error message

Hello Adrian, and everyone else. It has finally happened, the backup ran into an error again, and the verbose output set me on the right path. I'm getting this error message: > pg_basebackup: could not receive data from WAL stream: server closed the connection unexpectedly > This probably means

Re: Help Resolving Compiler Errors With enable-dtrace Flag

On 10/20/24 12:02, Barry Walker wrote: Unfortunately the people remaining are just as lost as me. No one has attempted to build with dtrace so I'm in uncharted territory. Was the customization done under version control? If so then as last resort use bisect or equivalent to find the breaking

Re: Help Resolving Compiler Errors With enable-dtrace Flag

Barry Walker writes: > I have compiled vanilla pg16.4 with the same flags and the probes got > created and linked as expected with no issues so I'm assuming there is some > difference in the custom version that is causing the errors but I'm having > a hard time tracking it down. I'm wondering if a

Re: Using Expanded Objects other than Arrays from plpgsql

Michel Pelletier writes: > On Sun, Oct 20, 2024 at 10:13 AM Tom Lane wrote: >> The other problem is that plpgsql only knows how to do such expansion >> for arrays, and it's not obvious how to extend that part. > Perhaps a third member function for ExpandedObjectMethods that formalizes > the expa

Re: Help Resolving Compiler Errors With enable-dtrace Flag

Unfortunately the people remaining are just as lost as me. No one has attempted to build with dtrace so I'm in uncharted territory. A diff of the object file doesn't give any useful information, the custom version has a lot of differences since there have been a number of changes from stock. postg

Re: Using Expanded Objects other than Arrays from plpgsql

On Sun, Oct 20, 2024 at 10:13 AM Tom Lane wrote: > Michel Pelletier writes: > > I found this thread from the original path implementation from Tom Lane > in > > >> appropriate APIs is left as a task for future work. > > Yeah, we thought that it wouldn't be appropriate to try to design > general

Re: Help Resolving Compiler Errors With enable-dtrace Flag

On 10/20/24 09:30, Barry Walker wrote: Hey folks, I have compiled vanilla pg16.4 with the same flags and the probes got created and linked as expected with no issues so I'm assuming there is some difference in the custom version that is causing the errors but I'm having a hard time tracking

Help Resolving Compiler Errors With enable-dtrace Flag

Hey folks, I'm working on a custom version of Postgres that is roughly in line with 16.4 but has customizations in it. I'm trying to compile this custom version (on Linux) with `--enable-dtrace` but I'm running into an issue during the linker stage. I've done a clean and full rebuild but that does

Re: Using Expanded Objects other than Arrays from plpgsql

Michel Pelletier writes: > I found this thread from the original path implementation from Tom Lane in > 2015: > https://www.postgresql.org/message-id/E1Ysvgz-s0-DP%40gemulon.postgresql.org >> In this initial implementation, a few heuristics have been hard-wired >> into plpgsql to improve perfo

Using Expanded Objects other than Arrays from plpgsql

Hello! I'm working on the OneSparse Postgres extension that wraps the GraphBLAS API with a SQL interface for doing graph analytics and other sparse linear algebra operations: https://onesparse.github.io/OneSparse/test_matrix_header/ OneSparse wraps the GraphBLAS opaque handles in Expanded Object

Re: Postgres attach partition: AccessExclusive lock set on different tables depending on how attaching is performed

On 10/20/24 04:31, user wrote: Hello, I was reading all the tips that could make the attach partition operation seamless. https://www.postgresql.org/docs/current/ddl-partitioning.html There is a mention about check constraint tha

Postgres attach partition: AccessExclusive lock set on different tables depending on how attaching is performed

Hello, I was reading all the tips that could make the attach partition operation seamless. https://www.postgresql.org/docs/current/ddl-partitioning.html There is a mention about check constraint that could be places before the attach process. But to minimise the time when AccessExclusive lock is he