Re: [HACKERS] 8.5 release timetable, again

[Greg Smith]

On Thu, 27 Aug 2009, Ron Mayer wrote:


The Linux kernel seems to do fine with a "when it is ready" cycle,
where some releases(2.6.24) take twice the time of others(2.6.28)[1,2].
[2] http://fblinux.freebase.com/view/base/fblinux/views/linux_kernel_release


That link has bad data.  If you check the tagging dates by looking at the 
source material here:


http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.27
http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.28

You can see that 2.6.28 didn't come out until 2008-12-14, not the 
2008-10-24 claimed on the freebase.com site.



I imagine it has similar stability and lack-of-data-loss requirements
as postgres does.


The Linux kernel developers are very clear that they don't care one bit 
about testing for stability or lack of data loss in any system-oriented 
way.  That's somebody else's job now, typically the Linux distributor who 
decides which of the kernels floating around are the most stable, 
hopefully running more and larger tests than the kernel developers do.


For example, if you consider Ubuntu 9.04 Jaunty, development started with 
2.6.27, upgraded to 2.6.28, then rejected moving to 2.6.29 even though 
they might have slipped it in.[1] When faced with the similar decision for 
2.6.26 vs. 2.6.27 in the previous release, they went for the later one, 
based on the features they needed to be stable.[2] It's really amazing 
that a useful result ever comes out of this model at all, and I know I'm 
not alone that I presume all Linux kernel releases are too full of bugs to 
be useful until I've proven otherwise with my own QA.


If the core PostgreSQL development worked like the Linux kernel, at the 
end of each CommitFest whatever was done at that point would get published 
as the new release.  Instead of pausing to focus on a stable release 
everyone would just speed ahead, backporting any major issues not 
discovered until after the official release.


[1] http://www.h-online.com/news/No-2-6-29-kernel-for-Jaunty-Jackalope--/112636
[2] https://lists.ubuntu.com/archives/ubuntu-devel/2008-August/026142.html

--
* Greg Smith gsm...@gregsmith.com http://www.gregsmith.com Baltimore, MD

--
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] [PATCH] Largeobject access controls

[KaiGai Kohei]

Itagaki Takahiro wrote:
> KaiGai Kohei  wrote:
> 
>> The pg_largeobject system catalog is reworked to manage its metadata.
>>
>>   CATALOG(pg_largeobject,2613)
>>   {
>>   Oid loowner;/* OID of the owner */
>>   Oid lochunk;/* OID of the data chunks */
>>   aclitem loacl[1];   /* access permissions */
>>   } FormData_pg_largeobject;
>>
>> Actual data chunks are stored in the toast relation of pg_largeobject,
>> and its chunk_id is stored in the pg_largeobject.lochunk.
> 
> A bit acrobatic, but insteresting idea.
> 
> I have some random comments:
> 
>   * Do you measure performance of the new LO implementation?
> AFAIK, Users expect performance benefits to LO; TOASTed
> bytea slows down when the size of data is 100KB or greater
> even if they don't use random seeks.

Not yet. Can you recommend commonly-used workload?

>   * We might take care of DROP ROLE and REASSIGN/DROP OWNED.
> Or, we might have large object without owner.
> It might require full-scanning of pg_largeobject table,
> but we can accept it because the size of pg_largeobject
> will be smaller; we have actual data out of the table.

I think it should be implemented using the dependency mechanism.
It requires full-scanning on the pg_shdepend tables, but it has
been accepted.

>   * Don't we also need "ALTER LARGE OBJECT  OWNER TO "
> for consistency?

Agreed. It will be also necessary to implement REASSIGN OWNED.

Thanks,
-- 
OSS Platform Development Division, NEC
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] [PATCH] Largeobject access controls

[Itagaki Takahiro]

KaiGai Kohei  wrote:

> The pg_largeobject system catalog is reworked to manage its metadata.
> 
>   CATALOG(pg_largeobject,2613)
>   {
>   Oid loowner;/* OID of the owner */
>   Oid lochunk;/* OID of the data chunks */
>   aclitem loacl[1];   /* access permissions */
>   } FormData_pg_largeobject;
> 
> Actual data chunks are stored in the toast relation of pg_largeobject,
> and its chunk_id is stored in the pg_largeobject.lochunk.

A bit acrobatic, but insteresting idea.

I have some random comments:

  * Do you measure performance of the new LO implementation?
AFAIK, Users expect performance benefits to LO; TOASTed
bytea slows down when the size of data is 100KB or greater
even if they don't use random seeks.

  * We might take care of DROP ROLE and REASSIGN/DROP OWNED.
Or, we might have large object without owner.
It might require full-scanning of pg_largeobject table,
but we can accept it because the size of pg_largeobject
will be smaller; we have actual data out of the table.

  * Don't we also need "ALTER LARGE OBJECT  OWNER TO "
for consistency?


Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center



-- 
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 release timetable, again

[Greg Stark]

On Fri, Aug 28, 2009 at 4:39 AM, Ron Mayer wrote:
> Josh Berkus wrote:
>> There's some very good reasons for the health of the project to have
>> specific release dates and stick to them.
>
> Help me understand why?
>
> The Linux kernel seems to do fine with a "when it is ready" cycle,
> where some releases(2.6.24) take twice the time of others(2.6.28)[1,2].
> I imagine it has similar stability and lack-of-data-loss requirements
> as postgres does.

Uhm, the Linux release process is actually now the canonical example
of time-based release management. They used to do "when it is ready"
and that led to such a dramatic catastrophic failure with 2.6 that
they adopted the most dogmatically time-based system of any open
source project.

They basically don't do any integration testing and leave that up to
the distributions now. Instead they have an "rc" release *every week*
like clockwork and every 2-3 months the last one becomes a new version
regardless of whether there's any notable new feature.

Other than the first few releases after 2.6.0 when things were still
fairly unstable and major fixes were going in the release cycle has
been remarkaby regular modulo holidays and vacations:

r | d  | days
--++--
 ChangeLog-2.6.30 | 2009-06-10 |   79
 ChangeLog-2.6.29 | 2009-03-23 |   89
 ChangeLog-2.6.28 | 2008-12-24 |   75
 ChangeLog-2.6.27 | 2008-10-10 |   89
 ChangeLog-2.6.26 | 2008-07-13 |   87
 ChangeLog-2.6.25 | 2008-04-17 |   84
 ChangeLog-2.6.24 | 2008-01-24 |  107
 ChangeLog-2.6.23 | 2007-10-09 |   92
 ChangeLog-2.6.22 | 2007-07-09 |   74
 ChangeLog-2.6.21 | 2007-04-26 |   81
 ChangeLog-2.6.20 | 2007-02-04 |   67
 ChangeLog-2.6.19 | 2006-11-29 |   70
 ChangeLog-2.6.18 | 2006-09-20 |   94
 ChangeLog-2.6.17 | 2006-06-18 |   90
 ChangeLog-2.6.16 | 2006-03-20 |   76
 ChangeLog-2.6.15 | 2006-01-03 |   67
 ChangeLog-2.6.14 | 2005-10-28 |   60
 ChangeLog-2.6.13 | 2005-08-29 |   73
 ChangeLog-2.6.12 | 2005-06-17 |  107
 ChangeLog-2.6.11 | 2005-03-02 |   68
 ChangeLog-2.6.10 | 2004-12-24 |   66
 ChangeLog-2.6.9  | 2004-10-19 |   66
 ChangeLog-2.6.8  | 2004-08-14 |   59
 ChangeLog-2.6.7  | 2004-06-16 |   37
 ChangeLog-2.6.6  | 2004-05-10 |   36
 ChangeLog-2.6.5  | 2004-04-04 |   24
 ChangeLog-2.6.4  | 2004-03-11 |   22
 ChangeLog-2.6.3  | 2004-02-18 |   14
 ChangeLog-2.6.2  | 2004-02-04 |   26
 ChangeLog-2.6.1  | 2004-01-09 |   22
 ChangeLog-2.6.0  | 2003-12-18 |
(31 rows)


-- 
greg
http://mit.edu/~gsstark/resume.pdf

-- 
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] Memory context usage

[Tom Lane]

Adriano Lange  writes:
> How can I get the used memory of a memory context?

MemoryContextStats() might help.  It just dumps the info to stderr
though.

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] [PATCH] Largeobject access controls

[KaiGai Kohei]

The attached patch provides access control features on largeobject.

This patch adds the ownership and two permissions (SELECT and UPDATE) on
largeobjects. The two permissions controls reader and writer accesses to
the largeobejcts. Only owner can unlink the largeobject which is owned by.
It also add a new attribute on the database role to control whether he
can create a new largeobject, or not. Because largeobject is not stored
within a certain namespace, we cannot control its creation using CREATE
permission.

The CREATE USER/ROLE statement got a new option: LARGEOBJECT/NOLARGEOBJECT.
It enables to controls whether the user can create a largeobject, or not.
The default is LARGEOBJECT which means user can create them.
This attribute is stored within pg_authid.rollargeobject defined as bool.

The pg_largeobject system catalog is reworked to manage its metadata.

  CATALOG(pg_largeobject,2613)
  {
  Oid loowner;/* OID of the owner */
  Oid lochunk;/* OID of the data chunks */
  aclitem loacl[1];   /* access permissions */
  } FormData_pg_largeobject;

Actual data chunks are stored in the toast relation of pg_largeobject,
and its chunk_id is stored in the pg_largeobject.lochunk.
As I noted before, there are several difficulties to implement partially
writable varlena type, so it uses the its toast relation just as a storage
to store its data chunks.

The GRANT/REVOKE statement also support largeobject, as follows:

  GRANT SELECT ON LARGE OBJECT 1234 TO kaigai;

It follows the matter when COMMENT ON statement specifies a large object.

Thanks,

 (Example) 
postgres=# CREATE USER dog;-- user can create largeobjects in default
CREATE ROLE
postgres=# CREATE USER cat NOLARGEOBJECT;
CREATE ROLE
postgres=# \c - dog
psql (8.5devel)
You are now connected to database "postgres" as user "dog".
postgres=> SELECT lo_create(123);
 lo_create
---
   123
(1 row)

postgres=> SELECT lo_create(100);
 lo_create
---
   100
(1 row)

postgres=> GRANT SELECT ON LARGE OBJECT 123 TO cat;
GRANT
postgres=> \c - cat
psql (8.5devel)
You are now connected to database "postgres" as user "cat".
postgres=> SELECT lo_create(456);
ERROR:  permission denied to create largeobject
postgres=> SELECT loread(lo_open(123, x'4'::int), 100);
 loread

 \x
(1 row)

postgres=> SELECT lowrite(lo_open(123, x'2'::int), 'abcdefg');
ERROR:  permission denied for largeobject 123
postgres=> SELECT lo_unlink(123);
ERROR:  must be owner of largeobject 123
===

[kai...@saba ~]$ diffstat sepgsql-02-blob-8.5devel-r2264.patch.gz
 doc/src/sgml/ref/create_role.sgml  |   13 +
 doc/src/sgml/ref/create_user.sgml  |1
 doc/src/sgml/ref/grant.sgml|8
 doc/src/sgml/ref/revoke.sgml   |6
 src/backend/catalog/aclchk.c   |  246 
 src/backend/catalog/dependency.c   |   14 +
 src/backend/catalog/pg_largeobject.c   |  139 +!!
 src/backend/catalog/pg_shdepend.c  |4
 src/backend/commands/comment.c |   10
 src/backend/commands/tablecmds.c   |1
 src/backend/commands/user.c|   32 ++
 src/backend/libpq/be-fsstubs.c |  141 ++-
 src/backend/parser/gram.y  |   26 +!
 src/backend/storage/large_object/inv_api.c |  344 ---
 src/backend/utils/adt/acl.c|4
 src/backend/utils/cache/syscache.c |   13 +
 src/include/catalog/dependency.h   |1
 src/include/catalog/indexing.h |4
 src/include/catalog/pg_authid.h|   14 !
 src/include/catalog/pg_largeobject.h   |   17 !
 src/include/catalog/toasting.h |   10
 src/include/nodes/parsenodes.h |1
 src/include/parser/kwlist.h|2
 src/include/utils/acl.h|6
 src/include/utils/syscache.h   |1
 src/test/regress/expected/privileges.out   |  202 +
 src/test/regress/input/largeobject.source  |7
 src/test/regress/output/largeobject.source |   10
 src/test/regress/sql/privileges.sql|   75 ++
 29 files changed, 857 insertions(+), 107 deletions(-), 388 modifications(!)

-- 
OSS Platform Development Division, NEC
KaiGai Kohei 


sepgsql-02-blob-8.5devel-r2264.patch.gz
Description: application/gzip

-- 
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 release timetable, again

[Ron Mayer]

Josh Berkus wrote:
> There's some very good reasons for the health of the project to have
> specific release dates and stick to them.  

Help me understand why?

The Linux kernel seems to do fine with a "when it is ready" cycle,
where some releases(2.6.24) take twice the time of others(2.6.28)[1,2].
I imagine it has similar stability and lack-of-data-loss requirements
as postgres does.

I understand why commercial packagers like Ubuntu - especially public
ones like Novell and Red Hat who have to forecast earnings -  want to
schedule their releases.

And I can imagine they'd appreciate it if project releases aren't
too close to their release schedules (if postgres releases right
after they release they suffer from not having the current version;
if postgres releases just before, they have limited testing time).

[1] http://www.linuxfoundation.org/publications/linuxkerneldevelopment.php
[2] http://fblinux.freebase.com/view/base/fblinux/views/linux_kernel_release

> So, with that in mind: what is your statement on three versus four
> commitfests?  Does it make a difference to you?


-- 
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] join removal

[Robert Haas]

On Sun, Aug 16, 2009 at 5:31 PM, Robert Haas wrote:
> It seems that the needed checks are very similar to the ones that we
> already implement when setting restrictinfo->mergeopfamilies.  That is
> filled in by get_mergejoin_opfamilies(), which checks for btree
> opfamilies where the strategy number is BTEqualStrategyNumber.  This
> might cease to be the correct check in the (not-too-distant?) future
> if we end up implementing other kinds of unique indices, but right now
> btrees are all there is.
>
> One possibility would be to have relation_is_distinct_for() call
> get_mergejoin_opfamilies() for each operator; then for each index we
> can check whether the opfamily of the relevant index column is in the
> returned list.  This seems a bit wasteful, though, since I believe
> that relation_is_distinct_for() would be called from joinpath.c, which
> has access to restrictinfo->mergeopfamilies already.
>
> I'm wondering whether it would make more sense to modify the proposed
> API for relation_is_distinct_for() in some way so that we don't lose
> this information.

Here is an attempt at the latter approach.  This doesn't actually
remove the join yet; it just checks whether the join can be removed.
I haven't tested it extensively yet, but am hoping for some feedback
on the basic approach.

...Robert
*** a/src/backend/optimizer/path/costsize.c
--- b/src/backend/optimizer/path/costsize.c
***
*** 109,114  bool		enable_hashagg = true;
--- 109,115 
  bool		enable_nestloop = true;
  bool		enable_mergejoin = true;
  bool		enable_hashjoin = true;
