[HACKERS] pg_uuid_t support in contrib/btree_gist

2015-07-18 Thread Jarred Ward
I'd like to add uuid support to contrib/btree_gist.


* 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
* Regression tests
* I've probably missed something, but that's the basic idea


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

Re: [HACKERS] pglogical_output - a general purpose logical decoding output plugin

2016-01-07 Thread Jarred Ward
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 Ringer  wrote:

> 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

Description: Binary data

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription: