Re: [HACKERS] pgkill on win32

[James Mansion]

Magnus Hagander wrote:
The problem is when winsock operations are interrupted by APCs. 


See:
http://archives.postgresql.org/pgsql-hackers-win32/2004-04/msg00013.php
  
Whoa! Indeed, that's a bit sucky because they really aren't documented 
as interruptible.


In this case though I see not material problem with going back to APCs.  
At the moment you
deliver to a pipe server thread with a pipe RPC.  I can't see why you 
cannot deliver to a
signal handling thread with the APC - the published {thread-id,function} 
tuple does not need
to refer to the main thread for the process. This would de-synchronize 
the delivery but make
a relatively small change since that background thread could deliver to 
the main thread the

same way it does now.

If there were any desire to provide a MT-aware postmaster, the same 
technique of masking

signals except on a signal thread might apply.

James


--
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] Can't start psql

[Zdenek Kotala]

Hello,

I don't have experience with windows installation, but try to look on 
pg_hba.conf setup. Else 8.1 is not recommended for windows. Please, use 8.3. And 
last comment is use pgsql-general for this kind of question.


Zdenek


王佳伟 napsal(a):

Hello!I have a problem with my postgresql. I install postgresql8.1 on windows xp with sp2 and get 
the error"could not connect to server: Connection refused (0x274D/10061)Is the server 
running on host "???" and accepting TCP/IP connections on port 5432?".I have stopped 
the windows firewall How can i check if this has been changed and change the configurations so that 
it works again.Thanks in advance!
_
用手机MSN聊天写邮件看空间，无限沟通，分享精彩！
http://mobile.msn.com.cn/




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

[HACKERS] Can't start psql

[王佳伟]

Hello!I have a problem with my postgresql. I install postgresql8.1 on windows 
xp with sp2 and get the error"could not connect to server: Connection refused 
(0x274D/10061)Is the server running on host "???" and accepting TCP/IP 
connections on port 5432?".I have stopped the windows firewall How can i check 
if this has been changed and change the configurations so that it works 
again.Thanks in advance!
_
用手机MSN聊天写邮件看空间，无限沟通，分享精彩！
http://mobile.msn.com.cn/

Re: [HACKERS] MERGE Specification

[Gregory Stark]

"Simon Riggs" <[EMAIL PROTECTED]> writes:

> Unrelated to rule processing, you did read the bit about MERGE and race
> conditions? ISTM that MERGE as it stands isn't very useful for anything
> other than large data loads since its going to cause problems if used
> concurrently.

If there are race conditions what advantage does it offer over writing plpgsql
or client code to do it?

I thought the whole advantage of having a built-in command is that it could do
the kind of locking our unique constraints do to avoid race conditions.


-- 
  Gregory Stark
  EnterpriseDB  http://www.enterprisedb.com
  Ask me about EnterpriseDB's On-Demand Production Tuning

-- 
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] MERGE Specification

[Alvaro Herrera]

Simon Riggs wrote:

> Unrelated to rule processing, you did read the bit about MERGE and race
> conditions? ISTM that MERGE as it stands isn't very useful for anything
> other than large data loads since its going to cause problems if used
> concurrently.

But that's how the committee designed it, yes?

-- 
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] MERGE Specification

[Simon Riggs]

On Mon, 2008-04-21 at 20:28 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Mon, 2008-04-21 at 16:38 -0400, A.M. wrote:
> >> "MERGE will not invoke Rules." Does this imply that MERGE cannot be  
> >> used on views or that the resulting INSERTs or UPDATEs do not work on  
> >> views?
> 
> > Yes, that's right. Just like COPY.
> 
> I find this to be pretty ugly.  COPY is a special case because
> (a) it is a utility statement not a plannable one, and (b) its only
> reason to exist is to transfer data as fast as possible, so bypassing
> rules isn't an unreasonable restriction.  MERGE has neither of those
> properties, and thus arguing that it can or should be like COPY is an
> entirely unconvincing proposition. 

Unrelated to rule processing, you did read the bit about MERGE and race
conditions? ISTM that MERGE as it stands isn't very useful for anything
other than large data loads since its going to cause problems if used
concurrently.

-- 
  Simon Riggs
  2ndQuadrant  http://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] MERGE Specification

[Simon Riggs]

On Mon, 2008-04-21 at 20:28 -0400, Tom Lane wrote:

> In fact, I don't even want to think
> about what kind of crock you're going to need in order to get it through
> the planner without also going through the rewriter.

Hmmm, I hadn't thought I might be adding work rather than avoiding it.

I'll give it a go.

-- 
  Simon Riggs
  2ndQuadrant  http://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] MERGE Specification

[Tom Lane]

Simon Riggs <[EMAIL PROTECTED]> writes:
> On Mon, 2008-04-21 at 16:38 -0400, A.M. wrote:
>> "MERGE will not invoke Rules." Does this imply that MERGE cannot be  
>> used on views or that the resulting INSERTs or UPDATEs do not work on  
>> views?

> Yes, that's right. Just like COPY.

I find this to be pretty ugly.  COPY is a special case because
(a) it is a utility statement not a plannable one, and (b) its only
reason to exist is to transfer data as fast as possible, so bypassing
rules isn't an unreasonable restriction.  MERGE has neither of those
properties, and thus arguing that it can or should be like COPY is an
entirely unconvincing proposition.  (In fact, I don't even want to think
about what kind of crock you're going to need in order to get it through
the planner without also going through the rewriter.)

Please think a bit harder.

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] Problem with server/utils/snapmgr.h

[Tom Lane]

Chris Browne <[EMAIL PROTECTED]> writes:
> I tried adding an autoconf rule to Slony-I to check for its existence
> (goal then is to do a suitable #define so that we can #ifdef the
> #include, so that we #include this only with versions of PostgreSQL
> that have the file).

The customary way of handling Postgres version differences at
compilation time has been something like

#include "catalog/catversion.h"
#if CATALOG_VERSION_NO >= 200804201
... new code ...
#else
... old code ...
#endif

Seems to me that would do just fine and you don't need autoconf help.

I concur with Alvaro's comment that you're probably wasting your time
to do anything touching snapmgr.h right now, but if you must ...

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] MERGE Specification

[Simon Riggs]

On Mon, 2008-04-21 at 16:38 -0400, A.M. wrote:

> "MERGE will not invoke Rules." Does this imply that MERGE cannot be  
> used on views or that the resulting INSERTs or UPDATEs do not work on  
> views?

Yes, that's right. Just like COPY. That seems fine to me because you're
likely to be doing a MERGE immediately after a COPY anyway, so the
restriction just continues.

Rules for Insert, Update and Delete are almost identical to the way
MERGE works anyway, so there's no particular loss of functionality. That
was why I co-opted the ability to DO NOTHING in a WHEN clause from the
way PostgreSQL Rules work.

I'm not taking any explicit decisions to exclude them permanently. I do
think its possible that we could support them and possibly very cheaply,
but I wouldn't make any promises initially.

-- 
  Simon Riggs
  2ndQuadrant  http://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] Problem with server/utils/snapmgr.h

[Alvaro Herrera]

Chris Browne wrote:

> If I use:
>   AC_CHECK_HEADER(utils/snapmgr.h, HAVE_SNAPMGR=1)
> 
> this turns out to fail.  Apparently autoconf wants to compile the
> #include file to validate that it's an OK #include file.
> 
> GCC barfs on it, thus:
> 
> [EMAIL PROTECTED]:~/Slony-I/CMD/slony1-HEAD> gcc 
> -I/opt/OXRS/dbs/pgsql84-beta/include/server 
> /opt/OXRS/dbs/pgsql84-beta/include/server/utils/snapmgr.h
> In file included from 
> /opt/OXRS/dbs/pgsql84-beta/include/server/storage/itemptr.h:17,
>  from 
> /opt/OXRS/dbs/pgsql84-beta/include/server/access/htup.h:17,
>  from 
> /opt/OXRS/dbs/pgsql84-beta/include/server/utils/snapshot.h:16,
>  from 
> /opt/OXRS/dbs/pgsql84-beta/include/server/utils/tqual.h:18,
>  from 
> /opt/OXRS/dbs/pgsql84-beta/include/server/utils/snapmgr.h:16:


Hmm.  It works for me if I forcefully include postgres.h:

gcc -I/pgsql/install/00head/include/server -include postgres.h 
/pgsql/install/00head/include/server/utils/snapmgr.h 

Our header file rule says that a header must include any header it needs
to compile, but never include postgres.h, which must be the first
include in all the .c files.

So I'm not sure the fix for this.

What does Slony-I need snapmgr.h for, anyway?  This code is in a state
of a flux right now -- there are pending patches which are likely to
change the horizon a bit.  Perhaps it does not make sense for Slony to
adjust to a state that's expected to be short-lived.

-- 
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] MERGE Specification

[A.M.]

On Apr 21, 2008, at 4:08 PM, Simon Riggs wrote:

The following two files specify the behaviour of the MERGE statement  
and
how it will work in the world of PostgreSQL. In places, this  
supercedes

my recent commentary on MERGE, particularly with regard to triggers.

Neither of these files is intended for CVS.

The HTML file was generated from SGML source, though the latter is not
included here for clarity.

The test file shows how I expect a successful test run to look when a
regression test is executed with a working version of final MERGE  
patch

applied. It has behavioural comments in it also, to make it slightly
more readable.

If anybody has any questions, ask them now please, before I begin
detailed implementation.



"MERGE will not invoke Rules." Does this imply that MERGE cannot be  
used on views or that the resulting INSERTs or UPDATEs do not work on  
views?


Cheers,
M

--
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] TODO, FAQs to Wiki?

[Tino Wildenhain]

Joshua D. Drake wrote:

On Mon, 21 Apr 2008 19:06:53 +0200
Tino Wildenhain <[EMAIL PROTECTED]> wrote:
 

Well... or reStructuredText which has the advantage of beeing human
editable? (without specialized editor that is)


Huh? How is XML not human editable... didn't you ever create webpages
in vi? :)


You know, I used a butterfly... there is even an emacs macro for it .-)

Cheers
Tino

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

[HACKERS] Problem with server/utils/snapmgr.h

[Chris Browne]

There's a new #include file that it turns out we need for Slony-I to
reference, namely include/server/utils/snapmgr.h

I tried adding an autoconf rule to Slony-I to check for its existence
(goal then is to do a suitable #define so that we can #ifdef the
#include, so that we #include this only with versions of PostgreSQL
that have the file).

If I use:
  AC_CHECK_HEADER(utils/snapmgr.h, HAVE_SNAPMGR=1)

this turns out to fail.  Apparently autoconf wants to compile the
#include file to validate that it's an OK #include file.

GCC barfs on it, thus:

[EMAIL PROTECTED]:~/Slony-I/CMD/slony1-HEAD> gcc 
-I/opt/OXRS/dbs/pgsql84-beta/include/server 
/opt/OXRS/dbs/pgsql84-beta/include/server/utils/snapmgr.h
In file included from 
/opt/OXRS/dbs/pgsql84-beta/include/server/storage/itemptr.h:17,
 from 
/opt/OXRS/dbs/pgsql84-beta/include/server/access/htup.h:17,
 from 
/opt/OXRS/dbs/pgsql84-beta/include/server/utils/snapshot.h:16,
 from 
/opt/OXRS/dbs/pgsql84-beta/include/server/utils/tqual.h:18,
 from 
/opt/OXRS/dbs/pgsql84-beta/include/server/utils/snapmgr.h:16:
/opt/OXRS/dbs/pgsql84-beta/include/server/storage/block.h:31: error: expected 
'=', ',', ';', 'asm' or '__attribute__' before 'BlockNumber'
/opt/OXRS/dbs/pgsql84-beta/include/server/storage/block.h:55: error: expected 
specifier-qualifier-list before 'uint16'
In file included from 
/opt/OXRS/dbs/pgsql84-beta/include/server/storage/off.h:17,
 from 
