Re: [HACKERS] further explain changes

[Jaime Casanova]

On Sat, Jan 23, 2010 at 10:08 PM, Robert Haas  wrote:
>
> I was also thinking about the possibility of adding a new option
> called "output" and making that control whether the "Output" line gets
> printed.  It's kind of annoying to use EXPLAIN (ANALYZE, VERBOSE)

why not let it go in ANALYZE, just as the sort info

-- 
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157

-- 
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] [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

[KaiGai Kohei]

(2010/01/24 12:29), Robert Haas wrote:

On Sat, Jan 23, 2010 at 1:45 PM, Bernd Helmle  wrote:

--On 14. Januar 2010 16:04:17 +0900 KaiGai Kohei
wrote:

This patch adds:

  List *find_column_origin(Oid relOid, const char *colName)

It returns the list of relation OIDs which originally defines the given
column. In most cases, it returns a list with an element. But, if the
column is inherited from multiple parent relations and merged during the
inheritance tree, the returned list contains multiple OIDs.
In this case, we have to forbid changing type and renaming to keep
correctness of the table definition.


Here's a slightly edited version of this patch from reviewing, fixing the
following:

* Fix a compiler warning by passing a pointer to skey to
systable_beginscan() (it's an array already)

* Edit some comments

The patch works as expected (at least, i don't see any remaining issues).
I'm going to mark this ready for committer.


I don't think this is ready for committer, becauseTom previously
objected to the approach taken by this patch here, and no one has
answered his objections:

http://archives.postgresql.org/pgsql-hackers/2010-01/msg00144.php

I think someone needs to figure out what the worst-case scenario for
this is performance-wise and submit a reproducible test case with
benchmark results.  In the meantime, I'm going to set this to Waiting
on Author.


Basically, I don't think it is not a performance focused command,
because we may be able to assume ALTER TABLE RENAME TO is not much
frequent operations.

However, I'm interested in between two approaches.
I'll check both of them. Isn't is necessary to compare the vanilla code base,
because the matter is a bug to be fixed?

 http://archives.postgresql.org/message-id/4b41bb04.2070...@ak.jp.nec.com
 
http://archives.postgresql.org/message-id/a7739f610fb0bd89e310d...@[172.26.14.62]

Please wait for weekday, because I don't have physical (not virtual) machine
in my home.

Thanks,
--
KaiGai Kohei 

--
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] restructuring "alter table" privilege checks

[KaiGai Kohei]

(2010/01/24 12:16), Robert Haas wrote:

On Sat, Jan 23, 2010 at 10:11 PM, KaiGai Kohei  wrote:

If we put the new ATSimplePermissions() with all the needed information
just after gathering them at the execution stage, we don't need to have
some of exceptions which takes additional checks except for ownership
on the relation to be altered.


Maybe I'm still not understanding, but I don't see how you're going to
do this without a massive pile of spaghetti code and a function with
about 12 parameters.  Feel free to show some code, but I think this is
a non-starter.


Hhmmm,...

Indeed, indeed, if a single function tries to handle all the ALTER TABLE
options, it needs many function arguments, because ALTER TABLE is one of
the most functional statement in PostgreSQL...

If the basis is head of the execution phase, it does not need a big switch
... case branch in ATSimplePermissions, because it is already branched in
ATExecCmd(). However, it also has tradeoff that we have multiple minor version
of functions to check ALTER TABLE permissions.

Perhaps, it may be a good idea to make two conceptual patches both head of
the ATPrepCmd() and ATExec*(). They will make clear good/bad points between
two approaches.

Is it waste of efforts?

Thanks,
--
KaiGai Kohei 

--
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] [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

[Robert Haas]

On Sat, Jan 23, 2010 at 1:45 PM, Bernd Helmle  wrote:
> --On 14. Januar 2010 16:04:17 +0900 KaiGai Kohei 
> wrote:
>> This patch adds:
>>
>>  List *find_column_origin(Oid relOid, const char *colName)
>>
>> It returns the list of relation OIDs which originally defines the given
>> column. In most cases, it returns a list with an element. But, if the
>> column is inherited from multiple parent relations and merged during the
>> inheritance tree, the returned list contains multiple OIDs.
>> In this case, we have to forbid changing type and renaming to keep
>> correctness of the table definition.
>
> Here's a slightly edited version of this patch from reviewing, fixing the
> following:
>
> * Fix a compiler warning by passing a pointer to skey to
> systable_beginscan() (it's an array already)
>
> * Edit some comments
>
> The patch works as expected (at least, i don't see any remaining issues).
> I'm going to mark this ready for committer.

I don't think this is ready for committer, becauseTom previously
objected to the approach taken by this patch here, and no one has
answered his objections:

http://archives.postgresql.org/pgsql-hackers/2010-01/msg00144.php

I think someone needs to figure out what the worst-case scenario for
this is performance-wise and submit a reproducible test case with
benchmark results.  In the meantime, I'm going to set this to Waiting
on Author.

...Robert

-- 
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] restructuring "alter table" privilege checks

[Robert Haas]

On Sat, Jan 23, 2010 at 10:11 PM, KaiGai Kohei  wrote:
> If we put the new ATSimplePermissions() with all the needed information
> just after gathering them at the execution stage, we don't need to have
> some of exceptions which takes additional checks except for ownership
> on the relation to be altered.

Maybe I'm still not understanding, but I don't see how you're going to
do this without a massive pile of spaghetti code and a function with
about 12 parameters.  Feel free to show some code, but I think this is
a non-starter.

...Robert

-- 
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] restructuring "alter table" privilege checks

[KaiGai Kohei]

(2010/01/24 11:27), Robert Haas wrote:

On Sat, Jan 23, 2010 at 8:33 PM, KaiGai Kohei  wrote:

(2010/01/24 9:08), Robert Haas wrote:


On Sat, Jan 23, 2010 at 2:17 AM, KaiGai Koheiwrote:


However, it is unclear for me whether the revised ATSimplePermissions()
provide cleaner code than currently we have, because it also needs
a big switch ... case statement within.

Am I misunderstanding something?


Well, not everyone is going to agree on what "cleaner code" means in
every case, but the reason that I like my design better is because it
moves all of the decision making out of ATPrepCmd() into
ATSimplePermissions().  What you're proposing would mean that
ATPrepCmd() would basically continue to know everything about which
operations need which permissions checks, which I don't think is going
to scale very well to alternative security providers, if we eventually
decide to support such a thing.


Hmm. Indeed, the existing ATPrepCmd() closely combines the permission
checks and controls of code path (inheritance recursion and AT_PASS_*),
and it is worthwhile to divide these independent logic into two.


Yeah, that's what I thought, too.


In your plan, where the new ATSimplePermissions() should be called?



From ATPrepCmd(), just before the big switch statement.



If we still call it from the ATPrepCmd() stage, it needs to apply
special treatments some of operations with part-B logic.


Not sure if I understand what you mean.  ATSimplePermissions() won't
be responsible for applying permissions checks related to other
objects upon which the command is operating (e.g. the other table, if
adding a foreign key).  It will however be responsible for knowing
everything about which permission checks to apply to the main table
involved, which will require some special-case logic for certain
command types.


One other candidate of the entrypoint is the head of each ATExec()
functions. [...snip...]


I don't think this is a good idea.  Calling it in just one place seems
less error-prone and easier to audit.


Yes, most of the ALTER TABLE options runs ATPrepCmd() except for RENAME
TO and SET SCHEMA, so it is a good candidate to apply less error-prone
permission checks.

The reason why I introduced this alternative idea is from the perspective
of simple basis/concept about where we should apply permission checks,
although it needs larger number of entrypoints compared to head of the
ATPrepCmd().

If we put the new ATSimplePermissions() with all the needed information
just after gathering them at the execution stage, we don't need to have
some of exceptions which takes additional checks except for ownership
on the relation to be altered.

Of course, code simpleness is important. Likewise, I think simpleness in
basis/concept (less number of special treatments) is also important.



I'd like to introduce it using a pseudo code.

  :

It will allow to eliminate self recursion in ATAddCheckConstraint() and
to apply permission checks for new CHECK constraint in ATPrepCmd() phase.

Perhaps, it may be consolidated to ATPrepAddConstraint().


I don't really see that this gains us anything.


Hmm, indeed, here is no more benefit except for eliminating one self recursion.

Thanks,
--
KaiGai Kohei 

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

[HACKERS] further explain changes

[Robert Haas]

Per recent discussion on pgsql-performance, and per discussion on
-hackers that it might not be too late for small patches after all,
here is a patch (as yet without documentation) which adds some
additional instrumentation to EXPLAIN for hashes: number of buckets,
number of batches, original number of batches, and peak memory
utilization.  Thoughts?

I was also thinking about the possibility of adding a new option
called "output" and making that control whether the "Output" line gets
printed.  It's kind of annoying to use EXPLAIN (ANALYZE, VERBOSE)
right now (and moreso with this patch) specifically because of that
line, which is quite... verbose.  If we're going to change it ever we
should do it for 9.0, since we've made a lot of other changes that
people will be adjusting for anyhow.

Also, do we want to change the schema URL?  The existing URL was
suggested by Peter but IIRC there was some thought that it might not
be the best choice.

http://www.postgresql.org/2009/explain

...Robert
diff --git a/src/backend/commands/explain.c b/src/backend/commands/explain.c
index 18ddeec..fca9ba4 100644
--- a/src/backend/commands/explain.c
+++ b/src/backend/commands/explain.c
@@ -20,6 +20,7 @@
 #include "commands/explain.h"
 #include "commands/prepare.h"
 #include "commands/trigger.h"
+#include "executor/hashjoin.h"
 #include "executor/instrument.h"
 #include "optimizer/clauses.h"
 #include "optimizer/planner.h"
@@ -67,6 +68,7 @@ static void show_upper_qual(List *qual, const char *qlabel, Plan *plan,
 ExplainState *es);
 static void show_sort_keys(Plan *sortplan, ExplainState *es);
 static void show_sort_info(SortState *sortstate, ExplainState *es);
+static void show_hash_info(HashState *hashstate, ExplainState *es);
 static const char *explain_get_index_name(Oid indexId);
 static void ExplainScanTarget(Scan *plan, ExplainState *es);
 static void ExplainMemberNodes(List *plans, PlanState **planstate,
@@ -1052,6 +1054,9 @@ ExplainNode(Plan *plan, PlanState *planstate,
 			"One-Time Filter", plan, es);
 			show_upper_qual(plan->qual, "Filter", plan, es);
 			break;
+		case T_Hash:
+			show_hash_info((HashState *) planstate, es);
+			break;
 		default:
 			break;
 	}
@@ -1405,6 +1410,37 @@ show_sort_info(SortState *sortstate, ExplainState *es)
 }
 
 /*
+ * Show information on hash buckets/batches.
+ */
+static void
+show_hash_info(HashState *hashstate, ExplainState *es)
+{
+	HashJoinTable hashtable;
+
+	Assert(IsA(hashstate, HashState));
+	hashtable = hashstate->hashtable;
+
+	if (es->verbose && hashtable)
+	{
+		long spacePeakKb = (hashtable->spacePeak + 1023) / 1024;
+		ExplainPropertyLong("Hash Buckets", hashtable->nbuckets, es);
+		ExplainPropertyLong("Hash Batches", hashtable->nbatch, es);
+		ExplainPropertyLong("Original Hash Batches",
+			hashtable->nbatch_original, es);
+		if (es->format == EXPLAIN_FORMAT_TEXT)
+		{
+			appendStringInfoSpaces(es->str, es->indent * 2);
+			appendStringInfo(es->str, "Peak Memory Usage: %ldkB\n",
+			 spacePeakKb);
+		}
+		else
+		{
+			ExplainPropertyLong("Peak Memory Usage", spacePeakKb, es);
+		}
+	}
+}
+
+/*
  * Fetch the name of an index in an EXPLAIN
  *
  * We allow plugins to get control here so that plans involving hypothetical
diff --git a/src/backend/executor/nodeHash.c b/src/backend/executor/nodeHash.c
index ef55b20..7ca387b 100644
--- a/src/backend/executor/nodeHash.c
+++ b/src/backend/executor/nodeHash.c
@@ -287,6 +287,7 @@ ExecHashTableCreate(Hash *node, List *hashOperators)
 	hashtable->innerBatchFile = NULL;
 	hashtable->outerBatchFile = NULL;
 	hashtable->spaceUsed = 0;
+	hashtable->spacePeak = 0;
 	hashtable->spaceAllowed = work_mem * 1024L;
 	hashtable->spaceUsedSkew = 0;
 	hashtable->spaceAllowedSkew =
@@ -719,6 +720,8 @@ ExecHashTableInsert(HashJoinTable hashtable,
 		hashTuple->next = hashtable->buckets[bucketno];
 		hashtable->buckets[bucketno] = hashTuple;
 		hashtable->spaceUsed += hashTupleSize;
+		if (hashtable->spaceUsed > hashtable->spacePeak)
+			hashtable->spacePeak = hashtable->spaceUsed;
 		if (hashtable->spaceUsed > hashtable->spaceAllowed)
 			ExecHashIncreaseNumBatches(hashtable);
 	}
@@ -1071,6 +1074,8 @@ ExecHashBuildSkewHash(HashJoinTable hashtable, Hash *node, int mcvsToUse)
 			+ mcvsToUse * sizeof(int);
 		hashtable->spaceUsedSkew += nbuckets * sizeof(HashSkewBucket *)
 			+ mcvsToUse * sizeof(int);
+		if (hashtable->spaceUsed > hashtable->spacePeak)
+			hashtable->spacePeak = hashtable->spaceUsed;
 
 		/*
 		 * Create a skew bucket for each MCV hash value.
@@ -1119,6 +1124,8 @@ ExecHashBuildSkewHash(HashJoinTable hashtable, Hash *node, int mcvsToUse)
 			hashtable->nSkewBuckets++;
 			hashtable->spaceUsed += SKEW_BUCKET_OVERHEAD;
 			hashtable->spaceUsedSkew += SKEW_BUCKET_OVERHEAD;
+			if (hashtable->spaceUsed > hashtable->spacePeak)
+hashtable->spacePeak = hashtable->spaceUsed;
 		}
 
 		free_attstatsslot(node->skewColType,
@@ -1205,6 +1212,8 @@ ExecHashSkewTableInsert(HashJoinTable hashtable,
 	/* Account for space use

Re: [HACKERS] commit fests

[Robert Haas]

On Sat, Jan 23, 2010 at 7:59 PM, Andrew Dunstan  wrote:
> And, BTW, more process and organization can itself consume scarce resources
> as well as annoying some of the people you want to do some of this work.
> There is a sweet spot that we need to aim at.

What, me annoy someone?  That never happens.

In all honesty, I think we are anything but drowning in process.

> OK, back to making the buildfarm client git-aware ...

+1!

...Robert

-- 
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] restructuring "alter table" privilege checks (was: remove redundant ownership checks)

[Robert Haas]

On Sat, Jan 23, 2010 at 8:33 PM, KaiGai Kohei  wrote:
> (2010/01/24 9:08), Robert Haas wrote:
>>
>> On Sat, Jan 23, 2010 at 2:17 AM, KaiGai Kohei  wrote:
>>>
>>> However, it is unclear for me whether the revised ATSimplePermissions()
>>> provide cleaner code than currently we have, because it also needs
>>> a big switch ... case statement within.
>>>
>>> Am I misunderstanding something?
>>
>> Well, not everyone is going to agree on what "cleaner code" means in
>> every case, but the reason that I like my design better is because it
>> moves all of the decision making out of ATPrepCmd() into
>> ATSimplePermissions().  What you're proposing would mean that
>> ATPrepCmd() would basically continue to know everything about which
>> operations need which permissions checks, which I don't think is going
>> to scale very well to alternative security providers, if we eventually
>> decide to support such a thing.
>
> Hmm. Indeed, the existing ATPrepCmd() closely combines the permission
> checks and controls of code path (inheritance recursion and AT_PASS_*),
> and it is worthwhile to divide these independent logic into two.

Yeah, that's what I thought, too.

> In your plan, where the new ATSimplePermissions() should be called?

From ATPrepCmd(), just before the big switch statement.

> If we still call it from the ATPrepCmd() stage, it needs to apply
> special treatments some of operations with part-B logic.

Not sure if I understand what you mean.  ATSimplePermissions() won't
be responsible for applying permissions checks related to other
objects upon which the command is operating (e.g. the other table, if
adding a foreign key).  It will however be responsible for knowing
everything about which permission checks to apply to the main table
involved, which will require some special-case logic for certain
command types.

> One other candidate of the entrypoint is the head of each ATExec()
> functions. [...snip...]

I don't think this is a good idea.  Calling it in just one place seems
less error-prone and easier to audit.

 It may also be worth refactoring is ATAddCheckConstraint(), which
 currently does its own recursion only so that the constraint name at
 the top of the inheritance hierarchy propagates all the way down
 unchanged.  I wonder if it would be cleaner/possible to work out the
 constraint name earlier and then just use the standard recursion
 mechanism.
>>>
>>> Isn't it possible to check whether the given constraint is CHECK()
>>> or FOREIGN KEY in the ATPrepCmd() stage, and assign individual
>>> cmd->subtype? If CONSTR_FOREIGN, it will never recursion.
>>>
>>> In this case, we can apply checks in ATPrepCmd() stage for CONSTR_CHECK.
>>
>> I don't understand what you're saying here.
>
> I'd like to introduce it using a pseudo code.
>
> Currently, in ATPrepCmd(),
>
> |    case AT_AddConstraint:  /* ADD CONSTRAINT */
> |        ATSimplePermissions(rel, false);
> |        /* Recursion occurs during execution phase */
> |        /* No command-specific prep needed except saving recurse flag */
> |        if (recurse)
> |            cmd->subtype = AT_AddConstraintRecurse;
> |        pass = AT_PASS_ADD_CONSTR;
> |        break;
>
> What I said is:
>
> |    case AT_AddConstraint:  /* ADD CONSTRAINT */
> |    {
> |        Constraint   *newCons = (Constraint *)cmd->def;
> |        if (newCons->contype == CONSTR_CHECK)
> |        {
> |            ATSimplePermissions(rel, false);
> |            if (recurse)
> |                ATSimpleRecursion(wqueue, rel, cmd, recurse);
> |            cmd->subtype = AT_AddCheckContraint;
> |        }
> |        else if (newCond->contype == CONSTR_FOREIGN)
> |        {
> |            /* Permission checks are applied during execution stage */
> |            /* And, it never recurse */
> |            cmd->subtype = AT_AddFKConstraint;
> |        }
> |        else
> |            elog(ERROR, "unrecognized constraint type");
> |
> |        pass = AT_PASS_ADD_CONSTR;
> |        break;
> |    }
>
> It will allow to eliminate self recursion in ATAddCheckConstraint() and
> to apply permission checks for new CHECK constraint in ATPrepCmd() phase.
>
> Perhaps, it may be consolidated to ATPrepAddConstraint().

I don't really see that this gains us anything.

...Robert

-- 
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] Miscellaneous changes to plperl [PATCH]