+ bool		enable_joinremoval = true;
  
  typedef struct
  {
*** a/src/backend/optimizer/path/joinpath.c
--- b/src/backend/optimizer/path/joinpath.c
***
*** 16,26 
--- 16,39 
  
  #include 
  
+ #include "optimizer/clauses.h"
  #include "optimizer/cost.h"
  #include "optimizer/pathnode.h"
  #include "optimizer/paths.h"
  
  
+ typedef struct path_operator_clause {
+ 	List   *mergeclause_list;
+ 	List   *hashclause_list;
+ 	List   *joinremovalclause_list;
+ 	List   *joinremovalvarattno_list;
+ } path_operator_clause;
+ 
+ static bool join_is_removable(RelOptInfo *joinrel,
+   RelOptInfo *outerrel,
+   RelOptInfo *innerrel,
+   path_operator_clause *poc,
+   JoinType jointype);
  static void sort_inner_and_outer(PlannerInfo *root, RelOptInfo *joinrel,
  	 RelOptInfo *outerrel, RelOptInfo *innerrel,
  	 List *restrictlist, List *mergeclause_list,
***
*** 31,47  static void match_unsorted_outer(PlannerInfo *root, RelOptInfo *joinrel,
  	 JoinType jointype, SpecialJoinInfo *sjinfo);
  static void hash_inner_and_outer(PlannerInfo *root, RelOptInfo *joinrel,
  	 RelOptInfo *outerrel, RelOptInfo *innerrel,
! 	 List *restrictlist,
  	 JoinType jointype, SpecialJoinInfo *sjinfo);
  static Path *best_appendrel_indexscan(PlannerInfo *root, RelOptInfo *rel,
  		 RelOptInfo *outer_rel, JoinType jointype);
! static List *select_mergejoin_clauses(PlannerInfo *root,
! 		 RelOptInfo *joinrel,
! 		 RelOptInfo *outerrel,
! 		 RelOptInfo *innerrel,
! 		 List *restrictlist,
! 		 JoinType jointype);
! 
  
  /*
   * add_paths_to_joinrel
--- 44,61 
  	 JoinType jointype, SpecialJoinInfo *sjinfo);
  static void hash_inner_and_outer(PlannerInfo *root, RelOptInfo *joinrel,
  	 RelOptInfo *outerrel, RelOptInfo *innerrel,
! 	 List *restrictlist, List *hashclauses,
  	 JoinType jointype, SpecialJoinInfo *sjinfo);
  static Path *best_appendrel_indexscan(PlannerInfo *root, RelOptInfo *rel,
  		 RelOptInfo *outer_rel, JoinType jointype);
! static bool rel_attrs_needed_above_join(RelOptInfo *rel, RelOptInfo *joinrel);
! static void select_operator_clauses(PlannerInfo *root,
! 		RelOptInfo *joinrel,
! 		RelOptInfo *outerrel,
! 		RelOptInfo *innerrel,
! 		List *restrictlist,
! 		JoinType jointype,
! 		path_operator_clause *poc);
  
  /*
   * add_paths_to_joinrel
***
*** 75,135  add_paths_to_joinrel(PlannerInfo *root,
  	 SpecialJoinInfo *sjinfo,
  	 List *restrictlist)
  {
! 	List	   *mergeclause_list = NIL;
  
  	/*
! 	 * Find potential mergejoin clauses.  We can skip this if we are not
! 	 * interested in doing a mergejoin.  However, mergejoin is currently our
! 	 * only way of implementing full outer joins, so override mergejoin
! 	 * disable if it's a full join.
  	 */
! 	if (enable_mergejoin || jointype == JOIN_FULL)
! 		mergeclause_list = select_mergejoin_clauses(root,
! 	joinrel,
! 	outerrel,
! 	innerrel,
! 	restrictlist,
! 	jointype);
  
  	/*
! 	 * 1. Consider mergejoin paths where both relations must be explicitly
  	 * sorted.
  	 */
  	sort_inner_and_outer(root, joinrel, outerrel, innerrel,
! 		 restrictlist, mergeclause_list, jointype, sjinfo);
  
  	/*
! 	 * 2. Consider paths where the outer relation need not be explicitly
  	 * sorted. This include

[HACKERS] patch: Review handling of MOVE and FETCH (ToDo)

[Pavel Stehule]

Hello,

this small patch complete MOVE support in plpgsql and equalize plpgsql
syntax with sql syntax.

There are possible new directions:

FORWARD expr, FORWARD ALL, BACKWARD expr, BACKWARD all.

These directions are not allowed for FETCH statement, because returns more rows.

This patch is related to ToDo issue: Review handling of MOVE and FETCH

Regards
Pavel Stehule

p.s. Scrollable cursors are supported yet in plpgsql. Do you know,
somebody, why this point is in ToDo (plpgsql) still?
*** ./doc/src/sgml/plpgsql.sgml.orig	2009-08-27 17:14:26.926410144 +0200
--- ./doc/src/sgml/plpgsql.sgml	2009-08-27 17:32:47.928407934 +0200
***
*** 2656,2670 
  
  
   The options for the direction clause are
!  the same as for FETCH, namely
   NEXT,
   PRIOR,
   FIRST,
   LAST,
   ABSOLUTE count,
   RELATIVE count,
!  FORWARD, or
!  BACKWARD.
   Omitting direction is the same
   as specifying NEXT.
   direction values that require moving
--- 2656,2670 
  
  
   The options for the direction clause are
!  similar as for FETCH, namely
   NEXT,
   PRIOR,
   FIRST,
   LAST,
   ABSOLUTE count,
   RELATIVE count,
!  FORWARD  count | ALL , or
!  BACKWARD  count | ALL .
   Omitting direction is the same
   as specifying NEXT.
   direction values that require moving
*** ./src/pl/plpgsql/src/gram.y.orig	2009-08-26 22:43:23.138239357 +0200
--- ./src/pl/plpgsql/src/gram.y	2009-08-27 08:18:13.418238086 +0200
***
*** 72,77 
--- 72,79 
  		  int until, const char *expected);
  static List*read_raise_options(void);
  
+ static PLpgSQL_stmt_fetch *complete_direction(PLpgSQL_stmt_fetch *fetch, bool *check_FROM);
+ 
  %}
  
  %expect 0
***
*** 178,183 
--- 180,186 
  		 * Keyword tokens
  		 */
  %token	K_ALIAS
+ %token  K_ALL
  %token	K_ASSIGN
  %token	K_BEGIN
  %token	K_BY
***
*** 1621,1626 
--- 1624,1635 
  
  		if (yylex() != ';')
  			yyerror("syntax error");
+ 			
+ 		if (!fetch->returns_row)
+ 			ereport(ERROR,
+ 	(errcode(ERRCODE_SYNTAX_ERROR),
+ 	 errmsg("statement FETCH returns more rows."),
+ 	 errhint("Multirows fetch are not allowed in PL/pgSQL.")));
  
  		fetch->lineno = $2;
  		fetch->rec		= rec;
***
*** 2252,2257 
--- 2261,2271 
  }
  
  
+ /*
+  * Read FETCH or MOVE statement direction. For statement for are only 
+  * one row directions allowed. MOVE statement can use FORWARD [(n|ALL)],
+  * BACKWARD [(n|ALL)] directions too.
+  */
  static PLpgSQL_stmt_fetch *
  read_fetch_direction(void)
  {
***
*** 2269,2274 
--- 2283,2289 
  	fetch->direction = FETCH_FORWARD;
  	fetch->how_many  = 1;
  	fetch->expr  = NULL;
+ 	fetch->returns_row = true;
  
  	/*
  	 * Most of the direction keywords are not plpgsql keywords, so we
***
*** 2313,2323 
  	}
  	else if (pg_strcasecmp(yytext, "forward") == 0)
  	{
! 		/* use defaults */
  	}
  	else if (pg_strcasecmp(yytext, "backward") == 0)
  	{
  		fetch->direction = FETCH_BACKWARD;
  	}
  	else if (tok != T_SCALAR)
  	{
--- 2328,2339 
  	}
  	else if (pg_strcasecmp(yytext, "forward") == 0)
  	{
! 		fetch = complete_direction(fetch, &check_FROM);
  	}
  	else if (pg_strcasecmp(yytext, "backward") == 0)
  	{
  		fetch->direction = FETCH_BACKWARD;
+ 		fetch = complete_direction(fetch, &check_FROM);
  	}
  	else if (tok != T_SCALAR)
  	{
***
*** 2346,2351 
--- 2362,2408 
  }
  
  
+ /*
+  * Allows directions:
+  *   FORWARD expr,  FORWARD ALL,  FORWARD
+  *   BACKWARD expr, BACKWARD ALL, BACKWARD
+  *
+  * so plpgsql should fully support PostgreSQL's MOVE statement.
+  */
+ static PLpgSQL_stmt_fetch *
+ complete_direction(PLpgSQL_stmt_fetch *fetch,  bool *check_FROM)
+ {
+ 	int	tok;
+ 	PLpgSQL_expr   *expr;
+ 
+ 	tok = yylex();
+ 	if (tok == K_FROM || tok == K_IN)
+ 	{
+ 		*check_FROM = false;
+ 		
+ 		return fetch;
+ 	}
+ 	
+ 	if (tok == K_ALL)
+ 	{
+ 		fetch->how_many = fetch->direction == FETCH_FORWARD ? -1 : 0;
+ 		fetch->direction = FETCH_ABSOLUTE;
+ 		fetch->returns_row = false;
+ 		*check_FROM = true;
+ 		
+ 		return fetch;
+ 	}
+ 
+ 	plpgsql_push_back_token(tok);
+ 	expr = read_sql_expression2(K_FROM, K_IN,
+ 			   "FROM or IN",
+ 			   NULL);
+ 	fetch->returns_row = false;
+ 	*check_FROM = false;
+ 	
+ 	return fetch;
+ }
+ 
  static PLpgSQL_stmt *
  make_return_stmt(int lineno)
  {
*** ./src/pl/plpgsql/src/plpgsql.h.orig	2009-08-27 07:46:45.051237969 +0200
--- ./src/pl/plpgsql/src/plpgsql.h	2009-08-27 07:58:57.816237398 +0200
***
*** 520,525 
--- 520,526 
  	int			how_many;		/* count, if constant (expr is NULL) */
  	PLpgSQL_expr *expr;			/* count, if expression */
  	bool		is_move;		/* is this a fetch or move? */
+ 	bool		returns_row;		/* returns one or more rows? */
  } PLpgSQL_stmt_fetch;
  
  
*** ./src/pl/plpgsql/

Re: [HACKERS] 8.5 release timetable, again

[Ron Mayer]

Andrew Dunstan wrote:
> I don't know of anyone who is likely to want to try out alphas in their
> normal development environments. The client I approached was
> specifically prepared to test beta releases that way.

Perhaps end-users won't, but I think companies who develop software that
works on top of postgres will. Perhaps to make sure their existing software
continues to work; or perhaps to get a head start working with new features.
I test against CVS-head occasionally.





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

[HACKERS] Memory context usage

[Adriano Lange]

Hi,

How can I get the used memory of a memory context?

Is there some function like:

int getMemoryUsage( MemoryContext )

?

I still working in a subplan cache for a query optimizer and I need to know
whether a temporary memory context is in certain limits.

Thanks

Adriano

-- 
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] [BUGS] fillfactor hides autovacuum parameters in 8.4.0

[Itagaki Takahiro]

Alvaro Herrera  wrote:

> So I'm going to apply your patch to both 8.4 and HEAD; we can always
> improve it later, I guess.

Thank you for your applying.
I think the fix is ugly, too. We need to introduce cleaner solution for 8.5.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center



-- 
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 release timetable, again

[Robert Haas]

On Thu, Aug 27, 2009 at 6:09 PM, Tom Lane wrote:
> "Kevin Grittner"  writes:
>> Robert Haas  wrote:
>>> The final CommitFest began November 11, 2008.  It closed March 25,
>>> 2009 (+ 144 days).  Beta1 was released April 15, 2009 (+ 21 days).
>
>> I'm not entirely clear on what was happening during the 21 days
>> between the end of the CommitFest and and the release of beta1.
>
> Release note drafting is one part of it, but mostly it's "loose end
> cleanup".  Historically there have always been a pile of loose ends
> to be dealt with, and the CommitFest structure doesn't really do
> anything to avoid that.  If you're interested, attached are all the
> commits between commitfest closure (which I announced immediately
> after committing the addition of contrib/btree_gin) and stamping
> beta1 (which was actually several days before the date Robert gives,
> because of the need for the packagers to do their thing).
>
> It appears to me that release notes weren't actually the bottleneck this
> time, though they have been in some prior cycles.  Bruce committed a
> first draft immediately after the commitfest closed.  Rather, it was
> arguing about things like \df behavior and cardinality() that took up
> the time.

It felt, at the time, like the release notes were holding things up,
hence the various and so-far-unsuccesful volunteering related to that
task.  But it's possible that there was enough parallel activity going
on that it wasn't actually so.

> We could certainly have released a perhaps-less-polished beta earlier.
> I think that the traditional criterion is that we don't release beta1
> as long as there are any known issues that might force an initdb.
> We were successful in avoiding a post-beta initdb this time, although
> IIRC the majority of release cycles have had one --- so maybe you
> could argue that that's not so important.  It would certainly be
> less important if we had working pg_migrator functionality to ease
> the pain of going from beta to final.
>
> Now that we have the alpha-release mechanism defined, some of the
> pressure for a quick beta could be taken off by releasing a final
> alpha right after the final commitfest closes.

Definitely.  Looking at it in hindsight, 3 weeks seems like a
reasonable amount of time between the end of the last CommitFest and
the start of beta.  It felt long at the time, but maybe that's partly
because the CommitFest was so intermininable.

I think what a lot of this boils down to is that we need a better
system for managing the tasks that need to be completed at each stage
of the release process, and who is working on each one, and what the
status of it is, just as we do for CommitFests.

...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] Unicode UTF-8 table formatting for psql text output

[Roger Leigh]

On Thu, Aug 27, 2009 at 10:17:32AM -0400, Alvaro Herrera wrote:
> Alvaro Herrera escribió:
> 
> > > I initially left these exactly the same as for ASCII (the ':' and ';'
> > > usage).  However, it's quite possible to make it use other characters.
> > > We could use the same lines, or two, three or four dashed lines
> > > ('╎' and '╏', or ┆' and '┇' or '┊' and '┋').
> > 
> > This works for me (say ╎ for newline-separated strings and ┊ for wrapped
> > output).
> 
> So it'd look like this:
> 
> alvherre=# select * from foo;
>  a │ b
>   
> ━━━┿
>  1 │ En un lugar de la Mancha, de cuyo nombre no quiero acordarme, no ha 
> mucho 
>┊ tiempo que vivía un hidalgo de los de lanza en astillero, adarga 
> antigua, 
>┊ rocín flaco y galgo corredor. Una olla de algo más vaca que carnero, 
> salpi
>┊ cón las más noches, duelos y quebrantos los sábados, lantejas los 
> viernes,
>┊  algún palomino de añadidura los domingos, consumían las tres partes de 
> su
>┊  hacienda. El resto della concluían sayo de velarte, calzas de velludo 
> par
>┊ a las fiestas, con sus pantuflos de lo mesmo, y los días de entresemana 
> se
>┊  honraba con su vellorí de lo más fino.  Tenía en su casa una ama que 
> pasa
>┊ ba de los cuarenta, y una sobrina que no llegaba a los veinte, y un mozo 
> d
>┊ e campo y plaza, que así ensillaba el rocín como tomaba la podadera.
>  2 │ —«Nunca fuera caballero de
>╎ damas tan bien servido
>╎ como fuera don Quijote
>╎ cuando de su aldea vino:
>╎ doncellas curaban dél;
>╎ princesas, del su rocino»
> (2 filas)

The attached patch adds support for the above output in wrapped mode.
It also uses single dashes (half lines) to represent lines which
contain no data, just vertical padding.  Output is unchanged for
ASCII output.

The last bit I'm missing is how to handle column wrapping for aligned
text output.  This is was introduced on 8th May 2008 by Bryce Nesbitt,
committed by Bruce Momjian (git commit f92f424d).  This patch
introduced the wrapped format, but I have not been able to activate
the codepaths that wrap column names in the table header (adding '+').

The logic in print_aligned_text goes like this:

col_count = cont->ncolumns;
...
more_col_wrapping = col_count;
curr_nl_line = 0;
while (more_col_wrapping)
{
  for (i = 0; i < cont->ncolumns; i++)
if (!(this_line + 1)->ptr)   // Surely only true once at end of columns?
  more_col_wrapping--;
  curr_nl_line++;
}

I'm not convinced looking at the code that more_col_wrapping is ever
true except for the first time through the loop, and it's reached
zero after completion of the inner loop, so all of the code used when
curr_nl_line is > 0 is never called.  I'm sure I'm interpreting this
incorrectly, but I can't see under what circumstances I would get the
column name header line wrapped over multiple lines.

It may be that I just haven't got a table with column names of the
correct number and lengths to trigger it?


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.
diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c
index 7505cd4..f85e507 100644
--- a/src/bin/psql/print.c
+++ b/src/bin/psql/print.c
@@ -21,6 +21,9 @@
 #endif
 
 #include 
+#ifdef HAVE_LANGINFO_H
+#include 
+#endif
 
 #include "catalog/pg_type.h"
 #include "pqsignal.h"
@@ -356,38 +359,75 @@ print_unaligned_vertical(const printTableContent *cont, FILE *fout)
 /* Aligned text		*/
 //
 
+static const printTextFormat asciiformat =
+{
+	{
+		{ "-", "+", "+", "+" },
+		{ "-", "+", "+", "+" },
+		{ "-", "+", "+", "+" },
+		{ "",  "|", "|", "|" }
+	},
+	":",
+	";",
+	" "
+};
+
+static const struct printTextFormat utf8format =
+{
+	{
+	  /* ─, ┌, ┬, ┐ */
+	  { "\342\224\200", "\342\224\214", "\342\224\254", "\342\224\220" },
+	  /* ━, ┝, ┿, ┥ */
+	  { "\342\224\201", "\342\224\235", "\342\224\277", "\342\224\245" },
+	  /* ─, └, ┴, ┘ */
+	  { "\342\224\200", "\342\224\224", "\342\224\264", "\342\224\230" },
+	  /* N/A, │, │, │ */
+	  { "", "\342\224\202", "\342\224\202", "\342\224\202" },
+	},
+	  /* ╎ */
+	  "\342\225\216",
+	  /* ┊ */
+	  "\342\224\212",
+	  /* ╷ */
+	  "\342\225\267"
+};
 
 /* draw "line" */
 static void
 _print_horizontal_line(const unsigned int ncolumns, const unsigned int *widths,
-	   unsigned short border, FILE *fout)
+		   unsigned short border, printTextRule pos,
+		   const printTextFormat *format,
+		   FILE *fout)
 {
 	unsigned int i,
 j;
 
+	const printTextLineFormat *lformat = &format->lrule[pos];
+
 	if (border == 1)
-		fputc('-', fout);
+		fputs(lformat->hrule, fout);
 	else if (border == 2)
-		fputs("+-", fout);
+		fprin

Re: [HACKERS] Patches for static check on geo_ops.c

[Paul Matthews]

Tom Lane wrote:
> I've applied the first three of these changes, but not the last two
> (the 'dist' assignments).  "clang" seems to have a tin ear for style :-(.
> It's failing to notice that we have several similar code blocks in
> sequence in these two places, and making the last one different from the
> rest would decrease code readability and modifiability.
>
>   
"Ah! The old programming via copy-and-paste
trick".

Maybe clang's ear for style isn't that bad after all.
:-)

-- 
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 release timetable, again

[Josh Berkus]

Simon,

> The level of detailed planning happening now is a change for the
> community and in general I think it's a good thing. In the past we've
> always said it will be shipped when it's ready, and now we seem to be
> caught by our own rules. There's no need to make hard decisions now.
> Let's keep some flexibility in our thinking. If the structures give us
> problems, lets change the structures. The idea is the plans help the
> developers, not hinder them or make it harder to include big features.

There's some very good reasons for the health of the project to have
specific release dates and stick to them.  "When will it be released" is
an important question to answer, and it's far better for the developers
who *aren't* working on big features to not be elastic.

So, with that in mind: what is your statement on three versus four
commitfests?  Does it make a difference to you?

-- 
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.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] MySQL Compatibility WAS: 8.5 release timetable, again