/opt/OXRS/dbs/pgsql84-beta/include/server/storage/itemptr.h:18,
 from 
/opt/OXRS/dbs/pgsql84-beta/include/server/access/htup.h:17,
 from 
/opt/OXRS/dbs/pgsql84-beta/include/server/utils/snapshot.h:16,
 from 
/opt/OXRS/dbs/pgsql84-beta/include/server/utils/tqual.h:18,
 from 
/opt/OXRS/dbs/pgsql84-beta/include/server/utils/snapmgr.h:16:
/opt/OXRS/dbs/pgsql84-beta/include/server/storage/itemid.h:46: error: expected 
'=', ',', ';', 'asm' or '__attribute__' before 'ItemOffset'
/opt/OXRS/dbs/pgsql84-beta/include/server/storage/itemid.h:47: error: expected 
'=', ',', ';', 'asm' or '__attribute__' before 'ItemLength'
In file included from 
/opt/OXRS/dbs/pgsql84-beta/include/server/storage/itemptr.h:18,
 from 
/opt/OXRS/dbs/pgsql84-beta/include/server/access/htup.h:17,
 from 
/opt/OXRS/dbs/pgsql84-beta/include/server/utils/snapshot.h:16,
 from 
/opt/OXRS/dbs/pgsql84-beta/include/server/utils/tqual.h:18,
 from 
/opt/OXRS/dbs/pgsql84-beta/include/server/utils/snapmgr.h:16:
/opt/OXRS/dbs/pgsql84-beta/include/server/storage/off.h:24: error: expected 
'=', ',', ';', 'asm' or '__attribute__' before 'OffsetNumber'
In file included from 
/opt/OXRS/dbs/pgsql84-beta/include/server/access/htup.h:17,
 from 
/opt/OXRS/dbs/pgsql84-beta/include/server/utils/snapshot.h:16,
 from 
/opt/OXRS/dbs/pgsql84-beta/include/server/utils/tqual.h:18,
 from 
/opt/OXRS/dbs/pgsql84-beta/include/server/utils/snapmgr.h:16:
/opt/OXRS/dbs/pgsql84-beta/include/server/storage/itemptr.h:40: error: expected 
specifier-qualifier-list before 'OffsetNumber'
/opt/OXRS/dbs/pgsql84-beta/include/server/storage/itemptr.h:143: error: 
expected '=', ',', ';', 'asm' or '__attribute__' before 'ItemPointerEquals'
/opt/OXRS/dbs/pgsql84-beta/include/server/storage/itemptr.h:144: error: 
expected '=', ',', ';', 'asm' or '__attribute__' before 'ItemPointerCompare'
In file included from 
/opt/OXRS/dbs/pgsql84-beta/include/server/access/htup.h:18,
 from 
/opt/OXRS/dbs/pgsql84-beta/include/server/utils/snapshot.h:16,
 from 
/opt/OXRS/dbs/pgsql84-beta/include/server/utils/tqual.h:18,
 from 
/opt/OXRS/dbs/pgsql84-beta/include/server/utils/snapmgr.h:16:
/opt/OXRS/dbs/pgsql84-beta/include/server/storage/relfilenode.h:44: error: 
expected specifier-qualifier-list before 'Oid'
In file included from 
/opt/OXRS/dbs/pgsql84-beta/include/server/utils/snapshot.h:16,
 from 
/opt/OXRS/dbs/pgsql84-beta/include/server/utils/tqual.h:18,
 from 
/opt/OXRS/dbs/pgsql84-beta/include/server/utils/snapmgr.h:16:
/opt/OXRS/dbs/pgsql84-beta/include/server/access/htup.h:106: error: expected 
specifier-qualifier-list before 'TransactionId'
/opt/OXRS/dbs/pgsql84-beta/include/server/access/htup.h:118: error: expected 
specifier-qualifier-list before 'int32'
/opt/OXRS/dbs/pgsql84-beta/include/server/access/htup.h:142: error: expected 
specifier-qualifier-list before 'uint16'
/opt/OXRS/dbs/pgsql84-beta/include/server/access/htup.h:442: error: expected 
specifier-qualifier-list before 'uint32'
/opt/OXRS/dbs/pgsql84-beta/include/server/access/htup.h:498: error: expected 
specifier-qualifier-list before 'uint32'
/opt/OXRS/dbs/pgsql84-beta/include/server/access/htup.h:623: error: expected 
specifier-qualifier-list before 'uint16'
/opt/OXRS/dbs/pgsql84-beta/include/server/access/htup.h:671:

Re: [HACKERS] TRUNCATE TABLE with IDENTITY

[Zoltan Boszormenyi]

Zoltan Boszormenyi írta:

Zoltan Boszormenyi írta:

Decibel! írta:

On Apr 3, 2008, at 12:52 AM, Zoltan Boszormenyi wrote:

Where is the info in the sequence to provide restarting with
the _original_ start value?


There isn't any. If you want the sequence to start at some magic 
value, adjust the minimum value.


There's the START WITH option for IDENTITY columns and this below
is paragraph 8 under General rules of 14.10 
in 6WD2_02_Foundation_2007-12.pdf (page 902):

8) If RESTART IDENTITY is specified and the table descriptor of T 
includes a column descriptor IDCD of

  an identity column, then:
  a) Let CN be the column name included in IDCD and let SV be the 
start value included in IDCD.
  b) The following  is effectively executed 
without further Access Rule checking:

  ALTER TABLE TN ALTER COLUMN CN RESTART WITH SV

This says that the original start value is used, not the minimum value.
IDENTITY has the same options as CREATE SEQUENCE. In fact the
"identity column specification" links to "11.63 definition>"

when it comes to IDENTITY sequence options. And surprise, surprise,
"11.64 " now defines
ALTER SEQUENCE sn RESTART [WITH newvalue]
where omitting the "WITH newval" part also uses the original start 
value.


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


Attached patch implements the extension found in the current SQL200n 
draft,
implementing stored start value and supporting ALTER SEQUENCE seq 
RESTART;
Some error check are also added to prohibit CREATE SEQUENCE ... 
RESTART ...

and ALTER SEQUENCE ... START ...

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


Updated patch implements TRUNCATE ... RESTART IDENTITY
which restarts all owned sequences for the truncated table(s).
Regression tests updated, documentation added. pg_dump was
also extended to output original[1] START value for creating SEQUENCEs.

[1] For 8.3 and below I could only guesstimate it as MINVALUE for ascending
 and MAXVALUE for descending sequences.

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

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



sql2008-compliant-seq-v2.patch.gz
Description: Unix tar 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] MERGE Specification

[Simon Riggs]

On Mon, 2008-04-21 at 22:18 +0200, Pavel Stehule wrote:

> would you support RETURNING clause?

I wouldn't rule it out completely, but not in the first implementation
because
- its more work
- its not in the SQL Standard
- neither Oracle nor DB2 support it either, so its only going to provide
incompatibility
- there are some wrinkles with MERGE that means I don't want to
over-complicate it because it looks to me like it will change in future
versions of the standard
- not sure what the use case for that will be

-- 
  Simon Riggs
  2ndQuadrant  http://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] MERGE Specification

[Pavel Stehule]

Hello Simon,

would you support RETURNING clause?

Regards
Pavel Stehule

On 21/04/2008, Simon Riggs <[EMAIL PROTECTED]> wrote:
> The following two files specify the behaviour of the MERGE statement and
>  how it will work in the world of PostgreSQL. In places, this supercedes
>  my recent commentary on MERGE, particularly with regard to triggers.
>
>  Neither of these files is intended for CVS.
>
>  The HTML file was generated from SGML source, though the latter is not
>  included here for clarity.
>
>  The test file shows how I expect a successful test run to look when a
>  regression test is executed with a working version of final MERGE patch
>  applied. It has behavioural comments in it also, to make it slightly
>  more readable.
>
>  If anybody has any questions, ask them now please, before I begin
>  detailed implementation.
>
>
>  --
>   Simon Riggs
>   2ndQuadrant  http://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
>
>
>

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

[HACKERS] WIP: psql default banner patch

[Joshua D. Drake]

Hello,

Attached is a patch for the default message from psql. Couple of things
of note:

1. I removed the force wrapping, instead allowing the terminal to do
it. This seems to work in X and well as on the console. I am not sure
if I like this or not and am not opposed to changing to a forced wrap.

2. I significantly reduced the wording making the intro more of a
notice than a welcome message.

3. I added a new line to help.c which stands for Execution. I read
the \? help three times before finding \g in the Query Buffer section.
That doesn't seem to me to be a good sign. I left the \g in Query
Buffer as well (yes its redundant) because it shows other options for
use with \g.

Please let me know what you think.

Sincerely,

Joshau D. Drake

-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate


? psql-Log
? psql_patch.diff
Index: help.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/psql/help.c,v
retrieving revision 1.126
diff -c -r1.126 help.c
*** help.c	4 Apr 2008 18:00:25 -	1.126
--- help.c	21 Apr 2008 20:11:06 -
***
*** 168,173 
--- 168,175 
  	 * if this " is the start of the string then it ought to end there to fit
  	 * in 80 columns >> "
  	 */
+ 	fprintf(output, _("Execution\n"));
+ 	fprintf(output, _("  \\g or ;	 execute query\n\n"));
  	fprintf(output, _("General\n"));
  	fprintf(output, _("  \\c[onnect] [DBNAME|- USER|- HOST|- PORT|-]\n"
  			" connect to new database (currently \"%s\")\n"),
Index: startup.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/psql/startup.c,v
retrieving revision 1.146
diff -c -r1.146 startup.c
*** startup.c	1 Jan 2008 19:45:56 -	1.146
--- startup.c	21 Apr 2008 20:11:06 -
***
*** 315,340 
  	server_version = server_ver_str;
  }
  
! printf(_("Welcome to %s %s (server %s), the PostgreSQL interactive terminal.\n\n"),
! 	   pset.progname, PG_VERSION, server_version);
  			}
  			else
! printf(_("Welcome to %s %s, the PostgreSQL interactive terminal.\n\n"),
  	   pset.progname, PG_VERSION);
  
! 			printf(_("Type:  \\copyright for distribution terms\n"
! 	 "   \\h for help with SQL commands\n"
! 	 "   \\? for help with psql commands\n"
!   "   \\g or terminate with semicolon to execute query\n"
! 	 "   \\q to quit\n\n"));
! 
! 			if (pset.sversion / 100 != client_ver / 100)
! printf(_("WARNING:  You are connected to a server with major version %d.%d,\n"
! 		 "but your %s client is major version %d.%d.  Some backslash commands,\n"
! 		 "such as \\d, might not work properly.\n\n"),
! 	   pset.sversion / 1, (pset.sversion / 100) % 100,
! 	   pset.progname,
! 	   client_ver / 1, (client_ver / 100) % 100);
  
  #ifdef USE_SSL
  			printSSLInfo();
--- 315,332 
  	server_version = server_ver_str;
  }
  
! printf(_("\n%s %s"),
! 	   pset.progname, PG_VERSION);
! 	   if (pset.sversion / 100 != client_ver / 100)
! printf(_(", WARNING: server version %d.%d, client version %d.%d. Some features may not work.\n\n"),
! 	   pset.sversion / 1, (pset.sversion / 100) % 100,
! 	   client_ver / 1, (client_ver / 100) % 100);
  			}
  			else
! printf(_("\nWelcome to %s %s, the PostgreSQL interactive terminal.\n\n"),
  	   pset.progname, PG_VERSION);
  