[Alex Hunsaker]

On Sat, Jan 23, 2010 at 16:16, Tim Bunce  wrote:
> On Fri, Jan 22, 2010 at 08:59:10PM -0700, Alex Hunsaker wrote:
>> On Thu, Jan 14, 2010 at 09:07, Tim Bunce  wrote:
>> I'd vote for use warnings; as well.
>
> I would to, but sadly it's not that simple.
>
> warnings uses Carp and Carp uses eval { ... } and, owing to a sad bug in
> perl < 5.11.4, Safe can't distinguish between eval "..." and eval {...}
> http://rt.perl.org/rt3/Ticket/Display.html?id=70970
> So trying to load warnings fails (at least for some versions of perl).

Well that stinks.

> I have a version of my final "Package namespace and Safe init cleanup
> for plperl" that works around that. I opted to post a less potentially
> controversial version of that patch in the end. If you think allowing
> plperl code to 'use warnings;' is important (and I'd tend to agree)
> then I'll update that final patch.

Sounds good.

-- 
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] Miscellaneous changes to plperl [PATCH]

[Alex Hunsaker]

On Sat, Jan 23, 2010 at 16:26, Andrew Dunstan  wrote:
>
>
> Tim Bunce wrote:
>>>
>>> -   } keys %$imports;
>>> +   } sort keys %$imports;
>>>
>>
>> Ok, good.
>>
>>
>>>
>>> -   my $funcsrc;
>>> -   $funcsrc .= qq[ undef *{'$name'}; *{'$name'} = sub { $BEGIN $prolog
>>> $src } ];
>>> -   #warn "plperl mkfuncsrc: $funcsrc\n";
>>> -   return $funcsrc;
>>> +   return qq[ undef *{'$name'}; *{'$name'} = sub { $BEGIN $prolog $src }
>>> ];
>>>
>>>
>>
>> Ok. (I don't think that'll clash with any later patches.)
>>
>>
>> So, what now? Should I resend the patch with the two 'ok' changes above
>> included, or can the committer make those very minor changes?
>>
>>
>>
>
> I'll pick these up, if Alex marks it ready for committer.

Done.

-- 
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] restructuring "alter table" privilege checks (was: remove redundant ownership checks)

[KaiGai Kohei]

(2010/01/24 9:08), Robert Haas wrote:

On Sat, Jan 23, 2010 at 2:17 AM, KaiGai Kohei  wrote:

However, it is unclear for me whether the revised ATSimplePermissions()
provide cleaner code than currently we have, because it also needs
a big switch ... case statement within.

Am I misunderstanding something?


Well, not everyone is going to agree on what "cleaner code" means in
every case, but the reason that I like my design better is because it
moves all of the decision making out of ATPrepCmd() into
ATSimplePermissions().  What you're proposing would mean that
ATPrepCmd() would basically continue to know everything about which
operations need which permissions checks, which I don't think is going
to scale very well to alternative security providers, if we eventually
decide to support such a thing.


Hmm. Indeed, the existing ATPrepCmd() closely combines the permission
checks and controls of code path (inheritance recursion and AT_PASS_*),
and it is worthwhile to divide these independent logic into two.

In your plan, where the new ATSimplePermissions() should be called?

If we still call it from the ATPrepCmd() stage, it needs to apply
special treatments some of operations with part-B logic.

One other candidate of the entrypoint is the head of each ATExec()
functions. In this case, we have already gathered enough information
in B2(ATExecDropColumn, ATExecDropConstraint), B3(ATExecAddInherit)
and B4(ATPrepSetTablespace). In B1(ATAddForeignKeyConstrants), we
will need a bit more steps to collect information, but we can call
it just after all the needed information.
We can also have enough information at the head of B5(ATExecAddIndex).
However, my preference is to apply checks at the DefineIndex() when
"check_rights" equals true, because it also allows to consolidate
permission checks in ProcessUtility() with T_IndexStmt.