[Jean-Michel Pouré]

Le jeudi 27 août 2009 à 14:27 -0500, Jaime Casanova a écrit :
> the point was that if we simply were saying: hey! mysql can interpret
> this, make postgres do the same then we could end up with a lot of
> broken stuff... just because mysql users think is wonderful to not
> have to write sane code...

Not MySQL in general. Only the subset which helps and seems reasonable.
Bye, JM


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: [HACKERS] 8.5 release timetable, again

[Andrew Dunstan]

David Fetter wrote:


How about something in the alphas to the effect of,

Using PostgreSQL?
Have a development server to spare?
Try your application stack on alpha1!
We'd love to hear back.  Functionality, performance, you name it.


  


I don't know of anyone who is likely to want to try out alphas in their 
normal development environments. The client I approached was 
specifically prepared to test beta releases that way.


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 release timetable, again

[David Fetter]

On Thu, Aug 27, 2009 at 03:04:20PM -0400, Robert Haas wrote:
> On Thu, Aug 27, 2009 at 2:54 PM, Peter Eisentraut wrote:
> > On tor, 2009-08-27 at 09:58 -0400, Robert Haas wrote:
> >> To get positive results in which you can have confidence, you
> >> have to know that the testing which was done actually did a
> >> reasonably good job exercising the code in a way that would have
> >> flushed out bugs, had any been present.  That sounds a lot like
> >> the definition of a regression test suite.  Of course, we have
> >> that already, but it's nowhere near comprehensive.  Maybe we
> >> should be looking at an expanded test suite that runs on a time
> >> scale of hours rather than seconds.  Actually, didn't Peter talk
> >> about something like this at PGCon?
> >
> > Let's look at it this way: If I were writing a compiler, then I
> > would have two main test approaches.  First, I would have an
> > in-tree test suite that compiles a bunch of example code snippets
> > and checks that the results are reasonable.  Call that a
> > regression test.  It would be informed by code coverage analysis
> > and previously reported bugs.  Second, as part of my release
> > cycle, I would have an agenda to try to compile a large set of
> > real programs against my new compiler version.  I would do that
> > during the beta period.  You will notice that GCC pretty much
> > operates that way.
> >
> > We have regression tests.  They could and should be expanded.
> >  That's a developer job, and we can start working on that now.
> >  But this discussion was about what to do during beta.  And I
> > think during beta you want to test PostgreSQL against a large set
> > of real applications.  But we could try to clarify how to actually
> > do that in an organized way.
> >
> > Now, if you want to improve the regression tests, I would suggest
> > going through the commits since 8.4beta and since 8.4.0 final
> > release and ask how these problems could have been prevented or
> > caught earlier.  I suppose a test suite for WAL might be part of
> > the answer, but a closer analysis might be insightful.
> 
> What I want to do is address the concern about too much of any given
> year being consumed by beta and CommitFest.  I'm not sure I know how
> to do that though.

How about something in the alphas to the effect of,

Using PostgreSQL?
Have a development server to spare?
Try your application stack on alpha1!
We'd love to hear back.  Functionality, performance, you name it.

Cheers,
David.
-- 
David Fetter  http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

-- 
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 release timetable, again

[Tom Lane]

"Kevin Grittner"  writes:
> Robert Haas  wrote: 
>> The final CommitFest began November 11, 2008.  It closed March 25,
>> 2009 (+ 144 days).  Beta1 was released April 15, 2009 (+ 21 days).
 
> I'm not entirely clear on what was happening during the 21 days
> between the end of the CommitFest and and the release of beta1.

Release note drafting is one part of it, but mostly it's "loose end
cleanup".  Historically there have always been a pile of loose ends
to be dealt with, and the CommitFest structure doesn't really do
anything to avoid that.  If you're interested, attached are all the
commits between commitfest closure (which I announced immediately
after committing the addition of contrib/btree_gin) and stamping
beta1 (which was actually several days before the date Robert gives,
because of the need for the packagers to do their thing).

It appears to me that release notes weren't actually the bottleneck this
time, though they have been in some prior cycles.  Bruce committed a
first draft immediately after the commitfest closed.  Rather, it was
arguing about things like \df behavior and cardinality() that took up
the time.

We could certainly have released a perhaps-less-polished beta earlier.
I think that the traditional criterion is that we don't release beta1
as long as there are any known issues that might force an initdb.
We were successful in avoiding a post-beta initdb this time, although
IIRC the majority of release cycles have had one --- so maybe you
could argue that that's not so important.  It would certainly be
less important if we had working pg_migrator functionality to ease
the pain of going from beta to final.

Now that we have the alpha-release mechanism defined, some of the
pressure for a quick beta could be taken off by releasing a final
alpha right after the final commitfest closes.

regards, tom lane


2009-04-09 20:20  scrappy

* configure, configure.in, doc/bug.template,
src/include/pg_config.h.win32: 
commit and tag beta1

2009-04-09 19:22  tgl

* doc/src/sgml/release.sgml: Update release notes through
yesterday; some minor wordsmithing.

2009-04-09 18:32  momjian

* doc/src/sgml/monitoring.sgml: Clarify documentation references to
pg_stat_get_blocks_fetched and pg_stat_get_blocks_hit, per
suggestion from Robert Haas.

2009-04-09 17:50  momjian

* src/tools/RELEASE_CHANGES: No more need to update FAQs.

2009-04-09 17:35  petere

* src/tools/RELEASE_CHANGES: Add URL for config.guess/sub updates

2009-04-09 17:33  petere

* config/: config.guess, config.sub: Update config.guess and
config.sub

2009-04-09 16:50  tgl

* src/timezone/data/: africa, asia, leapseconds, northamerica,
southamerica (REL8_1_STABLE), africa, asia, leapseconds,
northamerica, southamerica (REL8_3_STABLE), africa, asia,
leapseconds, northamerica, southamerica (REL8_0_STABLE), africa,
asia, leapseconds, northamerica, southamerica (REL8_2_STABLE),
africa, asia, leapseconds, northamerica, southamerica: Update time
zone data files to tzdata release 2009e: DST law changes in
Argentina/San_Luis, Cuba, Jordan (historical correction only),
Morocco, Palestine, Syria, Tunisia.

2009-04-09 15:38  petere

* src/: backend/nls.mk, backend/po/de.po, backend/po/es.po,
backend/po/fr.po, backend/po/ja.po, backend/po/nl.po,
backend/po/ru.po, backend/po/tr.po, bin/initdb/nls.mk,
bin/initdb/po/de.po, bin/initdb/po/es.po, bin/initdb/po/fr.po,
bin/initdb/po/ja.po, bin/initdb/po/ru.po, bin/pg_config/nls.mk,
bin/pg_config/po/de.po, bin/pg_config/po/fr.po,
bin/pg_config/po/ja.po, bin/pg_config/po/ru.po,
bin/pg_config/po/tr.po, bin/pg_controldata/nls.mk,
bin/pg_controldata/po/de.po, bin/pg_controldata/po/fr.po,
bin/pg_controldata/po/ja.po, bin/pg_ctl/nls.mk,
bin/pg_ctl/po/cs.po, bin/pg_ctl/po/de.po, bin/pg_ctl/po/fr.po,
bin/pg_ctl/po/ja.po, bin/pg_ctl/po/ru.po, bin/pg_dump/nls.mk,
bin/pg_dump/po/de.po, bin/pg_dump/po/fr.po, bin/pg_dump/po/ja.po,
bin/pg_dump/po/tr.po, bin/pg_resetxlog/nls.mk,
bin/pg_resetxlog/po/de.po, bin/pg_resetxlog/po/fr.po,
bin/pg_resetxlog/po/ja.po, bin/pg_resetxlog/po/ru.po,
bin/psql/nls.mk, bin/psql/po/de.po, bin/psql/po/es.po,
bin/psql/po/fr.po, bin/psql/po/ja.po, bin/psql/po/tr.po,
bin/scripts/nls.mk, bin/scripts/po/de.po, bin/scripts/po/fr.po,
bin/scripts/po/ja.po, interfaces/ecpg/ecpglib/nls.mk,
interfaces/ecpg/ecpglib/po/de.po, interfaces/ecpg/ecpglib/po/es.po,
interfaces/ecpg/ecpglib/po/fr.po, interfaces/ecpg/preproc/nls.mk,
interfaces/ecpg/preproc/po/de.po, interfaces/ecpg/preproc/po/es.po,
interfaces/ecpg/preproc/po/fr.po, interfaces/libpq/nls.mk,
interfaces/libpq/po/de.po, interfaces/libpq/po/fr.po,
interfaces/li

Re: [HACKERS] 8.5 release timetable, again

[Alvaro Herrera]

Kevin Grittner escribió:
> Robert Haas  wrote: 
>  
> > The final CommitFest began November 11, 2008.  It closed March 25,
> > 2009 (+ 144 days).  Beta1 was released April 15, 2009 (+ 21 days).
>  
> I'm not entirely clear on what was happening during the 21 days
> between the end of the CommitFest and and the release of beta1.  I
> seem to remember Bruce saying that there were bugs being fixed, and
> that it didn't make sense to release a beta with known bugs of that
> magnitude, but I'm not clear on what was up with that.

That's nonsense IMHO.  We should have just released a version
documenting the known bugs, and asking for people to test the rest of
the system.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

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

Re: [HACKERS] 8.5 release timetable, again

[Alvaro Herrera]

Robert Haas escribió:

> Of course I don't think we'd actually need to start a CommitFest quite
> as quickly as we did this time, because with a shorter release cycle
> there ought to be a lot less patches already accumulated by the time
> we release, especially if there are clearly defined tasks for
> developers to do during the beta period.  On the other hand, 8.4beta
> was arguably too short, since we missed some serious problems, so the
> picture above may be a bit too rosy.

Maybe what this says is that we need to get a "pre-beta" release out as
early as possible, just after finalizing the last commitfest, and before
the "open items" and Bruce-approved release note writing are sorted out.
Probably the last alpha release will fill that role.  Sadly, the greek
folk did not consider having a letter between alpha and beta :-(

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

-- 
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] return a set of records

[Andrew Dunstan]

t

Werner Echezuria wrote:

Hi, I need to return a set of records from a query, first I translate
from sqlf to sql and later I wanna return the query, but the server
crash (I guess it crashes around the yyparse call).

This is the sql:

CREATE OR REPLACE FUNCTION sqlf (text) RETURNS SETOF record
AS 'MODULE_PATHNAME', 'sqlf'
LANGUAGE C IMMUTABLE STRICT;
  


You function doesn't look too immutable. Is it really?

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 release timetable, again

[Kevin Grittner]

Robert Haas  wrote: 
 
> The final CommitFest began November 11, 2008.  It closed March 25,
> 2009 (+ 144 days).  Beta1 was released April 15, 2009 (+ 21 days).
 
I'm not entirely clear on what was happening during the 21 days
between the end of the CommitFest and and the release of beta1.  I
seem to remember Bruce saying that there were bugs being fixed, and
that it didn't make sense to release a beta with known bugs of that
magnitude, but I'm not clear on what was up with that.  Did we close
the CF with known bugs open, or were these missed in the CF and found
after?  Surely it shouldn't normally take three weeks to get a beta
test version to the public after we close the last CF?
 
Just looking for where we could pick up a few weeks more of
development in each year
 
-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] 8.5 release timetable, again

[David Fetter]

On Thu, Aug 27, 2009 at 04:22:58PM -0400, Jonah H. Harris wrote:
> On Thu, Aug 27, 2009 at 3:53 PM, David Fetter  wrote:
> 
> > > I would appreciate it if somebody could send out some messages
> > > of calm, while I/we work. The time for open review will come
> > > around soon enough.
> >
> > With all due respect, the time for open review is now.  You have
> > already tried closed development several times, and it each time
> > has been, more or less, a spectacular failure.
> 
> Unlike Robert and Heikki, I don't see you contributing to or
> assisting Simon's work.

My assistance is of the form of actually getting it done.  Simon's
work is absolutely fantastic, but only when the rest of the community
can actually help.  When it shows up late, it actually hurts
everybody, most of all Simon.

> And, while I may be wrong, I doubt that you assisted in funding any
> of Simon's work on hot standby either.  As such, it's my opinion
> that continuing to criticize him from the sidelines is not only
> rude, but is also a bad idea as it relates to his motivation in
> working on this feature.

If, "your past strategy has a track record of failure, go with a new
strategy, one pretty much universally adopted in PostgreSQL," will
demotivate someone, I can't help that, and I doubt it's actually true.
I'm trying to help here, and encouraging a failed strategy is not
helping.

Cheers,
David.
-- 
David Fetter  http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

-- 
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 release timetable, again

[Christopher Browne]

and...@dunslane.net (Andrew Dunstan) writes:
> Actually, what I had in mind was getting people to run their
> applications etc. in some non-production environment on the beta. I
> talked to a client today and he said "sure, we have several
> development environments and we can put one or two on the beta and
> then let the developers just do their thing on it." Testing the things
> we know about is in a way less important than making sure nothing else
> got broken.

I've gotten the DB work on one of our applications to the point where
there's a meaningful set of DB tests that can be run in automated
fashion.  As a result, I rotate between PG versions periodically; every
couple weeks, I recompile HEAD, and run a test against it to make sure I
don't see any regressions.

It would be insane to think about deploying on some 8.5-alpha version,
but it's nice to have something I can run in ~5 minutes that exercises a
fair bit of at least vaguely realistic functionality.
-- 
"cbbrowne","@","ca.afilias.info"
Christopher Browne
"Bother,"  said Pooh,  "Eeyore, ready  two photon  torpedoes  and lock
phasers on the Heffalump, Piglet, meet me in transporter room three"

-- 
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 release timetable, again

[Robert Haas]

On Thu, Aug 27, 2009 at 3:56 PM, Alvaro
Herrera wrote:
> Robert Haas escribió:
>> What I want to do is address the concern about too much of any given
>> year being consumed by beta and CommitFest.  I'm not sure I know how
>> to do that though.
>
> How much time were we in beta?  I thought most time was spent trying to
> get to beta in the first place.

[ looks ]

The final CommitFest began November 11, 2008.  It closed March 25,
2009 (+ 144 days).  Beta1 was released April 15, 2009 (+ 21 days).
8.4.0 was released July 1, 2009 (+ 77 days).  The first CommitFest for
8.5 began on July 15, 2009 (+ 14 days).

http://www.postgresql.org/about/news.1074
http://wiki.postgresql.org/index.php?title=CommitFest_2008-11&action=history
http://www.postgresql.org/docs/8.4/static/release-8-4.html

In total, the tree was closed for 256 days, or 8.5 months, of which
the final CommitFest accounted for approximately 56%.  Had we closed
the final CommitFest in 30 days rather than 144 days, and had
everything else taken the same amount of time, the release would have
occurred on March 9th and the first CommitFest for 8.5 would have
started on March 23rd.

Hmm... maybe that's not actually that bad.  If we stuck to a similar
schedule for 8.5, but with a timely last CF, then we'd have either (3
CF):

2009-11-15 Final CommitFest Begins
2009-12-15 Final CommitFest Ends
2010-01-05 Beta
2010-03-23 Release
2010-04-06 First CommitFest for 8.6 Begins

Or (4 CF):

2010-01-15 Final CommitFest Begins
2010-02-15 Final CommitFest Ends
2010-03-08 Beta
2010-05-24 Release
2010-06-07 First CommitFest for 8.6 Begins

Of course I don't think we'd actually need to start a CommitFest quite
as quickly as we did this time, because with a shorter release cycle
there ought to be a lot less patches already accumulated by the time
we release, especially if there are clearly defined tasks for
developers to do during the beta period.  On the other hand, 8.4beta
was arguably too short, since we missed some serious problems, so the
picture above may be a bit too rosy.

...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] 8.5 release timetable, again

[Jonah H. Harris]

On Thu, Aug 27, 2009 at 3:53 PM, David Fetter  wrote:

> > I would appreciate it if somebody could send out some messages of
> > calm, while I/we work. The time for open review will come around
> > soon enough.
>
> With all due respect, the time for open review is now.  You have
> already tried closed development several times, and it each time has
> been, more or less, a spectacular failure.


