Re: [HACKERS] pglogical_output - a general purpose logical decoding output plugin
I didn't receive a response on the bugs mailing list for the following bug, so I was hoping we could triage to someone with more familiarity with Postgres internals than I to fix. This ticket seems like folks who are invested in logical decoding. The attached script is a simple workload that logical decoding is unable to decode. It causes an unrecoverable crash in the logical decoder with 'ERROR: subxact logged without previous toplevel record'. On Thu, Jan 7, 2016 at 12:44 AM, Craig Ringerwrote: > > Here's v5 of the pglogical patch. > > Changes: > > * Implement relation metadata caching > * Add the relmeta_cache_size parameter for cache control > * Add an extension to get version information > * Create the pglogical_output header directory on install > * Restore 9.4 compatibility (it's small) > * Allow row filter hooks to see details of the changed tuple > * Remove forward_changesets from pglogical_output (use a hook if you want > this functionality) > > I'm not sure if 9.4 compat will be desirable or not. It's handy to avoid > needing a separate backported version, but also confusing to do a PGXS > build within a 9.6 tree against 9.4... > > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > > bug.sql Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] pg_uuid_t support in contrib/btree_gist
I'd like to add uuid support to contrib/btree_gist. Proposal: * Add `contrib/btree_gist/btree_uuid.c' with implementation based on gbtree_ninfo type description * Modify `contrib/btree_gist/btree_utils_num.c' to support pg_uuid_t * Modify `contrib/btree_gist/btree_gist.h' to add gbt_t_uuid type * Add `contrib/btree_gist/btree_gist--1.2.sql' with gist_uuid_ops * Modify `Makefile' to build btree_uuid * Modify `contrib/btree_gist/btree_gist.control' to set default_version to 1.2 * Regression tests * I've probably missed something, but that's the basic idea Question: pg_uuid_t is an opaque type in `src/include/utils/uuid.h'. To put this type in a struct for both a new uuidKEY and the gbtree_ninfo type description support we need the implementation of the struct that is currently hidden in `src/backend/utils/adt/uuid.c'. We could get around this by using gbtree_vinfo type description for uuid, but this is not a var type. That smells a little to me. Is modifying `src/include/utils/uuid.h' to leak the implementation details of pg_uuid_t in `src/backend/utils/adt/uuid.c' an option? It seems pretty drastic to make that change just for contrib/btree_gist, but the 16-byte char[] representation seems fairly standard to me. I don't know why this would be needed at some point in the future, but another possible impl could be a hi/lo int64 to represent the uuid type (like java), so leaking the implementation details would potentially add a btree_gist dependency to ever doing this in the future. A third option is to have our own impl of pg_uuid_t or something similar in btree_gist. Having two independent implementations of pg_uuid_t in postgres and btree_gist smells even worse and opens us up to dependency issues (that may very well be caught by the regression tests). The answer is not obvious to me how to proceed on this. (I'm a first-time poster so please correct any procedures or etiquette I'm missing)