It may also be worth refactoring is ATAddCheckConstraint(), which
currently does its own recursion only so that the constraint name at
the top of the inheritance hierarchy propagates all the way down
unchanged.  I wonder if it would be cleaner/possible to work out the
constraint name earlier and then just use the standard recursion
mechanism.


Isn't it possible to check whether the given constraint is CHECK()
or FOREIGN KEY in the ATPrepCmd() stage, and assign individual
cmd->subtype? If CONSTR_FOREIGN, it will never recursion.

In this case, we can apply checks in ATPrepCmd() stage for CONSTR_CHECK.


I don't understand what you're saying here.


I'd like to introduce it using a pseudo code.

Currently, in ATPrepCmd(),

|case AT_AddConstraint:  /* ADD CONSTRAINT */
|ATSimplePermissions(rel, false);
|/* Recursion occurs during execution phase */
|/* No command-specific prep needed except saving recurse flag */
|if (recurse)
|cmd->subtype = AT_AddConstraintRecurse;
|pass = AT_PASS_ADD_CONSTR;
|break;

What I said is:

|case AT_AddConstraint:  /* ADD CONSTRAINT */
|{
|Constraint   *newCons = (Constraint *)cmd->def;
|if (newCons->contype == CONSTR_CHECK)
|{
|ATSimplePermissions(rel, false);
|if (recurse)
|ATSimpleRecursion(wqueue, rel, cmd, recurse);
|cmd->subtype = AT_AddCheckContraint;
|}
|else if (newCond->contype == CONSTR_FOREIGN)
|{
|/* Permission checks are applied during execution stage */
|/* And, it never recurse */
|cmd->subtype = AT_AddFKConstraint;
|}
|else
|elog(ERROR, "unrecognized constraint type");
|
|pass = AT_PASS_ADD_CONSTR;
|break;
|}

It will allow to eliminate self recursion in ATAddCheckConstraint() and
to apply permission checks for new CHECK constraint in ATPrepCmd() phase.

Perhaps, it may be consolidated to ATPrepAddConstraint().


It is a good idea to consolidate permission check into tablecmd.c from
various kind of core routines.
And, it also makes the basis clear. The permission check should be applied
after the code path gathered enough information to make its access control
decision as early as possible.


And just as importantly, in a consistent place.


I agree.

Thanks,
--
KaiGai Kohei 

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

[HACKERS] handling contrib directories as modules not shared libraries

[Brook Milligan]

It seems that src/Makefile.shlib has special cases for several
directories that build loadable modules rather than shared libraries.
The contrib/adminpack is one of the special cases, but none of the
other contrib directories are.  As a result, they get built as shared
libraries (i.e., as libXXX.so rather than XXX.so) and the
corresponding *.sql.in files that load them refer to the wrong file
and therefore fail.  The following patch (against the 8.3 release)
fixes this by expanding the set of special cases to include all the
contrib directories, not just contrib/adminpack.  I only have tested
this with the uuid module, but it appears that all of them have the
same organization.

--- src/Makefile.shlib.orig
+++ src/Makefile.shlib
@@ -21,7 +21,7 @@
 ifneq (,$(findstring src/pl/,$(subdir)))
 shmodule   = yes
 else
-ifneq (,$(findstring contrib/adminpack,$(subdir)))
+ifneq (,$(findstring contrib/,$(subdir)))
 shmodule   = yes
 else
 shmodule   = no

Cheers,
Brook

-- 
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] commit fests

[Andrew Dunstan]

Robert Haas wrote:

On Sat, Jan 23, 2010 at 12:07 PM, Andrew Dunstan  wrote:
  

Robert Haas wrote:


Perhaps it isn't that five months is outrageous,
but that it doesn't really benefit from an unorganized swarm of
activity by all the developers, and we've not worked out a
reasonable framework for who should do what during that time to best
benefit the project while giving all these volunteer and sponsored
developers something they are willing to put effort into.


I think that's pretty close.
  

I think it's pretty close to 100% BS. Who constitutes this legion of
sponsored developers in desperate need of organization? And what are they
sponsored for? I can't speak for others, but with one exception the only
sponsorship I have received is for actual development work, not release
finishing (and the exception ended up being mostly development anyway).
Sponsors almost always want to provide money for actual features. And as for
volunteers, they have a fantastic resistance to being organized in some
prescriptive way. We need to achieve what we can by persuasion. It's
sometimes a pain in the neck, but it's the reality.

The real problem is that we take a long time between the end of the
development phase and the release. That is often not something you can just
throw bodies at ("Nine women can't make a baby in a month."). Sadly, some
things do just take time to work out. It's frustrating, but shortening the
time could simply result in our making less polished releases. The problem
is likely to grow with our increasing emphasis on enterprise level features.
But I don't think that sacrificing quality for timeliness is a good trade.

That is not to say that we can't make some improvements in process, but
expecting them magically to solve this problem is a bit cargo cultish.



I think you're kind of caricaturing what I said here, and what Kevin
said.  People really are willing to put time into helping get a
release out the door if they feel like their efforts will move the
needle.  Do they get directly paid to make the release happen faster?
No, probably not. That doesn't mean they won't put time into it.  I
don't think too many people get paid to do patch review either, but
somehow we manage to have CommitFests.  It's not magic, but it does
help.


  


Certainly I was being slightly facetious. If anyone is surpised they 
haven't been paying attention ;-)


But the point I'm trying to get across is that an assumption that better 
process and more organization is somehow going to get us to a shorter 
period between feature freeze and release is not necessarily so. See 
Tom's response upthread for more reasons why this is so. That's not 
meant to discourage people from doing work, it's meant to stop people 
from getting unreal expectations.


And, BTW, more process and organization can itself consume scarce 
resources as well as annoying some of the people you want to do some of 
this work. There is a sweet spot that we need to aim at.


OK, back to making the buildfarm client git-aware ...

cheers

andrew

--
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] commit fests

[Bruce Momjian]

Greg Smith wrote:
> So why not do that?  Developing new features is fun and tends to attract 
> sponsorship dollars.  Testing a frozen release, finding bugs, and 
> resolving them is boring, and no one sponsors it.  Therefore, if you let 
> both things go on at once, I guarantee you almost all of the community 
> attention will be diverted toward new development during any period 
> where both are happening at the same time.  Give developers a choice 
> between shiny and profitable vs. dull and unpaid, and they'll focus on 
> the former every time.  That means that there's no possible way you can 
> keep new development open without hurting the dreary work around 
> stabilizing the beta in the process.  You have to put all the fun toys 
> away in order to keep focus on the painful parts.

"put all the fun toys away in order to keep focus on the painful parts"
--- pure poetry.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

-- 
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] commit fests

[Greg Stark]

On Sat, Jan 23, 2010 at 9:57 PM, Tom Lane  wrote:
> What I find takes up a lot of time is post-commit patch review, fixing
> reported bugs, and documentation cleanup.  Now we could doubtless find
> other people to do the purely copy-editing aspects of doc cleanup, like
> fixing less-than-stellar English, but what I'm really looking for is
> factually incorrect or obsolete statements.  It takes someone who's
> pretty much familiar top-to-bottom with the whole product to do a decent
> job of spotting things that were true awhile ago but aren't any longer.
> We just don't have many people who (a) can and (b) will do that work.

So I've never seen this mentioned before. In retrospect I remember you
popping up with such things but I don't recall discussion of what work
remained and which sections of the docs or commits you've finished
with so far, etc. That makes it hard for anyone else to help the work
go any faster.

Would it be helpful if we divided up the manual and handed out
sections to different people? Or if you could note that something
sounded wrong and then, at least for some of them just send a quick
email noting the section and anyone else could write up the changes?
Obviously in some cases the changes will be minor but in others whole
examples might need to be rewritten or new sections added.



> What I think we really need for beta, and could reasonably hope to get,
> is a larger and better-organized beta testing effort.  But we are not
> going to get that if people are thinking about new development and
> commit fests instead of testing what's already there.

Incidentally I'm not convinced that's true. The people we really want
testing stuff are the people who have real-world test cases to throw
at the new version and they're the people who will be most excited
about a new release and the least interested in a commitfest for a
version that they won't be able to run for another year. We have a
hard enough time getting people to not wait until the last commitfest
after all.

But I would be happy getting our current process working perfectly
before trying experiments like that.


-- 
greg

-- 
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] commit fests

[Bruce Momjian]

Andrew Dunstan wrote:
> The real problem is that we take a long time between the end of the 
> development phase and the release. That is often not something you can 
> just throw bodies at ("Nine women can't make a baby in a month."). 

This is the best anti-analogy I have heard in years.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

-- 
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] restructuring "alter table" privilege checks (was: remove redundant ownership checks)

[Robert Haas]

On Sat, Jan 23, 2010 at 2:17 AM, KaiGai Kohei  wrote:
> However, it is unclear for me whether the revised ATSimplePermissions()
> provide cleaner code than currently we have, because it also needs
> a big switch ... case statement within.
>
> Am I misunderstanding something?

Well, not everyone is going to agree on what "cleaner code" means in
every case, but the reason that I like my design better is because it
moves all of the decision making out of ATPrepCmd() into
ATSimplePermissions().  What you're proposing would mean that
ATPrepCmd() would basically continue to know everything about which
operations need which permissions checks, which I don't think is going
to scale very well to alternative security providers, if we eventually
decide to support such a thing.

>> It may also be worth refactoring is ATAddCheckConstraint(), which
>> currently does its own recursion only so that the constraint name at
>> the top of the inheritance hierarchy propagates all the way down
>> unchanged.  I wonder if it would be cleaner/possible to work out the
>> constraint name earlier and then just use the standard recursion
>> mechanism.
>
> Isn't it possible to check whether the given constraint is CHECK()
> or FOREIGN KEY in the ATPrepCmd() stage, and assign individual
> cmd->subtype? If CONSTR_FOREIGN, it will never recursion.
>
> In this case, we can apply checks in ATPrepCmd() stage for CONSTR_CHECK.

I don't understand what you're saying here.

> It is a good idea to consolidate permission check into tablecmd.c from
> various kind of core routines.
> And, it also makes the basis clear. The permission check should be applied
> after the code path gathered enough information to make its access control
> decision as early as possible.

And just as importantly, in a consistent place.

...Robert

-- 
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] commit fests

[Robert Haas]

On Sat, Jan 23, 2010 at 12:07 PM, Andrew Dunstan  wrote:
> Robert Haas wrote:
>>> Perhaps it isn't that five months is outrageous,
>>> but that it doesn't really benefit from an unorganized swarm of
>>> activity by all the developers, and we've not worked out a
>>> reasonable framework for who should do what during that time to best
>>> benefit the project while giving all these volunteer and sponsored
>>> developers something they are willing to put effort into.
>>
>> I think that's pretty close.
>
> I think it's pretty close to 100% BS. Who constitutes this legion of
> sponsored developers in desperate need of organization? And what are they
> sponsored for? I can't speak for others, but with one exception the only
> sponsorship I have received is for actual development work, not release
> finishing (and the exception ended up being mostly development anyway).
> Sponsors almost always want to provide money for actual features. And as for
> volunteers, they have a fantastic resistance to being organized in some
> prescriptive way. We need to achieve what we can by persuasion. It's
> sometimes a pain in the neck, but it's the reality.
>
> The real problem is that we take a long time between the end of the
> development phase and the release. That is often not something you can just
> throw bodies at ("Nine women can't make a baby in a month."). Sadly, some
> things do just take time to work out. It's frustrating, but shortening the
> time could simply result in our making less polished releases. The problem
> is likely to grow with our increasing emphasis on enterprise level features.
> But I don't think that sacrificing quality for timeliness is a good trade.
>
> That is not to say that we can't make some improvements in process, but
> expecting them magically to solve this problem is a bit cargo cultish.