Unlike Robert and Heikki, I don't see you contributing to or assisting
Simon's work.  And, while I may be wrong, I doubt that you assisted in
funding any of Simon's work on hot standby either.  As such, it's my opinion
that continuing to criticize him from the sidelines is not only rude, but is
also a bad idea as it relates to his motivation in working on this feature.

-- 
Jonah H. Harris, Senior DBA
myYearbook.com

Re: [HACKERS] typo in doc/src/sgml/release-8.4.sgml

[Alvaro Herrera]

Jan Urbański wrote:
> Patch -p1 attached.

Applied, thanks

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

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

[HACKERS] typo in doc/src/sgml/release-8.4.sgml

[Jan Urbański]

Patch -p1 attached.

Cheers,
Jan
diff --git a/doc/src/sgml/release-8.4.sgml b/doc/src/sgml/release-8.4.sgml
index 184bf47..50d9cb0 100644
--- a/doc/src/sgml/release-8.4.sgml
+++ b/doc/src/sgml/release-8.4.sgml
@@ -104,7 +104,7 @@
 
  
   Properly show fractional seconds and milliseconds for
-  >EXTRACT() (Tom)
+  EXTRACT() (Tom)
  
 
 

-- 
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 release timetable, again

[Alvaro Herrera]

Robert Haas escribió:

> What I want to do is address the concern about too much of any given
> year being consumed by beta and CommitFest.  I'm not sure I know how
> to do that though.

How much time were we in beta?  I thought most time was spent trying to
get to beta in the first place.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

-- 
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 release timetable, again

[David Fetter]

On Thu, Aug 27, 2009 at 08:48:43PM +0100, Simon Riggs wrote:
> 
> On Sun, 2009-08-23 at 01:57 -0400, Tom Lane wrote:
> > Robert Haas  writes:
> > > I posted a note about a week ago which drew far less commentary
> > > than I expected, regarding the timetable for the release of 8.5.
> > 
> > > http://archives.postgresql.org/pgsql-hackers/2009-08/msg01256.php
> > 
> > > Perhaps this is already being discussed on -core, but if so the
> > > conclusions haven't been shared publicly.
> > 
> > Core hasn't discussed 8.5 schedule since the discussions that
> > Peter summarized in the message you cited above.  I share your
> > concern that "release in time for PGCon" isn't very realistic if
> > we don't get more aggressive about schedule.  On the other hand,
> > we didn't get all that much done in this fest.  If we cut back to
> > a three-fest schedule I think we may succeed in releasing 8.5
> > early, but only because there is nothing interesting in it :-(.
> > Dunno where the right balance is.
> 
> General comment on thread:
> 
> The level of detailed planning happening now is a change for the
> community and in general I think it's a good thing. In the past
> we've always said it will be shipped when it's ready, and now we
> seem to be caught by our own rules. There's no need to make hard
> decisions now.  Let's keep some flexibility in our thinking. If the
> structures give us problems, lets change the structures. The idea is
> the plans help the developers, not hinder them or make it harder to
> include big features.
> 
> In my view it is important that I have a holistic view of what I am
> doing and that means it is very difficult for others to help in a
> way that doesn't merely hinder me (or Fujii-san). Speed of coding is
> not the issue here, nor is the number of hands on a keyboard. 
> 
> I don't share the doubts or fears expressed that the two big patches
> will not make it into Postgres in this release. We now have more
> people experienced in these areas of code than at any other time in
> our history. We have almost-complete solutions from experienced
> developers.  In particular, I have faith in Fujii-san. 
> 
> I would appreciate it if somebody could send out some messages of
> calm, while I/we work. The time for open review will come around
> soon enough. 

With all due respect, the time for open review is now.  You have
already tried closed development several times, and it each time has
been, more or less, a spectacular failure.

Cheers,
David.
-- 
David Fetter  http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

-- 
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 release timetable, again

[Simon Riggs]

On Sun, 2009-08-23 at 01:57 -0400, Tom Lane wrote:
> Robert Haas  writes:
> > I posted a note about a week ago which drew far less commentary than I
> > expected, regarding the timetable for the release of 8.5.
> 
> > http://archives.postgresql.org/pgsql-hackers/2009-08/msg01256.php
> 
> > Perhaps this is already being discussed on -core, but if so the
> > conclusions haven't been shared publicly.
> 
> Core hasn't discussed 8.5 schedule since the discussions that Peter
> summarized in the message you cited above.  I share your concern that
> "release in time for PGCon" isn't very realistic if we don't get more
> aggressive about schedule.  On the other hand, we didn't get all that
> much done in this fest.  If we cut back to a three-fest schedule
> I think we may succeed in releasing 8.5 early, but only because there
> is nothing interesting in it :-(.  Dunno where the right balance is.

General comment on thread:

The level of detailed planning happening now is a change for the
community and in general I think it's a good thing. In the past we've
always said it will be shipped when it's ready, and now we seem to be
caught by our own rules. There's no need to make hard decisions now.
Let's keep some flexibility in our thinking. If the structures give us
problems, lets change the structures. The idea is the plans help the
developers, not hinder them or make it harder to include big features.

In my view it is important that I have a holistic view of what I am
doing and that means it is very difficult for others to help in a way
that doesn't merely hinder me (or Fujii-san). Speed of coding is not the
issue here, nor is the number of hands on a keyboard. 

I don't share the doubts or fears expressed that the two big patches
will not make it into Postgres in this release. We now have more people
experienced in these areas of code than at any other time in our
history. We have almost-complete solutions from experienced developers.
In particular, I have faith in Fujii-san. 

I would appreciate it if somebody could send out some messages of calm,
while I/we work. The time for open review will come around soon enough. 

Faith and patience. Please. No need for Fawlty Towers re-runs.

-- 
 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 release timetable, again

[Dimitri Fontaine]

Hi,

Robert Haas  writes:
> On Thu, Aug 27, 2009 at 2:54 PM, Peter Eisentraut wrote:
>> We have regression tests.  They could and should be expanded.  That's a
>> developer job, and we can start working on that now.  But this
>> discussion was about what to do during beta.  And I think during beta
>> you want to test PostgreSQL against a large set of real applications.
>> But we could try to clarify how to actually do that in an organized
>> way.

Exactly, and I think that what we're missing here is a simple tool for
our users to check a new PostgreSQL release against their existing
application.

We already know how to either log all queries and analyze the log files
(CSV makes it easier, pgfouine parses them too) or to have a fe/be
protocol proxy to record application SQL traffic (tsung recorder does
that).

What we miss is a tool to run the captured queries through both versions
of PG and report any resultset mismatch, of course with a way to account
for ordering issues (but we've seen people rely on the ordering when
they don't give an order by clause, then bug the lists about it if a new
release changes it).

> What I want to do is address the concern about too much of any given
> year being consumed by beta and CommitFest.  I'm not sure I know how
> to do that though.

To do this I think we *need* to provide beta tester a validator kind of
tool which they can use even without having an application unit test
suite. And a way to easily report success or failure, and in case of
success, a notion of their tests coverage (which is reduced to the list
of PG features the application exercices, but an automated way to
extract the information while running the tool would allow for hackers
friendly categories).

Anyone interrested into starting a project and coding the tool we so
much need?

Regards,
-- 
dim

PS: of course provided with such a tool, I'd run it for several
applications as soon as possible, which might include every alpha
release.

PPS: I'll be happy to participate into such a project, but I seem to
have a rather full plate already and a shrinking OpenSource free time,
so waiting for me to get there won't help until it's about too late.

-- 
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] MySQL Compatibility WAS: 8.5 release timetable, again

[Jaime Casanova]

2009/8/27 Rob Wultsch :
>
> And that behavior has changed to be sane in 5.0+, iirc.
>

5.0.12+ actually... that is stated in the same thread...

the point was that if we simply were saying: hey! mysql can interpret
this, make postgres do the same then we could end up with a lot of
broken stuff... just because mysql users think is wonderful to not
have to write sane code...

-- 
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] hot standby - merged up to CVS HEAD

[David Fetter]

On Thu, Aug 27, 2009 at 07:08:28PM +0100, Simon Riggs wrote:
> 
> On Mon, 2009-08-17 at 11:19 +0300, Heikki Linnakangas wrote:
> 
> > I think there's a race condition in the way LogCurrentRunningXacts() is
> > called at the end of checkpoint. This can happen in the master:
> > 
> > 1. Checkpoint starts
> > 2. Transaction 123 begins, and does some updates
> > 3. Checkpoint ends. LogCurrentRunningXacts() is called.
> > 4. LogCurrentRunningXacts() gets the list of currently running
> > transactions by calling GetCurrentTransactionData().
> > 5. Transaction 123 ends, writing commit record to WAL
> > 6. LogCurrentRunningXacts() writes the list of running XIDs to WAL. This
> > includes XID 123, since that was still running at step 4.
> > 
> > When that is replayed, ProcArrayUpdateTransactions() will zap the
> > unobserved xids array with the list that includes XID 123, even though
> > we already saw a commit record for it.
> 
> That's not a race condition, but it does make the code more complex. The
> issue has been long understood.
> 
> I don't think it's acceptable to take and hold both ProcArray and
> WALInsertLock. Those are now the two most heavily contended locks on the
> system. We have evidence that there are burst delays associated with
> various operations on just one of those locks, let alone two.
> 
> If you're still doubtful, the problem I've been working on recently is
> the point that I overlooked the initial state of the lock table in my
> earlier patch. GetRunningTransactionData() also needs to have initial
> lock data.
> 
> There is no way in hell that I could personally condone holding
> ProcArrayLock, WALInsertLock and all of the LockMgrLock partitions at
> same time. So we just have to eat the complexity. (No doubt someone will
> disagree with my strong language here, but please take it as an
> indication of exactly how bad an idea holding multiple locks will be).
> 
> Slight timing issues are not too bad really. We just have to be careful
> to assume that there is a mismatch in the data and must have code to
> handle that.
> 
> Anyway, I've been working on this problem for some time and continue to
> do so.

Great!  Where's the git repository?

Cheers,
David.
-- 
David Fetter  http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

-- 
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 release timetable, again

[Robert Haas]

On Thu, Aug 27, 2009 at 2:54 PM, Peter Eisentraut wrote:
> On tor, 2009-08-27 at 09:58 -0400, Robert Haas wrote:
>> To get positive results in which you can have confidence, you have to
>> know that the testing which was done actually did a reasonably good
>> job exercising the code in a way that would have flushed out bugs, had
>> any been present.  That sounds a lot like the definition of a
>> regression test suite.  Of course, we have that already, but it's
>> nowhere near comprehensive.  Maybe we should be looking at an expanded
>> test suite that runs on a time scale of hours rather than seconds.
>> Actually, didn't Peter talk about something like this at PGCon?
>
> Let's look at it this way: If I were writing a compiler, then I would
> have two main test approaches.  First, I would have an in-tree test
> suite that compiles a bunch of example code snippets and checks that the
> results are reasonable.  Call that a regression test.  It would be
> informed by code coverage analysis and previously reported bugs.
> Second, as part of my release cycle, I would have an agenda to try to
> compile a large set of real programs against my new compiler version.
> I would do that during the beta period.  You will notice that GCC pretty
> much operates that way.
>
> We have regression tests.  They could and should be expanded.  That's a
> developer job, and we can start working on that now.  But this
> discussion was about what to do during beta.  And I think during beta
> you want to test PostgreSQL against a large set of real applications.
> But we could try to clarify how to actually do that in an organized way.
>
> Now, if you want to improve the regression tests, I would suggest going
> through the commits since 8.4beta and since 8.4.0 final release and ask
> how these problems could have been prevented or caught earlier.  I
> suppose a test suite for WAL might be part of the answer, but a closer
> analysis might be insightful.

What I want to do is address the concern about too much of any given
year being consumed by beta and CommitFest.  I'm not sure I know how
to do that though.

...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] 8.5 release timetable, again

[Peter Eisentraut]

On tor, 2009-08-27 at 09:58 -0400, Robert Haas wrote:
> To get positive results in which you can have confidence, you have to
> know that the testing which was done actually did a reasonably good
> job exercising the code in a way that would have flushed out bugs, had
> any been present.  That sounds a lot like the definition of a
> regression test suite.  Of course, we have that already, but it's
> nowhere near comprehensive.  Maybe we should be looking at an expanded
> test suite that runs on a time scale of hours rather than seconds.
> Actually, didn't Peter talk about something like this at PGCon?

Let's look at it this way: If I were writing a compiler, then I would
have two main test approaches.  First, I would have an in-tree test
suite that compiles a bunch of example code snippets and checks that the
results are reasonable.  Call that a regression test.  It would be
informed by code coverage analysis and previously reported bugs.
Second, as part of my release cycle, I would have an agenda to try to
compile a large set of real programs against my new compiler version.
I would do that during the beta period.  You will notice that GCC pretty
much operates that way.

We have regression tests.  They could and should be expanded.  That's a
developer job, and we can start working on that now.  But this
discussion was about what to do during beta.  And I think during beta
you want to test PostgreSQL against a large set of real applications.
But we could try to clarify how to actually do that in an organized way.

Now, if you want to improve the regression tests, I would suggest going
through the commits since 8.4beta and since 8.4.0 final release and ask
how these problems could have been prevented or caught earlier.  I
suppose a test suite for WAL might be part of the answer, but a closer
analysis might be insightful.


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

[HACKERS] return a set of records

[Werner Echezuria]

Hi, I need to return a set of records from a query, first I translate
from sqlf to sql and later I wanna return the query, but the server
crash (I guess it crashes around the yyparse call).

This is the sql:

CREATE OR REPLACE FUNCTION sqlf (text) RETURNS SETOF record
AS 'MODULE_PATHNAME', 'sqlf'
LANGUAGE C IMMUTABLE STRICT;

This is the function:

Datum sqlf(PG_FUNCTION_ARGS) {

char *query = TextDatumGetCString(PG_GETARG_DATUM(0));
void *result;
int   ret,proc;
int j,i;

FuncCallContext *funcctx;
int call_cntr;
int max_calls;

TupleDesc tupdesc;
SPITupleTable *tuptable;
AttInMetadata *attinmeta;

yy_scan_string(query);
sqlf_yyparse(&result);

 // stuff done only on the first call of the function

if (SRF_IS_FIRSTCALL()) {

MemoryContext oldcontext;

// create a function context for cross-call persistence
funcctx = SRF_FIRSTCALL_INIT();

// switch to memory context appropriate for multiple
// function calls

oldcontext =MemoryContextSwitchTo(funcctx->multi_call_memory_ctx);

SPI_connect();
ret=SPI_execute(result,true,0);
proc=SPI_processed;

// total number of tuples to be returned
funcctx->max_calls = proc;

if (ret > 0 && SPI_tuptable != NULL){
tupdesc = SPI_tuptable->tupdesc;
tuptable = SPI_tuptable;
}

 MemoryContextSwitchTo(oldcontext);
}

// stuff done on every call of the function

funcctx = SRF_PERCALL_SETUP();

call_cntr = funcctx->call_cntr;
max_calls = funcctx->max_calls;
attinmeta = funcctx->attinmeta;

j=0;
if (call_cntr < max_calls) { // do when there is more left to send
Datum *values;
HeapTuple tuple;
Datum datum_result;
bool isnull;

values = (Datum **) palloc(tupdesc->natts * sizeof(Datum *));

for (i = 1; i <= tupdesc->natts; i++)
values[i]=SPI_getbinval(tuple,tupdesc,i,&isnull);

tuple=tuptable->vals[j];

// make the tuple into a datum
datum_result = HeapTupleGetDatum(tuple);

j++;

SRF_RETURN_NEXT(funcctx, datum_result);

} else { // do when there is no more left

SRF_RETURN_DONE(funcctx);
}

}

Greetings.

-- 
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] MySQL Compatibility WAS: 8.5 release timetable, again

[Rob Wultsch]

2009/8/27 Jaime Casanova :
> 2009/8/27 Jean-Michel Pouré :
>>
>> Otherwise, replicating some MySQL SQL syntax will not work.
>>
>> As you know, people willing to use PostgreSQL replication are possibly
>> already MySQL replication users. So if they test and PostgreSQL fails,
>> this is too bad.
>>
>
> yeah! but some times the reason MySQL is not failing on those cases is
> because it's broken...
> Consider this one:
> http://archives.postgresql.org/pgsql-general/2005-12/msg00487.php
>
> we don't want to copy the bugs nor the bad designs decisions from
> MySQL, no that everything from MySQL is bad but i would be scary if we
> start supporting every single piece of code MySQL accepts
>

And that behavior has changed to be sane in 5.0+, iirc.

-- 
Rob Wultsch
wult...@gmail.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] pretty print viewdefs

[Andrew Dunstan]

Tom Lane wrote:
I assume you are in effect saying you don't mind if there is an 
occasional blank line in the output.



What blank line?  I would expect prettyprinting of expressions to
sometimes insert an embedded newline, but not one at the beginning
or end.  Do you have a counterexample?


  


Yes, CASE expressions, as in my previously posted example:

