Re: [PATCHES] Patch for psql 8.0, 8.1 and 8.2 backwards compatibility
Bryce Nesbitt wrote: Ugh, I started the wrong version of psql again. This patch offers basic backwards compatibility, so a version 8.4 psql can successfully do common operations on Postgres 8.0, 8.1, 8.2 and 8.3. I expect it's incomplete support, but as of yet I can't find an actual problem. To me it is a step forward regardless, as it fixes \d which is pretty crucial even when just popping to an old server to check on something before an upgrade. Guillaume Lelarge just submitted a patch for this. Did you check it out? It's on the July commitfest page. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to change psql default banner v6
Guillaume Lelarge wrote: Here is a patch that tries to implement this. Meta-commands should work from 7.4 to 8.4-devel releases. It was not hard to do, and I don't think it really is a burden to maintain. One part left to fix is \du and \dg commands. I would be glad to continue to work on this but I would prefer to have comments before. Good work! I submitted a similar patch also. For your patch I have one critique: the version sensitive code is scattered all through describe.c. Are there opportunities to apply some tests at a higher level (reducing the number of tests), or gather the tests into an easily maintainable chunk? The cleaner it is, the more likely future patchers will continue to maintain compatibility. -Bryce Nesbitt -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Simplify formatting.c
Tom Lane wrote: Also, it seems a bit inconsistent to be relying on oracle_compat.c for upper/lower but not initcap. I saw this inconsistence while I'm doing the patch. What about moving that upper/lower/initcap and wcs* code to another file. pg_locale.c? BTW, formatting.c and oracle_compat.c already include pg_locale.h. -- Euler Taveira de Oliveira http://www.timbira.com/ -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] libpq object hooks (libpq events)
On Mon, May 19, 2008 at 8:22 PM, Tom Lane [EMAIL PROTECTED] wrote: Andrew Chernow [EMAIL PROTECTED] writes: Here is an updated patch for what was called object hooks. This is now called libpq events. If someone has a better name or hates ours, let us know. This is starting to get there, Interesting you haven't commented on two areas, the actual placement of the event callers in the libpq code (i'm assuming these are ok), and the PQcopyResult/PQsetvalue functions. The latter area introduces some new behavior into standard libpq (imo) so it deserves some scrutiny. merlin -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Patch to change psql default banner v6
Bryce Nesbitt a écrit :
Guillaume Lelarge wrote:
Here is a patch that tries to implement this. Meta-commands should
work from 7.4 to 8.4-devel releases. It was not hard to do, and I
don't think it really is a burden to maintain.
One part left to fix is \du and \dg commands. I would be glad to
continue to work on this but I would prefer to have comments before.
Good work! I submitted a similar patch also.
Yes, I've seen that.
For your patch I have one critique: the version sensitive code is
scattered all through describe.c. Are there opportunities to apply some
tests at a higher level (reducing the number of tests), or gather the
tests into an easily maintainable chunk?
I can't find an easy way to do this. And question is: is it really
interesting to do this? I'm not sure it's worth it. If you want to work
on this and patch my patch, you're welcome :)
The cleaner it is, the more likely future patchers will continue to
maintain compatibility.
+1
Attached is a new version of the patch. It fixes a few issues when one
adds a pattern to metacommands.
Regards.
--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com
Index: src/bin/psql/describe.c
===
RCS file: /opt/cvsroot_postgresql/pgsql/src/bin/psql/describe.c,v
retrieving revision 1.173
diff -c -c -r1.173 describe.c
*** src/bin/psql/describe.c 13 May 2008 00:23:17 - 1.173
--- src/bin/psql/describe.c 20 May 2008 19:33:27 -
***
*** 59,68
* There are two kinds of aggregates: ones that work on particular types
* and ones that work on all (denoted by input type = any)
*/
printfPQExpBuffer(buf,
SELECT n.nspname as \%s\,\n
p.proname AS \%s\,\n
! pg_catalog.format_type(p.prorettype, NULL) AS \%s\,\n
CASE WHEN p.pronargs = 0\n
THEN CAST('*' AS pg_catalog.text)\n
ELSE\n
--- 59,75
* There are two kinds of aggregates: ones that work on particular types
* and ones that work on all (denoted by input type = any)
*/
+
printfPQExpBuffer(buf,
SELECT n.nspname as \%s\,\n
p.proname AS \%s\,\n
! pg_catalog.format_type(p.prorettype, NULL) AS \%s\,
! gettext_noop(Schema),
! gettext_noop(Name),
! gettext_noop(Result data type));
!
! if (pset.sversion = 80100)
! appendPQExpBuffer(buf, ,\n
CASE WHEN p.pronargs = 0\n
THEN CAST('*' AS pg_catalog.text)\n
ELSE\n
***
*** 72,86
FROM\n
pg_catalog.generate_series(0, pg_catalog.array_upper(p.proargtypes, 1)) AS s(i)\n
), ', ')\n
! END AS \%s\,\n
! pg_catalog.obj_description(p.oid, 'pg_proc') as \%s\\n
FROM pg_catalog.pg_proc p\n
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = p.pronamespace\n
WHERE p.proisagg\n,
- gettext_noop(Schema),
- gettext_noop(Name),
- gettext_noop(Result data type),
- gettext_noop(Argument data types),
gettext_noop(Description));
processSQLNamePattern(pset.db, buf, pattern, true, false,
--- 79,91
FROM\n
pg_catalog.generate_series(0, pg_catalog.array_upper(p.proargtypes, 1)) AS s(i)\n
), ', ')\n
! END AS \%s\,
! gettext_noop(Argument data types));
!
! appendPQExpBuffer(buf, ,\n pg_catalog.obj_description(p.oid, 'pg_proc') as \%s\\n
FROM pg_catalog.pg_proc p\n
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = p.pronamespace\n
WHERE p.proisagg\n,
gettext_noop(Description));
processSQLNamePattern(pset.db, buf, pattern, true, false,
***
*** 132,142
gettext_noop(Location));
if (verbose)
appendPQExpBuffer(buf,
! ,\n spcacl AS \%s\
! ,\n pg_catalog.shobj_description(oid, 'pg_tablespace') AS \%s\,
! gettext_noop(Access privileges),
gettext_noop(Description));
appendPQExpBuffer(buf,
\nFROM pg_catalog.pg_tablespace\n);
--- 137,151
gettext_noop(Location));
if (verbose)
+ {
appendPQExpBuffer(buf,
! ,\n spcacl AS \%s\,
! gettext_noop(Access privileges));
! if (pset.sversion = 80200)
! appendPQExpBuffer(buf,
! ,\n pg_catalog.shobj_description(oid, 'pg_tablespace') AS \%s\,
gettext_noop(Description));
+ }
appendPQExpBuffer(buf,
\nFROM pg_catalog.pg_tablespace\n);
***
*** 179,186
SELECT n.nspname as \%s\,\n
p.proname as \%s\,\n
CASE WHEN p.proretset THEN 'setof ' ELSE '' END ||\n
! pg_catalog.format_type(p.prorettype, NULL) as \%s\,\n
! CASE WHEN proallargtypes IS NOT NULL THEN\n
pg_catalog.array_to_string(ARRAY(\n
SELECT\n
CASE\n
--- 188,201
Re: [PATCHES] Map forks (WIP)
Tom Lane wrote: One thing I did *not* like was changing the FSM API to refer to Relation rather than RelFileNode --- I don't believe that's a good idea at all. In particular, consider what happens during TRUNCATE or CLUSTER: it's not very clear how you'll tell the versions of the relation apart. If you want to push the FSM API up to use SMgrRelation instead of RelFileNode, that'd be okay, but not Relation. (Essentially the distinction I'm trying to preserve here is logical vs physical relation.) Oh really? I'm quite fond of the new API. From a philosophical point of view, in the new world order, the FSM is an integral part of a relation, not something tacked on the physical layer. TRUNCATE and CLUSTER will need to truncate and truncate+recreate the FSM file, respectively. The FSM fork is on an equal footing with the main fork: when TRUNCATE swaps the relation file, a new FSM fork is created as well, and there's no way or need to access the old file anymore. When a relation is moved to another tablespace, the FSM fork is moved as well, and while the RelFileNode changes at that point, the logical Relation is the same. Besides, Relation contains a bunch of very handy fields. pgstat_info in particular, which is needed if we want to collect pgstat information about FSM, and I think we will. I might also want add a field like rd_amcache there, for the FSM: I'm thinking of implementing something like the fastroot thing we have in b-tree, and we might need some other per-relation information there as well. The XLogOpenRelationWithFork stuff needs to be re-thought also, as again this is blurring the question of what's a logical and what's a physical relation --- and if forknum isn't part of the relation ID, that API is wrong either way. I'm not sure about a good solution in this area, but I wonder if the right answer might be to make the XLOG replay stuff use SMgrRelations instead of bogus Relations. IIRC the replay code design predates the existence of SMgrRelation, so maybe we need a fresh look there. Agreed, I'm not happy with that part either. I tried to do just what you suggest, make XLOG replay stuff deal with SMgrRelations instead of the lightweight relcache, and it did look good until I got to refactoring btree_xlog_cleanup() (GIN/GiST has the same problem, IIRC). btree_xlog_cleanup() uses the same functions as the normal-operation code to insert pointers to parent pages, which operates on Relation. That started to become really hairy to solve without completely bastardizing the normal code paths. Hmm. One idea would be to still provide a function to create a fake RelationData struct from SMgrRelation, which the redo function can call in that kind of situations. (On closer look, XLogOpenRelationWithFork seems unused anyway That's just because FSM WAL-logging hasn't been implemented yet. One really trivial thing that grated on me was + /* + * In a few places we need to loop through 0..MAX_FORKS to discover which + * forks exists, so we should try to keep this number small. + */ + #define MAX_FORKS (FSM_FORKNUM + 1) I think you should either call it MAX_FORK (equal to the last fork number) or NUM_FORKS (equal to last fork number plus one). As is, it's just confusing. Agreed, will fix. And the comment is flat out wrong for the current usage. What's described in the comment is done in ATExecSetTableSpace. I grant you that there's many other usages for it. I'll work on the comment. BTW, it would probably be a good idea to try to get the fork access API committed before you work on FSM. Whenever you can break a big patch into successive sections, it's a good idea, IMHO. I don't think there's any doubt that we are going to go in this direction, so I see no objection to committing fork-based API revisions in advance of having any real use for them. Yep. I'll develop them together for now, but will separate them when the fork stuff is ripe for committing. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Simplify formatting.c
Euler Taveira de Oliveira [EMAIL PROTECTED] writes: Tom Lane wrote: Also, it seems a bit inconsistent to be relying on oracle_compat.c for upper/lower but not initcap. I saw this inconsistence while I'm doing the patch. What about moving that upper/lower/initcap and wcs* code to another file. pg_locale.c? That doesn't seem a particularly appropriate place for them. pg_locale is about dealing with the locale state, not about doing actual operations based on the locale data. I was just thinking of having oracle_compat expose an initcap routine. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Map forks (WIP)
Heikki Linnakangas [EMAIL PROTECTED] writes: Tom Lane wrote: One thing I did *not* like was changing the FSM API to refer to Relation rather than RelFileNode --- I don't believe that's a good idea at all. Oh really? I'm quite fond of the new API. From a philosophical point of view, in the new world order, the FSM is an integral part of a relation, not something tacked on the physical layer. So? When you have two live versions of a relation, it's still going to be necessary to track their free state separately. Besides, Relation contains a bunch of very handy fields. This just sounds like you're looking for ways to commit layering violations. The reason we invented SMgrRelation in the first place was to get the low-level routines out of dealing with Relation, and I'm not eager to undo that effort. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
[PATCHES] LOCK_DEBUG documentation
Documentation patch by Kevin L. McBride explaining LOCK_DEBUG options in detail. -- Greg Sabino Mullane End Point Corporation Index: config.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/config.sgml,v retrieving revision 1.179 diff -c -c -r1.179 config.sgml *** config.sgml 19 May 2008 18:08:15 - 1.179 --- config.sgml 21 May 2008 00:03:09 - *** *** 5084,5098 varlistentry termvarnametrace_locks/varname (typeboolean/type)/term termvarnametrace_lwlocks/varname (typeboolean/type)/term termvarnametrace_userlocks/varname (typeboolean/type)/term ! termvarnametrace_lock_oidmin/varname (typeboolean/type)/term ! termvarnametrace_lock_table/varname (typeboolean/type)/term termvarnamedebug_deadlocks/varname (typeboolean/type)/term termvarnamelog_btree_build_stats/varname (typeboolean/type)/term listitem para ! Various other code tracing and debugging options. /para /listitem /varlistentry --- 5084,5244 varlistentry termvarnametrace_locks/varname (typeboolean/type)/term + indexterm +primaryvarnametrace_locks/ configuration parameter/primary + /indexterm + listitem +para + If on, emit information about lock usage. Information dumped + includes the type of lock operation, the type of lock and the unique + identifier of the object being locked or unlocked. Also included + are bitmasks for the lock types already granted on this object as + well as for the lock types awaited on this object. For each lock + type a count of the number of granted locks and waiting locks is + also dumped as well as the totals. An example of the log file output + is shown here: +/para +para + LOG: LockAcquire: new: lock(0xb7acd844) id(24688,24696,0,0,0,1) + grantMask(0) req(0,0,0,0,0,0,0)=0 grant(0,0,0,0,0,0,0)=0 + wait(0) type(AccessShareLock) +/para +para + LOG: GrantLock: lock(0xb7acd844) id(24688,24696,0,0,0,1) + grantMask(2) req(1,0,0,0,0,0,0)=1 grant(1,0,0,0,0,0,0)=1 + wait(0) type(AccessShareLock) + +/para +para + LOG: UnGrantLock: updated: lock(0xb7acd844) id(24688,24696,0,0,0,1) + grantMask(0) req(0,0,0,0,0,0,0)=0 grant(0,0,0,0,0,0,0)=0 + wait(0) type(AccessShareLock) +/para +para + LOG: CleanUpLock: deleting: lock(0xb7acd844) id(24688,24696,0,0,0,1) + grantMask(0) req(0,0,0,0,0,0,0)=0 grant(0,0,0,0,0,0,0)=0 + wait(0) type(INVALID) +/para +para + Details of the structure being dumped may be found in + src/include/storage/lock.h +/para +para + This parameter is only available if the symbolLOCK_DEBUG/symbol + macro was defined when productnamePostgreSQL/productname was + compiled. +/para + /listitem + /varlistentry + + varlistentry termvarnametrace_lwlocks/varname (typeboolean/type)/term + indexterm +primaryvarnametrace_lwlocks/ configuration parameter/primary + /indexterm + listitem +para + If on, emit information about lightweight lock usage. Lightweight + locks are intended primarily to provide mutual exclusion of access + to shared-memory data structures. +/para +para + This parameter is only available if the symbolLOCK_DEBUG/symbol + macro was defined when productnamePostgreSQL/productname was + compiled. +/para + /listitem + /varlistentry + + varlistentry termvarnametrace_userlocks/varname (typeboolean/type)/term ! indexterm !primaryvarnametrace_userlocks/ configuration parameter/primary ! /indexterm ! listitem !para ! If on, emit information about user lock usage. Output is the same ! as for symboltrace_locks/symbol, only for user locks. !/para !para ! User locks were removed as of PostgreSQL version 8.2. This option ! currently has no effect. !/para !para ! This parameter is only available if the symbolLOCK_DEBUG/symbol ! macro was defined when productnamePostgreSQL/productname was ! compiled. !/para ! /listitem ! /varlistentry ! ! varlistentry ! termvarnametrace_lock_oidmin/varname (typeinteger/type)/term ! indexterm !primaryvarnametrace_lock_oidmin/ configuration parameter/primary ! /indexterm ! listitem !para ! If set, do not trace locks for tables below this OID. (use to avoid ! output on system tables) !/para !para ! This
Re: [PATCHES] WITH RECURSIVE patch V0.1
On May 19, 1:17 am, [EMAIL PROTECTED] (David Fetter) wrote: On Mon, May 19, 2008 at 12:21:20AM -0400, Gregory Stark wrote: It's quite possible to have clauses which will limit the output but not in a way the database can determine. Consider for example a tree-traversal for a binary tree stored in a recursive table reference. The DBA might know that the data contains no loops but the database doesn't. I seem to recall Oracle's implementation can do this traversal on write operations, but maybe that's just their marketing. That's how I implement (id, name, parent)-trees as a DBA, having an insert/update trigger function check_no_loops(), but I'm not sure that it would be faster than the hash method suggested by Hannu Krosing. I guess it depends on whether you're inserting/updating or selecting more. Does it make sense to leave the option to the user, whether to check for infinite recursion just in time or not? Kev -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