I think you're kind of caricaturing what I said here, and what Kevin
said.  People really are willing to put time into helping get a
release out the door if they feel like their efforts will move the
needle.  Do they get directly paid to make the release happen faster?
No, probably not. That doesn't mean they won't put time into it.  I
don't think too many people get paid to do patch review either, but
somehow we manage to have CommitFests.  It's not magic, but it does
help.

...Robert

-- 
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] Miscellaneous changes to plperl [PATCH]

[Andrew Dunstan]

Tim Bunce wrote:

-   } keys %$imports;
+   } sort keys %$imports;



Ok, good.

  

-   my $funcsrc;
-   $funcsrc .= qq[ undef *{'$name'}; *{'$name'} = sub { $BEGIN $prolog $src } 
];
-   #warn "plperl mkfuncsrc: $funcsrc\n";
-   return $funcsrc;
+   return qq[ undef *{'$name'}; *{'$name'} = sub { $BEGIN $prolog $src } ];




Ok. (I don't think that'll clash with any later patches.)


So, what now? Should I resend the patch with the two 'ok' changes above
included, or can the committer make those very minor changes?


  


I'll pick these up, if Alex marks it ready for committer.

cheers

andrew

--
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] commit fests

[Robert Haas]

On Sat, Jan 23, 2010 at 4:57 PM, Tom Lane  wrote:
> Dimitri Fontaine  writes:
>> Goal being to continue being responsive to authors in a way that will
>> not compromise our stability, but if that means *all* qualified talents
>> of the community get assigned to release management team… I stop seeing
>> the point.
>
> There seems to be some weird notion abroad in this thread that the
> primary time sink during beta is unspecified low-skill "release
> management" tasks.  There really isn't all that much of that.

I wasn't under that impression.  I did have the impression that the
primary time sink was resolving "open items", which I think could have
been better organized last time around.

> What I find takes up a lot of time is post-commit patch review, fixing
> reported bugs, and documentation cleanup.  Now we could doubtless find
> other people to do the purely copy-editing aspects of doc cleanup, like
> fixing less-than-stellar English, but what I'm really looking for is
> factually incorrect or obsolete statements.  It takes someone who's
> pretty much familiar top-to-bottom with the whole product to do a decent
> job of spotting things that were true awhile ago but aren't any longer.
> We just don't have many people who (a) can and (b) will do that work.

Do you think I'd be qualified to help with any of this?  (Feel free to
reply off-list, if that's more appropriate... or just let 'er rip.)

> What I think we really need for beta, and could reasonably hope to get,
> is a larger and better-organized beta testing effort.  But we are not
> going to get that if people are thinking about new development and
> commit fests instead of testing what's already there.

We've had some interest in trying to organize that - from Josh Berkus,
I believe, among others.  As for beta-testing myself, AFAIR, the most
commonly advocated strategy for beta testing is "run your application
on the beta and see if it goes boom".  I don't really see how I'm
supposed to spend five months on that.  I could do it, but if I poke
at it for a couple of days and nothing blows up, it probably isn't
going to blow up.  What then?

...Robert

-- 
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] Miscellaneous changes to plperl [PATCH]

[Tim Bunce]

On Fri, Jan 22, 2010 at 08:59:10PM -0700, Alex Hunsaker wrote:
> On Thu, Jan 14, 2010 at 09:07, Tim Bunce  wrote:
> > - Allow (ineffective) use of 'require' in plperl
> >    If the required module is not already loaded then it dies.
> >    So "use strict;" now works in plperl.
> 
> [ BTW I think this is awesome! ]

Thanks!

> I'd vote for use warnings; as well.

I would to, but sadly it's not that simple. 

warnings uses Carp and Carp uses eval { ... } and, owing to a sad bug in
perl < 5.11.4, Safe can't distinguish between eval "..." and eval {...}
http://rt.perl.org/rt3/Ticket/Display.html?id=70970
So trying to load warnings fails (at least for some versions of perl).

I have a version of my final "Package namespace and Safe init cleanup
for plperl" that works around that. I opted to post a less potentially
controversial version of that patch in the end. If you think allowing
plperl code to 'use warnings;' is important (and I'd tend to agree)
then I'll update that final patch.


> > - Stored procedure subs are now given names.
> >    The names are not visible in ordinary use, but they make
> >    tools like Devel::NYTProf and Devel::Cover _much_ more useful.
> 
> This needs to quote at least '.  Any others you can think of?  Also I
> think we should sort the imports in ::mkfunsort so that they are
> stable.

Sort for stability, yes. The quoting is fine though (I see you've come
to the same conclusion via David).

> The cleanups were nice, the code worked as described.

Thanks.

> Other than the quoting issue it looks good to me.  Find below an
> incremental patch that fixes the items above.

> diff --git a/src/pl/plperl/plc_perlboot.pl b/src/pl/plperl/plc_perlboot.pl
> index daef469..fa5df0a 100644
> --- a/src/pl/plperl/plc_perlboot.pl
> +++ b/src/pl/plperl/plc_perlboot.pl
> @@ -27,16 +27,14 @@ sub ::mkfuncsrc {
> my $BEGIN = join "\n", map {
> my $names = $imports->{$_} || [];
> "$_->import(qw(@$names));"
> -   } keys %$imports;
> +   } sort keys %$imports;

Ok, good.

> $name =~ s/\\//g;
> $name =~ s/::|'/_/g; # avoid package delimiters
> +   $name =~ s/'/\'/g;

Not needed.

> -   my $funcsrc;
> -   $funcsrc .= qq[ undef *{'$name'}; *{'$name'} = sub { $BEGIN $prolog $src 
> } ];
> -   #warn "plperl mkfuncsrc: $funcsrc\n";
> -   return $funcsrc;
> +   return qq[ undef *{'$name'}; *{'$name'} = sub { $BEGIN $prolog $src } ];
>  }

Ok. (I don't think that'll clash with any later patches.)

>  # see also mksafefunc() in plc_safe_ok.pl
> diff --git a/src/pl/plperl/plc_safe_ok.pl b/src/pl/plperl/plc_safe_ok.pl
> index 8d35357..79d64ce 100644
> --- a/src/pl/plperl/plc_safe_ok.pl
> +++ b/src/pl/plperl/plc_safe_ok.pl
> @@ -25,6 +25,7 @@ $PLContainer->share(qw[&elog &return_next
>  $PLContainer->permit(qw[caller]);
>  ::safe_eval(q{
> require strict;
> +   require warnings;
> require feature if $] >= 5.01;
> 1;
>  }) or die $@;

Not viable, sadly.


> On Sat, Jan 23, 2010 at 12:42, David E. Wheeler  wrote:
> > On Jan 23, 2010, at 11:20 AM, Alex Hunsaker wrote:
> >
> >> Well no, i suppose we could fix that via:
> >> $name =~ s/[:|']/_/g;
> >>
> >> Im betting that was the intent.
> >
> > Doubtful. In Perl, the package separator is either `::` or `'` (for 
> > hysterical reasons). So the original code was replacing any package 
> > separator with a single underscore. Your regex would change This::Module to 
> > This__Module, which I'm certain was not the intent.
> 
> Haha, yep your right.  I could have sworn I tested it with a function
> name with a ' and it broke.  But your obviously right :)

I could have sworn I wrote a test file with a bunch of stressful names.
All seems well though:

template1=# create or replace function "a'b*c}d!"() returns text language 
plperl as '42'; 
CREATE FUNCTION
template1=# select "a'b*c}d!"();
 a'b*c}d! 
--
 42


So, what now? Should I resend the patch with the two 'ok' changes above
included, or can the committer make those very minor changes?

Tim.

-- 
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] commit fests

[Dimitri Fontaine]

Tom Lane  writes:
> There seems to be some weird notion abroad in this thread that the
> primary time sink during beta is unspecified low-skill "release
> management" tasks.  There really isn't all that much of that.

I'd have said high-skill, which the following paragraph I parse as
confirming it:

> What I find takes up a lot of time is post-commit patch review, fixing
> reported bugs, and documentation cleanup.  Now we could doubtless find
> other people to do the purely copy-editing aspects of doc cleanup, like
> fixing less-than-stellar English, but what I'm really looking for is
> factually incorrect or obsolete statements.  It takes someone who's
> pretty much familiar top-to-bottom with the whole product to do a decent
> job of spotting things that were true awhile ago but aren't any longer.
> We just don't have many people who (a) can and (b) will do that work.

Yeah and the ones who can, they're not all having the possibility to get
paid doing it...

> What I think we really need for beta, and could reasonably hope to get,
> is a larger and better-organized beta testing effort.  But we are not
> going to get that if people are thinking about new development and
> commit fests instead of testing what's already there.

That's where the advocacy people involvement would help I think. But for
beta testing to be effective you need all the 3 of non-trivial
application, non-trivial data set and meaningful automated test suite. I
for one don't have that handy.

So what I had in mind is that if you know you're not that helpful on the
release management issues (of which beta testing), maybe you could help
running the review fest for doing entry-level patch triage, even against
the stabilizing tree (if the only goal is timely feedback to authors).

Again I agree we miss resources more than organization, but I can't help
thinking some resources won't be able to participate in end-of-cycle and
are blocked waiting for the release lock.

Regards,
-- 
dim

-- 
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] We've broken something in error recovery

[Tom Lane]

I wrote:
> #4  0x4e85b4 in ExceptionalCondition (
> conditionName=0x1ac4ac "!(nestLevel > 0 && nestLevel <= GUCNestLevel)", 
> errorType=0x1abf44 "FailedAssertion", fileName=0x1abee4 "guc.c", 
> lineNumber=3907) at assert.c:57
> #5  0x501f48 in AtEOXact_GUC (isCommit=-86 'ª', nestLevel=84) at guc.c:3907
> #6  0x20618c in AbortTransaction () at xact.c:2194
> #7  0x20688c in AbortCurrentTransaction () at xact.c:2568
> #8  0x3b0f84 in AutoVacLauncherMain (argc=2063670312, argv=0x7b03b94c)
> at autovacuum.c:491

On investigation I think that Assert may just be overenthusiastic.
The problem is that StartTransaction is failing at
VirtualXactLockTableInsert, for lack of any shared memory to acquire
the lock with; and then we try to do AbortTransaction and GUC is
unhappy because it's not been initialized yet.  So this isn't a
new bug at all, it's been there awhile ...

regards, tom lane

-- 
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] commit fests

[Dimitri Fontaine]

Andres Freund  writes:
> I find "not talented" enough quite a bit too harsh...

Ok sorry about the term choice: RRR who like me are able to review
patches and help their authors but have yet to submit a patch and have
their code part of PostgreSQL, e.g.

I hope this is more clear stated this way.
-- 
dim

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

[HACKERS] Re: pgsql: In HS, Startup process sets SIGALRM when waiting for buffer pin.

[Simon Riggs]

On Sat, 2010-01-23 at 21:40 +, Greg Stark wrote:
> On Sat, Jan 23, 2010 at 8:28 PM, Simon Riggs  wrote:
> > What is your proposed way of handling buffer pin deadlocks? That will be
> > acceptable and working to some extent in the next week?
> >
> > Wait forever isn't always a good idea, anymore, if it ever was.
> 
> I've never said it was always a good idea. But killing correctly
> running queries isn't always a good idea either. I'm interested in
> using HS for running read-only replicas for load balancing. It would
> pretty sad if queries dispatched to a read-only replica received a
> spurious unpredictable errors for reasons the application programmer
> cannot control.