! 			printf(_("Type:  \\help or for SQL help, \\? for psql help\n\n"));
  
  #ifdef USE_SSL
  			printSSLInfo();

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

[HACKERS] MERGE Specification

[Simon Riggs]

The following two files specify the behaviour of the MERGE statement and
how it will work in the world of PostgreSQL. In places, this supercedes
my recent commentary on MERGE, particularly with regard to triggers.

Neither of these files is intended for CVS. 

The HTML file was generated from SGML source, though the latter is not
included here for clarity.

The test file shows how I expect a successful test run to look when a
regression test is executed with a working version of final MERGE patch
applied. It has behavioural comments in it also, to make it slightly
more readable.

If anybody has any questions, ask them now please, before I begin
detailed implementation.

-- 
  Simon Riggs
  2ndQuadrant  http://www.2ndQuadrant.com
--
-- MERGE
--
CREATE TABLE target (id integer, balance integer);
CREATE TABLE source (id integer, balance integer);
INSERT INTO target VALUES (1, 10);
INSERT INTO target VALUES (2, 20);
INSERT INTO target VALUES (3, 30);
SELECT * FROM target;
 id | balance 
+-
  1 |  10
  2 |  20
  3 |  30
(3 rows)

--
-- initial tests
--
-- empty source means 0 rows touched
MERGE into target t
USING (select * from source) AS s
ON t.id = s.id
WHEN MATCHED THEN
	UPDATE SET balance = t.balance + s.balance
;
-- insert some source rows to work from
INSERT INTO source VALUES (2, 5);
INSERT INTO source VALUES (3, 20);
INSERT INTO source VALUES (4, 40);
SELECT * FROM source;
 id | balance 
+-
  2 |   5
  3 |  20
  4 |  40
(3 rows)

-- do a simple equivalent of an UPDATE join
BEGIN;
MERGE into target t
USING (select * from source) AS s
ON t.id = s.id
WHEN MATCHED THEN
	UPDATE SET balance = t.balance + s.balance
;
SELECT * FROM target;
 id | balance 
+-
  1 |  10
  2 |  25
  3 |  50
(3 rows)

ROLLBACK;
-- do a simple equivalent of an INSERT SELECT
BEGIN;
MERGE into target t
USING (select * from source) AS s
ON t.id = s.id
WHEN NOT MATCHED THEN
	INSERT VALUES (s.id, s.balance)
;
SELECT * FROM target;
 id | balance 
+-
  1 |  10
  2 |  20
  3 |  30
  4 |  40
(4 rows)

ROLLBACK;
-- now the classic UPSERT
BEGIN;
MERGE into target t
USING (select * from source) AS s
ON t.id = s.id
WHEN MATCHED THEN
	UPDATE SET balance = t.balance + s.balance
WHEN NOT MATCHED THEN
	INSERT VALUES (s.id, s.balance)
;
SELECT * FROM target;
 id | balance 
+-
  1 |  10
  2 |  25
  3 |  50
  4 |  40
(4 rows)

ROLLBACK;
--
-- Non-standard functionality
-- 
-- do a simple equivalent of a DELETE join
BEGIN;
MERGE into target t
USING (select * from source) AS s
ON t.id = s.id
WHEN MATCHED THEN
	DELETE
;
SELECT * FROM target;
 id | balance 
+-
  1 |  10
(1 row)

ROLLBACK;
-- now the classic UPSERT, with a DELETE
-- the Standard doesn't allow the DELETE clause for some reason,
-- though other implementations do
BEGIN;
MERGE into target t
USING (select * from source) AS s
ON t.id = s.id
WHEN MATCHED AND s.balance > 10 THEN
	UPDATE SET balance = t.balance + s.balance
WHEN MATCHED THEN
	DELETE
WHEN NOT MATCHED THEN
	INSERT VALUES (s.id, s.balance)
;
SELECT * FROM target;
 id | balance 
+-
  1 |  10
  3 |  50
  4 |  40
(3 rows)

ROLLBACK;
-- Prepare the test data to generate multiple matching rows for a single target
INSERT INTO source VALUES (3, 5);
SELECT * FROM source ORDER BY id, balance;
 id | balance 
+-
  2 |   5
  3 |   5
  3 |  20
  4 |  40
(4 rows)

-- we now have a duplicate key in source, so when we join to
-- target we will generate 2 matching rows, not one
-- In the following statement row id=3 will be both updated
-- and deleted by this statement and so will cause a run-time error
-- when the second change to that row is detected
-- This next SQL statement
--  fails according to standard
--  fails in PostgreSQL implementation
BEGIN;
MERGE into target t
USING (select * from source) AS s
ON t.id = s.id
WHEN MATCHED AND s.balance > 10 THEN
	UPDATE SET balance = t.balance + s.balance
WHEN MATCHED THEN
	DELETE
WHEN NOT MATCHED THEN
	INSERT VALUES (s.id, s.balance)
;
ERROR:  multiple actions on single target row
 
ROLLBACK;

-- This next SQL statement
--  fails according to standard
--  suceeds in PostgreSQL implementation by simply ignoring the second
--  matching row since it activates no WHEN clause
BEGIN;
MERGE into target t
USING (select * from source) AS s
ON t.id = s.id
WHEN MATCHED AND s.balance > 10 THEN
	UPDATE SET balance = t.balance + s.balance
WHEN NOT MATCHED THEN
	INSERT VALUES (s.id, s.balance)
;
ROLLBACK;
-- Now lets prepare the test data to generate 2 non-matching rows
DELETE FROM source WHERE id = 3 AND balance = 5;
INSERT INTO source VALUES (4, 5);
SELECT * FROM source;
 id | balance 
+-
  2 |   5
  3 |  20
  4 |   5
  4 |  40
(4 rows)

-- This next SQL statement
--  suceeds according to standard (yes, it is inconsistent)
--  suceeds in PostgreSQL implementation, though could easily fail if
--  t

Re: [HACKERS] Commitfest namespacing (was: TODO, FAQs to Wiki?)

[Alvaro Herrera]

Bruce Momjian escribió:
> Brendan Jurd wrote:
> > I wonder if we should namespace the CommitFest pages by year as well
> > as month (i.e., move CommitFest:May to CommitFest:May2008).  This way,
> > even after we've had a CommitFest:May in 2009/2010/etc., the history
> > of the May 2008 CommitFest will still be easily viewable as a discrete
> > item.
> 
> Yep, makes sense.  Actually you can use '2008-05' so they sort properly.

Perhaps we should add a category "commitfest" (already there) and then
subcategories "2008", "2009", etc.

-- 
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] Commitfest namespacing (was: TODO, FAQs to Wiki?)

[Bruce Momjian]

Brendan Jurd wrote:
> I wonder if we should namespace the CommitFest pages by year as well
> as month (i.e., move CommitFest:May to CommitFest:May2008).  This way,
> even after we've had a CommitFest:May in 2009/2010/etc., the history
> of the May 2008 CommitFest will still be easily viewable as a discrete
> item.

Yep, makes sense.  Actually you can use '2008-05' so they sort properly.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>http://momjian.us
  EnterpriseDB http://enterprisedb.com

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

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

Re: [HACKERS] port/thread.c and pthreads

[Bruce Momjian]

Magnus Hagander wrote:
> port/thread.c includes the pthreads header files, and contains a bunch
> of comments about pthreads - but there seems to be no code related to
> pthreads at all in the file. Am I missing something completely here? ;-)

Uh, those files are thread-safe/reentrant versions of libc functions.  I
don't think they need the pthread.h includes.  You want to try removing
those includes and see how the buildfarm behaves?

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>http://momjian.us
  EnterpriseDB http://enterprisedb.com

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

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

Re: [HACKERS] typedefs for indent

[Andrew Dunstan]

Bruce Momjian wrote:

Andrew Dunstan wrote:
  
So I continue to think the best way to generate a list will be to 
consolidate lists generated from the buildfarm which represents a wide 
variety of build scenarios.


Is anyone else looking at GNU indent to see if it has improved enough to 
meet our needs?



I am not going to be able to test GNU indent for a few months so I hope
someone else tests it sooner than that.

Just checking, but you remembered that GNU indent needs a typedef list
too, right?  Also, there are scripts in pgindent surrounding the indent
binary that should also be reviewed.

  


Right now I am addressing the very specific problem of coming up with a 
better typedef list to use with whatever indenter we use, given that it 
seems a task well suited to the buildfarm.


If I do get to looking at GNU indent it will be a way down the track for 
me too. In fact, this seems a task that might be well suited to someone 
who is not spending what time they have available for Postgres on 
hacking (currently I'm trying to remove bitrot from the column level 
privs patch).


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] get rid of psql welcome message

[Shane Ambler]

This idea may be taking it to the extreme but I thought I'd throw it out
there anyway as everyone seems to want something different. (well there
seems to be three variants that if all were available would keep most
people happy) This may be one way to please everyone.



What if the actual welcome message can be defined in the .psqlrc ?
Something along the lines of -

WELCOME_MESSAGE="Welcome to  - \n"

(or similar with tags available that will allow predefined info to be
inserted)

I also see with this path that there could be a configure option to
specify the default welcome text, I am thinking three options would keep
most happy without adjustment in .psqlrc

--default-welcome-message=[classic|short|oneline|"custom string"]

"custom string" would match the above setting options - classic would be
the default.


This could also give the option in .psqlrc of having -

WELCOME_MESSAGE=


From there you can customise the setting to what you want and even
across all machines in the office to match company policy (so to speak)
setting default .psqlrc file for new users etc.

Along that line maybe implement a way to have default welcome message
settings per server? psql retrieves the welcome settings upon server
connection. (as in psql requests it after connection - not returned with
the initial connection request) This would be the default that is
overridden by the local .psqlrc file.


--

Shane Ambler
pgSQL (at) Sheeky (dot) Biz

Get Sheeky @ http://Sheeky.Biz

--
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] typedefs for indent

[Bruce Momjian]

Andrew Dunstan wrote:
> So I continue to think the best way to generate a list will be to 
> consolidate lists generated from the buildfarm which represents a wide 
> variety of build scenarios.
> 
> Is anyone else looking at GNU indent to see if it has improved enough to 
> meet our needs?

I am not going to be able to test GNU indent for a few months so I hope
someone else tests it sooner than that.

Just checking, but you remembered that GNU indent needs a typedef list
too, right?  Also, there are scripts in pgindent surrounding the indent
binary that should also be reviewed.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>http://momjian.us
  EnterpriseDB http://enterprisedb.com

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

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

Re: [HACKERS] TODO, FAQs to Wiki?

[Tino Wildenhain]

Greg Smith wrote:

On Mon, 21 Apr 2008, Tino Wildenhain wrote:


Alvaro Herrera wrote:

I suggest we start an experiment with the FAQ in XML Docbook, which is
amenable to automatic processing, and move from there.


Well... or reStructuredText which has the advantage of beeing human
editable? (without specialized editor that is)


reST is a reasonable tool for building small documents, I don't use it 
because it really doesn't scale well to handle larger ones.  Given that 
the rest of the project is already committed to using Docbook for those 
larger documents, I think it's hard to justify the additional toolchain 
needed for reST processing just to make the FAQ a little easier to edit.


Haha, yes thats good no problem. I just looked as we can throw ideas
and so I did.

Greets
Tino

--
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] Regression test fails when BLCKSZ is 1kB

[Peter Eisentraut]

Am Montag, 21. April 2008 schrieb Tom Lane:
> That sounds like a pretty bad idea, since it would treat ordering
> differences as insignificant even when they aren't --- for example,
> an ordering difference in the output of a query that *has* an
> ORDER BY is usually a bug.