SELECT 'a'::text AS b, ( SELECT 1
  FROM dual) AS x, random() AS y,
   CASE
   WHEN true THEN 1
   ELSE 0
   END AS c, 1 AS d
  FROM dual;

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] pretty print viewdefs

[Tom Lane]

Andrew Dunstan  writes:
> OK, and how are we going to set that flag? Like I did, with a separate 
> function?

I would be inclined to invent a variant of pg_get_viewdef with an
additional parameter rather than choosing a new function name, but
otherwise yeah.  Or we could decide this isn't worth all the
trouble and just go back to your original patch.  By the time you
get done with all the documentation and client-side hacking that
would be required, this patch is going to be a lot larger than it
seems worth.

> I assume you are in effect saying you don't mind if there is an 
> occasional blank line in the output.

What blank line?  I would expect prettyprinting of expressions to
sometimes insert an embedded newline, but not one at the beginning
or end.  Do you have a counterexample?

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] hot standby - merged up to CVS HEAD

[Simon Riggs]

On Mon, 2009-08-17 at 11:19 +0300, Heikki Linnakangas wrote:

> I think there's a race condition in the way LogCurrentRunningXacts() is
> called at the end of checkpoint. This can happen in the master:
> 
> 1. Checkpoint starts
> 2. Transaction 123 begins, and does some updates
> 3. Checkpoint ends. LogCurrentRunningXacts() is called.
> 4. LogCurrentRunningXacts() gets the list of currently running
> transactions by calling GetCurrentTransactionData().
> 5. Transaction 123 ends, writing commit record to WAL
> 6. LogCurrentRunningXacts() writes the list of running XIDs to WAL. This
> includes XID 123, since that was still running at step 4.
> 
> When that is replayed, ProcArrayUpdateTransactions() will zap the
> unobserved xids array with the list that includes XID 123, even though
> we already saw a commit record for it.

That's not a race condition, but it does make the code more complex. The
issue has been long understood.

I don't think it's acceptable to take and hold both ProcArray and
WALInsertLock. Those are now the two most heavily contended locks on the
system. We have evidence that there are burst delays associated with
various operations on just one of those locks, let alone two.

If you're still doubtful, the problem I've been working on recently is
the point that I overlooked the initial state of the lock table in my
earlier patch. GetRunningTransactionData() also needs to have initial
lock data.

There is no way in hell that I could personally condone holding
ProcArrayLock, WALInsertLock and all of the LockMgrLock partitions at
same time. So we just have to eat the complexity. (No doubt someone will
disagree with my strong language here, but please take it as an
indication of exactly how bad an idea holding multiple locks will be).

Slight timing issues are not too bad really. We just have to be careful
to assume that there is a mismatch in the data and must have code to
handle that.

Anyway, I've been working on this problem for some time and continue to
do so.

-- 
 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] pretty print viewdefs

[Andrew Dunstan]

Tom Lane wrote:

Andrew Dunstan  writes:
  

I am confused.



  
The original two line addition was already in effect driven by the 
PRETTY_INDENT flag, because the appendContextKeyword call would be 
effectively a no-op if that flag wasn't on. But apparently some people 
don't want each  column on a separate line,  as I do, even when it's 
pretty printed, so, since that's what I want, I provided for it in a 
separate function, but I made the code take account of the cases you and 
Greg mentioned, where it already begins a new line for the column def.



What I was imagining was simply providing an additional pretty-print
flag that gives the alternatives of the current behavior, or the patch
you originally proposed that adds newlines between targetlist items all
the time.  I don't think that you should complicate the behavior any
more than that.

Personally I would prefer the original patch to this one.


  


OK, and how are we going to set that flag? Like I did, with a separate 
function?


I assume you are in effect saying you don't mind if there is an 
occasional blank line in the output.


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] clang's static checker report.

[Tom Lane]

Alex Hunsaker  writes:
> (do you have to mark every function that calls ereport(ERROR) as one
> that exits?)

That would be an open-ended project, and probably in many cases wouldn't
change the clang report anyway.  I think it's only worth worrying about
the ones that we find will suppress some false positives.

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] clang's static checker report.

[Alex Hunsaker]

On Thu, Aug 27, 2009 at 06:39, Grzegorz Jaskiewicz wrote:
> heh, sorry folks for the noise again :/
>
> There was a fair amount of false positives there - due to nature of Assert()
> macro. Mainly, since assert_enabled is a runtime variable, not a macro
> (which I sadly overlooked).
>
> So, hardcoding it to (1) (using CPP) removed quite few false positives.
>
> New results at:
>
> http://zlew.org/postgresql_static_check/scan-build-2009-08-27-4/
> archive at:
> http://zlew.org/postgresql_static_check/postgresql_static_check_27thAugust2009_2.tar.xz
>
> Please tell me, if you think that it can be improved more.

Looks like your still missing ExitPostmaster(1) see
http://zlew.org/postgresql_static_check/scan-build-2009-08-27-4/report-iqR9gz.html#EndPath.

and maybe ereport(ERROR) ?

see 
http://zlew.org/postgresql_static_check/scan-build-2009-08-27-4/report-gkkK9S.html#EndPath
it calls report_untranslatable_char() which in turn calls ereport(ERROR)
(do you have to mark every function that calls ereport(ERROR) as one
that exits?)

:)

-- 
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] [pgsql-hackers] Daily digest v1.9418 (15 messages)

[Robert Haas]

On Thu, Aug 27, 2009 at 12:47 PM, Jeff Janes wrote:
>> -- Forwarded message --
>> From: Tom Lane 
>> To: Robert Haas 
>> Date: Thu, 27 Aug 2009 10:11:24 -0400
>> Subject: Re: 8.5 release timetable, again
>>
>> What I'd like to see is some sort of test mechanism for WAL recovery.
>> What I've done sometimes in the past (and recently had to fix the tests
>> to re-enable) is to kill -9 a backend immediately after running the
>> regression tests, let the system replay the WAL for the tests, and then
>> take a pg_dump and compare that to the dump gotten after a conventional
>> run.  However this is quite haphazard since (a) the regression tests
>> aren't especially designed to exercise all of the WAL logic, and (b)
>> pg_dump might not show the effects of some problems, particularly not
>> corruption in non-system indexes.  It would be worth the trouble to
>> create a more specific test methodology.
>
> I hacked mdwrite so that it had a static int counter.  When the counter hit
> 400 and if the guc_of_death was set, it would write out a partial block (to
> simulate a partial page write) and then PANIC.  I have some Perl code that
> runs against the database doing a bunch of updates until the database dies.
> Then when it can reconnect again it makes sure the data reflects what Perl
> thinks it should.  This is how I (belatedly) found and traced down the bug
> in the visibility bit.  (What I was trying to do is determine if my toying
> around with XLogInsert was breaking anything.  Since the regression suit
> wouldn't show me a problem if one existed, I came up with this.  Then I
> found things were broken even before I started toying with it...)
>
> I don't know how lucky I was to hit open a test that found an already
> existing bug.  I have to assume I was somewhat lucky, simply because it took
> a run of many hours or overnight (with a simulated crash every 2 minutes or
> so) to reliably detect the problem.  But how do you turn something like this
> into a regression test?  Scattering the code with intentional crash inducing
> code that is there to exercise the error recover parts seems like it would
> be quite a mess.

This is pretty cool, IMO.  Admittedly, it does seem hard to bottle it,
but you managed it, so it's not completely impossible.  What you could
for this kind of thing is a series of patches and driver scripts, so
you build PostgreSQL with the patch, then run the driver script
against it.  Probably we'd want to standardize some kind of framework
for the driver scripts, once we had a list of ideas for testing and
some idea what it should look like.

...Robert

P.S. The subject line of this thread is not ideal.

-- 
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] pretty print viewdefs

[Tom Lane]

Andrew Dunstan  writes:
> I am confused.

> The original two line addition was already in effect driven by the 
> PRETTY_INDENT flag, because the appendContextKeyword call would be 
> effectively a no-op if that flag wasn't on. But apparently some people 
> don't want each  column on a separate line,  as I do, even when it's 
> pretty printed, so, since that's what I want, I provided for it in a 
> separate function, but I made the code take account of the cases you and 
> Greg mentioned, where it already begins a new line for the column def.

What I was imagining was simply providing an additional pretty-print
flag that gives the alternatives of the current behavior, or the patch
you originally proposed that adds newlines between targetlist items all
the time.  I don't think that you should complicate the behavior any
more than that.

Personally I would prefer the original patch to this one.

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] [pgsql-hackers] Daily digest v1.9418 (15 messages)

[Jeff Janes]

>
> -- Forwarded message --
> From: Tom Lane 
> To: Robert Haas 
> Date: Thu, 27 Aug 2009 10:11:24 -0400
> Subject: Re: 8.5 release timetable, again
>
> What I'd like to see is some sort of test mechanism for WAL recovery.
> What I've done sometimes in the past (and recently had to fix the tests
> to re-enable) is to kill -9 a backend immediately after running the
> regression tests, let the system replay the WAL for the tests, and then
> take a pg_dump and compare that to the dump gotten after a conventional
> run.  However this is quite haphazard since (a) the regression tests
> aren't especially designed to exercise all of the WAL logic, and (b)
> pg_dump might not show the effects of some problems, particularly not
> corruption in non-system indexes.  It would be worth the trouble to
> create a more specific test methodology.


I hacked mdwrite so that it had a static int counter.  When the counter hit
400 and if the guc_of_death was set, it would write out a partial block (to
simulate a partial page write) and then PANIC.  I have some Perl code that
runs against the database doing a bunch of updates until the database dies.
Then when it can reconnect again it makes sure the data reflects what Perl
thinks it should.  This is how I (belatedly) found and traced down the bug
in the visibility bit.  (What I was trying to do is determine if my toying
around with XLogInsert was breaking anything.  Since the regression suit
wouldn't show me a problem if one existed, I came up with this.  Then I
found things were broken even before I started toying with it...)

I don't know how lucky I was to hit open a test that found an already
existing bug.  I have to assume I was somewhat lucky, simply because it took
a run of many hours or overnight (with a simulated crash every 2 minutes or
so) to reliably detect the problem.  But how do you turn something like this
into a regression test?  Scattering the code with intentional crash inducing
code that is there to exercise the error recover parts seems like it would
be quite a mess.



> In short: merely making the tests bigger doesn't impress me in the
> least.  Focused testing on areas we aren't covering at all could be
> worth the trouble.


Do you have suggestions on what other areas need it?

Jeff

Re: [HACKERS] MySQL Compatibility WAS: 8.5 release timetable, again

[Jaime Casanova]

2009/8/27 Jean-Michel Pouré :
>
> Otherwise, replicating some MySQL SQL syntax will not work.
>
> As you know, people willing to use PostgreSQL replication are possibly
> already MySQL replication users. So if they test and PostgreSQL fails,
> this is too bad.
>

yeah! but some times the reason MySQL is not failing on those cases is
because it's broken...
Consider this one:
http://archives.postgresql.org/pgsql-general/2005-12/msg00487.php

we don't want to copy the bugs nor the bad designs decisions from
MySQL, no that everything from MySQL is bad but i would be scary if we
start supporting every single piece of code MySQL accepts

-- 
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] 8.5 release timetable, again

[Tom Lane]

Greg Stark  writes:
> On Thu, Aug 27, 2009 at 3:11 PM, Tom Lane wrote:
>> ... However this is quite haphazard since (a) the regression tests
>> aren't especially designed to exercise all of the WAL logic, and (b)
>> pg_dump might not show the effects of some problems, particularly not
>> corruption in non-system indexes.  It would be worth the trouble to
>> create a more specific test methodology.

> What I've been thinking of doing is having the regression suite take a
> backup after initdb and set archive mode on. when the regression suite
> finishes start the backup up and replay all the WAL.

> I'm not sure how to compare the databases since I don't think pg_dump
> actually works here -- a lot of the data is dropped by the end of the
> test.

Yeah, that's another problem with using the existing tests for this
purpose --- a lot of possibly-useful stuff isn't kept around to the end.
And the desire to keep the test modules independent limits the amount of
interaction between them too.  I really think we'd need a bespoke set of
tests to get very far with this.

This reminds me that pg_dump/pg_restore is another large pile of code
that receives no formalized testing whatsoever ...

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] pretty print viewdefs

[Andrew Dunstan]

Tom Lane wrote:

Andrew Dunstan  writes:
  
OK, drawing this together, what I did was to go back closer to my 
original idea, but put this in a separate function, so nobody would get 
too upset ;-)



This seems seriously ugly.  Why don't you have the flag just driving
your original two-line addition?


  


I am confused.

The original two line addition was already in effect driven by the 
PRETTY_INDENT flag, because the appendContextKeyword call would be 
effectively a no-op if that flag wasn't on. But apparently some people 
don't want each  column on a separate line,  as I do, even when it's 
pretty printed, so, since that's what I want, I provided for it in a 
separate function, but I made the code take account of the cases you and 
Greg mentioned, where it already begins a new line for the column def.


So, what exactly is ugly? My code? I can believe that. I have since made 
it slightly simpler by using a pstrdup'ed string instead of an extra 
StringInfo object. The output? That's a matter of taste, but I don't see 
how it's less ugly than what's there now. The idea of a new function? I 
don't see how to get what I want without it unless we're prepared to 
upset some of the people who have objected to my proposal.


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] pretty print viewdefs

[Tom Lane]

Andrew Dunstan  writes:
> OK, drawing this together, what I did was to go back closer to my 
> original idea, but put this in a separate function, so nobody would get 
> too upset ;-)

This seems seriously ugly.  Why don't you have the flag just driving
your original two-line addition?

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] Build system problem in 8.3.x

[Tom Lane]

Heikki Linnakangas  writes:
>> *** src/Makefile.port.old2009-08-27 10:56:46.0 +0200
>> --- src/Makefile.port2009-08-27 10:56:46.0 +0200
>> ***
>> *** 11,16 
>> endif
>> 
>> %.so: %.o
>> !$(CC) -shared -o $@ $<
>> 
>> sqlmansect = 7
>> --- 11,16 
>> endif
>> 
>> %.so: %.o
>> !$(CC) $(CFLAGS) -shared -o $@ $<
>> 
>> sqlmansect = 7

> I guess we should change that rule to use $(LD) instead of $(CC), and
> include $(LDFLAGS) in the rules that build SUBSYS.o. Or maybe there's a
> reason they are what they are, I don't know. (SUBSYS.o's are gone in 8.4
> anyway)

Those rules are used to build .so's, not SUBSYS.o's.  I see that this
change is already applied to Makefile.linux in HEAD, but I'm not sure
it's worth back-patching by itself.  We know that on Darwin, which is
where the most work has been done on cross-arch/multiarch builds, you
really need the SUBSYS.o-ectomy as well to make multiarch builds simple.
And we're *not* back-patching that.

I'm inclined to say that making this workable is an 8.4 feature and
you should use 8.4 if you need it.

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] [pgsql-hackers] Daily digest v1.9418 (15 messages)

[Kevin Grittner]

Jeff Janes  wrote:
 
> But the fact that a piece of code was executed doesn't mean
> it did the right thing.  If it does something subtly wrong,
> will we notice?
 
That's why it takes some time to fashion a decent test.
 
On the other hand, if code is not being exercised at at all during the
beta testing phase, it could do something dramatically wrong and we
wouldn't notice.
 
-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] [pgsql-hackers] Daily digest v1.9418 (15 messages)

[Jeff Janes]

>
> -- Forwarded message --
> From: "Kevin Grittner" 
> To: "Robert Haas" , "Bruce Momjian" <
> br...@momjian.us>
> Date: Thu, 27 Aug 2009 09:07:05 -0500
> Subject: Re: 8.5 release timetable, again
> Robert Haas  wrote:
>
> > Maybe we should be looking at an expanded test suite that runs on a
> > time scale of hours rather than seconds.
>
> > if we could say that we had a regression test suite which covered X%
> > of our code, and it passed on all Y platforms tested, that would
> > certainly be a confidence booster, especially for large values of X.
>
> > Part of the question, of course, is how to build up such a
> > regression test suite.
>
> Aren't there code coverage monitoring tools that could be run during
> regression tests?  Sure it would take some time to review the results
> and fashion tests to exercise chunks of code which were missed, but at
> least we could quantify X and try to make incremental progress on
> increasing it


But the fact that a piece of code was executed doesn't mean
it did the right thing.  If it does something subtly wrong,
will we notice?


Jeff

Re: [HACKERS] Patches for static check on geo_ops.c

[Tom Lane]

Paul Matthews  writes:
> Grzegorz Jaskiewicz wonderful static checker coughed up 5 errors in
> geo_ops.c.  None of them of any particular excitement or of earth
> shattering nature. A patch is attached below that should correct these.
> (The more little issue we eliminate, the more the large ones will stand
> out.)

> At line 3131 value stored into 'dist' variable is never referenced again.
> At line 3014 value stored into 'dist' variable is never referenced again.
> At line 2942 value stored into 'd' variable is never referenced again.
> At line 2953 value stored into 'd' variable is never referenced again.
> At line 2993 value stored into 'd' variable is never referenced again.