I understand your concern and seek to provide the best way forwards in
the time available. Hopefully you have a better way, but we can do
little about the time. Your input is welcome, and your code also.

> I'll look at the buffer pin deadlock problem again, but I didn't
> realize the situation was so dire. And what were the downsides of the
> "stop gap"?

Any query that attempted to wait for a lock threw an ERROR.

Since the -1 setting would never resolve a deadlock itself, if we
allowed it we would have to either use the stop gap or use a full
deadlock detector.

Given the stop gap does what -1 says it will never do, ISTM that having
-1 would be contradictory. I did not wish to remove it, but it seemed
safer to do so. Putting it back is straightforward, if it makes sense.

We would need to detect deadlock from both directions, when Startup
begins to wait when users sleep and when users begin to wait when
Startup sleeps. Full deadlock detection is to much code for too small a
problem.

-- 
 Simon Riggs   www.2ndQuadrant.com


-- 
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] 8.5 vs. 9.0, Postgres vs. PostgreSQL

[Magnus Hagander]

2010/1/23 David E. Wheeler :
> On Jan 23, 2010, at 1:22 PM, Magnus Hagander wrote:
>
>> FYI, the figures for the past month are:
>> 1.    postgresql              45,579  10.91%
>> 2.    postgres                16,225  3.88%
>> 3.    postgre                 4,901   1.17%
>> 4.    postgresql download     4,590   1.10%
>> 5.    postgresql tutorial     2,408   0.58%
>> 6.    pg_dump                 1,755   0.42%
>> 7.    psql                    1,360   0.33%
>> 8.    postgresql odbc         1,022   0.24%
>> 9.    postgre sql             964     0.23%
>> 10.   pg_restore              871     0.21%
>
> Huh. No pgsql. Interesting.

pgsql shows up in position 31 with 0.12%.

Beaten even by "copy" with 0.15%.

Wel also have
17. postgress   0.16%
30. postgressql 0.12%
40. postg   0.10%
70. postgr  0.07%


-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

-- 
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] commit fests

[Tom Lane]

Dimitri Fontaine  writes:
> Goal being to continue being responsive to authors in a way that will
> not compromise our stability, but if that means *all* qualified talents
> of the community get assigned to release management team… I stop seeing
> the point.

There seems to be some weird notion abroad in this thread that the
primary time sink during beta is unspecified low-skill "release
management" tasks.  There really isn't all that much of that.

What I find takes up a lot of time is post-commit patch review, fixing
reported bugs, and documentation cleanup.  Now we could doubtless find
other people to do the purely copy-editing aspects of doc cleanup, like
fixing less-than-stellar English, but what I'm really looking for is
factually incorrect or obsolete statements.  It takes someone who's
pretty much familiar top-to-bottom with the whole product to do a decent
job of spotting things that were true awhile ago but aren't any longer.
We just don't have many people who (a) can and (b) will do that work.

What I think we really need for beta, and could reasonably hope to get,
is a larger and better-organized beta testing effort.  But we are not
going to get that if people are thinking about new development and
commit fests instead of testing what's already there.

regards, tom lane

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

[HACKERS] Re: pgsql: In HS, Startup process sets SIGALRM when waiting for buffer pin.

[Greg Stark]

On Sat, Jan 23, 2010 at 8:28 PM, Simon Riggs  wrote:
> What is your proposed way of handling buffer pin deadlocks? That will be
> acceptable and working to some extent in the next week?
>
> Wait forever isn't always a good idea, anymore, if it ever was.

I've never said it was always a good idea. But killing correctly
running queries isn't always a good idea either. I'm interested in
using HS for running read-only replicas for load balancing. It would
pretty sad if queries dispatched to a read-only replica received a
spurious unpredictable errors for reasons the application programmer
cannot control.

I'll look at the buffer pin deadlock problem again, but I didn't
realize the situation was so dire. And what were the downsides of the
"stop gap"?


-- 
greg

-- 
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] We've broken something in error recovery

[Tom Lane]

Andrew Dunstan  writes:
> Tom Lane wrote:
>> #5  0x501f48 in AtEOXact_GUC (isCommit=-86 'ª', nestLevel=84) at guc.c:3907

> This looks like maybe a corrupted stack - the args to AtEOXact_GUC at 
> that location in xact.c are hardwired.

No, that's just a fairly typical behavior of debugging with -O greater
than zero --- the registers holding those parameter values got recycled
for something else.  This is a rather old version of gdb and it doesn't
always print <> when it should.

regards, tom lane

-- 
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] commit fests

[Andres Freund]

On Saturday 23 January 2010 22:24:41 Dimitri Fontaine wrote:
> I was under the illusion than we had some RRR people not talented enough
> to be full-speed contributors to release management that we could have
> this team run one or two ReviewFest while the "serious" guys were
> working.
I find "not talented" enough quite a bit too harsh...

Andres

-- 
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] 8.5 vs. 9.0, Postgres vs. PostgreSQL

[David E. Wheeler]

On Jan 23, 2010, at 1:22 PM, Magnus Hagander wrote:

> FYI, the figures for the past month are:
> 1.postgresql  45,579  10.91%  
> 2.postgres16,225  3.88%   
> 3.postgre 4,901   1.17%   
> 4.postgresql download 4,590   1.10%   
> 5.postgresql tutorial 2,408   0.58%   
> 6.pg_dump 1,755   0.42%   
> 7.psql1,360   0.33%   
> 8.postgresql odbc 1,022   0.24%   
> 9.postgre sql 964 0.23%   
> 10.   pg_restore  871 0.21%   

Huh. No pgsql. Interesting.

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] commit fests

[Dimitri Fontaine]

Tom Lane  writes:
>  There simply isn't a pool of (qualified) talent that can go off and
> do beta testing and stabilization in parallel with new development.
> It's pretty much the same people who do both tasks; so if we try to do
> that, one of two things is going to happen: beta takes even longer, or
> release quality goes down.

I was under the illusion than we had some RRR people not talented enough
to be full-speed contributors to release management that we could have
this team run one or two ReviewFest while the "serious" guys were
working.

Goal being to continue being responsive to authors in a way that will
not compromise our stability, but if that means *all* qualified talents
of the community get assigned to release management team… I stop seeing
the point.

Regards,
-- 
dim

-- 
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] 8.5 vs. 9.0, Postgres vs. PostgreSQL

[Magnus Hagander]

2010/1/23 Robert Treat :
>  A yes, and here are those statistics I posted a couple of
> years ago, showing site traffic into our website.
> http://archives.postgresql.org/pgsql-advocacy/2007-09/msg00108.php
> These are for the people who figure it out, I wonder how many people we miss
> out on because they get sidetracked trying to find out more about postgre?

FYI, the figures for the past month are:
1.  postgresql  45,579  10.91%  
2.  postgres16,225  3.88%   
3.  postgre 4,901   1.17%   
4.  postgresql download 4,590   1.10%   
5.  postgresql tutorial 2,408   0.58%   
6.  pg_dump 1,755   0.42%   
7.  psql1,360   0.33%   
8.  postgresql odbc 1,022   0.24%   
9.  postgre sql 964 0.23%   
10. pg_restore  871 0.21%   

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

-- 
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] 8.5 vs. 9.0, Postgres vs. PostgreSQL

[Andrew Dunstan]

Robert Treat wrote:
I'm not saying there aren't 
downsides, but having a name the community can unify on is a definite plus, and 
imho that name has to be Postgres.  
  


Translation: "we'll only be unified if everyone agrees with me."

Sorry, that is quite clearly not going to happen.

Can we please get on with actually making a better product? Raising this 
issue again is simply an unnecessary distraction.


cheers

andrew

--
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] 8.5 vs. 9.0, Postgres vs. PostgreSQL

[Robert Treat]

On Friday 22 January 2010 23:44:11 Tom Lane wrote:
> "David E. Wheeler"  writes:
> > On Jan 22, 2010, at 4:54 PM, Mark Mielke wrote:
> >> MS SQL, MySQL, SQLite - do they have advocacy problems due to the SQL in
> >> their name? I think it is the opposite. SQL in the name almost grants
> >> legitimacy to them as products. Dropping the SQL has the potential to
> >> increase confusion. What is a Postgres? :-)
> >
> > Something that comes after black, but before white.
>
> Yeah.  As best I can tell, most newbies think that PostgreSQL means
> Postgre-SQL --- they're not too sure what "Postgre" is, but they guess
> it must be the specific name of the product.  And that annoys those of
> us who would rather they pronounced it "Postgres".  But in terms of
> recognizability of the product it's not a liability.  

Well, it clearly is a liability to have your product name be confused in 3 or 
4 different ways. I don't think it's impossible for people to not connect the 
dots that someone talking about "postgrey" is talking about the same thing as 
someone talking about "postgres-sequel". 

> The business about
> pronunciation is a red herring.  It's just as unclear whether MySQL is
> to be pronounced my-se-quel or my-ess-cue-ell, but how many people have
> you heard claiming that's a lousy name?
>

The difference is that that product name is still easily searchable. Looking 
for a job? type in mysql. trying to find talent? mysql. looking for product 
support? mysql. need training? mysql.  Every one of these things (and many 
more) is made harder by the constant confusion of our product name.  

We're currently looking to hire new dba's, and we have to adjust search 
information to account for the potential use of postgres or postgresql as a 
skill (we're currently on the fence philosophically about hiring someone who 
calls it postgre). But we're lucky, because we know enough to try to account 
for these things. Consider someone new to Postgres looking for a job. Go to 
monster.com and search on postgre, postgres, or postgresql and you will get a 
different list of jobs for each keyword. 

 A yes, and here are those statistics I posted a couple of 
years ago, showing site traffic into our website. 
http://archives.postgresql.org/pgsql-advocacy/2007-09/msg00108.php
These are for the people who figure it out, I wonder how many people we miss 
out on because they get sidetracked trying to find out more about postgre?

You once said "Arguably, the 1996 decision to call it PostgreSQL instead of 
reverting to plain Postgres was the single worst mistake this project ever 
made."  I think I would have to agree, and I can't see this issue ever going 
away as long as we stick with PostgreSQL. I'm not saying there aren't 
downsides, but having a name the community can unify on is a definite plus, and 
imho that name has to be Postgres.  

-- 
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com

-- 
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] We've broken something in error recovery

[Andrew Dunstan]

Tom Lane wrote:

#4  0x4e85b4 in ExceptionalCondition (
conditionName=0x1ac4ac "!(nestLevel > 0 && nestLevel <= GUCNestLevel)", 
errorType=0x1abf44 "FailedAssertion", fileName=0x1abee4 "guc.c", 
lineNumber=3907) at assert.c:57

#5  0x501f48 in AtEOXact_GUC (isCommit=-86 'ª', nestLevel=84) at guc.c:3907
#6  0x20618c in AbortTransaction () at xact.c:2194

  


This looks like maybe a corrupted stack - the args to AtEOXact_GUC at 
that location in xact.c are hardwired.


cheers

andrew

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

[HACKERS] We've broken something in error recovery

[Tom Lane]

In a somewhat misguided attempt to test something else, I did this in
CVS HEAD:

do $$begin
for i in 1 .. 1 loop
  execute 'create table t' || i::text || ' (f1 int primary key)';
end loop;
end$$;