Well, we wouldn't treat ordering differences as OK, but we could print

foo ... FAILED (only ordering differences)

which might give a clue.

Then again, the effort to make this bulletproof might be more than continuing 
to field the occasional question about the issue.

-- 
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] Regression test fails when BLCKSZ is 1kB

[Pavan Deolasee]

On Mon, Apr 21, 2008 at 10:54 PM, Pavan Deolasee
<[EMAIL PROTECTED]> wrote:

>  Case 1.
>
>  Insert 100 records --- goes into block 1 .. 10
>  Delete 100 records
>  Insert 100 more records --- goes into 11 .. 20
>
>
>  Case 2.
>
>  Insert 100 records --- goes into block 1 .. 10
>  Delete 100 records
>  *Autovacuum triggers*
>  Insert 100 more records -- goes into block 1 .. 10
>

Its probably not a very neat example because in this simplistic case,
the ordering would still be same, but we can easily construct a
slightly complex example to prove the point.

Thanks,
Pavan

-- 
Pavan Deolasee
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] TODO, FAQs to Wiki?

[Peter Eisentraut]

Am Montag, 21. April 2008 schrieb Tino Wildenhain:
> Well... or reStructuredText which has the advantage of beeing human
> editable? (without specialized editor that is)

Well, there is also asciidoc, markdown, and various other wiki-like minimal 
markup formats.  All fine ideas, if we want to introduce a whole new toolset.

I will point out, however, that minimal markup formats only have minimal 
features.  Asciidoc for example has very poor and broken i18n support.  And I 
don't know whether markdown can actually support a FAQ structure.  
reStructuredText  might do better, but superficially it looks the same.

-- 
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] Regression test fails when BLCKSZ is 1kB

[Tom Lane]

Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Montag, 21. April 2008 schrieb Zdenek Kotala:
>> set work_mem = 64;
>> + ERROR:  64 is outside the valid range for parameter "work_mem" (256 ..
>> 2097151) -- Test bitmap-and.

> This should probably be fixed by using a unit specification on work_mem.  Do 
> you want to prepare a patch?

The problem is that guc.c enforces a lower limit of 8*BLCKSZ on the
work_mem setting.  Unless we add an explicit unit specifier for "blocks"
to GUC's vocabulary, there doesn't seem to be any way to name that value
in the SET command.  And it's not entirely clear that the SET would
still have the desired effect for this test, anyway, if it were getting
translated to 256K or more.

Another possible answer is to change the minimum to be just 64K always.
I'm not certain that it's really sensible to tie the minimum work_mem to
BLCKSZ --- I don't think we do anything where work_mem is controlling a
pool of page buffers, do we?

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] TODO, FAQs to Wiki?

[Greg Smith]

On Mon, 21 Apr 2008, Tino Wildenhain wrote:


Alvaro Herrera wrote:

I suggest we start an experiment with the FAQ in XML Docbook, which is
amenable to automatic processing, and move from there.


Well... or reStructuredText which has the advantage of beeing human
editable? (without specialized editor that is)


reST is a reasonable tool for building small documents, I don't use it 
because it really doesn't scale well to handle larger ones.  Given that 
the rest of the project is already committed to using Docbook for those 
larger documents, I think it's hard to justify the additional toolchain 
needed for reST processing just to make the FAQ a little easier to edit.


--
* Greg Smith [EMAIL PROTECTED] 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] Regression test fails when BLCKSZ is 1kB

[Pavan Deolasee]

On Mon, Apr 21, 2008 at 8:20 PM, Tom Lane <[EMAIL PROTECTED]> wrote:

>
>  No, the reason you don't see that is that plain VACUUM doesn't move
>  tuples around.
>

I know. But plain VACUUM can free up dead space which can be used for
subsequent updates/inserts and that can cause reordering. For example:

Case 1.

Insert 100 records --- goes into block 1 .. 10
Delete 100 records
Insert 100 more records --- goes into 11 .. 20


Case 2.

Insert 100 records --- goes into block 1 .. 10
Delete 100 records
*Autovacuum triggers*
Insert 100 more records -- goes into block 1 .. 10


Thanks,
Pavan

-- 
Pavan Deolasee
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] TODO, FAQs to Wiki?

[Alvaro Herrera]

Tino Wildenhain wrote:

> Well... or reStructuredText which has the advantage of beeing human
> editable? (without specialized editor that is)

Hmm, that sounds like an useful idea, I'll do some research.

-- 
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] TODO, FAQs to Wiki?

[Joshua D. Drake]

On Mon, 21 Apr 2008 19:06:53 +0200
Tino Wildenhain <[EMAIL PROTECTED]> wrote:
 
> Well... or reStructuredText which has the advantage of beeing human
> editable? (without specialized editor that is)

Huh? How is XML not human editable... didn't you ever create webpages
in vi? :)

Joshua D. Drake


-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: 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] Regression test fails when BLCKSZ is 1kB

[Tom Lane]

Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Montag, 21. April 2008 schrieb Martijn van Oosterhout:
>> I wonder if it would be feasable to, whenever a regression test fails
>> to sort both files and compare again. This should tell you if the
>> difference are *only* rearrangement automatically, without having to
>> eyeball the output.

> That sounds like it should be worth a try.

That sounds like a pretty bad idea, since it would treat ordering
differences as insignificant even when they aren't --- for example,
an ordering difference in the output of a query that *has* an
ORDER BY is usually a bug.

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] TODO, FAQs to Wiki?

[Tino Wildenhain]

Alvaro Herrera wrote:

Bruce Momjian wrote:

Alvaro Herrera wrote:



As far as I know, what the doc translators do is translate the SGML
files directly, which is as difficult and cumbersome as you can possibly
get.  I am in no way suggesting we do that for the FAQ.

What can we do to help people translate the docs?


I suggest we start an experiment with the FAQ in XML Docbook, which is
amenable to automatic processing, and move from there.


Well... or reStructuredText which has the advantage of beeing human
editable? (without specialized editor that is)

Greets
Tino

--
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] Commitfest namespacing (was: TODO, FAQs to Wiki?)

[Joshua D. Drake]

On Tue, 22 Apr 2008 02:54:16 +1000
"Brendan Jurd" <[EMAIL PROTECTED]> wrote:

> Being able to submit patches via a web form is one of the more obvious
> benefits of a real patch tracker.  I'm not aware of any way to
> accomplish this in mediawiki without resorting to some nasty script
> hackery.

We could probably put the form "in front" of mediawiki and have it
autocreate a new page under some other page etc...

But then again... there is already perfectly could tracking software
out there.

Joshua D. Drake

-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: 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] Commitfest namespacing (was: TODO, FAQs to Wiki?)

[Greg Smith]

On Tue, 22 Apr 2008, Brendan Jurd wrote:


I wonder if we should namespace the CommitFest pages by year as well
as month (i.e., move CommitFest:May to CommitFest:May2008).


This already came up on pgsql-www and as I just replied to over there, the 
current structure has some things I'd like to fix beyond just this (and 
there's a pending namespace vs. categories argument brewing there). 
That's the list where this sort of thing will get hashed out at.  Please 
come join so you can get sucke...err, volunteer to help out even more than 
you already have.


This way, even after we've had a CommitFest:May in 2009/2010/etc., the 
history of the May 2008 CommitFest will still be easily viewable as a 
discrete item.


There ultimately should be pages for "CommitFest:2008" and 
"CommitFest:8.4" that the Wiki generates itself.  I'd prefer not to see 
any band-aid changes made in this area that aren't thinking forward to 
address those as well.  Work on improving the structure for May instead 
like you've been doing, that's much more valuable right now IMHO.



We probably need to have the following redirects in place:
* CommitFest:Current (for reviewers)...


Ditto here.  I already intend to eliminate the CommitFest redirect you've 
put there already and replace it with a page listing the "Views" available 
one day, and I'd prefer not to see more of these floating around.


Redirects are designed to be a useful hack when a page gets removed or to 
handle common shortcuts/errors.  In general, if you're relying on them 
heavily for external navigation structure, you're probably not using the 
right tool for that sort of job.


--
* Greg Smith [EMAIL PROTECTED] 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] Commitfest namespacing (was: TODO, FAQs to Wiki?)

[Brendan Jurd]

On Tue, Apr 22, 2008 at 2:44 AM, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
>  Why not use a form for posting new patches that would automatically put it
> on the right page? (I have no idea if you can do that sort of thing using
> mediawiki - it's just what I would do if I were designing a patch submission
> system from scratch).
>

Well at that point you're basically talking about using a patch tracker =)

As a matter of fact, I'm hoping that managing commitfests via the wiki
will demonstrate what patch tracking can bring to the project, as well
as help illuminate what we would actually require from patch tracking
software.  There's been a lot of conjecture on that topic, but putting
the wiki into practice might give us some real empirical results to
mull over.

Being able to submit patches via a web form is one of the more obvious
benefits of a real patch tracker.  I'm not aware of any way to
accomplish this in mediawiki without resorting to some nasty script
hackery.

Cheers,
BJ

-- 
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] Regression test fails when BLCKSZ is 1kB

[Andrew Dunstan]

Peter Eisentraut wrote:

Am Montag, 21. April 2008 schrieb Martijn van Oosterhout:
  

I wonder if it would be feasable to, whenever a regression test fails
to sort both files and compare again. This should tell you if the
difference are *only* rearrangement automatically, without having to
eyeball the output.



That sounds like it should be worth a try.
  


I think we need first to identify cases where we don't care that much 
about output order. Teaching pg-regress the new check shouldn't be very 
hard.


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] TODO, FAQs to Wiki?

[Peter Eisentraut]

Am Montag, 21. April 2008 schrieb Alvaro Herrera:
> Yes, basically my answer is "we don't".  Currently there's no such thing
> as easy editing, and while I agree it would be good to have it, I don't
> have a solution for it.

I think easy editing and easy translating are sort of mutually exclusive with 
the tool set we have, unfortunately.  I personally don't think the wiki is 
the right place for the FAQ, as I have previously mentioned, and if 
translating is important, then it is certainly the wrong place.

It seems the logical place to keep the FAQ would be in the pgweb svn, in 
DocBook XML possibly.  Translations could be managed via the pgtranslation 
project.

-- 
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] Commitfest namespacing (was: TODO, FAQs to Wiki?)

[Andrew Dunstan]

Brendan Jurd wrote:

On Tue, Apr 22, 2008 at 1:38 AM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
  

Brendan Jurd escribió:
 > I wonder if we should namespace the CommitFest pages by year as well
 > as month (i.e., move CommitFest:May to CommitFest:May2008).  This way,
 > even after we've had a CommitFest:May in 2009/2010/etc., the history
 > of the May 2008 CommitFest will still be easily viewable as a discrete
 > item.

 Agreed -- this same idea occurred to me some days ago, but I then forgot
 it :-)  For now, it would be good to ensure that CommitFest:May is a
 redirect to May2008.  (I think it would make sense to have a
 CommitFest:Current redirect and perhaps CommitFest:Next.)




We may need to draw some kind of distinction between the "open"
commitfest (which is where developers should submit new patches) and
the "current" commitfest (which is where reviewers should be directing
their attention).

There'll be a substantial time period where the "open" and "current"
commitfests are the same thing, but, for example, when the May
commitfest closes for new submissions, it will still be the "current"
commitfest, but will no longer be the appropriate place for developers
to post their new patches (that will become July).

I've started thinking of a commitfest as moving through the following
stages in its lifetime:

 1. Future
 2. Open for submissions
 3. In progress (closed for submissions)
 4. Complete

We probably need to have the following redirects in place:

 * CommitFest:Current (for reviewers)
 * CommitFest:Open (for submitters)
 * CommitFest:Next

