Re: [HACKERS] Extension upgrade, patch v0: debug help needed
Robert Haas writes: > Committed. Thanks! -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extension upgrade, patch v0: debug help needed
On Sun, Jan 2, 2011 at 6:43 AM, Dimitri Fontaine wrote: > Dimitri Fontaine writes: >> make -C contrib/citext install >> psql -f .../head/share/contrib/citext.sql >> psql >> dim=# do $$ begin execute 'alter operator class public.citext_ops using >> btree set schema utils'; end; $$; >> server closed the connection unexpectedly >> This probably means the server terminated abnormally >> before or while processing the request. >> The connection to the server was lost. Attempting reset: Failed. > > The fix was ok, but I had to test with the right environment to be able > to appreciate that :) Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extension upgrade, patch v0: debug help needed
"David E. Wheeler" writes: >> http://pgsql.tapoueh.org/extensions/doc/html/extend-extension.html > > I was responding to your email mentioning it, which did not reference said > docs. Fair enough, I'm still interested in you telling me if I get to rewrite them all or if it's explaining the thing well enough :) Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extension upgrade, patch v0: debug help needed
On Jan 3, 2011, at 11:54 AM, Dimitri Fontaine wrote: >> That's what I understood your original "UPGRADE from NULL" being. Did I >> misread you? > > Are the docs about the feature, available handy in HTML so that you > don't have to read them in SGML at my git repository, are they *that* > bad? > > http://pgsql.tapoueh.org/extensions/doc/html/extend-extension.html I was responding to your email mentioning it, which did not reference said docs. David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extension upgrade, patch v0: debug help needed
"David E. Wheeler" writes: > That's what I understood your original "UPGRADE from NULL" being. Did I > misread you? Are the docs about the feature, available handy in HTML so that you don't have to read them in SGML at my git repository, are they *that* bad? http://pgsql.tapoueh.org/extensions/doc/html/extend-extension.html Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extension upgrade, patch v0: debug help needed
On Jan 3, 2011, at 11:49 AM, Dimitri Fontaine wrote: > "David E. Wheeler" writes: >> I rather doubt that "WRAPPER" will be accepted as a reserved word in the >> grammar. > > It's already in the grammar, and I didn't change its "level". Okay. >>> dim=# create wrapper extension lo; >>> CREATE EXTENSION >> >> What happened to your UPGRADE from NULL idea? > > You upgrade an installed extension, right? What? >>> The WRAPPER keyword meaning is that we're only creating the catalog >>> entry, forcing version to NULL and not running the extension's script. >>> This keyword looked like the best choice from existing ones in our >>> grammar, please feel free to pick any other phrase here. >> >> I don't see why it's necessary at all. > > Care to offer an alternative or go in any level of details about what > you have in mind and how *exactly* you think it should work? I've not > been offered psychic powers this Christmas, sorry… That's what I understood your original "UPGRADE from NULL" being. Did I misread you? Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extension upgrade, patch v0: debug help needed
"David E. Wheeler" writes: > I rather doubt that "WRAPPER" will be accepted as a reserved word in the > grammar. It's already in the grammar, and I didn't change its "level". >> dim=# create wrapper extension lo; >> CREATE EXTENSION > > What happened to your UPGRADE from NULL idea? You upgrade an installed extension, right? >> The WRAPPER keyword meaning is that we're only creating the catalog >> entry, forcing version to NULL and not running the extension's script. >> This keyword looked like the best choice from existing ones in our >> grammar, please feel free to pick any other phrase here. > > I don't see why it's necessary at all. Care to offer an alternative or go in any level of details about what you have in mind and how *exactly* you think it should work? I've not been offered psychic powers this Christmas, sorry… Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extension upgrade, patch v0: debug help needed
On Jan 1, 2011, at 2:30 PM, Dimitri Fontaine wrote: > To support that is quite simple in fact, as the following commands will > do the trick: > > CREATE WRAPPER EXTENSION ...;-- don't run the script > ALTER OBJECT ... SET EXTENSION ...; -- that's in the upgrade script > ALTER EXTENSION ... UPGRADE; -- as "usual" I rather doubt that "WRAPPER" will be accepted as a reserved word in the grammar. > Here's an example: > > dim=# \i ~/pgsql/exts/share/contrib/lo.sql > CREATE DOMAIN > CREATE FUNCTION > CREATE FUNCTION > > dim=# create wrapper extension lo; > CREATE EXTENSION What happened to your UPGRADE from NULL idea? > The WRAPPER keyword meaning is that we're only creating the catalog > entry, forcing version to NULL and not running the extension's script. > This keyword looked like the best choice from existing ones in our > grammar, please feel free to pick any other phrase here. I don't see why it's necessary at all. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extension upgrade, patch v0: debug help needed
Dimitri Fontaine writes:
> make -C contrib/citext install
> psql -f .../head/share/contrib/citext.sql
> psql
> dim=# do $$ begin execute 'alter operator class public.citext_ops using
> btree set schema utils'; end; $$;
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> The connection to the server was lost. Attempting reset: Failed.
The fix was ok, but I had to test with the right environment to be able
to appreciate that :)
Please find it attached.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
*** a/src/backend/commands/alter.c
--- b/src/backend/commands/alter.c
***
*** 198,208 ExecAlterObjectSchemaStmt(AlterObjectSchemaStmt *stmt)
break;
case OBJECT_OPCLASS:
! AlterOpClassNamespace(stmt->object, stmt->objarg, stmt->newschema);
break;
case OBJECT_OPFAMILY:
! AlterOpFamilyNamespace(stmt->object, stmt->objarg, stmt->newschema);
break;
case OBJECT_SEQUENCE:
--- 198,208
break;
case OBJECT_OPCLASS:
! AlterOpClassNamespace(stmt->object, stmt->addname, stmt->newschema);
break;
case OBJECT_OPFAMILY:
! AlterOpFamilyNamespace(stmt->object, stmt->addname, stmt->newschema);
break;
case OBJECT_SEQUENCE:
*** a/src/backend/commands/opclasscmds.c
--- b/src/backend/commands/opclasscmds.c
***
*** 1993,2008 AlterOpClassOwner_internal(Relation rel, HeapTuple tup, Oid newOwnerId)
* ALTER OPERATOR CLASS any_name USING access_method SET SCHEMA name
*/
void
! AlterOpClassNamespace(List *name, List *argam, const char *newschema)
{
Oid amOid;
- char *access_method = linitial(argam);
Relation rel;
Oid oid;
Oid nspOid;
- Assert(list_length(argam) == 1);
-
amOid = get_am_oid(access_method, false);
rel = heap_open(OperatorClassRelationId, RowExclusiveLock);
--- 1993,2005
* ALTER OPERATOR CLASS any_name USING access_method SET SCHEMA name
*/
void
! AlterOpClassNamespace(List *name, char *access_method, const char *newschema)
{
Oid amOid;
Relation rel;
Oid oid;
Oid nspOid;
amOid = get_am_oid(access_method, false);
rel = heap_open(OperatorClassRelationId, RowExclusiveLock);
***
*** 2185,2199 get_am_oid(const char *amname, bool missing_ok)
* ALTER OPERATOR FAMILY any_name USING access_method SET SCHEMA name
*/
void
! AlterOpFamilyNamespace(List *name, List *argam, const char *newschema)
{
Oid amOid;
- char *access_method = linitial(argam);
Relation rel;
Oid nspOid;
Oid oid;
- Assert(list_length(argam) == 1);
amOid = get_am_oid(access_method, false);
rel = heap_open(OperatorFamilyRelationId, RowExclusiveLock);
--- 2182,2194
* ALTER OPERATOR FAMILY any_name USING access_method SET SCHEMA name
*/
void
! AlterOpFamilyNamespace(List *name, char *access_method, const char *newschema)
{
Oid amOid;
Relation rel;
Oid nspOid;
Oid oid;
amOid = get_am_oid(access_method, false);
rel = heap_open(OperatorFamilyRelationId, RowExclusiveLock);
*** a/src/backend/parser/gram.y
--- b/src/backend/parser/gram.y
***
*** 6225,6231 AlterObjectSchemaStmt:
AlterObjectSchemaStmt *n = makeNode(AlterObjectSchemaStmt);
n->objectType = OBJECT_OPCLASS;
n->object = $4;
! n->objarg = list_make1($6);
n->newschema = $9;
$$ = (Node *)n;
}
--- 6225,6231
AlterObjectSchemaStmt *n = makeNode(AlterObjectSchemaStmt);
n->objectType = OBJECT_OPCLASS;
n->object = $4;
! n->addname = $6;
n->newschema = $9;
$$ = (Node *)n;
}
***
*** 6234,6240 AlterObjectSchemaStmt:
AlterObjectSchemaStmt *n = makeNode(AlterObjectSchemaStmt);
n->objectType = OBJECT_OPFAMILY;
n->object = $4;
! n->objarg = list_make1($6);
n->newschema = $9;
$$ = (Node *)n;
}
--- 6234,6240
AlterObjectSchemaStmt *n = makeNode(AlterObjectSchemaStmt);
n->objectType = OBJECT_OPFAMILY;
n->object = $4;
! n->addname = $6;
n->newschema = $9;
$$ = (Node *)n;
}
*** a/src/include/commands/defrem.h
--- b/src/include/commands/defrem.h
***
*** 101,111 extern void RenameOpClass(List *name, const char *access_method, const char *new
extern void RenameOpFamily(List *name, const char *access_method, const char *newname);
extern void AlterOpClassOwner(List *name, const char *access_method, Oid newOwnerId);
extern void AlterOpClassOwner_oid(Oid opclassOid, Oid newOwnerId);
! extern void AlterOpClassNamespace(List *name, List *argam, const char *newschema);
extern void AlterOpFamilyOwner(List *name, const char *access_method, Oid newOwnerId);
extern void AlterOpFamilyOwner_oid(Oid opfamilyOid, Oid newOwnerI
Re: [HACKERS] Extension upgrade, patch v0: debug help needed
Dimitri Fontaine writes: > The problem occurs on ALTER OPERATOR FAMILY ... SET EXTENSION, that's > what dichotomy on the citext.upgrade.sql tells me. The code in question was copy/pasted from the SET SCHEMA code path in gram.y then other related files. So I just tested a clean HEAD checkout then the following steps: make -C contrib/citext install psql -f .../head/share/contrib/citext.sql psql dim=# do $$ begin execute 'alter operator class public.citext_ops using btree set schema utils'; end; $$; server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. Will try to debug that as soon as possible, but spare time here tends to be sparse so I preferred sending this mail first. Preliminary investigation leads me thinking the cause is using n->objarg rather than n->addname to host the access_method. Working on a fix. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