This ran for awhile and then ran out of lock table space, which was
not surprising in hindsight:

ERROR:  out of shared memory
HINT:  You might need to increase max_locks_per_transaction.

But what was surprising was what happened next: the autovac launcher
immediately crashed.

TRAP: FailedAssertion("!(nestLevel > 0 && nestLevel <= GUCNestLevel)", File: 
"guc.c", Line: 3907)
LOG:  autovacuum launcher process (PID 25220) was terminated by signal 6

Stack trace looks like

#4  0x4e85b4 in ExceptionalCondition (
conditionName=0x1ac4ac "!(nestLevel > 0 && nestLevel <= GUCNestLevel)", 
errorType=0x1abf44 "FailedAssertion", fileName=0x1abee4 "guc.c", 
lineNumber=3907) at assert.c:57
#5  0x501f48 in AtEOXact_GUC (isCommit=-86 'ª', nestLevel=84) at guc.c:3907
#6  0x20618c in AbortTransaction () at xact.c:2194
#7  0x20688c in AbortCurrentTransaction () at xact.c:2568
#8  0x3b0f84 in AutoVacLauncherMain (argc=2063670312, argv=0x7b03b94c)
at autovacuum.c:491
#9  0x3b0bd8 in StartAutoVacLauncher () at autovacuum.c:371

Haven't dug any deeper yet --- who's touched this code lately?

regards, tom lane

-- 
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] plpython3

[James William Pye]

On Jan 14, 2010, at 7:08 PM, Greg Smith wrote:
> So more targeted examples like you're considering now would help.

Here's the trigger example which should help reveal some of the advantages of 
"native typing". This is a generic trigger that constructs and logs 
manipulation statements for simple replication purposes.

The original plpython version is located here:

 http://ar.pycon.org/common/2009/talkdata/PyCon2009/020/plpython.txt
 [You'll need to scroll down to the very bottom of that page.]


There are three points in this example that need to be highlighted:

 1. There is no need for a "mogrify" function (see original in the above link).
 2. Attributes/columns of the records (new/old) are extracted when referenced.
 3. The comparisons in after_update uses the data type's actual inequality 
operator.

The first point is true because "native typing" gives the user direct access to 
a given type's typoutput via ``str(ob)``. This makes constructing the PG string 
representation of a given object *much* easier--quote_nullable, and done. The 
original plpython example will need to be updated to compensate for any changes 
in conversion: arrays will now need special handling and MD arrays will not 
work at all. It also relies heavily on the Python object representation 
matching PG's; where that fails, special cases need to be 
implemented(composites, notably). All of that compensation performed in the 
original version is unnecessary in the plpython3 version.

The second point touches on the "efficiency" that was referenced in an earlier 
message. No cycles are spent converting the contents of a container object 
unless the user chooses to. Naturally, there is no advantage performance-wise 
if you are always converting everything.
I'd wager that with triggers, it's rare that everything needs to be converted.

The third point reveals that Postgres.Object instances--a component of native 
typing--use the data type's operator for inequality. It's not limited to 
comparisons as all available Python operators are mapped to corresponding 
operators in PG. For many or all primitives, there is no added value over 
conversion. However, this provides a lot of convenience when working with UDTs, 
datetime types, and geometric types.

...ISTM that the primary advantage of "native typing" is that we get to define 
the Python interface to a given Postgres data type.


Three files are attached:

 afterlog.py - the trigger returning function
 afterlog.sql - the sql exercising the TRF (creates the replica_log table as 
well)
 afterlog.out - the contents of the replica_log table after executing 
afterlog.sql

To replay:

\i afterlog.py
\i afterlog.sql
SELECT * FROM replica_log;


CREATE OR REPLACE FUNCTION log_manipulation()
RETURNS TRIGGER LANGUAGE plpython3u AS
$python$
from Postgres import quote_nullable, quote_ident, notify

# parameter type extracted from the statement
record_manipulation = prepare("INSERT INTO replica_log (sql) VALUES ($1)")

def log(sql):
	record_manipulation(sql)
	# notify listeners that new data is available
	notify('replicas')

fmt_insert = "INSERT INTO {relname} ({columns}) VALUES ({values});".format
fmt_update = "UPDATE {relname} SET {changes} WHERE {keys};".format
fmt_delete = "DELETE FROM {relname} WHERE {keys};".format

def fmt_eqs(joinwith, keys, record, fmt = "{0} = {1}".format):
	pairs = [fmt(quote_ident(k), quote_nullable(record[k])) for k in keys]
	return joinwith.join(pairs)

##
# entry points

def after_insert(td, new):
	relname = td.args[0]
	sql = fmt_insert(
		relname = relname,
		columns = ', '.join(map(quote_ident, new.keys())),
		values = ', '.join(map(quote_nullable, new.values())),
	)
	log(sql)

def after_update(td, old, new):
	relname, *pkeys = td.args
	modified_columns = {k : v for k,v in new.items() if old[k] != v}

	# only log if there were modified columns
	if modified_columns:
		sql = fmt_update(
			relname = relname,
			changes = fmt_eqs(', ', modified_columns.keys(), modified_columns),
			keys = fmt_eqs(' AND ', pkeys, old)
		)
		log(sql)

def after_delete(td, old):
	relname, *pkeys = td.args
	sql = fmt_delete(
		relname = relname, 
		keys = fmt_eqs(' AND ', pkeys, old)
	)
	log(sql)
$python$;


afterlog.sql
Description: Binary data


afterlog.out
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] Re: pgsql: In HS, Startup process sets SIGALRM when waiting for buffer pin.

[Simon Riggs]

On Sat, 2010-01-23 at 17:35 +, Greg Stark wrote:
> On Sat, Jan 23, 2010 at 4:37 PM, Simon Riggs  wrote:
> > max_standby_delay = -1 option removed to prevent deadlock.
> 
> This seems unacceptable to me. It means it's impossible to configure a
> reporting slave so it doesn't spuriously signal errors if your reports
> run too long.
> 
> Recall that I am still of the opinion that the only reasonable default
> value for this parameter is actually -1. I don't think we should
> signal errors for correctly working systems unless the user requests
> them in some way.

What is your proposed way of handling buffer pin deadlocks? That will be
acceptable and working to some extent in the next week?

Wait forever isn't always a good idea, anymore, if it ever was.

Lots of things still on the TODO, if you are looking for a project.
http://wiki.postgresql.org/wiki/Hot_Standby_TODO

-- 
 Simon Riggs   www.2ndQuadrant.com


-- 
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] commit fests

[Andrew Dunstan]

Tom Lane wrote:

We already heard a lot of complaints that 8.4 should have gotten more
testing than it did.  Proposing to continue development in parallel
with beta is a good way to ensure that that will get worse not better.


  


Right. If we really want to improve matters we'll spend our efforts on 
finding more resources, not diverting those we have or making new rules.


cheers

andrew

--
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] commit fests

[Tom Lane]

Greg Smith  writes:
> ... if you let 
> both things go on at once, I guarantee you almost all of the community 
> attention will be diverted toward new development during any period 
> where both are happening at the same time.

Yes.  This is the big problem that would have to be solved before we
could have commitfests occurring in parallel with beta.  There simply
isn't a pool of (qualified) talent that can go off and do beta testing
and stabilization in parallel with new development.  It's pretty much
the same people who do both tasks; so if we try to do that, one of two
things is going to happen: beta takes even longer, or release quality
goes down.

We already heard a lot of complaints that 8.4 should have gotten more
testing than it did.  Proposing to continue development in parallel
with beta is a good way to ensure that that will get worse not better.

regards, tom lane

-- 
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] Miscellaneous changes to plperl [PATCH]

[Alex Hunsaker]

On Sat, Jan 23, 2010 at 12:42, David E. Wheeler  wrote:
> On Jan 23, 2010, at 11:20 AM, Alex Hunsaker wrote:
>
>> Well no, i suppose we could fix that via:
>> $name =~ s/[:|']/_/g;
>>
>> Im betting that was the intent.
>
> Doubtful. In Perl, the package separator is either `::` or `'` (for 
> hysterical reasons). So the original code was replacing any package separator 
> with a single underscore. Your regex would change This::Module to 
> This__Module, which I'm certain was not the intent.

Haha, yep your right.  I could have sworn I tested it with a function
name with a ' and it broke.  But your obviously right :)

-- 
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] 8.5 vs. 9.0, Postgres vs. PostgreSQL

[Andrew Dunstan]

Boszormenyi Zoltan wrote:

How about "PugSQL"? It's kind of butch, keeps the "pg" part, and we could have 
a dog logo.
  



IIRC, Pug is a little leprechaun in Shakespeare's Midsummer night's dream.
Another logo change opportunity. :-)

  



I think you've confused "Puck" and "Snug". See 



cheers

andrew

--
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] Miscellaneous changes to plperl [PATCH]

[David E. Wheeler]

On Jan 23, 2010, at 11:20 AM, Alex Hunsaker wrote:

> Well no, i suppose we could fix that via:
> $name =~ s/[:|']/_/g;
> 
> Im betting that was the intent.

Doubtful. In Perl, the package separator is either `::` or `'` (for hysterical 
reasons). So the original code was replacing any package separator with a 
single underscore. Your regex would change This::Module to This__Module, which 
I'm certain was not the intent.

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] commit fests

[Greg Smith]

Kevin Grittner wrote:

Does it really take the concerted efforts of the whole community five months to 
take things from the
deadline for patch commits (end of last CF) to release?


The idea is that it takes five months of complete lockdown to give the 
code enough testing time to hopefully reach stability.  I don't think 
that part is particularly controversial--reduce it, and quality drops, 
period.  And as pointed out by a couple of people, even one release per 
year of a database is more than many users really want to consume, as 
evidenced by the number of 7.X installs still going because "we don't 
want to touch the working app" we still hear about.


The question then is what else you could be doing during that period.  
Let's say that the day 9.0 beta 1 came out, a new 9.1 branch was created 
and CommitFests against it started, during what right now would be time 
exclusively devoted to beta testing.  Completely feasible idea.  There 
would be some forward/backporting duplication of work while those were 
running in parallel, and that would be harder than it needs to be until 
something like a git transition happens.  But you certainly could do it.


So why not do that?  Developing new features is fun and tends to attract 
sponsorship dollars.  Testing a frozen release, finding bugs, and 
resolving them is boring, and no one sponsors it.  Therefore, if you let 
both things go on at once, I guarantee you almost all of the community 
attention will be diverted toward new development during any period 
where both are happening at the same time.  Give developers a choice 
between shiny and profitable vs. dull and unpaid, and they'll focus on 
the former every time.  That means that there's no possible way you can 
keep new development open without hurting the dreary work around 
stabilizing the beta in the process.  You have to put all the fun toys 
away in order to keep focus on the painful parts.


Plenty of other projects don't work this way, with a beta drop being a 
kick off to resume full-on development.  There's a reason why PostgreSQL 
has a better reputation for quality releases than they do.  It's an 
enterprise-class database; you don't just throw code in there, release 
the result every quarter, and expect the result to be stable.  If 
developers are turned away because they want more instant gratification 
for their development efforts, they're working on the wrong type of 
project for them.


--
Greg Smith2ndQuadrant   Baltimore, MD
PostgreSQL Training, Services and Support
g...@2ndquadrant.com  www.2ndQuadrant.com


--
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] Miscellaneous changes to plperl [PATCH]

[Alex Hunsaker]