I've applied the first three of these changes, but not the last two
(the 'dist' assignments).  "clang" seems to have a tin ear for style :-(.
It's failing to notice that we have several similar code blocks in
sequence in these two places, and making the last one different from the
rest would decrease code readability and modifiability.  I'm happy if
the compiler optimizes away useless stores, but I don't really think
it should presume to dictate code style to us on that basis.

BTW, if we did apply those changes, I suppose clang would immediately
start complaining that the preceding assignments to 'd' are useless.
So by the time we'd made it happy, those code blocks would look quite
different from their mates.

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] 8.5 release timetable, again

[Jaime Casanova]

On Thu, Aug 27, 2009 at 10:38 AM, Greg Stark wrote:
>
> What I've been thinking of doing is having the regression suite take a
> backup after initdb and set archive mode on. when the regression suite
> finishes start the backup up and replay all the WAL.
>
> I'm not sure how to compare the databases

- execute 60 of the 121 tests (or at least those that create tables
and insert/update/delete the most data)
- crash the server and replay the WAL
- execute the rest of the tests and cross your fingers :)

-- 
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] 8.5 release timetable, again

[Robert Haas]

On Thu, Aug 27, 2009 at 11:29 AM, Tom Lane wrote:
> Robert Haas  writes:
>> Well, I wasn't suggesting adding a lot more testing of things that
>> we're already testing.  I was assuming that we would craft the
>> additional tests to hit areas that we are not now covering well.  My
>> point here is only to what Peter said upthread: we want to be able to
>> get positive results rather than waiting for "enough" negative results
>> (whatever that means).  To get positive results, you must have a test
>> suite.  While letting beta testers test whatever they want has some
>> value, testing things we think might be likely hiding places for bugs
>> (such as WAL recovery) has merit, too.  Making those tests
>> well-organized and easily repeatable is, IMHO, a Good Thing.
>
> The problem here is the "easily repeatable" bit.  Almost by definition,
> easily repeatable tests don't find hard-to-reproduce problems.  I don't
> mean to suggest that they're without value, but they are no substitute
> for beta testers doing unpredictable things.

I think you're overstating the case, but I don't want to argue the
point, particularly.  What I do want to do is find a way to address
the problem described in the last sentence of this email:

http://archives.postgresql.org/pgsql-hackers/2009-08/msg01614.php

Both committers and non-committers are currently suffering from the
fact that there is not a lot of time in the year which is set aside
for development, i.e. neither CommitFest-time nor beta-time.  To fix
this problem, we can:

1. Make CommitFests shorter.
2. Make CommitFests less frequent.
3. Continue developing during CommitFests.
4. Make beta cycles shorter.
5. Make beta cycles less frequent (i.e. lengthen the release cycle).
6. Continue developing during beta.

I believe (1) to be completely impractical and (3) to be
self-defeating.  I suspect (2) will backfire badly.  That doesn't
leave us with a lot of options.  We can certainly do (5), but the
downside is that features that get committed won't hit release for a
very long time.  I and others have suggested a couple of possible
approaches toward (4) or (6), such as changing the way we do release
notes, adding more regression tests to give us more (not perfect)
confidence that the release is solid, and/or branching the tree during
beta.  None of those ideas have gotten a single vote of confidence
from you or Bruce.  What's your suggestion?

...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] 8.5 release timetable, again

[Sam Mason]

On Thu, Aug 27, 2009 at 11:29:42AM -0400, Tom Lane wrote:
> Robert Haas  writes:
> > Well, I wasn't suggesting adding a lot more testing of things that
> > we're already testing.  I was assuming that we would craft the
> > additional tests to hit areas that we are not now covering well.  My
> > point here is only to what Peter said upthread: we want to be able to
> > get positive results rather than waiting for "enough" negative results
> > (whatever that means).  To get positive results, you must have a test
> > suite.  While letting beta testers test whatever they want has some
> > value, testing things we think might be likely hiding places for bugs
> > (such as WAL recovery) has merit, too.  Making those tests
> > well-organized and easily repeatable is, IMHO, a Good Thing.
> 
> The problem here is the "easily repeatable" bit.  Almost by definition,
> easily repeatable tests don't find hard-to-reproduce problems.  I don't
> mean to suggest that they're without value, but they are no substitute
> for beta testers doing unpredictable things.

I've wondered before about using a system emulator to snapshot the disk
on each write (I'd expect you could put some pretty low level hooks
in with qemu and gdb) and then run each snapshot in another system to
make sure that either the transaction is rolled back or committed as
appropriate.  I guess this would take a while to run but may help catch
some obscure bugs.  Or this an area that's well tested already?

-- 
  Sam  http://samason.me.uk/

-- 
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 #4996: postgres.exe memory consumption keeps going up

[Alvaro Herrera]

Magnus Hagander wrote:
> 2009/8/27 Alvaro Herrera :
> > Magnus Hagander wrote:
> >
> >> It'd be kind of neat of majordomo could insert a "held for moderation
> >> at " and "released from moderation at " headers or
> >> something. Anybody know if that's possible to do?
> >
> > You'd need to get Marc to patch the Majordomo2 source code ...
> > I proposed a patch months ago to have message-ids expanded in the
> > message footer, but no luck.
> 
> Did you cook up an actual patch? The majordomo server actually is
> something that the community has access to... (it's not properly
> documented, of course, but it's there)

Of course; attached.

I have not tried a patch for the feature you propose.  It'd be good to
have those (and also an indication of which moderator approved the
message).

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
diff -cr majordomo/lib/Mj/Resend.pm majordomo.orig/lib/Mj/Resend.pm
*** majordomo/lib/Mj/Resend.pm	2007-10-31 16:27:46.0 -0300
--- majordomo.orig/lib/Mj/Resend.pm	2009-03-17 12:06:32.0 -0400
***
*** 707,712 
--- 707,713 
   'SUBJECT'=> $subject || '(no subject)',
   'SUBSCRIBED' => ($avars{'days_since_subscribe'} < 0) ? "not" : "",
   'USER'   => "$user",
+  'MESSAGE_ID' => $msgid,
};
  
if ($mode !~ /archive/) {

-- 
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] [BUGS] fillfactor hides autovacuum parameters in 8.4.0

[Alvaro Herrera]

Itagaki Takahiro wrote:
> 
> Here is a patch to fix a bug in handling default values in reloptions.
> This fix should be applied to HEAD and 8.4.0.
> 
> I used 'magic number -1' to propagate "not-specified" information to
> autovacuum process. It might look strange because the default value is
> out of range of the reloption, but I think it has less impact to the
> codes comapred with other solutions (dynamic default values etc.).

I realized that any other solution here is going to be more complex and
thus less appropriate for backpatch.  I still don't like this very much
because it doesn't seem to offer enough flexibility to user-specified
reloptions; but any patch we come up with here is going to be applicable
to CVS HEAD.

So I'm going to apply your patch to both 8.4 and HEAD; we can always
improve it later, I guess.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

-- 
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 release timetable, again

[Greg Stark]

On Thu, Aug 27, 2009 at 3:11 PM, Tom Lane wrote:
>
> Precisely...
>
> What I'd like to see is some sort of test mechanism for WAL recovery.
> What I've done sometimes in the past (and recently had to fix the tests
> to re-enable) is to kill -9 a backend immediately after running the
> regression tests, let the system replay the WAL for the tests, and then
> take a pg_dump and compare that to the dump gotten after a conventional
> run.  However this is quite haphazard since (a) the regression tests
> aren't especially designed to exercise all of the WAL logic, and (b)
> pg_dump might not show the effects of some problems, particularly not
> corruption in non-system indexes.  It would be worth the trouble to
> create a more specific test methodology.

What I've been thinking of doing is having the regression suite take a
backup after initdb and set archive mode on. when the regression suite
finishes start the backup up and replay all the WAL.

I'm not sure how to compare the databases since I don't think pg_dump
actually works here -- a lot of the data is dropped by the end of the
test. But at least that would test that replaying WAL didn't cause any
crashes.

-- 
greg
http://mit.edu/~gsstark/resume.pdf

-- 
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 #4996: postgres.exe memory consumption keeps going up

[Magnus Hagander]

2009/8/27 Alvaro Herrera :
> Magnus Hagander wrote:
>
>> It'd be kind of neat of majordomo could insert a "held for moderation
>> at " and "released from moderation at " headers or
>> something. Anybody know if that's possible to do?
>
> You'd need to get Marc to patch the Majordomo2 source code ...
> I proposed a patch months ago to have message-ids expanded in the
> message footer, but no luck.

Did you cook up an actual patch? The majordomo server actually is
something that the community has access to... (it's not properly
documented, of course, but it's there)


-- 
 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] BUG #4996: postgres.exe memory consumption keeps going up

[Alvaro Herrera]

Magnus Hagander wrote:

> It'd be kind of neat of majordomo could insert a "held for moderation
> at " and "released from moderation at " headers or
> something. Anybody know if that's possible to do?

You'd need to get Marc to patch the Majordomo2 source code ...
I proposed a patch months ago to have message-ids expanded in the
message footer, but no luck.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

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

Re: [HACKERS] 8.5 release timetable, again

[Tom Lane]

Robert Haas  writes:
> Well, I wasn't suggesting adding a lot more testing of things that
> we're already testing.  I was assuming that we would craft the
> additional tests to hit areas that we are not now covering well.  My
> point here is only to what Peter said upthread: we want to be able to
> get positive results rather than waiting for "enough" negative results
> (whatever that means).  To get positive results, you must have a test
> suite.  While letting beta testers test whatever they want has some
> value, testing things we think might be likely hiding places for bugs
> (such as WAL recovery) has merit, too.  Making those tests
> well-organized and easily repeatable is, IMHO, a Good Thing.

The problem here is the "easily repeatable" bit.  Almost by definition,
easily repeatable tests don't find hard-to-reproduce problems.  I don't
mean to suggest that they're without value, but they are no substitute
for beta testers doing unpredictable things.

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] BUG #4996: postgres.exe memory consumption keeps going up

[Magnus Hagander]

2009/8/27 Alvaro Herrera :
> Greg Stark wrote:
>> Now why did this message get delayed by 4 hours before maia-1
>> delivered it to me? That was long enough in this to completely lose
>> the thread of conversation.
>>
>> Received: from postgresql.org (mail.postgresql.org [200.46.204.86])
>>       by maia-1.hub.org (Postfix) with ESMTP id 2909CAFD073;
>>       Thu, 27 Aug 2009 03:21:19 + (UTC)
>> Received: from localhost (unknown [200.46.208.211])
>>       by mail.postgresql.org (Postfix) with ESMTP id 0AC3463486D
>>       for ; Wed, 26 Aug 2009
>> 20:52:17 -0300 (ADT)
>
> Moderator delay?  I note that the message jumped to me from mx2.hub.org
> instead of maia-1, but at exactly the same time (down to seconds) -- but
> at a different time zone.

Quite likely. It's often not possible to see the difference between
moderation delay and mailsystem breakage delay, without looking at the
logfiles.

It'd be kind of neat of majordomo could insert a "held for moderation
at " and "released from moderation at " headers or
something. Anybody know if that's possible to do?

-- 
 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 release timetable, again

[Robert Haas]

On Thu, Aug 27, 2009 at 10:11 AM, Tom Lane wrote:
> Robert Haas  writes:
>> ... That sounds a lot like the definition of a
>> regression test suite.  Of course, we have that already, but it's
>> nowhere near comprehensive.  Maybe we should be looking at an expanded
>> test suite that runs on a time scale of hours rather than seconds.
>
> mysql's got one of those, and I haven't noticed that it's kept their
> defect rate down any.  Hour-long regression suites are the sort of
> thing developers won't run.

Well, I'll run them.  And I bet we could get volunteers to provide
machines to run them every night, too, against CVS HEAD.  This has
been discussed before, and I wasn't the one who suggested it.  I can't
speak to the value (or lack thereof) of mysql's regression test suite
as I know nothing about it, but even if it is completely worthless
that does not prove that a worthwhile test suite can't be constructed.

> Worse, regression suites are necessarily
> designed to exercise only 100%-reproducible behavior.

That is true, but our current testing methodology (hoping the
beta-testers find the bugs) seems not to be completely satisfactory
either.  Which brings us to:

>> I don't think that any test suite is going to eliminate the need for
>> beta-testing.
>
> Precisely...
>
> What I'd like to see is some sort of test mechanism for WAL recovery.
> What I've done sometimes in the past (and recently had to fix the tests
> to re-enable) is to kill -9 a backend immediately after running the
> regression tests, let the system replay the WAL for the tests, and then
> take a pg_dump and compare that to the dump gotten after a conventional
> run.  However this is quite haphazard since (a) the regression tests
> aren't especially designed to exercise all of the WAL logic, and (b)
> pg_dump might not show the effects of some problems, particularly not
> corruption in non-system indexes.  It would be worth the trouble to
> create a more specific test methodology.

Yep.  I was thinking about this as an area for possible improvement.
I don't immediately have a brilliant idea how to do it.  I did have
the idea of creating a loadable C function which would panic the
database.  This could be used to crash the database at a particular
point (even in mid-query, with sufficient creativity).

I think we would certainly need some more powerful way of checking
pass/failure than exact-text comparisons on SQL query results.  Being
a perl guy, the first thing that occurs to me is to write some kind of
test harness in perl that can issue SQL queries as well as do other
things, but I don't have an exact design mapped out in my head, and
I'm sure there are other viable approaches.

> In short: merely making the tests bigger doesn't impress me in the
> least.  Focused testing on areas we aren't covering at all could be
> worth the trouble.

Well, I wasn't suggesting adding a lot more testing of things that
we're already testing.  I was assuming that we would craft the
additional tests to hit areas that we are not now covering well.  My
point here is only to what Peter said upthread: we want to be able to
get positive results rather than waiting for "enough" negative results
(whatever that means).  To get positive results, you must have a test
suite.  While letting beta testers test whatever they want has some
value, testing things we think might be likely hiding places for bugs
(such as WAL recovery) has merit, too.  Making those tests
well-organized and easily repeatable is, IMHO, a Good Thing.

...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] BUG #4996: postgres.exe memory consumption keeps going up

[Alvaro Herrera]

Greg Stark wrote:
> Now why did this message get delayed by 4 hours before maia-1
> delivered it to me? That was long enough in this to completely lose
> the thread of conversation.
> 
> Received: from postgresql.org (mail.postgresql.org [200.46.204.86])
>   by maia-1.hub.org (Postfix) with ESMTP id 2909CAFD073;
>   Thu, 27 Aug 2009 03:21:19 + (UTC)
> Received: from localhost (unknown [200.46.208.211])
>   by mail.postgresql.org (Postfix) with ESMTP id 0AC3463486D
>   for ; Wed, 26 Aug 2009
> 20:52:17 -0300 (ADT)

Moderator delay?  I note that the message jumped to me from mx2.hub.org
instead of maia-1, but at exactly the same time (down to seconds) -- but
at a different time zone.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

-- 
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] Build system problem in 8.3.x

[Bernd Helmle]

--On 27. August 2009 11:34:29 +0200 Boszormenyi Zoltan  
wrote:



make -C ../../../contrib/spi refint.so autoinc.so
make[3]: Entering directory
`/home/zozo/Schönig-számlák/lucent/postgresql-8.3.5/contrib/spi'
gcc -m32 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
-Wdeclaration-after-statement
-Wendif-labels -fno-strict-aliasing -fwrapv -fpic -DREFINT_VERBOSE -I.
-I../../src/include
-D_GNU_SOURCE   -c -o refint.o refint.c
gcc -shared -o refint.so refint.o
/usr/bin/ld: i386 architecture of input file `refint.o' is incompatible
with i386:x86-64 output


I had a similar problem some time in the past on a multiarch SuSE on 
pSeries (however, it was the other way around, building 64-bit on 32-bit 
userspace). I blogged my solution here:




--
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] pretty print viewdefs

[Andrew Dunstan]

Tom Lane wrote:

Greg Stark  writes:
  

Incidentally I just tried
\d information_schema.views



  

and it *does* seem to put newlines after some of the target list
items. After each of the CASE expressions it puts a newline. So you
*already* get a mixture of some multiple items on a line and some
one-per-line.



Yeah, sufficiently complex expressions (sub-selects, for an obvious
case) will get internal pretty-printing that might include newlines.
  



OK, drawing this together, what I did was to go back closer to my 
original idea, but put this in a separate function, so nobody would get 
too upset ;-)


Here is what my function does, and also what the current "pretty 
printing" does:


   andrew=# select pg_get_viewdef_long('foo');
pg_get_viewdef_long 
   --

 SELECT 'a'::text AS b,
( SELECT 1
   FROM dual) AS x,
random() AS y,
CASE
WHEN true THEN 1
ELSE 0
END AS c,
1 AS d
   FROM dual;
   (1 row)

   andrew=# select pg_get_viewdef('foo',true);
  pg_get_viewdef   
   -

 SELECT 'a'::text AS b, ( SELECT 1
   FROM dual) AS x, random() AS y,
CASE
WHEN true THEN 1
ELSE 0
END AS c, 1 AS d
   FROM dual;
   (1 row)


WIP Patch is attached. To complete it I would add a psql option to use 
it, but maybe we should have a psql setting to enable it ... building 
something extra into the \d* stuff looks a bit ugly, since we already 
have a million options.


cheers

andrew