Suggestions for alternative (less ambiguous) nomenclature are welcome ...


  


Why not use a form for posting new patches that would automatically put 
it on the right page? (I have no idea if you can do that sort of thing 
using mediawiki - it's just what I would do if I were designing a patch 
submission system from scratch).


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] Regression test fails when BLCKSZ is 1kB

[Peter Eisentraut]

Am Montag, 21. April 2008 schrieb Martijn van Oosterhout:
> I wonder if it would be feasable to, whenever a regression test fails
> to sort both files and compare again. This should tell you if the
> difference are *only* rearrangement automatically, without having to
> eyeball the output.

That sounds like it should be worth a try.

-- 
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] Commitfest namespacing (was: TODO, FAQs to Wiki?)

[Brendan Jurd]

On Tue, Apr 22, 2008 at 1:38 AM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> Brendan Jurd escribió:
>  > I wonder if we should namespace the CommitFest pages by year as well
>  > as month (i.e., move CommitFest:May to CommitFest:May2008).  This way,
>  > even after we've had a CommitFest:May in 2009/2010/etc., the history
>  > of the May 2008 CommitFest will still be easily viewable as a discrete
>  > item.
>
>  Agreed -- this same idea occurred to me some days ago, but I then forgot
>  it :-)  For now, it would be good to ensure that CommitFest:May is a
>  redirect to May2008.  (I think it would make sense to have a
>  CommitFest:Current redirect and perhaps CommitFest:Next.)
>

We may need to draw some kind of distinction between the "open"
commitfest (which is where developers should submit new patches) and
the "current" commitfest (which is where reviewers should be directing
their attention).

There'll be a substantial time period where the "open" and "current"
commitfests are the same thing, but, for example, when the May
commitfest closes for new submissions, it will still be the "current"
commitfest, but will no longer be the appropriate place for developers
to post their new patches (that will become July).

I've started thinking of a commitfest as moving through the following
stages in its lifetime:

 1. Future
 2. Open for submissions
 3. In progress (closed for submissions)
 4. Complete

We probably need to have the following redirects in place:

 * CommitFest:Current (for reviewers)
 * CommitFest:Open (for submitters)
 * CommitFest:Next

Suggestions for alternative (less ambiguous) nomenclature are welcome ...

Cheers,
BJ

-- 
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] TODO, FAQs to Wiki?

[Chris Browne]

[EMAIL PROTECTED] (Bruce Momjian) writes:
> I am impressed at the state of the May wiki patch queue:
>
>   http://wiki.postgresql.org/wiki/CommitFest:May
>
> It is even tracking the psql wrap patch I am working on now.

Aside: I have made a few little changes that oughtn't be too
controversial:

1.  Added [[Category:CommitFest]] to all of the pages that are
related, thus generating a central 'index page' about this.



This makes it unnecessary to have so many direct interlinks between
the commitfests.

2.  Added a = CommitFest (March|May) 2008 = header to the respective
Fests, as it is not inconceivable that there might be a
"CommitFest:May2009" or "CommitFest:March2010".

I think I want to learn a bit more about this "templating" thing, used
in the May 'fest; that looks like that might be a real good way to
simplify some of the wiki work we're doing internally.  Seems like a
slick, slick way to make it easier to build pretty structures whilst
avoiding hard-coding tables.  I'm getting more and more impressed at
MediaWiki...
-- 
let name="cbbrowne" and tld="cbbrowne.com" in name ^ "@" ^ tld;;
http://cbbrowne.com/info/spreadsheets.html
Rules  of the Evil  Overlord #107.  "Even though  I don't  really care
because I plan  on living forever, I will hire  engineers who are able
to build  me a fortress  sturdy enough that,  if I am slain,  it won't
tumble   tothe   ground   for   nogood   structural   reason."


-- 
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] TODO, FAQs to Wiki?

[Joshua D. Drake]

On Mon, 21 Apr 2008 12:22:45 -0400
Alvaro Herrera <[EMAIL PROTECTED]> wrote:

> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> 
> > > I suggest we start an experiment with the FAQ in XML Docbook,
> > > which is amenable to automatic processing, and move from there.
> > 
> > That makes sense.  We have many translations of the main FAQ so it
> > would be a good test for the main docs.  But how do we allow easy
> > changes via a wiki?  Maybe that isn't a concern for the main FAQ.
> 
> Yes, basically my answer is "we don't".  Currently there's no such
> thing as easy editing, and while I agree it would be good to have it,
> I don't have a solution for it.

There is an option. We move to a databased format for the FAQ that
gets edited via the website. We can then write a script that wrips out
Docbook for transformation for translators.

If you look at:

 http://www.commandprompt.com/community/consultants/guide/

That is what we do with the above. That is all dynamically generated
from a DB.

Joshua D. Drake

-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: 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] TODO, FAQs to Wiki?

[Guillaume Lelarge]

Bruce Momjian a écrit :

Alvaro Herrera wrote:

Bruce Momjian wrote:

Alvaro Herrera wrote:

As far as I know, what the doc translators do is translate the SGML
files directly, which is as difficult and cumbersome as you can possibly
get.  I am in no way suggesting we do that for the FAQ.

What can we do to help people translate the docs?

I suggest we start an experiment with the FAQ in XML Docbook, which is
amenable to automatic processing, and move from there.


That makes sense.  We have many translations of the main FAQ so it would
be a good test for the main docs.  But how do we allow easy changes via
a wiki?  Maybe that isn't a concern for the main FAQ.



Seems it would be a great time to re-do the french translation of the 
TODO which is completely outdated.



--
Guillaume.
 http://www.postgresqlfr.org
 http://dalibo.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] TODO, FAQs to Wiki?

[Alvaro Herrera]

Bruce Momjian wrote:
> Alvaro Herrera wrote:

> > I suggest we start an experiment with the FAQ in XML Docbook, which is
> > amenable to automatic processing, and move from there.
> 
> That makes sense.  We have many translations of the main FAQ so it would
> be a good test for the main docs.  But how do we allow easy changes via
> a wiki?  Maybe that isn't a concern for the main FAQ.

Yes, basically my answer is "we don't".  Currently there's no such thing
as easy editing, and while I agree it would be good to have it, I don't
have a solution for it.

-- 
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] Regression test fails when BLCKSZ is 1kB

[Martijn van Oosterhout]

On Mon, Apr 21, 2008 at 02:25:31PM +0200, Peter Eisentraut wrote:
> > I think affected test should contain order by keyword.
> 
> For previously established reasons, we don't want to add ORDER BY clauses to 
> every test that might fail under exceptional circumstances so we test all 
> plan types equally.  I think very small block sizes are fairly exceptional, 
> unless you have a reason up your sleeve why they are a good idea.

I wonder if it would be feasable to, whenever a regression test fails
to sort both files and compare again. This should tell you if the
difference are *only* rearrangement automatically, without having to
eyeball the output.

Have a nice day,
-- 
Martijn van Oosterhout   <[EMAIL PROTECTED]>   http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while 
> boarding. Thank you for flying nlogn airlines.


signature.asc
Description: Digital signature

Re: [HACKERS] TODO, FAQs to Wiki?

[Bruce Momjian]

Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> 
> > > As far as I know, what the doc translators do is translate the SGML
> > > files directly, which is as difficult and cumbersome as you can possibly
> > > get.  I am in no way suggesting we do that for the FAQ.
> > 
> > What can we do to help people translate the docs?
> 
> I suggest we start an experiment with the FAQ in XML Docbook, which is
> amenable to automatic processing, and move from there.

That makes sense.  We have many translations of the main FAQ so it would
be a good test for the main docs.  But how do we allow easy changes via
a wiki?  Maybe that isn't a concern for the main FAQ.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>http://momjian.us
  EnterpriseDB http://enterprisedb.com

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

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

Re: [HACKERS] TODO, FAQs to Wiki?

[Alvaro Herrera]

Bruce Momjian wrote:
> Alvaro Herrera wrote:

> > As far as I know, what the doc translators do is translate the SGML
> > files directly, which is as difficult and cumbersome as you can possibly
> > get.  I am in no way suggesting we do that for the FAQ.
> 
> What can we do to help people translate the docs?

I suggest we start an experiment with the FAQ in XML Docbook, which is
amenable to automatic processing, and move from there.

-- 
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] TODO, FAQs to Wiki?

[Bruce Momjian]

Alvaro Herrera wrote:
> Joshua D. Drake wrote:
> > Magnus Hagander wrote:
> >
> >> I remain very unconvinced that making it that much more complex is
> >> worth it.. But if someone sets up a complete system to test it, sure -
> >> since I don't write *or* read any of the translated FAQs we should
> >> obviously listen more to those who do.
> >
> > Isn't this what we do with the docs now?
> 
> I don't know of anyone using the gettext chain (PO files and xml2po) to
> translate the docs, so no, this is not at all what we do with the docs.
> 
> As far as I know, what the doc translators do is translate the SGML
> files directly, which is as difficult and cumbersome as you can possibly
> get.  I am in no way suggesting we do that for the FAQ.

What can we do to help people translate the docs?

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>http://momjian.us
  EnterpriseDB http://enterprisedb.com

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

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

Re: [HACKERS] Regression test fails when BLCKSZ is 1kB

[Peter Eisentraut]

Am Montag, 21. April 2008 schrieb Zdenek Kotala:
> I'm only testing behavior with different block size and I think it is not
> good idea to support only 8kB for regtest. When 4kB is used then PG fails
> in Join regresion test and  with 16kB, 32kB it fails because:
>
>   *** ./expected/bitmapops.outFri Apr 11 00:25:26 2008
> --- ./results/bitmapops.out Mon Apr 21 15:30:18 2008
> ***
> *** 20,25 
> --- 20,26 
>set enable_seqscan=false;
>-- Lower work_mem to trigger use of lossy bitmaps
>set work_mem = 64;
> + ERROR:  64 is outside the valid range for parameter "work_mem" (256 ..
> 2097151) -- Test bitmap-and.
>SELECT count(*) FROM bmscantest WHERE a = 1 AND b = 1;
> count

This should probably be fixed by using a unit specification on work_mem.  Do 
you want to prepare a patch?

-- 
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] Commitfest namespacing (was: TODO, FAQs to Wiki?)

[Alvaro Herrera]

Brendan Jurd escribió:

> I wonder if we should namespace the CommitFest pages by year as well
> as month (i.e., move CommitFest:May to CommitFest:May2008).  This way,
> even after we've had a CommitFest:May in 2009/2010/etc., the history
> of the May 2008 CommitFest will still be easily viewable as a discrete
> item.

Agreed -- this same idea occurred to me some days ago, but I then forgot
it :-)  For now, it would be good to ensure that CommitFest:May is a
redirect to May2008.  (I think it would make sense to have a
CommitFest:Current redirect and perhaps CommitFest:Next.)

-- 
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] Commitfest namespacing (was: TODO, FAQs to Wiki?)

[Brendan Jurd]

On Sun, Apr 20, 2008 at 1:45 AM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> Bruce Momjian wrote:
>  > I am impressed at the state of the May wiki patch queue:
>  >
>  >   http://wiki.postgresql.org/wiki/CommitFest:May
>  >
>  > It is even tracking the psql wrap patch I am working on now.
>
>  Thanks.  We've put a certain amount of effort on it.  Credit for the
>  templating system goes to Brendan Jurd, who implemented the way to make
>  it display as tables but without the messy markup.  I think the
>  templates that are now in place make for a reasonably comfortable
>  environment.  Not as simple as editing a plain text file, but I expect
>  it is lean enough.

I appreciate your positive comment Bruce.  Credit must also go to
Alvaro for supplying valuable feedback and encouragement offlist while
I worked on those templates =)