On Sat, Jan 23, 2010 at 11:30, David E. Wheeler  wrote:
> On Jan 22, 2010, at 7:59 PM, Alex Hunsaker wrote:
>
>>    $name =~ s/::|'/_/g; # avoid package delimiters
>> +   $name =~ s/'/\'/g;
>
> Looks to me like ' is already handled in the line above the one you added, no?

Well no, i suppose we could fix that via:
$name =~ s/[:|']/_/g;

Im betting that was the intent.

-- 
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] 8.5 vs. 9.0, Postgres vs. PostgreSQL

[Boszormenyi Zoltan]

David E. Wheeler írta:
> On Jan 23, 2010, at 3:25 AM, Greg Stark wrote:
>
>   
>> Actually the original promounciation was mee-ess-cue-ell, "My" is
>> monty's daughter's name and is pronounced like that. People generally
>> pronounced it "my" though so they just made that the official
>> pronounciation -- but they still don't approve of "my-sequel".
>> 
>
> We could go with "PrySQL," as in you can pry it from my cold dead fingers. Or 
> if you're Finnish, you can think of it as coming before SQL.
>
> Or maybe "TrySQL", to encourage you to try it and because you can make tress 
> out of it. It's greener, too.
>
> Or perhaps OMGWTFSQL. No, wait, sorry, that's what I say when I'm working 
> with MySQL.
>
> How about "PugSQL"? It's kind of butch, keeps the "pg" part, and we could 
> have a dog logo.
>   

IIRC, Pug is a little leprechaun in Shakespeare's Midsummer night's dream.
Another logo change opportunity. :-)

> Or maybe we can determine that geeks are completely useless at branding and 
> not touch this issue with a 10m pole.
>
> So, 10mPoleSQL it is. Or maybe KillThisFuckingThreadSQL. Rather suggestive, 
> don't you think?
>
> Best,
>
> David
>   


-- 
Bible has answers for everything. Proof:
"But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil." (Matthew 5:37) - basics of digital technology.
"May your kingdom come" - superficial description of plate tectonics

--
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
http://www.postgresql.at/


-- 
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] [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

[Bernd Helmle]

--On 14. Januar 2010 16:04:17 +0900 KaiGai Kohei  
wrote:



This patch adds:

  List *find_column_origin(Oid relOid, const char *colName)

It returns the list of relation OIDs which originally defines the given
column. In most cases, it returns a list with an element. But, if the
column is inherited from multiple parent relations and merged during the
inheritance tree, the returned list contains multiple OIDs.
In this case, we have to forbid changing type and renaming to keep
correctness of the table definition.


Here's a slightly edited version of this patch from reviewing, fixing the 
following:


* Fix a compiler warning by passing a pointer to skey to 
systable_beginscan() (it's an array already)


* Edit some comments

The patch works as expected (at least, i don't see any remaining issues). 
I'm going to mark this ready for committer.


--
Thanks

Bernd

pg-fix-inherit-rename-type-review.patch
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

Re: [HACKERS] 8.5 vs. 9.0, Postgres vs. PostgreSQL

[David E. Wheeler]

On Jan 23, 2010, at 3:25 AM, Greg Stark wrote:

> Actually the original promounciation was mee-ess-cue-ell, "My" is
> monty's daughter's name and is pronounced like that. People generally
> pronounced it "my" though so they just made that the official
> pronounciation -- but they still don't approve of "my-sequel".

We could go with "PrySQL," as in you can pry it from my cold dead fingers. Or 
if you're Finnish, you can think of it as coming before SQL.

Or maybe "TrySQL", to encourage you to try it and because you can make tress 
out of it. It's greener, too.

Or perhaps OMGWTFSQL. No, wait, sorry, that's what I say when I'm working with 
MySQL.

How about "PugSQL"? It's kind of butch, keeps the "pg" part, and we could have 
a dog logo.

Or maybe we can determine that geeks are completely useless at branding and not 
touch this issue with a 10m pole.

So, 10mPoleSQL it is. Or maybe KillThisFuckingThreadSQL. Rather suggestive, 
don't you think?

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] Miscellaneous changes to plperl [PATCH]

[David E. Wheeler]

On Jan 22, 2010, at 7:59 PM, Alex Hunsaker wrote:

>$name =~ s/::|'/_/g; # avoid package delimiters
> +   $name =~ s/'/\'/g;

Looks to me like ' is already handled in the line above the one you added, no?

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] tab completion for prepared transactions?

[Peter Eisentraut]

On lör, 2010-01-23 at 12:42 -0500, Tom Lane wrote:
> Peter Eisentraut  writes:
> > Was there a designed-in reason not to have psql tab completion for
> > COMMIT/ROLLBACK PREPARED ...?  It does complete the "PREPARED" but not
> > the transaction identifiers.  Maybe it's not a common use case, but
> > these transaction identifiers sure can be nontrivial to type.
> 
> Hmm, what's the use scenario?  I would think that painfully long
> gxids would come from some XA manager software, which would be
> responsible for committing or canceling them.  Manual override
> of that would usually be a bad idea.

The scenario that I encountered is that you go around manually cleaning
them up when the XA software fails for some reason.


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

[HACKERS] Re: Cstring vs. Datum values ( BuildTupleFromCStrings vs. BlessTupleDesc)

[Greg Stark]

On Sat, Jan 23, 2010 at 5:53 PM, Ivan Sergio Borgonovo
 wrote:
> That confused me further since it seems a 3rd technique to return
> set of records.
>

The heapfuncs.c example uses get_call_result_type() to get the
tupledesc and calls heap_form_tuple() to construct the return value,
just like the docs describe. The extra code is because it's a
set-returning-function which has its own set of tricky things to do.


-- 
greg

-- 
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] Re: Cstring vs. Datum values ( BuildTupleFromCStrings vs. BlessTupleDesc)

[Ivan Sergio Borgonovo]

On Sat, 23 Jan 2010 15:54:04 +
Greg Stark  wrote:

> On Sat, Jan 23, 2010 at 12:56 PM, Ivan Sergio Borgonovo
>  wrote:
> > And if I can... how, why and when... because I didn't find any
> > clear example in the source tree that gives me a clue about when
> > I'd use one form or the other.
> >
> 
> There are a few contrib modules which make good examples, you could
> look at  contrib/pageinspect/heapfuncs.c:heap_page_items() for
> example.

That confused me further since it seems a 3rd technique to return
set of records.

One way is given for example in:
./src/backend/utils/adt/tsvector_op.c
that uses BlessTupleDesc
another that seems to be more frequent is given in the docs:
http://www.postgresql.org/docs/8.4/static/xfunc-c.html#AEN44970
and finally the one you gave as an example

I can't understand when each one should be used and I can't
understand why so many ways to return a tuple... not to mention I've
to "reverse engineer" many of the parameters of the function
involved.

Could someone give me a clue about when it is more suitable to use
all the above techniques?

thanks

-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it


-- 
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] tab completion for prepared transactions?

[Tom Lane]

Peter Eisentraut  writes:
> Was there a designed-in reason not to have psql tab completion for
> COMMIT/ROLLBACK PREPARED ...?  It does complete the "PREPARED" but not
> the transaction identifiers.  Maybe it's not a common use case, but
> these transaction identifiers sure can be nontrivial to type.

Hmm, what's the use scenario?  I would think that painfully long
gxids would come from some XA manager software, which would be
responsible for committing or canceling them.  Manual override
of that would usually be a bad idea.

In short, there's probably no "designed-in reason", but it's not
clear to me that it's worth the code & maintenance effort to have
tab completion for that.

regards, tom lane

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

[HACKERS] Re: pgsql: In HS, Startup process sets SIGALRM when waiting for buffer pin.

[Greg Stark]

On Sat, Jan 23, 2010 at 4:37 PM, Simon Riggs  wrote:
> max_standby_delay = -1 option removed to prevent deadlock.

This seems unacceptable to me. It means it's impossible to configure a
reporting slave so it doesn't spuriously signal errors if your reports
run too long.

Recall that I am still of the opinion that the only reasonable default
value for this parameter is actually -1. I don't think we should
signal errors for correctly working systems unless the user requests
them in some way.

Was there any discussion about this change? I don't recall seeing it
proposed on hackers.

--
greg

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

[HACKERS] tab completion for prepared transactions?

[Peter Eisentraut]

Was there a designed-in reason not to have psql tab completion for
COMMIT/ROLLBACK PREPARED ...?  It does complete the "PREPARED" but not
the transaction identifiers.  Maybe it's not a common use case, but
these transaction identifiers sure can be nontrivial to type.


-- 
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] commit fests

[Andrew Dunstan]

Robert Haas wrote:

Perhaps it isn't that five months is outrageous,
but that it doesn't really benefit from an unorganized swarm of
activity by all the developers, and we've not worked out a
reasonable framework for who should do what during that time to best
benefit the project while giving all these volunteer and sponsored
developers something they are willing to put effort into.



I think that's pretty close.


  


I think it's pretty close to 100% BS. Who constitutes this legion of 
sponsored developers in desperate need of organization? And what are 
they sponsored for? I can't speak for others, but with one exception the 
only sponsorship I have received is for actual development work, not 
release finishing (and the exception ended up being mostly development 
anyway). Sponsors almost always want to provide money for actual 
features. And as for volunteers, they have a fantastic resistance to 
being organized in some prescriptive way. We need to achieve what we can 
by persuasion. It's sometimes a pain in the neck, but it's the reality.


The real problem is that we take a long time between the end of the 
development phase and the release. That is often not something you can 
just throw bodies at ("Nine women can't make a baby in a month."). 
Sadly, some things do just take time to work out. It's frustrating, but 
shortening the time could simply result in our making less polished 
releases. The problem is likely to grow with our increasing emphasis on 
enterprise level features. But I don't think that sacrificing quality 
for timeliness is a good trade.


That is not to say that we can't make some improvements in process, but 
expecting them magically to solve this problem is a bit cargo cultish.


cheers

andrew



--
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] Largeobject Access Controls (r2460)

[Tom Lane]

KaiGai Kohei  writes:
> (2010/01/23 5:12), Tom Lane wrote:
>> Now the argument against that is that it won't scale terribly well
>> to situations with very large numbers of blobs.

> Even if the database contains massive number of large objects, all the
> pg_dump has to manege on RAM is its metadata, not data contents.

I'm not so worried about the amount of RAM needed as whether pg_dump's
internal algorithms will scale to large numbers of TOC entries.  Any
O(N^2) behavior would be pretty painful, for example.  No doubt we could
fix any such problems, but it might take more work than we want to do
right now.

regards, tom lane

-- 
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] Largeobject Access Controls (r2460)

[Tom Lane]

"Kevin Grittner"  writes:
> ...  After a few minutes that left me curious just how big
> the database was, so I tried:
 
> select pg_size_pretty(pg_database_size('test'));
 
> I did a Ctrl+C after about five minutes and got:
 
> Cancel request sent
 
> but it didn't return for 15 or 20 minutes.

Hm, we probably are lacking CHECK_FOR_INTERRUPTS in the inner loops in
dbsize.c ...

regards, tom lane

-- 
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] commit fests

[Robert Haas]

On Sat, Jan 23, 2010 at 10:47 AM, Kevin Grittner
 wrote:
>> What I'd really like is to stop arguing about the number of
>> CommitFests per cycle and the exact charter of each CommitFest and
>> start talking about how we can create an environment where patch
>> authors can get their work committed reasonably quickly (assuming
>> it's good, of course) and released within some reasonable time
>> frame after that
>
> Dimitri's reply with the "Too bad we can't have" portion makes me
> wonder whether we really can't.  Does it really take the concerted
> efforts of the whole community five months to take things from the
> deadline for patch commits (end of last CF) to release?

No.

> Is it that
> nobody would volunteer to take the burden of that effort so that
> others could code?

No.

> Perhaps it isn't that five months is outrageous,
> but that it doesn't really benefit from an unorganized swarm of
> activity by all the developers, and we've not worked out a
> reasonable framework for who should do what during that time to best
> benefit the project while giving all these volunteer and sponsored
> developers something they are willing to put effort into.

I think that's pretty close.

...Robert

-- 
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] Largeobject Access Controls (r2460)

[Kevin Grittner]

"Kevin Grittner"  wrote:
 
> So I'm not sure whether I can get to a state suitable for starting
> the desired test, but I'll stay with a for a while.
 
I have other commitments today, so I'm going to leave the VACUUM
ANALYZE running and come back tomorrow morning to try the pg_dump.
 
-Kevin

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

[HACKERS] Re: Cstring vs. Datum values ( BuildTupleFromCStrings vs. BlessTupleDesc)

[Greg Stark]

On Sat, Jan 23, 2010 at 12:56 PM, Ivan Sergio Borgonovo
 wrote:
> And if I can... how, why and when... because I didn't find any clear
> example in the source tree that gives me a clue about when I'd use
> one form or the other.
>

There are a few contrib modules which make good examples, you could
look at  contrib/pageinspect/heapfuncs.c:heap_page_items() for
example.



-- 
greg

-- 
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] commit fests

[Kevin Grittner]

Robert Haas  wrote:
 
> That means I'd like releases to be reasonably frequent - like
> annually - and I'd like the time for which nobody can get anything
> committed to be relatively short.
 
Yeah, the current approach seems to be to develop a schedule around
a one-year cycle, with an implicit assumption that the date will
never actually be hit, so the release cycle will really be 15 months
or more.  Just don't say it out loud [oops].  Close to half of that
is effectively closed to submissions from non-committers.
 
> if we're able to put out a release in early July as we did for
> 8.4, I'll be quite happy.
 
Well, six months from the start of the last CF to release seems like
it would leave a lot of room for improvement in project management
techniques, but at this point July would be a happy thing just
because I currently get the sense that we're actually on track for a
release well past that.
 
> What I'd really like is to stop arguing about the number of
> CommitFests per cycle and the exact charter of each CommitFest and
> start talking about how we can create an environment where patch
> authors can get their work committed reasonably quickly (assuming
> it's good, of course) and released within some reasonable time
> frame after that
 
Dimitri's reply with the "Too bad we can't have" portion makes me
wonder whether we really can't.  Does it really take the concerted
efforts of the whole community five months to take things from the
deadline for patch commits (end of last CF) to release?  Is it that
nobody would volunteer to take the burden of that effort so that
others could code?  Perhaps it isn't that five months is outrageous,
but that it doesn't really benefit from an unorganized swarm of
activity by all the developers, and we've not worked out a
reasonable framework for who should do what during that time to best
benefit the project while giving all these volunteer and sponsored
developers something they are willing to put effort into.
 
At the risk of hanging a big "slacker" bulls-eye on my chest, I will
say that while I've managed to get approval from management here to
test prior releases during their beta periods "on the clock", with
the justification that it would catch bugs which affect our "unique"
environment before have to try to bring it in for production use,
that is simply not an option this time.  Any such contribution would
have to be off-hours (like today), because they have become
convinced of the need for a particular PostgreSQL feature that
nobody else is addressing and authorized time for that; and there's
no way they're going to pay for both this year.  I don't know how
many other find themselves in such binds, but I'm sure it happens.
 
-Kevin

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

Re: commit fests (was Re: [HACKERS] primary key error message)

[Andrew Dunstan]

Bernd Helmle wrote:



--On 22. Januar 2010 15:40:58 +0200 Peter Eisentraut  
wrote:



Beta is still the definite cutoff; and the closer we get to
beta, the smaller the acceptable changes become.  I think that formula
basically applies throughout the entire cycle.


For someone like me it's hard to guess, what "small" means in that 
context. For example, i delayed my work on improving the 
representation of NOT NULL constraints in favor of the pg_table_size() 
patch (my time was too limited to work on both), since i always 
thought submitting beyond CF start would be a non-starter for such a 
thing.


It's a judgement call. I know that bothers the heck out of some people, 
but hard and fast rules bug the heck out of others, so someone is going 
to get bugged either way. As Ricky Nelson sang, "You can't please everyone."


cheers

andrew

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

Re: commit fests (was Re: [HACKERS] primary key error message)

[Bernd Helmle]

--On 22. Januar 2010 15:40:58 +0200 Peter Eisentraut  
wrote:



Beta is still the definite cutoff; and the closer we get to
beta, the smaller the acceptable changes become.  I think that formula
basically applies throughout the entire cycle.


For someone like me it's hard to guess, what "small" means in that context. 
For example, i delayed my work on improving the representation of NOT NULL 
constraints in favor of the pg_table_size() patch (my time was too limited 
to work on both), since i always thought submitting beyond CF start would 
be a non-starter for such a thing.


--
Thanks

Bernd

--
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] Largeobject Access Controls (r2460)

[Kevin Grittner]

Tom Lane  wrote: 
> "Kevin Grittner"  writes:
>> Tom Lane  wrote:
>>> Do you have the opportunity to try an experiment on hardware
>>> similar to what you're running that on?  Create a database with
>>> 7 million tables and see what the dump/restore times are like,
>>> and whether pg_dump/pg_restore appear to be CPU-bound or
>>> memory-limited when doing it.
>  
>> If these can be empty (or nearly empty) tables, I can probably
>> swing it as a background task.  You didn't need to match the
>> current 1.3 TB database size I assume?
> 
> Empty is fine.
 
After about 15 hours of run time it was around 5.5 million tables;
the rate of creation had slowed rather dramatically.  I did create
them with primary keys (out of habit) which was probably the wrong
thing.  I canceled the table creation process and started a VACUUM
ANALYZE, figuring that we didn't want any hint-bit writing or bad
statistics confusing the results.  That has been running for 30
minutes with 65 MB to 140 MB per second disk activity, mixed read
and write.  After a few minutes that left me curious just how big
the database was, so I tried:
 
select pg_size_pretty(pg_database_size('test'));
 
I did a Ctrl+C after about five minutes and got:
 
Cancel request sent
 
but it didn't return for 15 or 20 minutes.  Any attempt to query
pg_locks stalls.  Tab completion stalls.  (By the way, this is not
related to the false alarm on that yesterday, which was a result of
my attempting tab completion from within a failed transaction, which
just found nothing rather than stalling.)
 
So I'm not sure whether I can get to a state suitable for starting
the desired test, but I'll stay with a for a while.
 
-Kevin

-- 
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] commit fests

[Hitoshi Harada]

2010/1/23 Dimitri Fontaine :
> Robert Haas  writes:
>>> I agree with trying to cut down the submission-to-commit delay, but
>>
>> It seems to me that the CommitFest process is pretty darn effective at
>> reducing the submission-to-commit delay, except when you miss the last
>> one for the release - then it sucks hard.
>
> Too bad we can't have a release management team (with committers,
> testers, advocacy, doc writers, etc) taking care of the beta to release
> road while the first commit fest(s) for next release happen in parallel.
>
> It would move the primary goal of a commit fest from committing patches
> to reviewing them (return with feedback or stamp ready for a committer),
> reducing the chances that anyone will have some time to handle the last
> step.
>
It seems to me that recent discussions pass over this point. At least
for me, the commit fest is to review patches and give authors feedback
in not-so-long time after posting them. I like this idea.


Regards,

-- 
Hitoshi Harada

-- 
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] commit fests

[Dimitri Fontaine]

Robert Haas  writes:
>> I agree with trying to cut down the submission-to-commit delay, but
>
> It seems to me that the CommitFest process is pretty darn effective at
> reducing the submission-to-commit delay, except when you miss the last
> one for the release - then it sucks hard.

Too bad we can't have a release management team (with committers,
testers, advocacy, doc writers, etc) taking care of the beta to release
road while the first commit fest(s) for next release happen in parallel.

It would move the primary goal of a commit fest from committing patches
to reviewing them (return with feedback or stamp ready for a committer),
reducing the chances that anyone will have some time to handle the last
step.

But that would allow say 6 commit fests per year, even if 2 of them
would in fact be (almost) review-only fests.

You could say that those 2 extra fests will only pile up more work to do
for committers once they're back from release management, but actually
that's already what happens: 

 - the first 8.5 commit fest had a lot of patches never reviewed

 - the 3rd commit fest for 9.1 would instead have plenty of ready to
   commit patches

 - authors that happen to have the bad luck of only having time to
   devote to PostgreSQL between beta and release would still enjoy a
   timely patch review, if not commit.

Regards,
-- 
dim

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

[HACKERS] Cstring vs. Datum values ( BuildTupleFromCStrings vs. BlessTupleDesc)

[Ivan Sergio Borgonovo]

Hi,

I'm trying to write a couple of C function that will:
- return a tsvector as a set of record.
- turn a tsvector into a tsquery

I'm looking at the example function to return set of records
http://www.postgresql.org/docs/8.4/static/xfunc-c.html#AEN44970

and to this:
"There are two ways you can build a composite data value (henceforth
a "tuple"): you can build it from an array of Datum values, or from
an array of C strings that can be passed to the input conversion
functions of the tuple's column data types. In either case, you
first need to obtain or construct a TupleDesc descriptor for the
tuple structure. When working with Datums, you pass the TupleDesc to
BlessTupleDesc, and then call heap_form_tuple for each row. When
working with C strings, you pass the TupleDesc to
TupleDescGetAttInMetadata, and then call BuildTupleFromCStrings for
each row. In the case of a function returning a set of tuples, the
setup steps can all be done once during the first call of the
function."

And I can't understand if I can avoid transforming everything into
its text representation:

snprintf(values[0], 16, "%d", 1 * PG_GETARG_INT32(1));
snprintf(values[1], 16, "%d", 2 * PG_GETARG_INT32(1));
snprintf(values[2], 16, "%d", 3 * PG_GETARG_INT32(1));

And if I can... how, why and when... because I didn't find any clear
example in the source tree that gives me a clue about when I'd use
one form or the other.

Up to my understanding the way to go to use Datum is:

/*
create a template tupledesc specifying numbers of columns (eg.2)
*/
tupdesc = CreateTemplateTupleDesc(3, false);

/*
???
bool hasoid
*/

/* configure the "fields" */
TupleDescInitEntry(tupdesc, (AttrNumber) 1, "word",
   TEXTOID, -1, 0);
/*
??
Oid oidtypeid, // where can I get a list of OID
int32 typmod,
int attdim)
*/

/* ??? */
funcctx->tuple_desc = BlessTupleDesc(tupdesc);
funcctx->attinmeta = TupleDescGetAttInMetadata(tupdesc);


-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it


-- 
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] 8.5 vs. 9.0, Postgres vs. PostgreSQL

[Greg Stark]

On Sat, Jan 23, 2010 at 4:44 AM, Tom Lane  wrote:
>  It's just as unclear whether MySQL is
> to be pronounced my-se-quel or my-ess-cue-ell, but how many people have
> you heard claiming that's a lousy name?

Actually the original promounciation was mee-ess-cue-ell, "My" is
monty's daughter's name and is pronounced like that. People generally
pronounced it "my" though so they just made that the official
pronounciation -- but they still don't approve of "my-sequel".

-- 
greg

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