Index: src/include/catalog/pg_proc.h
===
RCS file: /cvsroot/pgsql/src/include/catalog/pg_proc.h,v
retrieving revision 1.549
diff -c -r1.549 pg_proc.h
*** src/include/catalog/pg_proc.h	4 Aug 2009 04:04:12 -	1.549
--- src/include/catalog/pg_proc.h	27 Aug 2009 14:22:04 -
***
*** 4071,4076 
--- 4071,4080 
  DESCR("select statement of a view with pretty-print option");
  DATA(insert OID = 2506 (  pg_get_viewdef	   PGNSP PGUID 12 1 0 0 f f f t f s 2 0 25 "26 16" _null_ _null_ _null_ _null_	pg_get_viewdef_ext _null_ _null_ _null_ ));
  DESCR("select statement of a view with pretty-print option");
+ DATA(insert OID = 2336 (  pg_get_viewdef_long	   PGNSP PGUID 12 1 0 0 f f f t f s 1 0 25 "25" _null_ _null_ _null_ _null_	pg_get_viewdef_name_long _null_ _null_ _null_ ));
+ DESCR("select statement of a view with pretty-printing, columns line separated");
+ DATA(insert OID = 2337 (  pg_get_viewdef_long	   PGNSP PGUID 12 1 0 0 f f f t f s 1 0 25 "26" _null_ _null_ _null_ _null_	pg_get_viewdef_long _null_ _null_ _null_ ));
+ DESCR("select statement of a view with pretty-printing, columns line separated");
  DATA(insert OID = 2507 (  pg_get_indexdef	   PGNSP PGUID 12 1 0 0 f f f t f s 3 0 25 "26 23 16" _null_ _null_ _null_ _null_	pg_get_indexdef_ext _null_ _null_ _null_ ));
  DESCR("index description (full create statement or single expression) with pretty-print option");
  DATA(insert OID = 2508 (  pg_get_constraintdef PGNSP PGUID 12 1 0 0 f f f t f s 2 0 25 "26 16" _null_ _null_ _null_ _null_	pg_get_constraintdef_ext _null_ _null_ _null_ ));
Index: src/include/utils/builtins.h
===
RCS file: /cvsroot/pgsql/src/include/utils/builtins.h,v
retrieving revision 1.338
diff -c -r1.338 builtins.h
*** src/include/utils/builtins.h	4 Aug 2009 16:08:36 -	1.338
--- src/include/utils/builtins.h	27 Aug 2009 14:22:05 -
***
*** 582,589 
--- 582,591 
  extern Datum pg_get_ruledef_ext(PG_FUNCTION_ARGS);
  extern Datum pg_get_viewdef(PG_FUNCTION_ARGS);
  extern Datum pg_get_viewdef_ext(PG_FUNCTION_ARGS);
+ extern Datum pg_get_viewdef_long(PG_FUNCTION_ARGS);
  extern Datum pg_get_viewdef_name(PG_FUNCTION_ARGS);
  extern Datum pg_get_viewdef_name_ext(PG_FUNCTION_ARGS);
+ extern Datum pg_get_viewdef_name_long(PG_FUNCTION_ARGS);
  extern Datum pg_get_indexdef(PG_FUNCTION_ARGS);
  extern Datum pg_get_indexdef_ext(PG_FUNCTION_ARGS);
  extern char *pg_get_indexdef_string(Oid indexrelid);
Index: src/backend/utils/adt/ruleutils.c
===
RCS file: /cvsroot/pgsql/src/backend/utils/adt/ruleutils.c,v
retrieving revision 1.306
diff -c -r1.306 ruleutils.c
*** src/backend/utils/adt/ruleutils.c	1 Aug 2009 19:59:41 -	1.306
--- src/backend/utils/adt/ruleutils.c	27 Aug 2009 14:22:05 -
***
*** 71,80 
--- 71,83 
  /* Pretty flags */
  #define PRETTYFLAG_PAREN		1
  #define PRETTYFLAG_INDENT		2
+ #define PRETTYFLAG_ONETARGET	4
  
  /* macro to test if pretty action needed */
  #define PRETTY_PAREN(context)	((context)->prettyFlags & PRETTYFLAG_PAREN)
  #define PRETTY_INDENT(context)	((context)->prettyFlags & PRETTYFLAG_INDENT)
+

Re: [HACKERS] Unicode UTF-8 table formatting for psql text output

[Alvaro Herrera]

Alvaro Herrera escribió:

> > I initially left these exactly the same as for ASCII (the ':' and ';'
> > usage).  However, it's quite possible to make it use other characters.
> > We could use the same lines, or two, three or four dashed lines
> > ('╎' and '╏', or ┆' and '┇' or '┊' and '┋').
> 
> This works for me (say ╎ for newline-separated strings and ┊ for wrapped
> output).

So it'd look like this:

alvherre=# select * from foo;
 a │ b  
━━━┿
 1 │ En un lugar de la Mancha, de cuyo nombre no quiero acordarme, no ha mucho 
   ┊ tiempo que vivía un hidalgo de los de lanza en astillero, adarga antigua, 
   ┊ rocín flaco y galgo corredor. Una olla de algo más vaca que carnero, salpi
   ┊ cón las más noches, duelos y quebrantos los sábados, lantejas los viernes,
   ┊  algún palomino de añadidura los domingos, consumían las tres partes de su
   ┊  hacienda. El resto della concluían sayo de velarte, calzas de velludo par
   ┊ a las fiestas, con sus pantuflos de lo mesmo, y los días de entresemana se
   ┊  honraba con su vellorí de lo más fino.  Tenía en su casa una ama que pasa
   ┊ ba de los cuarenta, y una sobrina que no llegaba a los veinte, y un mozo d
   ┊ e campo y plaza, que así ensillaba el rocín como tomaba la podadera.
 2 │ —«Nunca fuera caballero de
   ╎ damas tan bien servido
   ╎ como fuera don Quijote
   ╎ cuando de su aldea vino:
   ╎ doncellas curaban dél;
   ╎ princesas, del su rocino»
(2 filas)

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

-- 
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 release timetable, again

[Tom Lane]

Robert Haas  writes:
> ... That sounds a lot like the definition of a
> regression test suite.  Of course, we have that already, but it's
> nowhere near comprehensive.  Maybe we should be looking at an expanded
> test suite that runs on a time scale of hours rather than seconds.

mysql's got one of those, and I haven't noticed that it's kept their
defect rate down any.  Hour-long regression suites are the sort of
thing developers won't run.  Worse, regression suites are necessarily
designed to exercise only 100%-reproducible behavior.

> I don't think that any test suite is going to eliminate the need for
> beta-testing.

Precisely...

What I'd like to see is some sort of test mechanism for WAL recovery.
What I've done sometimes in the past (and recently had to fix the tests
to re-enable) is to kill -9 a backend immediately after running the
regression tests, let the system replay the WAL for the tests, and then
take a pg_dump and compare that to the dump gotten after a conventional
run.  However this is quite haphazard since (a) the regression tests
aren't especially designed to exercise all of the WAL logic, and (b)
pg_dump might not show the effects of some problems, particularly not
corruption in non-system indexes.  It would be worth the trouble to
create a more specific test methodology.

In short: merely making the tests bigger doesn't impress me in the
least.  Focused testing on areas we aren't covering at all could be
worth the trouble.

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] MySQL Compatibility WAS: 8.5 release timetable, again

[Jean-Michel Pouré]

Le mercredi 26 août 2009 à 15:51 -0700, Josh Berkus a écrit :
> I doubt this would be an accurate description of all Drupal
> developers.

My opinion was : 

Before adding replication to PostgreSQL, it would be better to support a
basic set of MySQL syntax seems relevant:

DELETE FROM table1, table2 FROM table1 INNER JOIN table2 ON ...
UPDATE table1, table1 SET table1.foo=1, table2.bar=3 WHERE table1.foo=2
INNER JOIN table2 ..., 
etc ...

There is not much to add to PostgreSQL, but it seems relevant.

Otherwise, replicating some MySQL SQL syntax will not work. 

As you know, people willing to use PostgreSQL replication are possibly
already MySQL replication users. So if they test and PostgreSQL fails,
this is too bad.

Drupal was only an example, I did not mean to criticize all Drupal
developers. Just to say they focus on PHP and not SQL. They don't have
time to port MySQL code. Besides, they are very nice people.

So I apologize for this short (false) focus.

Bye, Jean-Michel


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: [HACKERS] 8.5 release timetable, again

[Kevin Grittner]

Robert Haas  wrote:
 
> Maybe we should be looking at an expanded test suite that runs on a
> time scale of hours rather than seconds.
 
> if we could say that we had a regression test suite which covered X%
> of our code, and it passed on all Y platforms tested, that would
> certainly be a confidence booster, especially for large values of X.
 
> Part of the question, of course, is how to build up such a
> regression test suite.
 
Aren't there code coverage monitoring tools that could be run during
regression tests?  Sure it would take some time to review the results
and fashion tests to exercise chunks of code which were missed, but at
least we could quantify X and try to make incremental progress on
increasing it
 
-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] Unicode UTF-8 table formatting for psql text output

[Alvaro Herrera]

Roger Leigh escribió:
> On Tue, Aug 25, 2009 at 10:32:50PM -0400, Alvaro Herrera wrote:
> > Roger Leigh escribió:
> > 
> > > An updated copy of the patch is attached.
> > 
> > Did you give expanded output a look?  (\x)  I find it a bit weird that
> > the first line shows a single-pixel wide line but the subsequent ones
> > are thicker.
> 
> Yes, it's just due to the fact that the middle lines are using a
> thicker line character, while the top and bottom lines are thin.
> This can easily be changed to be e.g. all thin.

Yeah, I think expanded output should use the same char for all lines.

> > BTW I think you should also look at multiline fields,
> > 
> >  a │   b
> >
> > ━━━┿━━━
> >  4 │ some text
> >: and some more
> >: and then some
> > (1 filas)
> > 
> > And wrapped:
> > 
> > alvherre=# select * from foo;
> >  a │ b  
> > 
> > ━━━┿
> >  5 │ En un lugar de la Mancha, de cuyo nombre no quiero acordarme, no ha 
> > mucho 
> >; tiempo que vivía un hidalgo
> > (1 fila)
> 
> I initially left these exactly the same as for ASCII (the ':' and ';'
> usage).  However, it's quite possible to make it use other characters.
> We could use the same lines, or two, three or four dashed lines
> ('╎' and '╏', or ┆' and '┇' or '┊' and '┋').

This works for me (say ╎ for newline-separated strings and ┊ for wrapped
output).

> The wrapping code also appears slightly broken anyway, since
> continuation lines don't get '|' printed for subsequent blank columns
> on the same line:

Yeah ... maybe there's a point to this, or maybe it's just a bug -- I
don't know.

> I also see in the code that under some circumstances (curr_nl_line), a
> '+' is used instead of a space when printing table headers, but I
> haven't been able to trigger this yet.  We could also use dashed
> horizontal rules here.

Hmm, can't say I know what's this about.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

-- 
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 release timetable, again

[Robert Haas]

On Wed, Aug 26, 2009 at 7:39 PM, Bruce Momjian wrote:
> Peter Eisentraut wrote:
>> Much of the delay and uncertainty during beta in my mind comes from the
>> situation that we wait for negative results and don't trust the release
>> until we have seen and fixed enough of them.  Instead of waiting for
>> concrete, positive results and producing the release with confidence.
>
> Yep, that is our dilemma.

To get positive results in which you can have confidence, you have to
know that the testing which was done actually did a reasonably good
job exercising the code in a way that would have flushed out bugs, had
any been present.  That sounds a lot like the definition of a
regression test suite.  Of course, we have that already, but it's
nowhere near comprehensive.  Maybe we should be looking at an expanded
test suite that runs on a time scale of hours rather than seconds.
Actually, didn't Peter talk about something like this at PGCon?

I don't think that any test suite is going to eliminate the need for
beta-testing.  But if we could say that we had a regression test suite
which covered X% of our code, and it passed on all Y platforms tested,
that would certainly be a confidence booster, especially for large
values of X.  What we're basically doing now is hoping that
beta-testers come up with some novel tests, and that's a bit
hit-or-miss.

Part of the question, of course, is how to build up such a regression
test suite.  One way to do it is try to add a test every time you fix
a bug, such that the new test fails on the unpatched code and passes
with the fix...  or we could have a expanded-regression-test only
commitfest during beta, or something.  I think people would be willing
to put in some work on this.  I certainly would.  I run the regression
tests frequently during development but unless I'm making system
catalog changes they rarely catch anything.  I'm not prepared to write
the whole thing myself, but I would definitely be willing to develop
and contribute some tests.

...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] clang's static checker report.

[Grzegorz Jaskiewicz]

heh, sorry folks for the noise again :/

There was a fair amount of false positives there - due to nature of  
Assert() macro. Mainly, since assert_enabled is a runtime variable,  
not a macro (which I sadly overlooked).


So, hardcoding it to (1) (using CPP) removed quite few false positives.

New results at:

http://zlew.org/postgresql_static_check/scan-build-2009-08-27-4/
archive at: 
http://zlew.org/postgresql_static_check/postgresql_static_check_27thAugust2009_2.tar.xz

Please tell me, if you think that it can be improved more.



--
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] Patches for static check on geo_ops.c

[Grzegorz Jaskiewicz]

On 27 Aug 2009, at 10:46, Paul Matthews wrote:


Grzegorz Jaskiewicz wonderful static checker coughed up 5 errors in
geo_ops.c.  None of them of any particular excitement or of earth
shattering nature. A patch is attached below that should correct  
these.
(The more little issue we eliminate, the more the large ones will  
stand

out.)


I am flattered, but I am merely a user of it - running it against  
postgresql's source. The checker is written by wonderful llvm  
developers, so you should thank them (and apple, for sponsoring  
development of the checker).



--
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] clang's static checker report.

[Grzegorz Jaskiewicz]

On 24 Aug 2009, at 14:40, Peter Eisentraut wrote:


On mån, 2009-08-24 at 00:42 +0100, Grzegorz Jaskiewicz wrote:

--enable-cassert,  enabled, and also added exit_* in pg_dump to list
of functions that never return.


A few more functions to mark noreturn: DateTimeParseError(), and
die_horribly() in pg_dump


done.

new scan at: http://zlew.org/postgresql_static_check/scan-build-2009-08-27-2/
archive at: 
http://zlew.org/postgresql_static_check/postgresql_static_check_27thAugust2009.tar.xz

If people find it useful (altho, I've only seen single commit as  
result of that checker, and nothing fancy either) - I can write a  
script that would update it on daily basis.


what you people say ?

New Patch :

Index: src/Makefile.global.in
===
RCS file: /projects/cvsroot/pgsql/src/Makefile.global.in,v
retrieving revision 1.258
diff -u -b -r1.258 Makefile.global.in
--- src/Makefile.global.in  26 Aug 2009 22:24:42 -  1.258
+++ src/Makefile.global.in  27 Aug 2009 11:54:36 -
@@ -205,7 +205,10 @@
 endif
 endif # not PGXS

+ifndef CC
 CC = @CC@
+endif
+
 GCC = @GCC@
 SUN_STUDIO_CC = @SUN_STUDIO_CC@
 CFLAGS = @CFLAGS@
Index: src/bin/pg_dump/pg_backup.h
===
RCS file: /projects/cvsroot/pgsql/src/bin/pg_dump/pg_backup.h,v
retrieving revision 1.52
diff -u -b -r1.52 pg_backup.h
--- src/bin/pg_dump/pg_backup.h 11 Jun 2009 14:49:07 -  1.52
+++ src/bin/pg_dump/pg_backup.h 27 Aug 2009 11:54:37 -
@@ -150,7 +150,7 @@

 extern void
 exit_horribly(Archive *AH, const char *modulename, const char  
*fmt,...)

-__attribute__((format(printf, 3, 4)));
+__attribute__((format(printf, 3, 4))) __attribute__ 
((analyzer_noreturn));



 /* Lets the archive know we have a DB connection to shutdown if it  
dies */

Index: src/bin/pg_dump/pg_backup_archiver.h
===
RCS file: /projects/cvsroot/pgsql/src/bin/pg_dump/pg_backup_archiver.h,v
retrieving revision 1.82
diff -u -b -r1.82 pg_backup_archiver.h
--- src/bin/pg_dump/pg_backup_archiver.h7 Aug 2009 22:48:34 -   
1.82
+++ src/bin/pg_dump/pg_backup_archiver.h27 Aug 2009 11:54:37 -
@@ -325,7 +325,7 @@
 /* Used everywhere */
 extern const char *progname;

-extern void die_horribly(ArchiveHandle *AH, const char *modulename,  
const char *fmt,...) __attribute__((format(printf, 3, 4)));
+extern void die_horribly(ArchiveHandle *AH, const char *modulename,  
const char *fmt,...) __attribute__((format(printf, 3, 4)))  
__attribute__((analyzer_noreturn));
 extern void warn_or_die_horribly(ArchiveHandle *AH, const char  
*modulename, const char *fmt,...) __attribute__((format(printf, 3, 4)));
 extern void write_msg(const char *modulename, const char *fmt,...)  
__attribute__((format(printf, 2, 3)));