I wonder if we should namespace the CommitFest pages by year as well
as month (i.e., move CommitFest:May to CommitFest:May2008).  This way,
even after we've had a CommitFest:May in 2009/2010/etc., the history
of the May 2008 CommitFest will still be easily viewable as a discrete
item.

Thoughts?

Cheers,
BJ

-- 
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] Regression test fails when BLCKSZ is 1kB

[Zdenek Kotala]

Peter Eisentraut napsal(a):

Am Montag, 21. April 2008 schrieb Zdenek Kotala:

I compiled postgreSQL with 1kB block size and regresion test fails. Main
problem is that output is correct but in different order. See attachment.


This was previously reported: 
http://archives.postgresql.org/pgsql-hackers/2006-11/msg00901.php



I think affected test should contain order by keyword.


For previously established reasons, we don't want to add ORDER BY clauses to 
every test that might fail under exceptional circumstances so we test all 
plan types equally.  I think very small block sizes are fairly exceptional, 
unless you have a reason up your sleeve why they are a good idea.


I'm only testing behavior with different block size and I think it is not good 
idea to support only 8kB for regtest. When 4kB is used then PG fails in Join 
regresion test and  with 16kB, 32kB it fails because:


 *** ./expected/bitmapops.outFri Apr 11 00:25:26 2008
--- ./results/bitmapops.out Mon Apr 21 15:30:18 2008
***
*** 20,25 
--- 20,26 
  set enable_seqscan=false;
  -- Lower work_mem to trigger use of lossy bitmaps
  set work_mem = 64;
+ ERROR:  64 is outside the valid range for parameter "work_mem" (256 .. 
2097151)
  -- Test bitmap-and.
  SELECT count(*) FROM bmscantest WHERE a = 1 AND b = 1;
   count


Zdenek

--
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] TODO, FAQs to Wiki?

[Bruce Momjian]

Brendan Jurd wrote:
> On Mon, Apr 21, 2008 at 11:20 PM, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> >  For reference, the developer FAQ (which really is a different thing,
> >  given the audience) now lives on the wiki at
> >  http://wiki.postgresql.org/wiki/Developer_FAQ. I'd like to hear what
> >  people think about that one, and get a "signoff" on if this should be
> >  the main location for it, thus removing it from CVS. (We've already had
> >  a couple of fixes go into it, so it's actually more up-to-date than the
> >  one in CVS...)
> >
> 
> Nice.  My 0.02$ is that the wiki is a better place for the Dev FAQ.
> 
> I did notice that the section on vim settings doesn't mention anything
> about the expandtab setting.  Ideally this should be set to
> noexpandtab (noet) to preserve tab spacing.  I'll add it to the wiki
> page, but feel free to revert it if you don't want it in there.

Yes, please add it.

> I also saw that the Dev FAQ still points to Bruce's personal patch
> lists as the primary source for the current patch queue.  Have we
> reached the point where we can direct developers to
> http://wiki.postgresql.org/wiki/CommitFest instead?

Yes, but we need to update the main web site too:

http://www.postgresql.org/developer/roadmap

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>http://momjian.us
  EnterpriseDB http://enterprisedb.com

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

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

Re: [HACKERS] TODO, FAQs to Wiki?

[Bruce Momjian]

Magnus Hagander wrote:
> I'm sure we can find a way to do that. We do a lot of fairly ugly work
> to mirror from the cvs tree to the website today... 
> 
> For reference, the developer FAQ (which really is a different thing,
> given the audience) now lives on the wiki at
> http://wiki.postgresql.org/wiki/Developer_FAQ. I'd like to hear what
> people think about that one, and get a "signoff" on if this should be
> the main location for it, thus removing it from CVS. (We've already had
> a couple of fixes go into it, so it's actually more up-to-date than the
> one in CVS...)

Looks good to me.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>http://momjian.us
  EnterpriseDB http://enterprisedb.com

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

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

Re: [HACKERS] Regression test fails when BLCKSZ is 1kB

[Tom Lane]

"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> Now that we have autovacuum on by default, we might get into random
> failures because of re-ordering. Though I don't seem to recall anybody
> complaining yet, it could just be that we are lucky or our regression
> suite don't have long enough running tests to give autovacuum chance
> to recycle some of the dead tuples.

No, the reason you don't see that is that plain VACUUM doesn't move
tuples around.

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] TODO, FAQs to Wiki?

[Alvaro Herrera]

Joshua D. Drake wrote:
> Magnus Hagander wrote:
>
>> I remain very unconvinced that making it that much more complex is
>> worth it.. But if someone sets up a complete system to test it, sure -
>> since I don't write *or* read any of the translated FAQs we should
>> obviously listen more to those who do.
>
> Isn't this what we do with the docs now?

I don't know of anyone using the gettext chain (PO files and xml2po) to
translate the docs, so no, this is not at all what we do with the docs.

As far as I know, what the doc translators do is translate the SGML
files directly, which is as difficult and cumbersome as you can possibly
get.  I am in no way suggesting we do that for the FAQ.

-- 
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] TODO, FAQs to Wiki?

[Bruce Momjian]

Alvaro Herrera wrote:
> ... and no response from Bruce, either.

Oh, I am trying not to read community email during weekends, especially
Sundays, so that is why you didn't get a reply earlier.  I find it quite
liberating.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>http://momjian.us
  EnterpriseDB http://enterprisedb.com

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

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

Re: [HACKERS] TODO, FAQs to Wiki?

[Bruce Momjian]

Peter Eisentraut wrote:
> Am Montag, 21. April 2008 schrieb Magnus Hagander:
> > Agreed. I don't think we *ever* backpatch FAQ stuff, which is a clear
> > indicator it's the later.
> 
> Another thought: Would be still ship the FAQ in the release tarball?  That 
> might be a bit weird if it is not maintained in the source code repository.
> 
> I think I consider the FAQ to be more of a web resource, to be read before 
> you 
> install PostgreSQL, so the thought of not shipping the FAQ doesn't bother me 
> too much, but others might not like it.

I think if we just point to a URL from the tarball that is enough.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>http://momjian.us
  EnterpriseDB http://enterprisedb.com

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

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

Re: [HACKERS] TODO, FAQs to Wiki?

[Bruce Momjian]

Alvaro Herrera wrote:
> Magnus Hagander wrote:
> > Alvaro Herrera wrote:
> > > Magnus Hagander wrote:
> > > 
> > > > Hold on a minute. You're saying only the english version would be in
> > > > Docbook, and then you'd use .po files? So how do I as an end user
> > > > actually *read* the FAQ then? I need to both process .po and
> > > > Docbook?
> > > 
> > > The xml2po tools allow the reconstruction of translated XML files from
> > > the translated PO.
> > 
> > Again, this seems a whole lot more complex for very little gain to me.
> > But if you're willing to do the work, and can get the FAQ translator
> > onboard thinking it's easier than the wiki, be my guest...
> 
> Actually not only I have to convince the translator -- I have to
> convince Bruce *as a first step*.  I have tried in the past and failed.
> Now he is open to discuss changing the format of the FAQs, so I suggest
> this idea again, and here I get a ton of negative responses from guys
> who have never had anything to do with the FAQ at all ...
> 
> I mean what interest does Josh Drake have on whether the FAQ is in SGML
> or XML?
> 
> ... and no response from Bruce, either.

I am good on moving to a wiki, as I indicated because I started this
thread.

The issue with PO is that translators should be able to pull the
_changed_ text and translate just that.  Not sure if the wiki allows
that but the PO system does.

Now, we don't have any non-English translations of the developer's FAQ,
so that isn't an issue yet, but the main FAQ does have translators.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>http://momjian.us
  EnterpriseDB http://enterprisedb.com

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

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

Re: [HACKERS] TODO, FAQs to Wiki?

[Magnus Hagander]

Peter Eisentraut wrote:
> Am Montag, 21. April 2008 schrieb Magnus Hagander:
> > Agreed. I don't think we *ever* backpatch FAQ stuff, which is a
> > clear indicator it's the later.
> 
> Another thought: Would be still ship the FAQ in the release tarball?
> That might be a bit weird if it is not maintained in the source code
> repository.
> 
> I think I consider the FAQ to be more of a web resource, to be read
> before you install PostgreSQL, so the thought of not shipping the FAQ
> doesn't bother me too much, but others might not like it.

That's what I was thinking, yes. We could/should include a reference to
where it is, of course, but the content should be on the web. That also
allows us to add an FAQ for a current release without people having to
wait for the next release to actually get it...


> > For reference, the developer FAQ (which really is a different thing,
> > given the audience) now lives on the wiki at
> > http://wiki.postgresql.org/wiki/Developer_FAQ. I'd like to hear what
> > people think about that one, and get a "signoff" on if this should
> > be the main location for it, thus removing it from CVS.
> 
> Looks good to me.
> 
> Actually, I expect that the Developer_FAQ will mostly disappear over
> time and devolve to a list of links to other places in the wiki,
> eventually being merged with or replaced by the
> Development_information page.

Agreed - there's probably some duplication already. But moving it up
there will let the people who want to expand on certain topic do that
without having to flood bruce with patches.

//Magnus

-- 
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] TODO, FAQs to Wiki?

[Peter Eisentraut]

Am Montag, 21. April 2008 schrieb Magnus Hagander:
> Agreed. I don't think we *ever* backpatch FAQ stuff, which is a clear
> indicator it's the later.

Another thought: Would be still ship the FAQ in the release tarball?  That 
might be a bit weird if it is not maintained in the source code repository.

I think I consider the FAQ to be more of a web resource, to be read before you 
install PostgreSQL, so the thought of not shipping the FAQ doesn't bother me 
too much, but others might not like it.

> For reference, the developer FAQ (which really is a different thing,
> given the audience) now lives on the wiki at
> http://wiki.postgresql.org/wiki/Developer_FAQ. I'd like to hear what
> people think about that one, and get a "signoff" on if this should be
> the main location for it, thus removing it from CVS.

Looks good to me.

Actually, I expect that the Developer_FAQ will mostly disappear over time and 
devolve to a list of links to other places in the wiki, eventually being 
merged with or replaced by the Development_information page.

-- 
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] pgstat SRF?

[Magnus Hagander]

Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > While looking over the statistics-for-functions patch
> > (http://archives.postgresql.org/pgsql-patches/2008-03/msg00300.php),
> > I came back to a thought I've had before - why do we keep one
> > function per column for pgstat functions, instead of using a set
> > returning function? Is there some actual reason for this, or is it
> > just legacy from a time when it was (much) harder to write SRFs?
> 
> I think it's so that you can build your own stats views instead of
> being compelled to select the data someone thought was good for you.

You can still do that if it's an SRF. You could even make the SRF take
an optional argument to either return a single value (filtered the same
way the individual functions are) or when this one is set to NULL,
return the whole table. 

It would make the overhead a lot lower in the most common case ("SELECT
* FROM pg_stat_"), while only adding a little in the
other cases, I think.

Though I'm not sure that overhead is big enough to care about in the
first place, but if you're VIEWs are longish it could be...

//Magnus

-- 
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] TODO, FAQs to Wiki?

[Magnus Hagander]

Brendan Jurd wrote:
> On Mon, Apr 21, 2008 at 11:20 PM, Magnus Hagander
> <[EMAIL PROTECTED]> wrote:
> >  For reference, the developer FAQ (which really is a different
> > thing, given the audience) now lives on the wiki at
> >  http://wiki.postgresql.org/wiki/Developer_FAQ. I'd like to hear
> > what people think about that one, and get a "signoff" on if this
> > should be the main location for it, thus removing it from CVS.
> > (We've already had a couple of fixes go into it, so it's actually
> > more up-to-date than the one in CVS...)
> >
> 
> Nice.  My 0.02$ is that the wiki is a better place for the Dev FAQ.
> 
> I did notice that the section on vim settings doesn't mention anything
> about the expandtab setting.  Ideally this should be set to
> noexpandtab (noet) to preserve tab spacing.  I'll add it to the wiki
> page, but feel free to revert it if you don't want it in there.
> 
> I also saw that the Dev FAQ still points to Bruce's personal patch
> lists as the primary source for the current patch queue.  Have we
> reached the point where we can direct developers to
> http://wiki.postgresql.org/wiki/CommitFest instead?

These are  both content questions, of course, which once (if) we
approve it to live on the wiki as source, you are very welcome to fix
for us :-) That being the whole point of it living in the wiki.