Index: src/bin/pg_dump/pg_dump.h
===
RCS file: /projects/cvsroot/pgsql/src/bin/pg_dump/pg_dump.h,v
retrieving revision 1.156
diff -u -b -r1.156 pg_dump.h
--- src/bin/pg_dump/pg_dump.h   2 Aug 2009 22:14:52 -   1.156
+++ src/bin/pg_dump/pg_dump.h   27 Aug 2009 11:54:37 -
@@ -481,7 +481,7 @@
 extern void *pg_realloc(void *ptr, size_t size);

 extern void check_conn_and_db(void);
-extern void exit_nicely(void);
+extern void exit_nicely(void) __attribute__((analyzer_noreturn));

 extern void parseOidArray(const char *str, Oid *array, int arraysize);

Index: src/include/postgres.h
===
RCS file: /projects/cvsroot/pgsql/src/include/postgres.h,v
retrieving revision 1.92
diff -u -b -r1.92 postgres.h
--- src/include/postgres.h  1 Jan 2009 17:23:55 -   1.92
+++ src/include/postgres.h  27 Aug 2009 11:54:37 -
@@ -691,6 +691,6 @@

 extern int ExceptionalCondition(const char *conditionName,
 const char *errorType,
-const char *fileName, int lineNumber);
+	 const char *fileName, int lineNumber) __attribute__ 
((analyzer_noreturn));


 #endif   /* POSTGRES_H */
Index: src/include/utils/datetime.h
===
RCS file: /projects/cvsroot/pgsql/src/include/utils/datetime.h,v
retrieving revision 1.75
diff -u -b -r1.75 datetime.h
--- src/include/utils/datetime.h11 Jun 2009 14:49:13 -  1.75
+++ src/include/utils/datetime.h27 Aug 2009 11:54:37 -
@@ -300,7 +300,7 @@
  int *dtype, struct pg_tm * tm, fsec_t 
*fsec);

 extern void DateTimeParseError(int dterr, const char *str,
-  const char *datatype);
+  const char *datatype) 
__attribute__((__noreturn__));

 extern int DetermineTimeZoneOffset(struct pg_tm * tm, pg_tz *tzp);

Index: src/include/utils/elog.h

Re: [HACKERS] Build system problem in 8.3.x

[Boszormenyi Zoltan]

Heikki Linnakangas írta:
> Boszormenyi Zoltan wrote:
>   
>> we have come across a problem in 8.3.x (8.3.5 and 8.3.7 was tested)
>> while building PostgreSQL for 32-bit on 64-bit RHEL5 and Fedora 9.
>>
>> The following defines were used before running configure:
>>
>> export CFLAGS="-m32"
>> export LD="ld -melf_i386"
>>
>> The above are needed because when SUBSYS.o files are created,
>> the $(LD) ... lines don't contain $(LDFLAGS) anywhere, so overriding
>> $(LD) on the command line has to be done instead.
>>
>> However, there's one additional problem that can be solved by the
>> attached one liner. The problem is that during building the core,
>> something (test/regress) requires contrib/spi/refint.so to be built.
>> 
>
> If you're willing to override $(LD), seems you could get around that
> additional problem by overriding $(CC) as well:
>
> export CC="$(CC) -m32"
> export LD="ld -melf_i386"
>   

Yes, it's true. Ultimately CFLAGS and LDFLAGS should be
the way to control special compilation or linking. But there's
a problem:

export CFLAGS="-m32"
export LDFLAGS="-melf_i386"

$ ./configure --prefix=/home/zozo/pgc835_32 --enable-depend --enable-debug
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking which template to use... linux
checking whether to build with 64-bit integer date/time support... no
checking whether NLS is wanted... no
checking for default port number... 5432
checking for gcc... gcc
checking for C compiler default output file name... configure: error: C
compiler cannot create executables
See `config.log' for more details.

In "config.log":

configure:2246: checking for C compiler default output file name
configure:2249: gcc -m32  -melf_i386 conftest.c  >&5
cc1: error: unrecognized command line option "-melf_i386"

configure:2252: $? = 1
configure: failed program was:
| /* confdefs.h.  */
|
| #define PACKAGE_NAME "PostgreSQL"
| #define PACKAGE_TARNAME "postgresql"
| #define PACKAGE_VERSION "8.3.5"
| #define PACKAGE_STRING "PostgreSQL 8.3.5"
| #define PACKAGE_BUGREPORT "pgsql-b...@postgresql.org"
| #define PG_VERSION "8.3.5"
| #define DEF_PGPORT 5432
| #define DEF_PGPORT_STR "5432"
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:2291: error: C compiler cannot create executables

GCC should get only CFLAGS on the compilation line,
it passes -melf_i386 to LD automatically.

Also, modifying LD and CC may stir up some problems in the
USE_PGXS=1 machinery, I don't know. Adding $(LDFLAGS)
to Makefiles would be the way to go, some discussion is needed.

>> *** src/Makefile.port.old2009-08-27 10:56:46.0 +0200
>> --- src/Makefile.port2009-08-27 10:56:46.0 +0200
>> ***
>> *** 11,16 
>>   endif
>>   
>>   %.so: %.o
>> !$(CC) -shared -o $@ $<
>>   
>>   sqlmansect = 7
>> --- 11,16 
>>   endif
>>   
>>   %.so: %.o
>> !$(CC) $(CFLAGS) -shared -o $@ $<
>>   
>>   sqlmansect = 7
>> 
>
> I guess we should change that rule to use $(LD) instead of $(CC), and
> include $(LDFLAGS) in the rules that build SUBSYS.o. Or maybe there's a
> reason they are what they are, I don't know.

Maybe the one who wrote the Makefiles for this SUBSYS.o
scheme could tell us. Maybe the reason is simply multilib systems
weren't so widespread at the time.

> (SUBSYS.o's are gone in 8.4 anyway)
>   

I know, but older 8.x versions are still supported, such build-system
fixes might be allowed to go in...

-- 
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] Unicode UTF-8 table formatting for psql text output

[Roger Leigh]

On Tue, Aug 25, 2009 at 10:32:50PM -0400, Alvaro Herrera wrote:
> Roger Leigh escribió:
> 
> > An updated copy of the patch is attached.
> 
> Did you give expanded output a look?  (\x)  I find it a bit weird that
> the first line shows a single-pixel wide line but the subsequent ones
> are thicker.

Yes, it's just due to the fact that the middle lines are using a
thicker line character, while the top and bottom lines are thin.
This can easily be changed to be e.g. all thin.

> BTW I think you should also look at multiline fields,
> 
>  a │   b  
>  
> ━━━┿━━━
>  4 │ some text
>: and some more
>: and then some
> (1 filas)
> 
> And wrapped:
> 
> alvherre=# select * from foo;
>  a │ b
>   
> ━━━┿
>  5 │ En un lugar de la Mancha, de cuyo nombre no quiero acordarme, no ha 
> mucho 
>; tiempo que vivía un hidalgo
> (1 fila)

I initially left these exactly the same as for ASCII (the ':' and ';'
usage).  However, it's quite possible to make it use other characters.
We could use the same lines, or two, three or four dashed lines
('╎' and '╏', or ┆' and '┇' or '┊' and '┋').
There are also additional characters such as half-lines
('╶', '╷', '╹' and '╻').  Is this the kind of this you are referring
to?

The wrapping code also appears slightly broken anyway, since
continuation lines don't get '|' printed for subsequent blank columns
on the same line:

# SELECT * FROM testw;
 a │  b  │ c │ kfduagahkjdfghalksdkfhajsdkl 
━━━┿━┿━━━┿━━
 1 │ This is a test stri │   │  
   ; ng
 2 │ sbuild-createchroot │   │
   ;  installs build-ess
   ; entials so your wor
   ; king
 3 │ sbuild-createchroot │   │
   ;  installs build-ess
   ; entials so your wor
   ; king environment sh
   ; ould already be ok.
   ;  You will need only
   ;  to add a few more
   ; packages in the chr
   ; oot, using e.g.
(3 rows)

(this is unchanged from psql behaviour in CVS.)

I also see in the code that under some circumstances (curr_nl_line), a
'+' is used instead of a space when printing table headers, but I
haven't been able to trigger this yet.  We could also use dashed
horizontal rules here.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: [HACKERS] Build system problem in 8.3.x

[Heikki Linnakangas]

Boszormenyi Zoltan wrote:
> we have come across a problem in 8.3.x (8.3.5 and 8.3.7 was tested)
> while building PostgreSQL for 32-bit on 64-bit RHEL5 and Fedora 9.
> 
> The following defines were used before running configure:
> 
> export CFLAGS="-m32"
> export LD="ld -melf_i386"
> 
> The above are needed because when SUBSYS.o files are created,
> the $(LD) ... lines don't contain $(LDFLAGS) anywhere, so overriding
> $(LD) on the command line has to be done instead.
> 
> However, there's one additional problem that can be solved by the
> attached one liner. The problem is that during building the core,
> something (test/regress) requires contrib/spi/refint.so to be built.

If you're willing to override $(LD), seems you could get around that
additional problem by overriding $(CC) as well:

export CC="$(CC) -m32"
export LD="ld -melf_i386"

> *** src/Makefile.port.old 2009-08-27 10:56:46.0 +0200
> --- src/Makefile.port 2009-08-27 10:56:46.0 +0200
> ***
> *** 11,16 
>   endif
>   
>   %.so: %.o
> ! $(CC) -shared -o $@ $<
>   
>   sqlmansect = 7
> --- 11,16 
>   endif
>   
>   %.so: %.o
> ! $(CC) $(CFLAGS) -shared -o $@ $<
>   
>   sqlmansect = 7

I guess we should change that rule to use $(LD) instead of $(CC), and
include $(LDFLAGS) in the rules that build SUBSYS.o. Or maybe there's a
reason they are what they are, I don't know. (SUBSYS.o's are gone in 8.4
anyway)

-- 
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.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] MySQL Compatibility WAS: 8.5 release timetable, again

[Boszormenyi Zoltan]

Tom Lane írta:
> Greg Stark  writes:
>   
>> Actually it always bothered me that we don't have implicit casts from
>> integer->boolean. I can't see any ambiguity or unintentional effects
>> this would cause problems with. Am I missing something?
>> 
>
> Personally, as an old Pascal-lover, I always thought that C's failure
> to distinguish between int and boolean was the single biggest design
> mistake in the language.

On the other hand, the first two programming languages I have learnt
was Sinclair ZX Spectrum BASIC and Z80 assembly,
I welcomed C being so near to assembly... :-)

>   I'm very glad that SQL doesn't make that
> mistake, and I don't want to go against the standard to introduce it.
>   

In that we agree. SQL is not C.

Best regards,
Zoltán Böszörményi

-- 
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] MySQL Compatibility WAS: postgresql.conf settings autoconfiguration

[Jean-Michel Pouré]

Dear all,

Just a quick message about postgresql.conf auto-configuration.

When MySQL users test PostgreSQL, they load their data and run simple
SQL queries. If postgresql.conf is configured with default values, it
may produce slow results. 

Would there be a way for postgresql.conf to auto configure?

This is how MySQL works. Nothing is configurable. And people love it. So
why not implement a simple auto configuration mechanism which would set
basic parameters.

Example
autotune=true;
autotune_profile='web site';
autotune_profile='dedicated SQL server';

...

Kind regards,
Jean-Michel



signature.asc
Description: Ceci est une partie de message numériquement signée

[HACKERS] Patches for static check on geo_ops.c

[Paul Matthews]

Grzegorz Jaskiewicz wonderful static checker coughed up 5 errors in
geo_ops.c.  None of them of any particular excitement or of earth
shattering nature. A patch is attached below that should correct these.
(The more little issue we eliminate, the more the large ones will stand
out.)

At line 3131 value stored into 'dist' variable is never referenced again.
At line 3014 value stored into 'dist' variable is never referenced again.
At line 2942 value stored into 'd' variable is never referenced again.
At line 2953 value stored into 'd' variable is never referenced again.
At line 2993 value stored into 'd' variable is never referenced again.


? patchfile_clang
Index: src/backend/utils/adt/geo_ops.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/adt/geo_ops.c,v
retrieving revision 1.103
diff -c -r1.103 geo_ops.c
*** src/backend/utils/adt/geo_ops.c 28 Jul 2009 09:47:59 -  1.103
--- src/backend/utils/adt/geo_ops.c 27 Aug 2009 09:31:30 -
***
*** 2939,2945 
memcpy(&point, &l1->p[1], sizeof(Point));
}
  
!   if ((d = dist_ps_internal(&l2->p[0], l1)) < dist)
{
result = DatumGetPointP(DirectFunctionCall2(close_ps,

PointPGetDatum(&l2->p[0]),
--- 2939,2945 
memcpy(&point, &l1->p[1], sizeof(Point));
}
  
!   if (dist_ps_internal(&l2->p[0], l1) < dist)
{
result = DatumGetPointP(DirectFunctionCall2(close_ps,

PointPGetDatum(&l2->p[0]),
***
*** 2950,2956 

LsegPGetDatum(l2)));
}
  
!   if ((d = dist_ps_internal(&l2->p[1], l1)) < dist)
{
result = DatumGetPointP(DirectFunctionCall2(close_ps,

PointPGetDatum(&l2->p[1]),
--- 2950,2956 

LsegPGetDatum(l2)));
}
  
!   if (dist_ps_internal(&l2->p[1], l1) < dist)
{
result = DatumGetPointP(DirectFunctionCall2(close_ps,

PointPGetDatum(&l2->p[1]),
***
*** 2990,2996 
point.x = box->low.x;
point.y = box->high.y;
statlseg_construct(&lseg, &box->low, &point);
!   dist = d = dist_ps_internal(pt, &lseg);
  
statlseg_construct(&seg, &box->high, &point);
if ((d = dist_ps_internal(pt, &seg)) < dist)
--- 2990,2996 
point.x = box->low.x;
point.y = box->high.y;
statlseg_construct(&lseg, &box->low, &point);
!   dist = dist_ps_internal(pt, &lseg);
  
statlseg_construct(&seg, &box->high, &point);
if ((d = dist_ps_internal(pt, &seg)) < dist)
***
*** 3011,3017 
statlseg_construct(&seg, &box->high, &point);
if ((d = dist_ps_internal(pt, &seg)) < dist)
{
-   dist = d;
memcpy(&lseg, &seg, sizeof(lseg));
}
  
--- 3011,3016 
***
*** 3128,3134 
statlseg_construct(&seg, &box->high, &point);
if ((d = lseg_dt(lseg, &seg)) < dist)
{
-   dist = d;
memcpy(&bseg, &seg, sizeof(bseg));
}
  
--- 3127,3132 

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

[HACKERS] Build system problem in 8.3.x

[Boszormenyi Zoltan]

Hi,

we have come across a problem in 8.3.x (8.3.5 and 8.3.7 was tested)
while building PostgreSQL for 32-bit on 64-bit RHEL5 and Fedora 9.

The following defines were used before running configure:

export CFLAGS="-m32"
export LD="ld -melf_i386"

The above are needed because when SUBSYS.o files are created,
the $(LD) ... lines don't contain $(LDFLAGS) anywhere, so overriding
$(LD) on the command line has to be done instead.

However, there's one additional problem that can be solved by the
attached one liner. The problem is that during building the core,
something (test/regress) requires contrib/spi/refint.so to be built.
The error follows:

make -C ../../../contrib/spi refint.so autoinc.so
make[3]: Entering directory
`/home/zozo/Schönig-számlák/lucent/postgresql-8.3.5/contrib/spi'
gcc -m32 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
-Wdeclaration-after-statement
-Wendif-labels -fno-strict-aliasing -fwrapv -fpic -DREFINT_VERBOSE -I.
-I../../src/include
-D_GNU_SOURCE   -c -o refint.o refint.c
gcc -shared -o refint.so refint.o
/usr/bin/ld: i386 architecture of input file `refint.o' is incompatible
with i386:x86-64 output

I tried building contrib manually, but it turned out that the same
error happens whenever contrib/*/Makefile contains MODULES
instead of MODULE_big.

I modified Makefile.port in the attached patch, and now
all the contrib files also build correctly.

Best regards,
Zoltán Böszörményi

-- 
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/

*** src/Makefile.port.old	2009-08-27 10:56:46.0 +0200
--- src/Makefile.port	2009-08-27 10:56:46.0 +0200
***
*** 11,16 
  endif
  
  %.so: %.o
! 	$(CC) -shared -o $@ $<
  
  sqlmansect = 7
--- 11,16 
  endif
  
  %.so: %.o
! 	$(CC) $(CFLAGS) -shared -o $@ $<
  
  sqlmansect = 7

-- 
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] MySQL Compatibility WAS: 8.5 release timetable, again

[Tino Wildenhain]

Tom Lane wrote:

Greg Stark  writes:

Actually it always bothered me that we don't have implicit casts from
integer->boolean. I can't see any ambiguity or unintentional effects
this would cause problems with. Am I missing something?


Personally, as an old Pascal-lover, I always thought that C's failure
to distinguish between int and boolean was the single biggest design
mistake in the language.  I'm very glad that SQL doesn't make that
mistake, and I don't want to go against the standard to introduce it.


Then you should love Python where everything non-empty is regarded True
in boolean context ;-)

Cheers
Tino


smime.p7s
Description: S/MIME Cryptographic Signature