//Magnus

-- 
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] TODO, FAQs to Wiki?

[Joshua D. Drake]

Magnus Hagander wrote:

Joshua D. Drake wrote:




And we've certainly had our share of people not working on the docs
because it's too hard. (I know I used to have to submit all docs
patches untested because it took me a year or so to get the build
process working on win32. Now I've given that up and have a linux VM to
build the docs in, but you get the idea..)


The only thing hard about editing the docs is if you do so on broken 
platforms :P


Seriously though. Docbook isn't for the feint hearted, especially if you 
are going to take into account the tools. Unfortunately as far as I know 
it is the only format I know of that is as flexible as it is.


Our only other real option is something like ODF and I really don't want 
to have that discussion.


Sincerely,

Joshua D. Drake


--
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] pgstat SRF?

[Tom Lane]

Magnus Hagander <[EMAIL PROTECTED]> writes:
> While looking over the statistics-for-functions patch
> (http://archives.postgresql.org/pgsql-patches/2008-03/msg00300.php), I
> came back to a thought I've had before - why do we keep one function
> per column for pgstat functions, instead of using a set returning
> function? Is there some actual reason for this, or is it just legacy
> from a time when it was (much) harder to write SRFs?

I think it's so that you can build your own stats views instead of being
compelled to select the data someone thought was good for you.

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] TODO, FAQs to Wiki?

[Brendan Jurd]

On Mon, Apr 21, 2008 at 11:20 PM, Magnus Hagander <[EMAIL PROTECTED]> wrote:
>  For reference, the developer FAQ (which really is a different thing,
>  given the audience) now lives on the wiki at
>  http://wiki.postgresql.org/wiki/Developer_FAQ. I'd like to hear what
>  people think about that one, and get a "signoff" on if this should be
>  the main location for it, thus removing it from CVS. (We've already had
>  a couple of fixes go into it, so it's actually more up-to-date than the
>  one in CVS...)
>

Nice.  My 0.02$ is that the wiki is a better place for the Dev FAQ.

I did notice that the section on vim settings doesn't mention anything
about the expandtab setting.  Ideally this should be set to
noexpandtab (noet) to preserve tab spacing.  I'll add it to the wiki
page, but feel free to revert it if you don't want it in there.

I also saw that the Dev FAQ still points to Bruce's personal patch
lists as the primary source for the current patch queue.  Have we
reached the point where we can direct developers to
http://wiki.postgresql.org/wiki/CommitFest instead?

Cheers,
BJ

-- 
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] TODO, FAQs to Wiki?

[Magnus Hagander]

Joshua D. Drake wrote:
> Magnus Hagander wrote:
> > Alvaro Herrera wrote:
> >> Magnus Hagander wrote:
> 
> > I remain very unconvinced that making it that much more complex is
> > worth it.. But if someone sets up a complete system to test it,
> > sure - since I don't write *or* read any of the translated FAQs we
> > should obviously listen more to those who do.
> 
> Isn't this what we do with the docs now?

More or less. In my view, a FAQ is a much more dynamic document.

And we've certainly had our share of people not working on the docs
because it's too hard. (I know I used to have to submit all docs
patches untested because it took me a year or so to get the build
process working on win32. Now I've given that up and have a linux VM to
build the docs in, but you get the idea..)


//Magnus

-- 
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] TODO, FAQs to Wiki?

[Alvaro Herrera]

Magnus Hagander wrote:

> For reference, the developer FAQ (which really is a different thing,
> given the audience) now lives on the wiki at
> http://wiki.postgresql.org/wiki/Developer_FAQ. I'd like to hear what
> people think about that one, and get a "signoff" on if this should be
> the main location for it, thus removing it from CVS. (We've already had
> a couple of fixes go into it, so it's actually more up-to-date than the
> one in CVS...)

Signoff-By: [EMAIL PROTECTED]

-- 
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] TODO, FAQs to Wiki?

[Joshua D. Drake]

Alvaro Herrera wrote:


Actually not only I have to convince the translator -- I have to
convince Bruce *as a first step*.  I have tried in the past and failed.
Now he is open to discuss changing the format of the FAQs, so I suggest
this idea again, and here I get a ton of negative responses from guys
who have never had anything to do with the FAQ at all ...

I mean what interest does Josh Drake have on whether the FAQ is in SGML
or XML?


Uhh my response was a +1.

Joshua D. Drake

--
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] TODO, FAQs to Wiki?

[Brendan Jurd]

On Mon, Apr 21, 2008 at 11:54 PM, Brendan Jurd <[EMAIL PROTECTED]> wrote:
>  I did notice that the section on vim settings doesn't mention anything
>  about the expandtab setting.  Ideally this should be set to
>  noexpandtab (noet) to preserve tab spacing.  I'll add it to the wiki
>  page, but feel free to revert it if you don't want it in there.

Oh, and I always set textwidth (tw) to 79 as well, to get automatic
line wrapping on comments.

Cheers,
BJ

-- 
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] TODO, FAQs to Wiki?

[Joshua D. Drake]

Magnus Hagander wrote:

Alvaro Herrera wrote:

Magnus Hagander wrote:



I remain very unconvinced that making it that much more complex is
worth it.. But if someone sets up a complete system to test it, sure -
since I don't write *or* read any of the translated FAQs we should
obviously listen more to those who do.


Isn't this what we do with the docs now?

Joshua D. Drake


--
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] INSERT ... SELECT ... FOR SHARED?

[Tom Lane]

Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> The lack of regression tests covering this area is a bit annoying
>> at this point.  However, it's hard to see how to test FOR UPDATE
>> until we get some concurrent-sessions support in psql.

> Well, end-to-end testing would e better but we can test that the locks are
> at least being recorded by white-box inspection:

> postgres=# select distinct age(xmax) from tellers;

Huh, that's a cute trick ... and it would answer the immediate problem,
which is to check that the statement did take the row locks it was
supposed to.

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] TODO, FAQs to Wiki?

[Alvaro Herrera]

Magnus Hagander wrote:
> Alvaro Herrera wrote:
> > Magnus Hagander wrote:
> > 
> > > Hold on a minute. You're saying only the english version would be in
> > > Docbook, and then you'd use .po files? So how do I as an end user
> > > actually *read* the FAQ then? I need to both process .po and
> > > Docbook?
> > 
> > The xml2po tools allow the reconstruction of translated XML files from
> > the translated PO.
> 
> Again, this seems a whole lot more complex for very little gain to me.
> But if you're willing to do the work, and can get the FAQ translator
> onboard thinking it's easier than the wiki, be my guest...

Actually not only I have to convince the translator -- I have to
convince Bruce *as a first step*.  I have tried in the past and failed.
Now he is open to discuss changing the format of the FAQs, so I suggest
this idea again, and here I get a ton of negative responses from guys
who have never had anything to do with the FAQ at all ...

I mean what interest does Josh Drake have on whether the FAQ is in SGML
or XML?

... and no response from Bruce, either.

-- 
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] WAL files format

[Alvaro Herrera]

mito escribió:
> What information are currently strored in WAL sequence ?

Everything needed to replay each change, at the physical page level.

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

[HACKERS] pgstat SRF?

[Magnus Hagander]

While looking over the statistics-for-functions patch
(http://archives.postgresql.org/pgsql-patches/2008-03/msg00300.php), I
came back to a thought I've had before - why do we keep one function
per column for pgstat functions, instead of using a set returning
function? Is there some actual reason for this, or is it just legacy
from a time when it was (much) harder to write SRFs?

If there's no actual reason, I think it would be a good idea to make at
least new views added based on SRFs instead

//Magnus

-- 
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] TODO, FAQs to Wiki?

[Magnus Hagander]

Peter Eisentraut wrote:
> Am Samstag, 19. April 2008 schrieb Alvaro Herrera:
> > The FAQs are another matter however.  I suggested some time back
> > moving those to DocBook XML.
> 
> The question is whether we consider the FAQ to be a document tied to
> a PostgreSQL release (e.g., there is a separate FAQ applying to each
> release) or whether it is a "global" document.  In the former case,
> it should be in CVS, in the latter it should be somewhere else.  In
> my mind, it is quite clear that it is the latter.

Agreed. I don't think we *ever* backpatch FAQ stuff, which is a clear
indicator it's the later.


> But while I am in favor of moving as much as possible of the
> developer documentation to the wiki, I am not sure such a primary,
> user-facing document should be in a wiki.  Not because I am afraid of
> anyone being able to edit it, but I am concerned about the impression
> this creates with (new) users. Could we mirror it from the wiki to
> the "real" web site?

I'm sure we can find a way to do that. We do a lot of fairly ugly work
to mirror from the cvs tree to the website today... 

For reference, the developer FAQ (which really is a different thing,
given the audience) now lives on the wiki at
http://wiki.postgresql.org/wiki/Developer_FAQ. I'd like to hear what
people think about that one, and get a "signoff" on if this should be
the main location for it, thus removing it from CVS. (We've already had
a couple of fixes go into it, so it's actually more up-to-date than the
one in CVS...)

//Magnus

-- 
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] TODO, FAQs to Wiki?

[Magnus Hagander]

Alvaro Herrera wrote:
> Magnus Hagander wrote:
> 
> > Hold on a minute. You're saying only the english version would be in
> > Docbook, and then you'd use .po files? So how do I as an end user
> > actually *read* the FAQ then? I need to both process .po and
> > Docbook?
> 
> The xml2po tools allow the reconstruction of translated XML files from
> the translated PO.

Again, this seems a whole lot more complex for very little gain to me.
But if you're willing to do the work, and can get the FAQ translator
onboard thinking it's easier than the wiki, be my guest...

//Magnus

-- 
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] TODO, FAQs to Wiki?

[Alvaro Herrera]

Magnus Hagander wrote:

> Hold on a minute. You're saying only the english version would be in
> Docbook, and then you'd use .po files? So how do I as an end user
> actually *read* the FAQ then? I need to both process .po and Docbook?

The xml2po tools allow the reconstruction of translated XML files from
the translated PO.

-- 
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] INSERT ... SELECT ... FOR SHARED?

[Gregory Stark]

"Tom Lane" <[EMAIL PROTECTED]> writes:

> The lack of regression tests covering this area is a bit annoying
> at this point.  However, it's hard to see how to test FOR UPDATE
> until we get some concurrent-sessions support in psql.

Well, end-to-end testing would e better but we can test that the locks are
at least being recorded by white-box inspection:

postgres=# begin;
BEGIN
postgres=# select * from tellers for share;
 tid | bid | tbalance | filler 
-+-+--+
   1 |   1 |0 | 
   2 |   1 |0 | 
   3 |   1 |0 | 
   4 |   1 |0 | 
   5 |   1 |0 | 
   6 |   1 |0 | 
   7 |   1 |0 | 
   8 |   1 |0 | 
   9 |   1 |0 | 
  10 |   1 |0 | 
(10 rows)

postgres=# select distinct age(xmax) from tellers;
 age 
-
   0
(1 row)

-- 
  Gregory Stark
  EnterpriseDB  http://www.enterprisedb.com
  Ask me about EnterpriseDB's RemoteDBA services!

-- 
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] Regression test fails when BLCKSZ is 1kB

[Pavan Deolasee]

On Mon, Apr 21, 2008 at 5:55 PM, Peter Eisentraut <[EMAIL PROTECTED]> wrote:

>
>  For previously established reasons, we don't want to add ORDER BY clauses to
>  every test that might fail under exceptional circumstances so we test all
>  plan types equally.  I think very small block sizes are fairly exceptional,
>  unless you have a reason up your sleeve why they are a good idea.
>

Now that we have autovacuum on by default, we might get into random
failures because of re-ordering. Though I don't seem to recall anybody
complaining yet, it could just be that we are lucky or our regression
suite don't have long enough running tests to give autovacuum chance
to recycle some of the dead tuples.

Thanks,
Pavan


-- 
Pavan Deolasee
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] TODO, FAQs to Wiki?

[Peter Eisentraut]

Am Samstag, 19. April 2008 schrieb Alvaro Herrera:
> The FAQs are another matter however.  I suggested some time back moving
> those to DocBook XML.

The question is whether we consider the FAQ to be a document tied to a 
PostgreSQL release (e.g., there is a separate FAQ applying to each release) 
or whether it is a "global" document.  In the former case, it should be in 
CVS, in the latter it should be somewhere else.  In my mind, it is quite 
clear that it is the latter.

But while I am in favor of moving as much as possible of the developer 
documentation to the wiki, I am not sure such a primary, user-facing document 
should be in a wiki.  Not because I am afraid of anyone being able to edit 
it, but I am concerned about the impression this creates with (new) users.  
Could we mirror it from the wiki to the "real" web site?

-- 
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] Regression test fails when BLCKSZ is 1kB

[Peter Eisentraut]

Am Montag, 21. April 2008 schrieb Zdenek Kotala:
> I compiled postgreSQL with 1kB block size and regresion test fails. Main
> problem is that output is correct but in different order. See attachment.

This was previously reported: 
http://archives.postgresql.org/pgsql-hackers/2006-11/msg00901.php

> I think affected test should contain order by keyword.

For previously established reasons, we don't want to add ORDER BY clauses to 
every test that might fail under exceptional circumstances so we test all 
plan types equally.  I think very small block sizes are fairly exceptional, 
unless you have a reason up your sleeve why they are a good idea.

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

[HACKERS] Regression test fails when BLCKSZ is 1kB

[Zdenek Kotala]

I compiled postgreSQL with 1kB block size and regresion test fails. Main problem 
is that output is correct but in different order. See attachment.


I think affected test should contain order by keyword.

Any comments?

Zdenek
*** ./expected/join.out Wed Jan  9 21:42:28 2008
--- ./results/join.out  Mon Apr 21 13:50:53 2008
***
*** 214,226 
WHERE t1.a = t2.d;
   xxx | a | e  
  -+---+
-  | 0 |   
   | 1 | -1
   | 2 |  2
-  | 2 |  4
   | 3 | -3
   | 5 | -5
   | 5 | -5
  (7 rows)
  
  --
--- 214,226 
WHERE t1.a = t2.d;
   xxx | a | e  
  -+---+
   | 1 | -1
   | 2 |  2
   | 3 | -3
+  | 2 |  4
   | 5 | -5
   | 5 | -5
+  | 0 |   
  (7 rows)
  
  --
***
*** 1569,1581 
FROM J1_TBL INNER JOIN J2_TBL USING (i);
   xxx | i | j |   t   | k  
  -+---+---+---+
-  | 0 |   | zero  |   
   | 1 | 4 | one   | -1
   | 2 | 3 | two   |  2
-  | 2 | 3 | two   |  4
   | 3 | 2 | three | -3
   | 5 | 0 | five  | -5
   | 5 | 0 | five  | -5
  (7 rows)
  
  -- Same as above, slightly different syntax
--- 1569,1581 
FROM J1_TBL INNER JOIN J2_TBL USING (i);
   xxx | i | j |   t   | k  
  -+---+---+---+
   | 1 | 4 | one   | -1
   | 2 | 3 | two   |  2
   | 3 | 2 | three | -3
+  | 2 | 3 | two   |  4
   | 5 | 0 | five  | -5
   | 5 | 0 | five  | -5
+  | 0 |   | zero  |   
  (7 rows)
  
  -- Same as above, slightly different syntax
***
*** 1583,1595 
FROM J1_TBL JOIN J2_TBL USING (i);
   xxx | i | j |   t   | k  
  -+---+---+---+
-  | 0 |   | zero  |   
   | 1 | 4 | one   | -1
   | 2 | 3 | two   |  2
-  | 2 | 3 | two   |  4
   | 3 | 2 | three | -3
   | 5 | 0 | five  | -5
   | 5 | 0 | five  | -5
  (7 rows)
  
  SELECT '' AS "xxx", *
--- 1583,1595 
FROM J1_TBL JOIN J2_TBL USING (i);
   xxx | i | j |   t   | k  
  -+---+---+---+
   | 1 | 4 | one   | -1
   | 2 | 3 | two   |  2
   | 3 | 2 | three | -3
+  | 2 | 3 | two   |  4
   | 5 | 0 | five  | -5
   | 5 | 0 | five  | -5
+  | 0 |   | zero  |   
  (7 rows)
  
  SELECT '' AS "xxx", *
***
*** 1625,1637 
FROM J1_TBL NATURAL JOIN J2_TBL;
   xxx | i | j |   t   | k  
  -+---+---+---+
-  | 0 |   | zero  |   
   | 1 | 4 | one   | -1
   | 2 | 3 | two   |  2
-  | 2 | 3 | two   |  4
   | 3 | 2 | three | -3
   | 5 | 0 | five  | -5
   | 5 | 0 | five  | -5
  (7 rows)
  
  SELECT '' AS "xxx", *
--- 1625,1637 
FROM J1_TBL NATURAL JOIN J2_TBL;
   xxx | i | j |   t   | k  
  -+---+---+---+
   | 1 | 4 | one   | -1
   | 2 | 3 | two   |  2
   | 3 | 2 | three | -3
+  | 2 | 3 | two   |  4
   | 5 | 0 | five  | -5
   | 5 | 0 | five  | -5
+  | 0 |   | zero  |   
  (7 rows)
  
  SELECT '' AS "xxx", *
***
*** 1638,1650 
FROM J1_TBL t1 (a, b, c) NATURAL JOIN J2_TBL t2 (a, d);
   xxx | a | b |   c   | d  
  -+---+---+---+
-  | 0 |   | zero  |   
   | 1 | 4 | one   | -1
   | 2 | 3 | two   |  2
-  | 2 | 3 | two   |  4
   | 3 | 2 | three | -3
   | 5 | 0 | five  | -5
   | 5 | 0 | five  | -5
  (7 rows)
  
  SELECT '' AS "xxx", *
--- 1638,1650 
FROM J1_TBL t1 (a, b, c) NATURAL JOIN J2_TBL t2 (a, d);
   xxx | a | b |   c   | d  
  -+---+---+---+
   | 1 | 4 | one   | -1
   | 2 | 3 | two   |  2
   | 3 | 2 | three | -3
+  | 2 | 3 | two   |  4
   | 5 | 0 | five  | -5
   | 5 | 0 | five  | -5
+  | 0 |   | zero  |   
  (7 rows)
  
  SELECT '' AS "xxx", *
***
*** 1651,1659 
FROM J1_TBL t1 (a, b, c) NATURAL JOIN J2_TBL t2 (d, a);
   xxx | a | b |  c   | d 
  -+---+---+--+---
-  | 0 |   | zero |  
   | 2 | 3 | two  | 2
   | 4 | 1 | four | 2
  (3 rows)
  
  -- mismatch number of columns
--- 1651,1659 
FROM J1_TBL t1 (a, b, c) NATURAL JOIN J2_TBL t2 (d, a);
   xxx | a | b |  c   | d 
  -+---+---+--+---
   | 2 | 3 | two  | 2
   | 4 | 1 | four | 2
+  | 0 |   | zero |  
  (3 rows)
  
  -- mismatch number of columns
***
*** 1662,1674 
FROM J1_TBL t1 (a, b) NATURAL JOIN J2_TBL t2 (a);
   xxx | a | b |   t   | k  
  -+---+---+---+
-  | 0 |   | zero  |   
   | 1 | 4 | one   | -1
   | 2 | 3 | two   |  2
-  | 2 | 3 | two   |  4
   | 3 | 2 | three | -3
   | 5 | 0 | five  | -5
   | 5 | 0 | five  | -5
  (7 rows)
  
  --
--- 1662,1674 
FROM J1_TBL t1 (a, b) NATURAL JOIN J2_TBL t2 (a);
   xxx | a | b |   t   | k  
  -+---+---+---+
   | 1 | 4 | one   | -1
   | 2 | 3 | two   |  2
   | 3 | 2 | three | -3
+  | 2 | 3 | two   |  4
   | 5 | 0 | five  | -5
   | 5 | 0 | five  | -5
+  | 0 |   | zero  |   
  (7 rows)
  
  --
***
*** 1678,16

[HACKERS] port/thread.c and pthreads

[Magnus Hagander]

port/thread.c includes the pthreads header files, and contains a bunch
of comments about pthreads - but there seems to be no code related to
pthreads at all in the file. Am I missing something completely here? ;-)

//Magnus

-- 
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] pgkill on win32

[Magnus Hagander]

James Mansion wrote:
> Magnus Hagander wrote:
> > Yes. We used to use APCs, but touching anything remotely related to
> > Winsock from an APC is not supported... We had a lot of trouble
> > with it 
> By implication you'd be doing socket'y stuff from the signal handler
> on UNIX? Scary.

Uh, sorry, got that explained backwards.
The problem is when winsock operations are interrupted by APCs. 

See:
http://archives.postgresql.org/pgsql-hackers-win32/2004-04/msg00013.php


> I was assuming it would be used to signal an event that would release 
> the main
> thread and then do the real work there.
> 
> I suppose by implication you can't knock a thread out of select from
> the APC?

Not only that, but you may corrupt internal winsock structures if you
try. 

As stated, one major issue is that we have third-party libs calling the
winsock functions directly (SSL and Kerberos come to mind - the GSSAPI
code specifically does not do this). For SSL, I'd like to eventually
rewrite it to make sure *we* call the send and receive functions and
just use the library to encrypt buffers, which should make things a
bit safer in that regard.


> I can help feeling that the eventselect mechanism is the one to use,
> not the crappy bsd select emulation.

The original design, which is what is there now, was written to make
sure we made as little change as possible to the backend code itself,
and instead implemented portability layers. I think now that the port
is more mature, if we need to make some smaller changes around say the
select loop processing, we can do that - as long as we're careful. But
we certainly don't want to do anything that'll require more or less
global changes around the code.


> > initially, and it took a long support case with Microsoft PSS to
> > figure out what was broken, because this being unsupported was not
> > properly documented.
> >   
> Indeed. And its a very odd limitation given the way that APCs are
> used with completion ports.
> Did any sort of reference get written to the knowledge base for this,
> do you know?

There was one written, AFIAK, but I don't remember the number or can't
find it right now. It may well be that it's premier only. Also, it only
applied to traditional sockets API calls, and not "native" Winsock2
calls. But see above about SSL.


> > It certainly is ;-) We could probably find something more efficient,
> > but APCs are not the one.
> >   
> The concern I have isn't so much that the mechanism might be a bit
> ugly, but the synchronous
> delivery and the scheduling gymnastics implied..

Right.

//Magnus

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