Re: [HACKERS] Issues with two-server Synch Rep

2010-10-14 Thread Dimitri Fontaine
Peter Eisentraut pete...@gmx.net writes:
 Seems like a reasonable solution, although I've never heard
 of .emacs.custom; my emacsen have always written their custom settings
 somewhere in the middle of the .emacs proper.

See (info (emacs) Saving Customizations) and add the following to your
setup:
 (setq custom-file ~/.emacs-custom.el)
 (load custom-file)

  
http://www.gnu.org/software/emacs/manual/html_mono/emacs.html#Saving-Customizations

I guess it's relevant enough here.

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

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


Re: [HACKERS] Extensions, this time with a patch

2010-10-14 Thread Dimitri Fontaine
Alvaro Herrera alvhe...@commandprompt.com writes:
 Does this mean that the control file should contain a version number in
 the filename?  Otherwise, I don't see how you'd have more than one
 version of the control file.

 Also, if upgrading is necessary, there will need to be one upgrade
 control file that says how to upgrade from version N to N+1.

I like both ideas. I'd like to propose that we get back to this part of
the feature later, after the first patch is in. After all, the main goal
is to support dumprestore of extensions. Let's do that first.

If some of you are interested, the development happens here:
  
http://git.postgresql.org/gitweb?p=postgresql-extension.git;a=shortlog;h=refs/heads/extension

I've written some basic documentation in the Extending SQL
chapter (and command man pages too). There's not so much to tell about
the new features, as the goal is for it to fix something quite basic.

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

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


Re: [HACKERS] SQL command to edit postgresql.conf, with comments

2010-10-14 Thread Dimitri Fontaine
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
 cat postgresql.conf.d/work_mem
 16MB
 This database needs at least such a value.
 Note it's overridden in some ROLEs setup.


 With such a format (name is filename, value is first line content's,
 rest is comments), it's easy to preserve comments and have them machine
 editable. What do I miss?

Allow me to insist on this some more, because there's something
important going on here. The other proposal (.auto) have a major failure
mode that I don't think is acceptable.

  SET PERMANENT work_mem TO '8 MB';
  select pg_reload_conf();

There's simply no way after this sequence to guess the current active
value of work_mem, because it could be overridden in the non-automatic
file. How do you work with such a system?


So, back to my funny proposal. It does not have the problem above
because it's either postgresql.conf or postgresql.conf.d, not both. A
single source of authority.

I'm being told that we're talking about something over 200 files and
that's too many. That's a problem size we already know how to handle, I
would say:

dim ~/dev/PostgreSQL/postgresql-extension ls -C1 doc/src/sgml/ref/ |wc -l
 166

Ok, now, some people want to still be able to edit the files by hand
because it's the way they do it now. Well, first, that's still possible
and easy to script if so you care, then again, open an editor a prepare
a SQL script:

 set permanent foo to bar with comment 'blah';
 set …

Then you psql -f the script and you're done. So you use the remote
edit feature to be able to edit a single file rather than a bunch of
them if so you want.

Another option in the same spirit would be to prepare a file in the CSV
format (name;value) and have a script that COPY it into some table, then
  SELECT set_config(name, value, 'permanent')
FROM import_setup_table;

With a CSV foreign data wrapper at the door, you don't even have to use
an intermediate table where to direct your COPY.

Executive Summary: you can still edit some file the old way, you just
need a tool to then issue the SQL for you rather than reload.

Now, there are some comments that are not tied to any setting in
particular. We could extend my idea to include a .comments file in the
directory, and a command to edit it.

We could make it so that COMMENT ON SETTING would just amend the given
GUC's file, and that COMMENT ON CONFIG allow you to edit the main
.comment file.

Then, there's another feature here, which is having a single comment
entry for more than one parameter. Again, we could support it rather
easily by having directories to group files, and the common comment
would be the groupname/.comment file entry. Add some new commands to
manage that, and refuse to consider the setup at all as soon as there's
file name duplication in there.

  CREATE SETTING GROUP name WITH foo, bar, ... AND COMMENT 'foobar';
  CREATE SETTING GROUP other WITH baz, foo;
  NOTICE: foo was in the group name, it's been moved to other.

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

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


Re: [HACKERS] Why do we have a database specification in .pgpass?

2010-10-14 Thread Alvaro Herrera
Excerpts from Bruce Momjian's message of mié oct 13 15:32:22 -0300 2010:
 We have a database specification in .pgpass:
 
 hostname:port:database:username:password
 
 What is the purpose of 'database' since username/password combinations
 are global, not per database?  I would like to documents its purpose.

I think when I wrote it, I was hoping that the db_user_namespace thing
would be changed into a real per-database user implementation.  That
would have meant having different passwords depending on the database.


-- 
Álvaro Herrera alvhe...@commandprompt.com
The PostgreSQL Company - Command Prompt, Inc.
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] string function - format function proposal

2010-10-14 Thread Alvaro Herrera
Excerpts from Itagaki Takahiro's message of mié oct 13 23:03:16 -0300 2010:
 On Thu, Oct 14, 2010 at 10:23 AM, Robert Haas robertmh...@gmail.com wrote:
  On Wed, Sep 29, 2010 at 3:59 AM, Pavel Stehule pavel.steh...@gmail.com 
  wrote:
  [ updated patch, in response to a review from Itagaki Takahiro ]
 
  This patch appears to be waiting for a second round of review.
  Itagaki-san, are you planning to do that?
 
 I can, but I was waiting for other people's comments about the design:
   - format() in core, that implements %s, %i, and %l.
   - substitute() for $n format and sprintf() that partially implements
 the same function in C in contrib/stringfunc.
 
 I don't like having three similar functions for the same purpose,
 but Pavel said they are the best solutions. What will be our consensus?

I don't have much love for moving the position stuff ($n) out of the main
function either.  I've been meaning to take a look at how hard it would
be to integrate that into format() in core -- no luck :-(

-- 
Álvaro Herrera alvhe...@commandprompt.com
The PostgreSQL Company - Command Prompt, Inc.
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] [JDBC] Support for JDBC setQueryTimeout, et al.

2010-10-14 Thread Radosław Smogura
On Wed, 13 Oct 2010 21:01:06 -0400, Robert Haas robertmh...@gmail.com
wrote:
 Is this a JDBC patch or a PG patch?  Are we tracking JDBC patches
 using the CF app?

It is JDBC patch. I will clean it and submit on this site. I didn't know
about such application and such process.

--
Radosław Smogura
http://www.softperience.eu

-- 
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] [GENERAL] Text search parser's treatment of URLs and emails

2010-10-14 Thread Christian Ullrich

* Bruce Momjian wrote:


Thom Brown wrote:



Also:

SELECT alias, description, token FROM ts_debug('myname+prior...@gmail.com');

Yields:

alias   |   description   |   token
---+-+
  asciiword | Word, all ASCII | myname
  blank | Space symbols   | +
  email | Email address   | prior...@gmail.com
(3 rows)

The entire string I entered is a valid email address, and isn't
totally uncommon.  Shouldn't that take such email address styles be
taken into account?  The example above incorrectly identifies the
email address since the real destination address would most likely be
myn...@gmail.com.


I had no idea '+' could be part of an email address, and in fact it is a
modifier that is stripped off when delivering the email:


No, it's not. Strictly speaking, + is simply one of many characters 
that are valid in the local-part of an e-mail address according to RFC 
2822 (and 822, which was even more lenient there). The plus sign does 
not have any intrinsic semantics, except that it is obviously different 
from any other character for purposes of comparing addresses.


Even among applications that make decisions based on the value of 
various parts of e-mail addresses (usually MTAs when forwarding 
messages), the only ones that should be assigning special meaning to the 
plus sign are the MTAs responsible for delivering messages to their 
recipients in the recipient domain. A database that is only used for 
storing such addresses definitely should not attempt to divine what the 
_sender_ of the message meant when he put that plus sign in, or what it 
might mean to the _recipient_, who has no control over what people use 
as addresses when they send him e-mail.


Plainly put, the local-part should be treated as opaque everywhere 
outside the administrative scope of the recipient, and if you don't 
know whether you are in that scope, you are not. Splitting the 
local-part into subparts based on arbitrary rules that have no actual 
knowledge of the policies in place at the organization that assigned the 
address can only be a mistake.


Of course, the application that is using the database is free to use a 
ts configuration that does assign such meaning, if it has a reason to do 
so.


Examples:

- chris+postgre...@chrullrich.net

  Looks like I have a dedicated folder for messages concerning
  PostgreSQL. Now, _I_ know that I do not have such a folder, and
  that the suffix is meaningless. Nobody else can know for sure.

- jane+j...@example.com

  What is this?

  - A special suffix that John uses when sending messages
to Jane, so they are forwarded to her BlackBerry with high
priority?
  - A folder for Jane's large collection of Dear John letters?
  - Or is it simply Jane's and John's everyday address?

(Disclosure: I am what might be called a plus sign nut. I routinely 
complain to webmasters and such when their applications try to tell me 
that the plus sign is not allowed in e-mail addresses. If you think I 
feel too strongly about this, you are free to disregard my message.)


--
Christian


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


[HACKERS] Re: [BUGS] rollback to savepoint leads to transaction already in progress

2010-10-14 Thread David Newall

On 14/10/10 12:14, Itagaki Takahiro wrote:

Which solution is better? Or, another idea?
   


This does seem to be an new bug in previously working code.  While any 
solution that fixes the problem is good, it might pay to look the code 
that worked before.  As reported, it worked for ecpg (PostgreSQL 8.3.8) 
4.4.1.


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


Re: [HACKERS] Re: starting to review the Extend NOT NULL representation to pg_constraint patch

2010-10-14 Thread Robert Haas
On Tue, Oct 5, 2010 at 4:57 PM, Bernd Helmle maili...@oopsware.de wrote:
 --On 30. September 2010 10:12:48 +0200 Bernd Helmle maili...@oopsware.de
 wrote:

 Yeah, there where some changes in the meantime to the master which
 generate some merge failures...will provide a new version along with
 other fixes soon

 Here's a new patch that addresses all DDL commands around NOT NULL
 constraints and maintain and follow inheritance information correctly now
 (but it lags documentation updates). I hope i haven't introduced nasty bugs
 and broke something badly, some deeper testing is welcome.

This appears to be waiting on further review from Andrew Geery.
Andrew, will you be posting a new review soon?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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


Re: [HACKERS] string function - format function proposal

2010-10-14 Thread Pavel Stehule
Hello

2010/10/14 Itagaki Takahiro itagaki.takah...@gmail.com:
 Let's make format support %s, %i, and %l, as well as
 allowing things like %$3l (meaning, escape the third argument as a
 literal and interpolate here), and call it good.

 Your idea is:
  % [ $ pos ] format  -- ex. %$3l , %l
  Escapes: %% = %

 Just for information, $ and pos are reversed in C sprintf.
  % [ pos $ ] format  -- ex. %3$l , %l
  Escapes: %% = %

ook - +1 for %3$l


 IMHO, I like {} syntax as like as C# because the format strings are 
 extensible.
  { pos [ : format ] } -- ex {3:l}, {3} (, and {l} could be also supported)
  Escapes: {{ = {, }} = }


I dislike it. The target usage for this function is plpgsql code. I
prefer a simply design - second sprintf is useles. More - {} can be
used in  messages relative often and with your proposal, you have to
intensivelly use a escaping.

Regards

Pavel

 --
 Itagaki Takahiro


-- 
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] ECPG FETCH readahead

2010-10-14 Thread Robert Haas
On Thu, Jun 24, 2010 at 8:19 AM, Michael Meskes mes...@postgresql.org wrote:
 On Thu, Jun 24, 2010 at 12:04:30PM +0300, Heikki Linnakangas wrote:
 Is there a reason not to enable it by default? I'm a bit worried
 that it will receive no testing if it's not always on.

 Yes, there is a reason, namely that you don't need it in native mode at all.
 ECPG can read as many records as you want in one go, something ESQL/C
 apparently cannot do. This patch is a workaround for that restriction. I still
 do not really see that this feature gives us an advantage in native mode
 though.

So, who has the next action on this patch?  Does Zoltan need to revise
it, or does Michael need to review it, or where are we?

Thanks,

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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


Re: [HACKERS] [COMMITTERS] pgsql: Still more tweaking of git_changelog.

2010-10-14 Thread Bruce Momjian
Tom Lane wrote:
  I maintain that if someone else whacked around one of your commits the
  way you whacked this around, you'd bite their head off.
 
 I apologize if I offended you.  I hadn't believed that there was any
 particular consensus on how this script ought to behave; I thought
 it was something you'd whipped up in an hour based on my request for
 something like cvs2cl, and that making it work more like that would be
 uncontroversial.

I am hoping git_changelog wil be like pgcvslog so I can easily create
the 9.1 major release notes someday.

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

  + It's impossible for everything to be true. +

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


Re: [HACKERS] [BUGS] rollback to savepoint leads to transaction already in progress

2010-10-14 Thread Itagaki Takahiro
On Thu, Oct 14, 2010 at 3:52 PM, David Newall
postgre...@davidnewall.com wrote:
 This does seem to be an new bug in previously working code.  While any
 solution that fixes the problem is good, it might pay to look the code that
 worked before.  As reported, it worked for ecpg (PostgreSQL 8.3.8) 4.4.1.

It works on 8.3, but it's still broken. Here is the code in 8.3.
It ignores ROLLBACK TO savepoint, but also ignores ROLLBACK TRANSACTION.


if (strcmp(transaction, commit) == 0 || strcmp(transaction, rollback) == 0)
   con-committed = true;
else
   con-committed = false;


-- 
Itagaki Takahiro

-- 
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] Why do we have a database specification in .pgpass?

2010-10-14 Thread Andrew Dunstan



On 10/13/2010 02:32 PM, Bruce Momjian wrote:

We have a database specification in .pgpass:

hostname:port:database:username:password

What is the purpose of 'database' since username/password combinations
are global, not per database?  I would like to documents its purpose.


If you use wildcards for some of the other params it could well be useful.

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] string function - format function proposal

2010-10-14 Thread Itagaki Takahiro
 Let's make format support %s, %i, and %l, as well as
 allowing things like %$3l (meaning, escape the third argument as a
 literal and interpolate here), and call it good.

Your idea is:
  % [ $ pos ] format  -- ex. %$3l , %l
  Escapes: %% = %

Just for information, $ and pos are reversed in C sprintf.
  % [ pos $ ] format  -- ex. %3$l , %l
  Escapes: %% = %

IMHO, I like {} syntax as like as C# because the format strings are extensible.
  { pos [ : format ] } -- ex {3:l}, {3} (, and {l} could be also supported)
  Escapes: {{ = {, }} = }

-- 
Itagaki Takahiro

-- 
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] string function - format function proposal

2010-10-14 Thread Robert Haas
On Wed, Oct 13, 2010 at 10:03 PM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
 On Thu, Oct 14, 2010 at 10:23 AM, Robert Haas robertmh...@gmail.com wrote:
 On Wed, Sep 29, 2010 at 3:59 AM, Pavel Stehule pavel.steh...@gmail.com 
 wrote:
 [ updated patch, in response to a review from Itagaki Takahiro ]

 This patch appears to be waiting for a second round of review.
 Itagaki-san, are you planning to do that?

 I can, but I was waiting for other people's comments about the design:
  - format() in core, that implements %s, %i, and %l.
  - substitute() for $n format and sprintf() that partially implements
    the same function in C in contrib/stringfunc.

 I don't like having three similar functions for the same purpose,
 but Pavel said they are the best solutions. What will be our consensus?

rereads thread

I agree with you.  I think we should pick one implementation and just
go with it.  There's nothing to say that Pavel can't distribute his
own code however he likes, but I don't think there's any compelling
reason for us to carry all that code in the main tree, even in
/contrib.  Let's make format support %s, %i, and %l, as well as
allowing things like %$3l (meaning, escape the third argument as a
literal and interpolate here), and call it good.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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


Re: [HACKERS] Re: starting to review the Extend NOT NULL representation to pg_constraint patch

2010-10-14 Thread Andrew Geery
I'll post it sometime tomorrow...
Thanks
Andrew

On Wed, Oct 13, 2010 at 9:25 PM, Robert Haas robertmh...@gmail.com wrote:
 On Tue, Oct 5, 2010 at 4:57 PM, Bernd Helmle maili...@oopsware.de wrote:
 --On 30. September 2010 10:12:48 +0200 Bernd Helmle maili...@oopsware.de
 wrote:

 Yeah, there where some changes in the meantime to the master which
 generate some merge failures...will provide a new version along with
 other fixes soon

 Here's a new patch that addresses all DDL commands around NOT NULL
 constraints and maintain and follow inheritance information correctly now
 (but it lags documentation updates). I hope i haven't introduced nasty bugs
 and broke something badly, some deeper testing is welcome.

 This appears to be waiting on further review from Andrew Geery.
 Andrew, will you be posting a new review soon?

 --
 Robert Haas
 EnterpriseDB: http://www.enterprisedb.com
 The Enterprise PostgreSQL Company


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


Re: [HACKERS] WIP: extensible enums

2010-10-14 Thread Dean Rasheed
On 13 October 2010 23:17, Robert Haas robertmh...@gmail.com wrote:
 On Wed, Oct 13, 2010 at 7:33 AM, Andrew Dunstan and...@dunslane.net wrote:
 Sorry, got distracted. Here's a new patch that fixes the above and also
 contains some documentation.

 Someone want to review this and (hopefully) mark it Ready for
 Committer?  I see that Brendan Jurd is the reviewer of record in the
 CF app, but it seems Dean Rasheed is the person who has actually
 reviewed it recently.  Either way...


I'm happy to take another look at it, but I'm short on time, so I
doubt that I be able to do anything before the weekend. If anyone
wants to jump in before then, feel free.

Regards,
Dean

 --
 Robert Haas
 EnterpriseDB: http://www.enterprisedb.com
 The Enterprise PostgreSQL Company


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


Re: [HACKERS] Issues with Quorum Commit

2010-10-14 Thread Greg Stark
On Tue, Oct 12, 2010 at 11:50 PM, Robert Haas robertmh...@gmail.com wrote:
 There's another problem here we should think about, too.  Suppose you
 have a master and two standbys.  The master dies.  You promote one of
 the standbys, which turns out to be behind the other.  You then
 repoint the other standby at the one you promoted.  Congratulations,
 your database is now very possible corrupt, and you may very well get
 no warning of that fact.  It seems to me that we would be well-advised
 to install some kind of bullet-proof safeguard against this kind of
 problem, so that you will KNOW that the standby needs to be re-synced.
  I mention this because I have a vague feeling that timelines are
 supposed to prevent you from getting different WAL histories confused
 with each other, but they don't actually cover all the cases that can
 happen.


Why don't the usual protections kick in here? The new record read from
the location the xlog reader is expecting to find it has to have a
valid CRC and a correct back pointer to the previous record. If the
new wal sender is behind the old one then the new record it's sent
won't match up at all.

-- 
greg

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


Re: [HACKERS] WIP: extensible enums

2010-10-14 Thread Robert Haas
On Wed, Oct 13, 2010 at 7:33 AM, Andrew Dunstan and...@dunslane.net wrote:
 Sorry, got distracted. Here's a new patch that fixes the above and also
 contains some documentation.

Someone want to review this and (hopefully) mark it Ready for
Committer?  I see that Brendan Jurd is the reviewer of record in the
CF app, but it seems Dean Rasheed is the person who has actually
reviewed it recently.  Either way...

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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


Re: [HACKERS] wip: functions median and percentile

2010-10-14 Thread Greg Stark
On Wed, Oct 13, 2010 at 5:54 PM, Robert Haas robertmh...@gmail.com wrote:
 Or to put it more bluntly - what is the problem with planner and hash
 agg that all of these functions need to solve?  And why does it need
 a flag in pg_proc?  Why can't't we leave it to the individual
 functions to perform a sort of one is needed?


So I think that's backwards. Why is the function doing data
manipulations like sorts that we usually put in the plan? Is there
some some key meta information that should be flagged in pg_proc and
general functionality the executor should be providing so that this
general class of problems can be solved efficiently?

Otherwise I fear lots of things we would expect to be efficient such
as calculating the top, median, and last items in the same sort order
would require three separate sorts of the same data. We have a planner
capable of comparing sort orders and estimating the costs of different
plans, we should be using it.


-- 
greg

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


[HACKERS] Bug in writeTimeLineHistory

2010-10-14 Thread Fujii Masao
Hi,

--
if (recoveryTarget == RECOVERY_TARGET_XID)
snprintf(buffer, sizeof(buffer),
 %s%u\t%s\t%s transaction %u\n,
 (srcfd  0) ?  : \n,
 parentTLI,
 xlogfname,
 recoveryStopAfter ? after : before,
 recoveryStopXid);
if (recoveryTarget == RECOVERY_TARGET_TIME)
snprintf(buffer, sizeof(buffer),
 %s%u\t%s\t%s %s\n,
 (srcfd  0) ?  : \n,
 parentTLI,
 xlogfname,
 recoveryStopAfter ? after : before,
 timestamptz_to_str(recoveryStopTime));
else
snprintf(buffer, sizeof(buffer),
 %s%u\t%s\tno recovery target specified\n,
 (srcfd  0) ?  : \n,
 parentTLI,
 xlogfname);
--

In writeTimeLineHistory, the result of the above first snprintf is always
overwritten by the following snprintf wrongly. I guess we forgot putting
else in the second if statement. I attached the very simple patch.

Since this bug was introduced in v9.0, the patch needs to be backported
to 9.0.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


add_else_v1.patch
Description: Binary data

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


Re: [HACKERS] duplicate connection failure messages

2010-10-14 Thread Magnus Hagander
On Wed, Oct 13, 2010 at 21:21, Peter Eisentraut pete...@gmx.net wrote:
 This surprised me:

 psql -p 5 -h localhost
 psql: could not connect to server: Connection refused
        Is the server running on host localhost and accepting
        TCP/IP connections on port 5?
 could not connect to server: Connection refused
        Is the server running on host localhost and accepting
        TCP/IP connections on port 5?

 It shows the same error message twice.  I can reproduce this back to PG
 8.2.

 It appears to have something to do with localhost resolving to an IPv4
 and an IPv6 address, since it doesn't happen with other host names that
 only resolve to one address.  However, fe-connect.c claims:

    /*
     * Try to initiate a connection to one of the addresses
     * returned by pg_getaddrinfo_all().  conn-addr_cur is the
     * next one to try. We fail when we run out of addresses
     * (reporting the error returned for the *last* alternative,
     * which may not be what users expect :-().
     */

That comment is out of date. I implemented the keep all error
messages and append them to each other feature to make sure it didn't
throw away the interesting error message and replaced it with a
generic one later, must've missed that comment - at least it should be
changed. And I agree it's not very friendly in this specific case - I
wonder if we should log it as localhost (127.0.0.1) and localhost
(::1) (and similar for any other case that returns more than one
address).


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

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


[HACKERS] signal and startup process

2010-10-14 Thread Fujii Masao
Hi,

It takes nonsensically extra several seconds to shut down the standby server.
This is because the startup process cannot respond immediately the SIGTERM
signal sent by postmaster for the shutdown while it's sleeping on WaitLatch.
This delays the shutdown for up to the sleep time on WaitLatch (currently
5 seconds).

The signal handlers of the startup process should call SetLatch to respond
the signals even while it's sleeping on WaitLatch, like those of walsender
already do. The attached patch does this.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


signal_handler_wakeup_recovery_v1.patch
Description: Binary data

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


Re: [HACKERS] Why do we have a database specification in .pgpass?

2010-10-14 Thread Dennis Björklund
 We have a database specification in .pgpass:

   hostname:port:database:username:password

 What is the purpose of 'database' since username/password combinations
 are global, not per database?  I would like to documents its purpose.

There is the GUC parameter db_user_namespace. Just for that you could
probably  use den...@foo as username instead, so maybe it's not the
purpose. But I can't think of any other reason.

/Dennis


-- 
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] wip: functions median and percentile

2010-10-14 Thread Robert Haas
On Wed, Oct 13, 2010 at 6:56 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
 2010/10/13 Pavel Stehule pavel.steh...@gmail.com:
 2010/10/13 Peter Eisentraut pete...@gmx.net:
 On mån, 2010-10-11 at 20:46 +0200, Pavel Stehule wrote:
 The problem is in interface. The original patch did it, but I removed
 it. We cannot to unsure immutability of some parameters now.

 How about you store the immutable parameter in the transition state
 and error out if it changes between calls?


 yes, it's possibility. Now I looking there and I see the as more
 important problem the conformance with ANSI SQL. see my last post.
 There can be a kind of aggregate functions based on tuplesort.

 more - all these functions needs to solve same problem with planner
 and hash agg. So maybe is time to add a flag ISTUPLESORTED to pg_proc
 and add solve these functions together.

I think that the design of this patch is still sufficiently up in the
air that it is not going to be practical to get it committed during
the current CommitFest, which is nearly over, so I am going to mark it
as Returned with Feedback.  I suggest that we continue discussing it,
however, so that we can get things squared away for the next
CommitFest.  It seems that the fundamental question here is whether
median is an instance of some more general problem, or whether it's a
special case; and more importantly, if it is an instance of a more
general problem, what is the shape of that general problem?

Or to put it more bluntly - what is the problem with planner and hash
agg that all of these functions need to solve?  And why does it need
a flag in pg_proc?  Why can't't we leave it to the individual
functions to perform a sort of one is needed?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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


Re: [HACKERS] How to reliably detect if it's a promoting standby

2010-10-14 Thread Tatsuo Ishii
Ok, it seems impossible to do that by using any public interfaces
currently available in PostgreSQL 9.0. I will create a custom C
function to be distributed along with pgpool-II.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

 Hi,
 
 I'm looking for a way to reliably detect if it's a promoting
 standby. This is neccessary for pgpool-II manage streaming replication
 clusters. When primary goes down, standby *could* start promoting to
 primary. The only way to find it is calling
 pg_is_in_recovery(). Problem is, it returns true even if standby is
 promoting. If pgpool-II waits for cetain period, it may finishes
 promotion, thus it returns false. But how long should we wait?
 
 Any idea?
 --
 Tatsuo Ishii
 SRA OSS, Inc. Japan
 English: http://www.sraoss.co.jp/index_en.php
 Japanese: http://www.sraoss.co.jp
 
 -- 
 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] First patch proposal

2010-10-14 Thread Alastair Turner
Hi

I am a keen Postgres user and I run my local PUG (JNBPUG in Gauteng,
South Africa), but I have found the idea of contributing on a code
level daunting.

Having read the many warnings along the lines of It's still on the
todo because it isn't trivial I have identified what I believe is a
manageble task for my first patch and expect to have the time to
tackle it at the end of the month. I think the proposed changes are
small enough for a first attempt and I don't find anything in the
archives suggesting that the outcome I am proposing was deliberately
avoided.

I am proposing altering psql to raise certain errors and exit before
prompting for a password. These errors would have to be on items which
didn't leak any information, my current list is:
 - Does the input file (-f) exist and is it readable
 - Do paths to the output files ( -o and -l) exist and are they writable
 - Is the host/socket listening (-h)

This is obviously scratching an itch of my own - I end up capturing
passwords and then getting errors from mistyped input files on a
regular basis. I don't think that I'm the only person to have the
problem though (at least I hope not).

Does this sound like a sane, desirable set of changes?

Regards

Alastair Bell Turner

Technical Lead
^F5

-- 
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] ECPG FETCH readahead

2010-10-14 Thread Boszormenyi Zoltan
Hi,

Robert Haas írta:
 On Thu, Jun 24, 2010 at 8:19 AM, Michael Meskes mes...@postgresql.org wrote:
   
 On Thu, Jun 24, 2010 at 12:04:30PM +0300, Heikki Linnakangas wrote:
 
 Is there a reason not to enable it by default? I'm a bit worried
 that it will receive no testing if it's not always on.
   
 Yes, there is a reason, namely that you don't need it in native mode at all.
 ECPG can read as many records as you want in one go, something ESQL/C
 apparently cannot do. This patch is a workaround for that restriction. I 
 still
 do not really see that this feature gives us an advantage in native mode
 though.
 

 So, who has the next action on this patch?  Does Zoltan need to revise
 it, or does Michael need to review it, or where are we?
   

Michael reviewed it shortly in private and I need to send
a new revision anyway, regardless of his comments.
I will refresh it ASAP.

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

-- 
--
Zoltán Böszörményi
Cybertec Schönig  Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
 http://www.postgresql.at/


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


Re: [HACKERS] SQL command to edit postgresql.conf, with comments

2010-10-14 Thread Dimitri Fontaine
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
 Ok, now, some people want to still be able to edit the files by hand

I wonder if providing a system function to load some configuration
option from a file, using the current parser, would do it:

  SELECT pg_load_conf('path/to/filename.conf', permament = true);

Of course comments are ignored. Settings in the directory would be
changed according to what's in your file, so that it'd be roughtly
equivalent as current steps:
 a. edit the file
 b. use pg_load_conf() rather than pg_reload_conf()

Comments?
-- 
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

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


Re: [DOCS] [HACKERS] Docs for archive_cleanup_command are poor

2010-10-14 Thread Brendan Jurd
On 14 October 2010 08:45, Robert Haas robertmh...@gmail.com wrote:
 Is someone working on a patch?

Yes, I will prepare a patch to get us started.

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] [JDBC] Support for JDBC setQueryTimeout, et al.

2010-10-14 Thread Robert Haas
On Wed, Oct 13, 2010 at 2:27 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
 Rados*aw Smogurarsmog...@softperience.eu wrote:

 I updated patch to latets CVS version, I didn't have time to
 remove some trashes from it.

 If something will be wrong with patch, give a feedback.

 I skimmed it and agree that it is the right general approach --
 using java.util.Timer to trigger the cancel method.  It doesn't
 confuse the function of the setQueryTimeout method of the JDBC
 driver with the statement_timeout GUC of PostgreSQL, which strike me
 as no more or less similar to each other than the brakes on my car
 are to a highway guardrail -- both are designed to stop something,
 but under different circumstances.

 I certainly can't fault you for lack of testing, since about
 two-thirds of the patch is testing classes.  I didn't see any need
 to include the last two classes (ByteConverter and
 InfiniteTimerTask); can you explain why those are in there?

 That said, some of the details of the implementation gave me pause
 -- there seem to be rather more moving parts and more places to
 check things than the overall complexity of the problem would seem
 to warrant; however, it's entirely possible that on closer review
 I'll find that they were necessary for reasons which escape me on a
 quick scan of the code.

 If you could add this to the open CommitFest, I'll be glad to review
 it (if nobody beats me to it):

 https://commitfest.postgresql.org/action/commitfest_view/open

Is this a JDBC patch or a PG patch?  Are we tracking JDBC patches
using the CF app?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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


Re: [HACKERS] string function - format function proposal

2010-10-14 Thread Pavel Stehule
2010/10/14 Robert Haas robertmh...@gmail.com:
 On Wed, Oct 13, 2010 at 10:03 PM, Itagaki Takahiro
 itagaki.takah...@gmail.com wrote:
 On Thu, Oct 14, 2010 at 10:23 AM, Robert Haas robertmh...@gmail.com wrote:
 On Wed, Sep 29, 2010 at 3:59 AM, Pavel Stehule pavel.steh...@gmail.com 
 wrote:
 [ updated patch, in response to a review from Itagaki Takahiro ]

 This patch appears to be waiting for a second round of review.
 Itagaki-san, are you planning to do that?

 I can, but I was waiting for other people's comments about the design:
  - format() in core, that implements %s, %i, and %l.
  - substitute() for $n format and sprintf() that partially implements
    the same function in C in contrib/stringfunc.

 I don't like having three similar functions for the same purpose,
 but Pavel said they are the best solutions. What will be our consensus?

 rereads thread

 I agree with you.  I think we should pick one implementation and just
 go with it.  There's nothing to say that Pavel can't distribute his
 own code however he likes, but I don't think there's any compelling
 reason for us to carry all that code in the main tree, even in
 /contrib.  Let's make format support %s, %i, and %l, as well as
 allowing things like %$3l (meaning, escape the third argument as a
 literal and interpolate here), and call it good.


my objection to put all to one functions was a format complexity and
little bit less readability - like %$3. But I am not strong it this.

Regards

Pavel Stehule



 --
 Robert Haas
 EnterpriseDB: http://www.enterprisedb.com
 The Enterprise PostgreSQL Company


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


Re: [HACKERS] wip: functions median and percentile

2010-10-14 Thread Pavel Stehule
2010/10/14 Robert Haas robertmh...@gmail.com:
 On Wed, Oct 13, 2010 at 6:56 AM, Pavel Stehule pavel.steh...@gmail.com 
 wrote:
 2010/10/13 Pavel Stehule pavel.steh...@gmail.com:
 2010/10/13 Peter Eisentraut pete...@gmx.net:
 On mån, 2010-10-11 at 20:46 +0200, Pavel Stehule wrote:
 The problem is in interface. The original patch did it, but I removed
 it. We cannot to unsure immutability of some parameters now.

 How about you store the immutable parameter in the transition state
 and error out if it changes between calls?


 yes, it's possibility. Now I looking there and I see the as more
 important problem the conformance with ANSI SQL. see my last post.
 There can be a kind of aggregate functions based on tuplesort.

 more - all these functions needs to solve same problem with planner
 and hash agg. So maybe is time to add a flag ISTUPLESORTED to pg_proc
 and add solve these functions together.

 I think that the design of this patch is still sufficiently up in the
 air that it is not going to be practical to get it committed during
 the current CommitFest, which is nearly over, so I am going to mark it
 as Returned with Feedback.  I suggest that we continue discussing it,
 however, so that we can get things squared away for the next
 CommitFest.  It seems that the fundamental question here is whether
 median is an instance of some more general problem, or whether it's a
 special case; and more importantly, if it is an instance of a more
 general problem, what is the shape of that general problem?

+1

Median implemented as special case of some special sort of functions
will be better. The use case of ANSI SQL functions are more general -
but it needs discussion about design. I didn't find too much
consistency in standard. These functions are defined individually -
not as some special kind of functions. All functions from standard has
a immutable parameters - but Oracle listagg function has one parameter
mutable and second immutable.

More we should better to solve using these functions together with
window clause. I didn't find any note about using combination in
standard, but minimally Oracle allows a within_group and over clauses
together.

On second hand - this work can be really useful. We can get a bigger
conformity with ANSI SQL 200x and with other db - DB2, Oracle, MSSQL,
Sybase support this feature.


 Or to put it more bluntly - what is the problem with planner and hash
 agg that all of these functions need to solve?  And why does it need
 a flag in pg_proc?  Why can't't we leave it to the individual
 functions to perform a sort of one is needed?

These functions are hungry - It takes a 30 kb (minimum tuplesort) per
group. More there is relative general pattern, that can be shared -
there can be minimaly 6 functions, that just fill tuplesort in
iterations - so these code can be shared, tuplesort can be reseted and
used respectively. And it's question if requested sort can be used in
outer optimalizations. Primary thing for solving is memory usage.

Regards

Pavel Stehule



 --
 Robert Haas
 EnterpriseDB: http://www.enterprisedb.com
 The Enterprise PostgreSQL Company


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


Re: [HACKERS] string function - format function proposal

2010-10-14 Thread Robert Haas
On Wed, Sep 29, 2010 at 3:59 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
 [ updated patch, in response to a review from Itagaki Takahiro ]

This patch appears to be waiting for a second round of review.
Itagaki-san, are you planning to do that?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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


Re: [HACKERS] ask for review of MERGE

2010-10-14 Thread Robert Haas
On Wed, Sep 29, 2010 at 2:44 AM, Greg Smith g...@2ndquadrant.com wrote:
 Starting looking at the latest MERGE patch from Boxuan here tonight. The
 regression tests pass for me here, good starting sign. I expect to move onto
 trying to break it more creatively next, then onto performance tests.
 Nothing much more exciting than that to report so far.

Greg, are you still working on a review of this patch?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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


Re: [HACKERS] patch: SQL/MED(FDW) DDL

2010-10-14 Thread Robert Haas
On Tue, Oct 12, 2010 at 2:27 AM, Shigeru HANADA
han...@metrosystems.co.jp wrote:
 Thanks for the review!
 I'll finish the SQL/MED patch by applying your comments.

I think this patch has gotten as much review as we can reasonably give
it this CommitFest (which is about to end), so I'm going to mark it
Returned with Feedback.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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


[HACKERS] knngist plans

2010-10-14 Thread Marios Vodas
I would like to ask in which future version of postgresql knngist is planned
to be included. Is there any possibility to be included in 9.1?


Re: [HACKERS] Per-column collation, work in progress

2010-10-14 Thread Robert Haas
On Fri, Sep 24, 2010 at 1:57 AM, Peter Eisentraut pete...@gmx.net wrote:
 On fre, 2010-09-24 at 09:32 +0900, Itagaki Takahiro wrote:
 On Wed, Sep 22, 2010 at 10:29 PM, Peter Eisentraut pete...@gmx.net wrote:
  We could support it also on MSVC.
  http://msdn.microsoft.com/en-us/library/a7cwbx4t(v=VS.90).aspx -- 
  _strcoll_l
  http://msdn.microsoft.com/en-us/library/45119yx3(v=VS.90).aspx -- 
  _towupper_l
 
  Great.

 If we support both glibc and msvc, how to we handle CREATE TABLE DDLs
 in pg_dump? Since collation names depend on platforms, a backup dumped
 at UNIX cannot be reloaded to Windows. We might need to normalize
 locale names to generate a portable dump.

 It is not necessary that the SQL collation names are the same as the OS
 locale names.  That is just a convenient way to initialize it.  If you
 need to transport dumps, you can create your own SQL collation entry at
 the target that locally fits what you are trying to do (or perhaps
 rename the collation at the source).

 I don't think there is a universally applicable way to normalize
 locale names, because we want to support user-defined OS locales.

What's the status of this patch?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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


Re: [DOCS] [HACKERS] Docs for archive_cleanup_command are poor

2010-10-14 Thread Robert Haas
On Tue, Oct 12, 2010 at 8:28 AM, Fujii Masao masao.fu...@gmail.com wrote:
 On Sat, Oct 9, 2010 at 10:04 AM, Brendan Jurd dire...@gmail.com wrote:
 Hi folks,

 I have just set up HS+SR for the first time, and for the most part,
 the docs were excellent.  The one exception for me was the discussion
 of archive_cleanup_command.  This is a pretty important part of
 constructing a healthy standby server, and IMO the docs don't give it
 the treatment it deserves.

 Under 25.2.4. Setting Up a Standby Server, we have:

 You can use archive_cleanup_command to prune the archive of files no
 longer needed by the standby.

 ... then a few paragraphs later ...

 If you're using a WAL archive, its size can be minimized using the
 archive_cleanup_command  option to remove files that are no longer
 required by the standby server. Note however, that if you're using the
 archive for backup purposes, you need to retain files needed to
 recover from at least the latest base backup, even if they're no
 longer needed by the standby.

 So there are a couple of brief mentions of what
 archive_cleanup_command is for, but nothing about how it works, no
 exampes of how to use it, and no links at all.  Contrast how we deal
 with archive_command, restore_command and primary_conninfo.

 I'd like to suggest a few ways we could improve on this:

 1. Remove the former paragraph.  It's stranded out there on its own in
 the middle of some unrelated text, and doesn't say anything of
 substance not also said in the latter paragraph.

 2. Include an example archive_cleanup_command in the recovery.conf
 example snippet.

 3. Link to 26.1 which actually explains how a_c_c works.

 4. Mention, and link to, pg_archivecleanup from both 25.2.4 and 26.1.
 This is the utility that most newcomers to WAL archiving will want to
 use, so it's rather weird of us not to advertise it.

 I'm willing to write a patch for this, but I thought I'd raise the
 suggestions on-list first, before getting too invested.  So, please
 comment if you have an opinion on this.

 Agreed.

Is someone working on a patch?

 And, ISTM that we should mention that we must not just specify
 pg_archivecleanup in archive_cleanup_command when there are multiple
 standby servers. This is because, in that case, we must calculate
 the oldest restart point in those standbys and delete the archived
 WAL files according to that point.

How do we expect people to do that, by the way?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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


[HACKERS] Re: [BUGS] rollback to savepoint leads to transaction already in progress

2010-10-14 Thread Michael Meskes

Am 14.10.2010 08:52, schrieb David Newall:

On 14/10/10 12:14, Itagaki Takahiro wrote:

Which solution is better? Or, another idea?


This does seem to be an new bug in previously working code. While any
solution that fixes the problem is good, it might pay to look the code
that worked before. As reported, it worked for ecpg (PostgreSQL 8.3.8)
4.4.1.


You seem to be answering to an email that I didn't see and couldn't find 
in the archive either. Was it send in private or to the list? If it went 
to the list I might be lagging behind.


Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at googlemail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

--
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] How to reliably detect if it's a promoting standby

2010-10-14 Thread Itagaki Takahiro
On Thu, Oct 14, 2010 at 11:10 AM, Tatsuo Ishii is...@postgresql.org wrote:
 Ok, it seems impossible to do that by using any public interfaces
 currently available in PostgreSQL 9.0. I will create a custom C
 function to be distributed along with pgpool-II.

Could you submit the function for 9.1? Thanks :-)

-- 
Itagaki Takahiro

-- 
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] Issues with Quorum Commit

2010-10-14 Thread Robert Haas
On Wed, Oct 13, 2010 at 5:22 AM, Fujii Masao masao.fu...@gmail.com wrote:
 On Wed, Oct 13, 2010 at 3:50 PM, Robert Haas robertmh...@gmail.com wrote:
 There's another problem here we should think about, too.  Suppose you
 have a master and two standbys.  The master dies.  You promote one of
 the standbys, which turns out to be behind the other.  You then
 repoint the other standby at the one you promoted.  Congratulations,
 your database is now very possible corrupt, and you may very well get
 no warning of that fact.  It seems to me that we would be well-advised
 to install some kind of bullet-proof safeguard against this kind of
 problem, so that you will KNOW that the standby needs to be re-synced.

 Yep. This is why I said it's not easy to implement that.

 To start the standby without taking a base backup from new master after
 failover, the user basically has to promote the standby which is ahead
 of the other standbys (e.g., by comparing pg_last_xlog_replay_location
 on each standby).

 As the safeguard, we seem to need to compare the location at the switch
 of the timeline on the master with the last replay location on the standby.
 If the latter location is ahead AND the timeline ID of the standby is not
 the same as that of the master, we should emit warning and terminate the
 replication connection.

That doesn't seem very bullet-proof.  You can accidentally corrupt a
standby even when only one time-line is involved. AFAIK, stopping a
standby, removing recovery.conf, and starting it up again does not
change time lines.  You can even shut down the standby, bring it up as
a master, generate a little WAL, shut it back down, and bring it back
up as a standby pointing to the same master.  It would be nice to
embed in each checkpoint record an identifier that changes randomly on
each transition to normal running, so that if you do something like
this we can notice and complain loudly.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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


Re: [HACKERS] string function - format function proposal

2010-10-14 Thread Itagaki Takahiro
On Thu, Oct 14, 2010 at 10:23 AM, Robert Haas robertmh...@gmail.com wrote:
 On Wed, Sep 29, 2010 at 3:59 AM, Pavel Stehule pavel.steh...@gmail.com 
 wrote:
 [ updated patch, in response to a review from Itagaki Takahiro ]

 This patch appears to be waiting for a second round of review.
 Itagaki-san, are you planning to do that?

I can, but I was waiting for other people's comments about the design:
  - format() in core, that implements %s, %i, and %l.
  - substitute() for $n format and sprintf() that partially implements
the same function in C in contrib/stringfunc.

I don't like having three similar functions for the same purpose,
but Pavel said they are the best solutions. What will be our consensus?

-- 
Itagaki Takahiro

-- 
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] Issues with Quorum Commit

2010-10-14 Thread Fujii Masao
On Thu, Oct 14, 2010 at 11:18 AM, Greg Stark gsst...@mit.edu wrote:
 Why don't the usual protections kick in here? The new record read from
 the location the xlog reader is expecting to find it has to have a
 valid CRC and a correct back pointer to the previous record.

Yep. In most cases, those protections seem to be able to make the standby
notice the inconsistency of WAL and then give up continuing replication.
But not in all the cases. We can regard those protections as bullet-proof
safeguard?

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

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


Re: [HACKERS] Why do we have a database specification in .pgpass?

2010-10-14 Thread Pavel Golub
Hello, Bruce.

You wrote:

BM We have a database specification in .pgpass:

BM hostname:port:database:username:password

BM What is the purpose of 'database' since username/password combinations
BM are global, not per database?  I would like to documents its purpose.

BM -- 
BM   Bruce Momjian  br...@momjian.ushttp://momjian.us
BM   EnterpriseDB http://enterprisedb.com

BM   + It's impossible for everything to be true. +


For future use?

-- 
With best wishes,
 Pavel  mailto:pa...@gf.microolap.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] wip: functions median and percentile

2010-10-14 Thread Robert Haas
On Wed, Oct 13, 2010 at 10:37 PM, Greg Stark gsst...@mit.edu wrote:
 On Wed, Oct 13, 2010 at 5:54 PM, Robert Haas robertmh...@gmail.com wrote:
 Or to put it more bluntly - what is the problem with planner and hash
 agg that all of these functions need to solve?  And why does it need
 a flag in pg_proc?  Why can't't we leave it to the individual
 functions to perform a sort of one is needed?


 So I think that's backwards. Why is the function doing data
 manipulations like sorts that we usually put in the plan? Is there
 some some key meta information that should be flagged in pg_proc and
 general functionality the executor should be providing so that this
 general class of problems can be solved efficiently?

 Otherwise I fear lots of things we would expect to be efficient such
 as calculating the top, median, and last items in the same sort order
 would require three separate sorts of the same data. We have a planner
 capable of comparing sort orders and estimating the costs of different
 plans, we should be using it.

Good point.  I think you're right.  I'm not sure what the best design
for it is, though.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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


Re: [HACKERS] Issues with Quorum Commit

2010-10-14 Thread Robert Haas
On Wed, Oct 13, 2010 at 10:18 PM, Greg Stark gsst...@mit.edu wrote:
 On Tue, Oct 12, 2010 at 11:50 PM, Robert Haas robertmh...@gmail.com wrote:
 There's another problem here we should think about, too.  Suppose you
 have a master and two standbys.  The master dies.  You promote one of
 the standbys, which turns out to be behind the other.  You then
 repoint the other standby at the one you promoted.  Congratulations,
 your database is now very possible corrupt, and you may very well get
 no warning of that fact.  It seems to me that we would be well-advised
 to install some kind of bullet-proof safeguard against this kind of
 problem, so that you will KNOW that the standby needs to be re-synced.
  I mention this because I have a vague feeling that timelines are
 supposed to prevent you from getting different WAL histories confused
 with each other, but they don't actually cover all the cases that can
 happen.


 Why don't the usual protections kick in here? The new record read from
 the location the xlog reader is expecting to find it has to have a
 valid CRC and a correct back pointer to the previous record. If the
 new wal sender is behind the old one then the new record it's sent
 won't match up at all.

There's some kind of logic that rewinds to the beginning of the WAL
segment and tries to replay from there.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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


Re: [HACKERS] [BUGS] rollback to savepoint leads to transaction already in progress

2010-10-14 Thread Robert Haas
On Thu, Oct 14, 2010 at 6:53 AM, Michael Meskes mes...@postgresql.org wrote:
 Am 14.10.2010 08:52, schrieb David Newall:

 On 14/10/10 12:14, Itagaki Takahiro wrote:

 Which solution is better? Or, another idea?

 This does seem to be an new bug in previously working code. While any
 solution that fixes the problem is good, it might pay to look the code
 that worked before. As reported, it worked for ecpg (PostgreSQL 8.3.8)
 4.4.1.

 You seem to be answering to an email that I didn't see and couldn't find in
 the archive either. Was it send in private or to the list? If it went to the
 list I might be lagging behind.

I didn't get it either.  The original report was posted to pgsql-bugs
on October 10.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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


Re: [HACKERS] [JDBC] Support for JDBC setQueryTimeout, et al.

2010-10-14 Thread Robert Haas
On Thu, Oct 14, 2010 at 2:59 AM, Radosław Smogura
rsmog...@softperience.eu wrote:
 On Wed, 13 Oct 2010 21:01:06 -0400, Robert Haas robertmh...@gmail.com
 wrote:
 Is this a JDBC patch or a PG patch?  Are we tracking JDBC patches
 using the CF app?

 It is JDBC patch. I will clean it and submit on this site. I didn't know
 about such application and such process.

I'm not aware that the JDBC folks participate in the CommitFest
process, so it's probably best to work with the folks on pgsql-jdbc to
figure out how they'd like to see this submitted.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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


Re: [HACKERS] string function - format function proposal

2010-10-14 Thread Robert Haas
On Thu, Oct 14, 2010 at 2:25 AM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
 Let's make format support %s, %i, and %l, as well as
 allowing things like %$3l (meaning, escape the third argument as a
 literal and interpolate here), and call it good.

 Your idea is:
  % [ $ pos ] format  -- ex. %$3l , %l
  Escapes: %% = %

 Just for information, $ and pos are reversed in C sprintf.
  % [ pos $ ] format  -- ex. %3$l , %l
  Escapes: %% = %

Oh, woops.  I intended to copy the way C works.

 IMHO, I like {} syntax as like as C# because the format strings are 
 extensible.
  { pos [ : format ] } -- ex {3:l}, {3} (, and {l} could be also supported)
  Escapes: {{ = {, }} = }

My personal preference (and Pavel's, I guess) is to use the C-like
syntax.  But I wouldn't be upset if consensus congealed around some
other option.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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


Re: [HACKERS] [BUGS] rollback to savepoint leads to transaction already in progress

2010-10-14 Thread Itagaki Takahiro
On Mon, Oct 11, 2010 at 7:42 AM, David Newall
postgre...@davidnewall.com wrote:
 Trivial program to demonstrate problem:

 main() {
    ECPGdebug(1,stderr);
    exec sql connect to postgres;
    exec sql set autocommit to off;
    exec sql start transaction;
    exec sql savepoint s;
    exec sql rollback to s;
    exec sql commit;
    return 0;
 }

 Output:
 [28397]: ECPGdebug: set to 1
 [28397]: ECPGconnect: opening database postgres on DEFAULT port DEFAULT
 [28397]: ECPGsetcommit on line 4: action off; connection postgres
 [28397]: ECPGtrans on line 5: action start transaction; connection 
 postgres
 [28397]: ECPGtrans on line 6: action savepoint s; connection postgres
 [28397]: ECPGtrans on line 7: action rollback to s; connection postgres
 [28397]: ECPGtrans on line 8: action commit; connection postgres
 [28397]: ECPGnoticeReceiver: there is already a transaction in progress
 [28397]: raising sqlcode -603

 Problem:
 It shouldn't raise there is already a transaction in progress error,
 particularly when doing a commit.  Remove rollback to s and no problem.

 Environment:
 ecpg (PostgreSQL 8.4.5) 4.5.0
 This appears to be a regression; it doesn't occur with ecpg (PostgreSQL
 8.3.8) 4.4.1

The bug comes from string-based transaction control in ECPGtrans().
The code cannot distinguish ROLLBACK TRANSACTION and ROLLBACK TO savepoint.

if (strncmp(transaction, commit, 6) == 0 || strncmp(transaction,
rollback, 8) == 0)
con-committed = true;
else
con-committed = false;


I think the string-comparison is unreliable. So, I'd like to replace
the code to use PQtransactionStatus(). I have two patches to do it:
The first one (ecpg-trans-quick_20101014.patch) is a quick fix
that replaces only the above test.
The second one (ecpg-trans-full_20101014.patch) replaces all of
struct connection-committed with PQtransactionStatus().

Which solution is better? Or, another idea?

-- 
Itagaki Takahiro


ecpg-trans-full_20101014.patch
Description: Binary data


ecpg-trans-quick_20101014.patch
Description: Binary data

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


Re: [HACKERS] string function - format function proposal

2010-10-14 Thread Andrew Dunstan



On 10/14/2010 08:25 AM, Robert Haas wrote:



IMHO, I like {} syntax as like as C# because the format strings are extensible.
  { pos [ : format ] } -- ex {3:l}, {3} (, and {l} could be also supported)
  Escapes: {{ =  {, }} =  }

My personal preference (and Pavel's, I guess) is to use the C-like
syntax.  But I wouldn't be upset if consensus congealed around some
other option.


They're both somewhat arcane. But I think the C syntax is likely to be 
more familiar to a wider group of users (including, for example, perl 
hackers) than the C# syntax, and is to be preferred on those grounds alone.


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] [JDBC] Support for JDBC setQueryTimeout, et al.

2010-10-14 Thread Kevin Grittner
Robert Haas  wrote:
 
 Is this a JDBC patch or a PG patch? Are we tracking JDBC patches
 using the CF app?
 
If this were the only patch for setQueryTimeout in front of us I
probably wouldn't have suggested that, but this thread started with a
patch proposal to implement the same JDBC feature through adding new
backend functions.  Unless that patch is withdrawn or rejected, it
seems odd for two different groups to be simultaneously considering
patches to implement exactly the same functionality
 
-Kevin

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


Re: [HACKERS] Re: starting to review the Extend NOT NULL representation to pg_constraint patch

2010-10-14 Thread Andrew Geery
Below is my review of the latest iteration of the Extend NOT NULL
Representation to pg_constraint patch found here:
http://archives.postgresql.org/message-id/e57a252dfd60c1fca9173...@amenophis

Thanks
Andrew



Basic questions


Is the patch in context diff format? Yes

Does it apply cleanly to the current git master? Yes
patching file src/backend/catalog/heap.c
patching file src/backend/commands/tablecmds.c
patching file src/backend/parser/parse_utilcmd.c
patching file src/backend/port/pg_latch.c
patching file src/backend/utils/adt/ruleutils.c
Hunk #1 succeeded at 1076 (offset 5 lines).
patching file src/include/catalog/heap.h
patching file src/include/catalog/pg_constraint.h
patching file src/include/nodes/parsenodes.h
patching file src/test/regress/expected/alter_table.out
patching file src/test/regress/expected/cluster.out

However, one of the modified files in the patch is
/src/backend/port/pg_latch.c.  There are no functional changes in this
file, but it does add a line to the top of the file that breaks the
build:

diff --git a/src/backend/port/pg_latch.c b/src/backend/port/pg_latch.c
index ...002f2f4 .
*** a/src/backend/port/pg_latch.c
--- b/src/backend/port/pg_latch.c
***
*** 0 
--- 1 
+ ../../../src/backend/port/unix_latch.c
\ No newline at end of file

Removing the line allows the build to complete successfully.

Overview
==

The impetus for this patch is to prevent a child table from dropping
an inherited not null constraint.  Not only does dropping an inherited
not null constraint violate the spirit of table inheritance, but it
also breaks pg_dump (the dropped constraint on the child table is not
in the dump, so any null values in the child data will be disallowed).

To fix this problem, the patch adds a new constraint type for not null
constraints in the pg_constraint catalog, while continuing to maintain
the attnotnull info in pg_attribute.

Problem
==

In 9.0 and before, not null constraints are tracked in the
pg_attribute.attnotnull.  The problem is that there is nothing in this
catalog that indicates whether the not null constraint is inherited.
However, the pg_constraint catalog does have columns for tracking
whether a constraint is local to the relation or inherited (conislocal
and coninhcount), so it makes sense to add a new constraint type
(contype=’n’) for not null constraints which enables the db to
disallow dropping inherited not null constraints.  Not null
constraints are given the name (conname)
table_name_column_name_not_null.  (Note that this also opens up
the possibility (if, for example, the alter table syntax was changed)
for giving the not null constraint an arbitrary name.)

Here’s a simple example of the problem:

create table foo_parent ( id int not null );
create table foo_child () inherits ( foo_parent );
alter table foo_child alter column id drop not null;
insert into foo_child values ( null );

In 9.0 and before, the db cannot detect that the “alter table ...
alter column ... drop not null” should not be allowed because there is
no information in the pg_attribute catalog to specify that the
relation is inherited.

In this example, with the patch, the pg_constraint catalog has two
additional rows, foo_parent_id_not_null (conislocal=t, coninhcount=0)
and foo_child_id_not_null (conislocal=f, coninhcount=1) and the db can
now detect that the “alter table ... alter column ... drop not null”
statement should be disallowed because the not null constraint on
foo_child is inherited.  The db reports the following error for this
statement:

cannot drop inherited NOT NULL constraint foo_child_id_not_null,
relation foo_child

[perhaps to make this more consistent with the error message produced
when trying to drop, for example, an inherited check constraint,
change the comma to the word “of”]

Basic tests


I performed the following basic SQL tests with the patch:

* create table with a column with a not null constraint -- check that
the not null constraint is recorded in the pg_constraint table
* create table with no not null column constraint; alter table to add
it -- check that the column not null constraint is recorded in the
pg_constraint table
* create parent with a not null column constraint; create child table
that inherits from the parent -- check that both have a not null
column constraint in pg_constraint and that the child’s not null
constraint inherits from the parent’s
* create parent table with no not null column constraint; create child
table that inherits from the parent; alter the parent table to add a
not null column constraint -- check that both the parent and the child
have a not null column constraint in pg_constraint
* create parent table with no not null column constraint; create child
table that inherits from the parent; alter the child table to add a
not null column constraint -- check that there is only a not 

Re: [HACKERS] First patch proposal

2010-10-14 Thread Hitoshi Harada
2010/10/14 Alastair Turner b...@ctrlf5.co.za:
 I am proposing altering psql to raise certain errors and exit before
 prompting for a password. These errors would have to be on items which
 didn't leak any information, my current list is:
  - Does the input file (-f) exist and is it readable
  - Do paths to the output files ( -o and -l) exist and are they writable
  - Is the host/socket listening (-h)

 This is obviously scratching an itch of my own - I end up capturing
 passwords and then getting errors from mistyped input files on a
 regular basis. I don't think that I'm the only person to have the
 problem though (at least I hope not).

 Does this sound like a sane, desirable set of changes?

I think yes. Just for information, did you pick this topic from TODO
list? If so, could you attach links to the entry or to some related
former thread? And in general it is encouraged that you'd better send
one feature per a patch, in order for it to be reviewed and committed
easily, rather than going all the three you mentioned above.

Regards,


-- 
Hitoshi Harada

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


Re: [HACKERS] ask for review of MERGE

2010-10-14 Thread Greg Smith

Robert Haas wrote:

Greg, are you still working on a review of this patch?
  


Yes, just had more distractions while coming to speed up on this area 
than I'd hoped.  I'll get a second round of looking at this done by the 
weekend.


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



--
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] SQL command to edit postgresql.conf, with comments

2010-10-14 Thread Tom Lane
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
 Allow me to insist on this some more, because there's something
 important going on here. The other proposal (.auto) have a major failure
 mode that I don't think is acceptable.

   SET PERMANENT work_mem TO '8 MB';
   select pg_reload_conf();

 There's simply no way after this sequence to guess the current active
 value of work_mem,

Um, other than show work_mem or select from pg_settings?

The fact is that you cannot know the active value anyway without
checking, because what you did with SET PERMANENT might be overridden
in various session-local ways.  The proposal for hand-edited versus
machine-edited files just adds one more layer of possible overrides
to the existing half-dozen layers, all of which are widely considered
features not bugs.  So I see no merit in your argument.

 I'm being told that we're talking about something over 200 files and
 that's too many.

Yup, you're dead right about that.  Backup/restore of configurations
would become a real mess.

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] Why do we have a database specification in .pgpass?

2010-10-14 Thread Kenneth Marshall
On Thu, Oct 14, 2010 at 06:09:35AM +0200, Dennis Bj??rklund wrote:
  We have a database specification in .pgpass:
 
  hostname:port:database:username:password
 
  What is the purpose of 'database' since username/password combinations
  are global, not per database?  I would like to documents its purpose.
 
 There is the GUC parameter db_user_namespace. Just for that you could
 probably  use den...@foo as username instead, so maybe it's not the
 purpose. But I can't think of any other reason.
 
 /Dennis
 

This will allow the same user to save and use automatically different
passwords for each separate database.

Cheers,
Ken

-- 
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] First patch proposal

2010-10-14 Thread Tom Lane
Alastair Turner b...@ctrlf5.co.za writes:
 I am proposing altering psql to raise certain errors and exit before
 prompting for a password. These errors would have to be on items which
 didn't leak any information, my current list is:
  - Does the input file (-f) exist and is it readable
  - Do paths to the output files ( -o and -l) exist and are they writable
  - Is the host/socket listening (-h)

You could probably do the first two (not sure how badly you'd have to
contort the logic in psql, but in principle you could do it).  I'm not
sure I like/believe the last one though.  The prompt for password is
already driven by the server demanding one, isn't it?  So you won't get
one if -h is bad.  If you're thinking of altering the behavior when -W
is specified, I'd be agin it, because I think the point of that switch
is to ensure predictable behavior, ie that the program will ask for a
password no matter how the server responds or doesn't.

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] First patch proposal

2010-10-14 Thread Alastair Turner
On Thu, Oct 14, 2010 at 4:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 Alastair Turner b...@ctrlf5.co.za writes:
 I am proposing altering psql to raise certain errors and exit before
 prompting for a password. These errors would have to be on items which
 didn't leak any information, my current list is:
  - Does the input file (-f) exist and is it readable
  - Do paths to the output files ( -o and -l) exist and are they writable
  - Is the host/socket listening (-h)

 You could probably do the first two (not sure how badly you'd have to
 contort the logic in psql, but in principle you could do it).  I'm not
 sure I like/believe the last one though.  The prompt for password is
 already driven by the server demanding one, isn't it?  So you won't get
 one if -h is bad.  If you're thinking of altering the behavior when -W
 is specified, I'd be agin it, because I think the point of that switch
 is to ensure predictable behavior, ie that the program will ask for a
 password no matter how the server responds or doesn't.

Thanks for the feedback, I'll keep it to the first two then.

Regards

Bell

-- 
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] SQL command to edit postgresql.conf, with comments

2010-10-14 Thread Tom Lane
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
 I wonder if providing a system function to load some configuration
 option from a file, using the current parser, would do it:

   SELECT pg_load_conf('path/to/filename.conf', permament = true);

That seems like a pretty bizarre idea.  The settings wouldn't be
persistent would they?  Or are you proposing this as a substitute
way of providing input for SET PERMANENT?  If so what's the value?
It seems to me that it just introduces unnecessary failure modes
(ie, server can't read file because of permissions) without any
really useful new functionality.

regards, tom lane

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


[HACKERS] UNION DISTINCT in doc

2010-10-14 Thread Hitoshi Harada
I found PostgreSQL accepts UNION DISTINCT but documents don't mention it.

http://www.postgresql.org/docs/9.0/static/sql-select.html#SQL-UNION

select_statement UNION [ ALL ] select_statement

UNION DISTINCT is nothing more than UNION itself, but gram.y
definitely accept it and the SQL standard describes it as well. Should
we add DISTINCT to docs?

Regards,

-- 
Hitoshi Harada

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


[HACKERS] Re: [BUGS] rollback to savepoint leads to transaction already in progress

2010-10-14 Thread David Newall

On Thu, Oct 14, 2010 at 6:53 AM, Michael Meskesmes...@postgresql.org  wrote:


You seem to be answering to an email that I didn't see and couldn't find in
the archive either. Was it send in private or to the list? If it went to the
list I might be lagging behind.
   


On 14/10/10 22:51, Robert Haas wrote:

I didn't get it either.  The original report was posted to pgsql-bugs
on October 10.
   


It might be lag; it'll probably turn up, about 6 seconds after I press *S

 Original Message 
Subject:Re: [BUGS] rollback to savepoint leads to transaction already
in progress
Date:   Thu, 14 Oct 2010 10:44:50 +0900
From:   Itagaki Takahiroitagaki.takah...@gmail.com
To: David Newallpostgre...@davidnewall.com, PostgreSQL Hackers
pgsql-hackers@postgresql.org
CC: pgsql-b...@postgresql.org



On Mon, Oct 11, 2010 at 7:42 AM, David Newall
postgre...@davidnewall.com   wrote:

  Trivial program to demonstrate problem:

  main() {
  ECPGdebug(1,stderr);
  exec sql connect to postgres;
  exec sql set autocommit to off;
  exec sql start transaction;
  exec sql savepoint s;
  exec sql rollback to s;
  exec sql commit;
  return 0;
  }

  Output:
  [28397]: ECPGdebug: set to 1
  [28397]: ECPGconnect: opening database postgres onDEFAULT   portDEFAULT
  [28397]: ECPGsetcommit on line 4: action off; connection postgres
  [28397]: ECPGtrans on line 5: action start transaction; connection 
postgres
  [28397]: ECPGtrans on line 6: action savepoint s; connection postgres
  [28397]: ECPGtrans on line 7: action rollback to s; connection postgres
  [28397]: ECPGtrans on line 8: action commit; connection postgres
  [28397]: ECPGnoticeReceiver: there is already a transaction in progress
  [28397]: raising sqlcode -603

  Problem:
  It shouldn't raise there is already a transaction in progress error,
  particularly when doing a commit.  Remove rollback to s and no problem.

  Environment:
  ecpg (PostgreSQL 8.4.5) 4.5.0
  This appears to be a regression; it doesn't occur with ecpg (PostgreSQL
  8.3.8) 4.4.1


The bug comes from string-based transaction control in ECPGtrans().
The code cannot distinguish ROLLBACK TRANSACTION and ROLLBACK TO savepoint.

if (strncmp(transaction, commit, 6) == 0 || strncmp(transaction,
rollback, 8) == 0)
con-committed = true;
else
con-committed = false;


I think the string-comparison is unreliable. So, I'd like to replace
the code to use PQtransactionStatus(). I have two patches to do it:
The first one (ecpg-trans-quick_20101014.patch) is a quick fix
that replaces only the above test.
The second one (ecpg-trans-full_20101014.patch) replaces all of
struct connection-committed with PQtransactionStatus().

Which solution is better? Or, another idea?

--
Itagaki Takahiro


--
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] SQL command to edit postgresql.conf, with comments

2010-10-14 Thread Dimitri Fontaine
Tom Lane t...@sss.pgh.pa.us writes:
 Um, other than show work_mem or select from pg_settings?

 The fact is that you cannot know the active value anyway without
 checking, because what you did with SET PERMANENT might be overridden
 in various session-local ways.  The proposal for hand-edited versus
 machine-edited files just adds one more layer of possible overrides
 to the existing half-dozen layers, all of which are widely considered
 features not bugs.  So I see no merit in your argument.

I understand that. I just think there are already too many sources for
GUCs and would welcome that there's a single possible source file with a
complete remote editing feature.

-- 
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

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


Re: [HACKERS] SQL command to edit postgresql.conf, with comments

2010-10-14 Thread Dimitri Fontaine
Tom Lane t...@sss.pgh.pa.us writes:
   SELECT pg_load_conf('path/to/filename.conf', permament = true);

 That seems like a pretty bizarre idea.  The settings wouldn't be
 persistent would they?  Or are you proposing this as a substitute
 way of providing input for SET PERMANENT?  If so what's the value?

Yeah, it only has value if those two conditions are met:
 1. there's a single source file possible for the configuration
 2. it's not in the format you'd like it to be for easy hand editing

As the premise aren't reached, I agree such a function would have no value.
-- 
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

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


Re: [HACKERS] First patch proposal

2010-10-14 Thread Alastair Turner
Excerpt from Hitoshi Harada umi.tan...@gmail.com - Thu, Oct 14, 2010
at 4:32 PM:
 Just for information, did you pick this topic from TODO
 list? If so, could you attach links to the entry or to some related
 former thread? And in general it is encouraged that you'd better send
 one feature per a patch, in order for it to be reviewed and committed
 easily, rather than going all the three you mentioned above.

It isn't a TODO item, or related to any previous thread I could find.
When I'm making the changes I'll bear in mind the preference for
multiple small patches. I have a feeling that the changes would be to
the logic structure and that it wouldn't be possible to separate the
implementation of each check though.

Regards

Bell.

-- 
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] UNION DISTINCT in doc

2010-10-14 Thread Tom Lane
Hitoshi Harada umi.tan...@gmail.com writes:
 UNION DISTINCT is nothing more than UNION itself, but gram.y
 definitely accept it and the SQL standard describes it as well. Should
 we add DISTINCT to docs?

I think it'd be hard to describe without confusing people, because
while DISTINCT is a noise word there, it's definitely not a noise
word after SELECT.  And the way that the reference pages are laid
out, it's hard to connect different descriptions of the same
keyword to different usages.  If you can think of a non-forced
way of describing this, fine.  But I don't have a problem with
leaving it as an undocumented standards-compliance nit.

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] SQL command to edit postgresql.conf, with comments

2010-10-14 Thread Tom Lane
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
 I understand that. I just think there are already too many sources for
 GUCs and would welcome that there's a single possible source file with a
 complete remote editing feature.

[ shrug... ]  So don't use the option of hand-editing postgresql.conf.
You're not being forced to do that, and on the other side of the coin,
you shouldn't think that you get to force people who'd rather hand-edit
to change their habits.

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] SQL command to edit postgresql.conf, with comments

2010-10-14 Thread Dimitri Fontaine
Tom Lane t...@sss.pgh.pa.us writes:
 [ shrug... ]  So don't use the option of hand-editing postgresql.conf.
 You're not being forced to do that, and on the other side of the coin,
 you shouldn't think that you get to force people who'd rather hand-edit
 to change their habits.

Sure. I just lose comments. I'll live with that.
-- 
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

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


Re: [HACKERS] How to reliably detect if it's a promoting standby

2010-10-14 Thread Tatsuo Ishii
 On Thu, Oct 14, 2010 at 11:10 AM, Tatsuo Ishii is...@postgresql.org wrote:
 Ok, it seems impossible to do that by using any public interfaces
 currently available in PostgreSQL 9.0. I will create a custom C
 function to be distributed along with pgpool-II.
 
 Could you submit the function for 9.1? Thanks :-)

I can't wait till 9.1 since pgpool-II needs it now. Of course I could
propose a patch against HEAD when I have enough time...

BTW, I have checked xlog.c etc. and probably the only way to know if
the standby is promoting is, to see if ShutdownWalRcv() is called. If
it's called, global variable WalRcvData-walRcvsState is set to other
than WALRCV_RUNNING, I think.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

-- 
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] Docs for archive_cleanup_command are poor

2010-10-14 Thread Brendan Jurd
On 12 October 2010 23:28, Fujii Masao masao.fu...@gmail.com wrote:
 On Sat, Oct 9, 2010 at 10:04 AM, Brendan Jurd dire...@gmail.com wrote:
 I have just set up HS+SR for the first time, and for the most part,
 the docs were excellent.  The one exception for me was the discussion
 of archive_cleanup_command.  This is a pretty important part of
 constructing a healthy standby server, and IMO the docs don't give it
 the treatment it deserves.
...

 Agreed.

 And, ISTM that we should mention that we must not just specify
 pg_archivecleanup in archive_cleanup_command when there are multiple
 standby servers. This is because, in that case, we must calculate
 the oldest restart point in those standbys and delete the archived
 WAL files according to that point.

As promised, here is a patch to try to address $SUBJECT.

Summary of changes:

In 25.2.4. Setting Up a Standby Server:

 * Get rid of the extraneous short paragraph,
 * move the full-size paragraph up to where the now-extinct short para was,
 * add an archive_cleanup_command to the example recovery.conf,
 * flesh out the wording,
 * add links to 26.1 and F.22.

In 26.1. Archive recovery settings:

 * Add detail to the description of how it works,
 * add an example recovery.conf snippet,
 * per Fujii-san's comment, indicate that multi-standby setups require
more finesse,
 * link to F.22.

In F.22. pg_archivecleanup:

 * Edit and clarify wording,
 * standardise label for the archivelocation argument,
 * again indicate the multi-standby issue,
 * link to 25.2.

I'll drop this onto the next open commitfest.  If it passes muster, it
sure wouldn't hurt to backpatch it to 9.0.

Cheers,
BJ
*** a/doc/src/sgml/high-availability.sgml
--- b/doc/src/sgml/high-availability.sgml
***
*** 681,691  protocol to make nodes agree on a serializable transactional 
order.
 /para
  
 para
- You can use varnamearchive_cleanup_command/ to prune the archive of
- files no longer needed by the standby.
-/para
- 
-para
  If you're setting up the standby server for high availability purposes,
  set up WAL archiving, connections and authentication like the primary
  server, because the standby server will work as a primary server after
--- 681,686 
***
*** 697,708  protocol to make nodes agree on a serializable transactional 
order.
--- 692,716 
 /para
  
 para
+ If you're using a WAL archive, its size can be minimized using the xref
+ linkend=archive-cleanup-command parameter to remove files that are no
+ longer required by the standby server.
+ The applicationpg_archivecleanup/ utility is designed specifically to
+ be used with varnamearchive_cleanup_command/ in typical single-standby
+ configurations, see xref linkend=pgarchivecleanup.
+ Note however, that if you're using the archive for backup purposes, you
+ need to retain files needed to recover from at least the latest base
+ backup, even if they're no longer needed by the standby.
+/para
+ 
+para
  A simple example of a filenamerecovery.conf/ is:
  programlisting
  standby_mode = 'on'
  primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
  restore_command = 'cp /path/to/archive/%f %p'
  trigger_file = '/path/to/trigger_file'
+ archive_cleanup_command = 'pg_archivecleanup /path/to/archive %r'
  /programlisting
 /para
  
***
*** 712,725  trigger_file = '/path/to/trigger_file'
  the primary to allow them to be connected simultaneously.
 /para
  
-para
- If you're using a WAL archive, its size can be minimized using
- the varnamearchive_cleanup_command/ option to remove files that are
- no longer required by the standby server. Note however, that if you're
- using the archive for backup purposes, you need to retain files needed
- to recover from at least the latest base backup, even if they're no
- longer needed by the standby.
-/para
/sect2
  
sect2 id=streaming-replication
--- 720,725 
*** a/doc/src/sgml/pgarchivecleanup.sgml
--- b/doc/src/sgml/pgarchivecleanup.sgml
***
*** 8,17 
   /indexterm
  
   para
!   applicationpg_archivecleanup/ is designed to cleanup an archive when 
used
!   as an literalarchive_cleanup_command/literal when running with
!   literalstandby_mode = on/literal. applicationpg_archivecleanup/ can
!   also be used as a standalone program to clean WAL file archives.
   /para
  
   para
--- 8,18 
   /indexterm
  
   para
!   applicationpg_archivecleanup/ is designed to be used as an
!   literalarchive_cleanup_command/literal to clean up WAL file archives 
when
!   running as a standby server (see xref linkend=warm-standby).
!   applicationpg_archivecleanup/ can also be used as a standalone program 
to
!   clean WAL file archives.
   /para
  
   para
***
*** 39,58 
 server to use applicationpg_archivecleanup/, put this into its
 

Re: [HACKERS] [JDBC] Support for JDBC setQueryTimeout, et al.

2010-10-14 Thread Robert Haas
On Thu, Oct 14, 2010 at 8:55 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
 Robert Haas  wrote:

 Is this a JDBC patch or a PG patch? Are we tracking JDBC patches
 using the CF app?

 If this were the only patch for setQueryTimeout in front of us I
 probably wouldn't have suggested that, but this thread started with a
 patch proposal to implement the same JDBC feature through adding new
 backend functions.  Unless that patch is withdrawn or rejected, it
 seems odd for two different groups to be simultaneously considering
 patches to implement exactly the same functionality

True.  I thought we had decided on the client-side approach, but maybe
I'm confused.  I don't have a position one way or the other, just
trying to understand the state of the conversation.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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


Re: [HACKERS] Path question

2010-10-14 Thread Tom Lane
I wrote:
 I rather wonder if we don't want two separate
 execution-time node types anyway, since what Append does seems
 significantly different from Merge (and MergeAppend would be just a
 misnomer).

I've been working on this patch, and have gotten the executor side split
out as a new node type.  That adds something like 600 lines of
boilerplate code in various places, but I think it's well worthwhile to
get rid of the spaghetti-code effect of retail checks to see which kind
of Append we're dealing with.  (Greg didn't catch all the places that
needed to distinguish, anyway.)

I did run into a problem with my plan to call the new node type Merge:
the planner is already using MergePath as the name for the Path struct
that is precursor to a MergeJoin.  For the moment I'm calling the new
node type MergeAppend, but as mentioned I feel that that's a bit of a
misnomer.

The only good alternative that I can think of is to rename MergePath to
MergeJoinPath (and then for consistency probably also HashPath to
HashJoinPath and NestPath to NestLoopPath).  While that wouldn't touch
a huge number of files, it seems to carry some risk of breaking pending
patches, and anyway those are names that go back to Berkeley days so
people are used to 'em.

Anybody have a strong feeling about what to call these things?
At the moment I'm leaning to sticking with MergeAppend, but if we
decide to rename it it'd probably be better to do so before committing.

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] Path question

2010-10-14 Thread Robert Haas
On Thu, Oct 14, 2010 at 11:34 AM, Tom Lane t...@sss.pgh.pa.us wrote:
 I wrote:
 I rather wonder if we don't want two separate
 execution-time node types anyway, since what Append does seems
 significantly different from Merge (and MergeAppend would be just a
 misnomer).

 I've been working on this patch, and have gotten the executor side split
 out as a new node type.  That adds something like 600 lines of
 boilerplate code in various places, but I think it's well worthwhile to
 get rid of the spaghetti-code effect of retail checks to see which kind
 of Append we're dealing with.  (Greg didn't catch all the places that
 needed to distinguish, anyway.)

 I did run into a problem with my plan to call the new node type Merge:
 the planner is already using MergePath as the name for the Path struct
 that is precursor to a MergeJoin.  For the moment I'm calling the new
 node type MergeAppend, but as mentioned I feel that that's a bit of a
 misnomer.

 The only good alternative that I can think of is to rename MergePath to
 MergeJoinPath (and then for consistency probably also HashPath to
 HashJoinPath and NestPath to NestLoopPath).  While that wouldn't touch
 a huge number of files, it seems to carry some risk of breaking pending
 patches, and anyway those are names that go back to Berkeley days so
 people are used to 'em.

 Anybody have a strong feeling about what to call these things?
 At the moment I'm leaning to sticking with MergeAppend, but if we
 decide to rename it it'd probably be better to do so before committing.

I don't like the idea of renaming the join nodes.  Both the code churn
and the possibility of confusing long-time users seem undesirable.

Let's just stick with MergeAppend.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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


Re: [HACKERS] [JDBC] Support for JDBC setQueryTimeout, et al.

2010-10-14 Thread David Fetter
On Thu, Oct 14, 2010 at 08:22:21AM -0400, Robert Haas wrote:
 On Thu, Oct 14, 2010 at 2:59 AM, Radosław Smogura
 rsmog...@softperience.eu wrote:
  On Wed, 13 Oct 2010 21:01:06 -0400, Robert Haas robertmh...@gmail.com
  wrote:
  Is this a JDBC patch or a PG patch?  Are we tracking JDBC patches
  using the CF app?
 
  It is JDBC patch. I will clean it and submit on this site. I didn't know
  about such application and such process.
 
 I'm not aware that the JDBC folks participate in the CommitFest
 process, so it's probably best to work with the folks on pgsql-jdbc to
 figure out how they'd like to see this submitted.

Perhaps they'd like to participate :)

Cheers,
David.
-- 
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

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

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


Re: [HACKERS] Re: starting to review the Extend NOT NULL representation to pg_constraint patch

2010-10-14 Thread Robert Haas
On Thu, Oct 14, 2010 at 10:02 AM, Andrew Geery andrew.ge...@gmail.com wrote:
 I didn’t have much time to look at the code.  The only thing I’ll
 mention is that there are a couple of XXX TODO items that should be
 cleared up.
[...]
 Since this patch actually makes inheritance behave in a more expected
 way, nothing needs to be changed in the inheritance documentation.
 However, at the very least, the documentation dealing with the
 pg_catalog 
 [http://www.postgresql.org/docs/9.0/interactive/catalog-pg-constraint.html]
 needs to be updated to deal with the new constraint type.

Thanks for catching these problems.

 I did a sanity make clean  make  make check before applying the
 patch and all the tests passed.  After applying the patch and doing
 make clean  make  make check, I got a number of failures of the
 form “FAILED (test process exited with exit code 2)”.  The exact
 number of failures varies by run, so I’m wondering if I didn’t do
 something wrong...

That indicates that PostgreSQL is crashing.  So I think this patch is
definitely not ready for prime time yet, and needs some debugging.  In
view of the fact that we are out of time for this CommitFest, I'm
going to mark this Returned with Feedback in the CommitFest
application.  Hopefully it will be resubmitted for the next CommitFest
after further refinement, because I think this is a good and useful
improvement.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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


Re: [HACKERS] How to reliably detect if it's a promoting standby

2010-10-14 Thread David Fetter
What new public interfaces do you think are needed for 9.1 in this
regard?

Cheers,
David.
On Thu, Oct 14, 2010 at 11:10:14AM +0900, Tatsuo Ishii wrote:
 Ok, it seems impossible to do that by using any public interfaces
 currently available in PostgreSQL 9.0. I will create a custom C
 function to be distributed along with pgpool-II.
 --
 Tatsuo Ishii
 SRA OSS, Inc. Japan
 English: http://www.sraoss.co.jp/index_en.php
 Japanese: http://www.sraoss.co.jp
 
  Hi,
  
  I'm looking for a way to reliably detect if it's a promoting
  standby. This is neccessary for pgpool-II manage streaming replication
  clusters. When primary goes down, standby *could* start promoting to
  primary. The only way to find it is calling
  pg_is_in_recovery(). Problem is, it returns true even if standby is
  promoting. If pgpool-II waits for cetain period, it may finishes
  promotion, thus it returns false. But how long should we wait?
  
  Any idea?
  --
  Tatsuo Ishii
  SRA OSS, Inc. Japan
  English: http://www.sraoss.co.jp/index_en.php
  Japanese: http://www.sraoss.co.jp
  
  -- 
  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

-- 
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

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

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


Re: [HACKERS] Path question

2010-10-14 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes:
 On Thu, Oct 14, 2010 at 11:34 AM, Tom Lane t...@sss.pgh.pa.us wrote:
 Anybody have a strong feeling about what to call these things?
 At the moment I'm leaning to sticking with MergeAppend, but if we
 decide to rename it it'd probably be better to do so before committing.

 I don't like the idea of renaming the join nodes.  Both the code churn
 and the possibility of confusing long-time users seem undesirable.

Yeah, especially if MergePath would still be there but now meaning
something different.

The other possible line of attack is to call the new node type something
else than either Merge or MergeAppend.  Robert and I batted around a few
thoughts off-list last night, but none of them seemed any better than
MergeAppend.

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] Extensions, this time with a patch

2010-10-14 Thread Alvaro Herrera
Excerpts from Dimitri Fontaine's message of mié oct 13 18:11:21 -0300 2010:

 I like both ideas. I'd like to propose that we get back to this part of
 the feature later, after the first patch is in. After all, the main goal
 is to support dumprestore of extensions. Let's do that first.

Okay.  I looked at the code and I have to admit that it seems awkward to
have pg_dump left-joining everything against pg_depend and checking for
NULLs.  I wondered if there was a simpler way to go about it, perhaps
using EXCEPT?  No specific proposal though.
  
 If some of you are interested, the development happens here:
   
 http://git.postgresql.org/gitweb?p=postgresql-extension.git;a=shortlog;h=refs/heads/extension

Thanks.  I managed to retrieve into an already-checked-out copy of HEAD
and it worked pretty well:
git remote add extensions 
git://git.postgresql.org/git/postgresql-extension.git
git fetch extensions extension:extension

then I could run git diff master...extension and see the complete
diff.  Of course, I can also see each commit individually.  Or 
git checkout extension.

Maybe it would be worthwhile to split the parts that parse a file and
execute from a file, and submit separately.  It is obviously
self-contained and serves a useful purpose on its own.  It also forces
you to think harder about renaming the parse function :-)

-- 
Álvaro Herrera alvhe...@commandprompt.com
The PostgreSQL Company - Command Prompt, Inc.
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] duplicate connection failure messages

2010-10-14 Thread Alvaro Herrera
Excerpts from Magnus Hagander's message of jue oct 14 02:30:36 -0300 2010:

 And I agree it's not very friendly in this specific case - I
 wonder if we should log it as localhost (127.0.0.1) and localhost
 (::1) (and similar for any other case that returns more than one
 address).

+1

-- 
Álvaro Herrera alvhe...@commandprompt.com
The PostgreSQL Company - Command Prompt, Inc.
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] [GENERAL] pg_filedump binary for CentOS

2010-10-14 Thread Bruce Momjian
David Boreham wrote:
 
 As far as I can see there is no pre-built pg_filedump binary for the 
 PDGD yum repository (8.3.11 for RHEL5). Before I embark on building it 
 from source I figured I'd ask here if I'm correct that there is no 
 binary hidden somewhere in the packages.

[  CC to hackers.]

Should we consider moving pg_filedump into our /contrib?

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

  + It's impossible for everything to be true. +

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


Re: [HACKERS] Re: starting to review the Extend NOT NULL representation to pg_constraint patch

2010-10-14 Thread Dean Rasheed
On 14 October 2010 16:42, Robert Haas robertmh...@gmail.com wrote:
 In view of the fact that we are out of time for this CommitFest, ...


When is the official end of this commitfest?
I remember talk at the start, that the end would be postponed (by a
week?) due to time spent on the git migration. Is that still the case?

Regards,
Dean

-- 
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] SQL command to edit postgresql.conf, with comments

2010-10-14 Thread Josh Berkus



Sure. I just lose comments. I'll live with that.


Actually, as part of this scheme, it would be nice if pg_settings had a 
comment column, which would be optionally set with SET PERMANENT.  Not 
required, but nice to have.


If we had that, I suspect that a lot fewer people would want a 
hand-edited file.


--
  -- Josh Berkus
 PostgreSQL Experts Inc.
 http://www.pgexperts.com

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


Re: [HACKERS] Per-column collation, work in progress

2010-10-14 Thread Peter Eisentraut
On ons, 2010-10-13 at 19:15 -0400, Robert Haas wrote:
 What's the status of this patch?

I would appreciate some more review of the basic architecture.


-- 
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] duplicate connection failure messages

2010-10-14 Thread Peter Eisentraut
On tor, 2010-10-14 at 07:30 +0200, Magnus Hagander wrote:
 And I agree it's not very friendly in this specific case - I
 wonder if we should log it as localhost (127.0.0.1) and localhost
 (::1) (and similar for any other case that returns more than one
 address).

That looks good.


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


Re: [HACKERS] Re: starting to review the Extend NOT NULL representation to pg_constraint patch

2010-10-14 Thread Bernd Helmle



--On 14. Oktober 2010 11:42:27 -0400 Robert Haas robertmh...@gmail.com 
wrote:



I did a sanity make clean  make  make check before applying the
patch and all the tests passed.  After applying the patch and doing
make clean  make  make check, I got a number of failures of the
form “FAILED (test process exited with exit code 2)”.  The exact
number of failures varies by run, so I’m wondering if I didn’t do
something wrong...


That indicates that PostgreSQL is crashing.  So I think this patch is
definitely not ready for prime time yet, and needs some debugging.  In
view of the fact that we are out of time for this CommitFest, I'm
going to mark this Returned with Feedback in the CommitFest
application.  Hopefully it will be resubmitted for the next CommitFest
after further refinement, because I think this is a good and useful
improvement.


Yeah, its crashing but it doesn't do it here on my MacBook (passing the 
regression test is one of my top prio when submitting a patch). Must be 
some broken pointer or similar oversight which is triggered on Andrew's 
box. Andrew, which OS and architecture have you tested on?


--
Thanks

Bernd

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


Re: [HACKERS] A small update for postgresql.conf.sample

2010-10-14 Thread Bruce Momjian
Robert Haas wrote:
 2010/9/27 Devrim G?ND?Z dev...@gunduz.org:
  On Mon, 2010-09-27 at 09:40 -0400, Robert Haas wrote:
   Actually, I don't see any reason why not to backpatch it.
 
  I was wondering if it would cause package management headaches for
  people who had already modified their postgresql.conf.
 
  We don't overwrite .conf files during upgrades.
 
 All right, have it your way.  Done.  :-)
 
 (Dang this is a lot easier than the old way.)

Uh, I have always been reluctant to backpatch changes to
postgresql.conf.sample because those changes are going to be installed
in share/postgresql.conf.sample during a minor upgrade.  After that, if
someone diffs their data/postgresql.conf with
share/postgresql.conf.sample, they will see change that they did not
make to postgresql.conf.

Not sure you want to revert this changes, but I wanted to be sure people
understood this behavior.

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

  + It's impossible for everything to be true. +

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

2010-10-14 Thread Robert Haas
On Thu, Oct 14, 2010 at 12:44 PM, Dean Rasheed dean.a.rash...@gmail.com wrote:
 On 14 October 2010 16:42, Robert Haas robertmh...@gmail.com wrote:
 In view of the fact that we are out of time for this CommitFest, ...

 When is the official end of this commitfest?
 I remember talk at the start, that the end would be postponed (by a
 week?) due to time spent on the git migration. Is that still the case?

Well, I guess we need to decide that.  It sounds reasonable to me.

However, even if we do that, we do need to start bouncing out fairly
aggressively those patches that are not yet ready to be looked at by a
committer.  There are 58 patches in this CommitFest.  14 were
committed, returned with feedback, or rejected before the official
start of the CommitFest.  So, at the beginning of the CommitFest, we
had roughly 44 patches to deal with.

In the past 30 days, we have committed or returned with feedback 22 of
those 44 patches, or roughly 50%.  In the remaining portion of the
CommitFest, however long we decide to make it, we need to deal with
the remaining 22 of those patches.  At this point in the CommitFest,
we should be in a situation where at least half of the unresolved
patches are Ready for Committer; the actual number is 3 of 22.  We are
way behind.  Some patches haven't even received a FIRST review yet,
and I think it's very important that we make that happen before
closing out the CommitFest.  But if a patch has been reviewed two or
more times and is still not ready, I don't think we can hold the CF
open for it, which means we mark it Returned with Feedback and ask the
author to resubmit for next time.

As another metric, consider that at a comparable point in the last
CommitFest cycle, we had one (1) remaining patch that was neither
Committed, Returned with Feedback, or moved to another CommitFest,
versus 22 at present.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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


Re: [HACKERS] A small update for postgresql.conf.sample

2010-10-14 Thread Robert Haas
2010/10/14 Bruce Momjian br...@momjian.us:
 Robert Haas wrote:
 2010/9/27 Devrim G?ND?Z dev...@gunduz.org:
  On Mon, 2010-09-27 at 09:40 -0400, Robert Haas wrote:
   Actually, I don't see any reason why not to backpatch it.
 
  I was wondering if it would cause package management headaches for
  people who had already modified their postgresql.conf.
 
  We don't overwrite .conf files during upgrades.

 All right, have it your way.  Done.  :-)

 (Dang this is a lot easier than the old way.)

 Uh, I have always been reluctant to backpatch changes to
 postgresql.conf.sample because those changes are going to be installed
 in share/postgresql.conf.sample during a minor upgrade.  After that, if
 someone diffs their data/postgresql.conf with
 share/postgresql.conf.sample, they will see change that they did not
 make to postgresql.conf.

 Not sure you want to revert this changes, but I wanted to be sure people
 understood this behavior.

Yeah, I think the horse has left the barn on these changes, since they
are in 9.0.1 at this point, but it's certainly something to keep in
mind.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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


Re: [HACKERS] [GENERAL] pg_filedump binary for CentOS

2010-10-14 Thread Robert Haas
On Thu, Oct 14, 2010 at 12:41 PM, Bruce Momjian br...@momjian.us wrote:
 David Boreham wrote:

 As far as I can see there is no pre-built pg_filedump binary for the
 PDGD yum repository (8.3.11 for RHEL5). Before I embark on building it
 from source I figured I'd ask here if I'm correct that there is no
 binary hidden somewhere in the packages.

 [  CC to hackers.]

 Should we consider moving pg_filedump into our /contrib?

If it's license-compatible, +1.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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


Re: [HACKERS] UNION DISTINCT in doc

2010-10-14 Thread Robert Haas
On Thu, Oct 14, 2010 at 10:37 AM, Hitoshi Harada umi.tan...@gmail.com wrote:
 I found PostgreSQL accepts UNION DISTINCT but documents don't mention it.

 http://www.postgresql.org/docs/9.0/static/sql-select.html#SQL-UNION

 select_statement UNION [ ALL ] select_statement

 UNION DISTINCT is nothing more than UNION itself, but gram.y
 definitely accept it and the SQL standard describes it as well. Should
 we add DISTINCT to docs?

+1, with due regard for the issue raised by Tom.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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


Re: [HACKERS] A small update for postgresql.conf.sample

2010-10-14 Thread Bruce Momjian
Robert Haas wrote:
 2010/10/14 Bruce Momjian br...@momjian.us:
  Robert Haas wrote:
  2010/9/27 Devrim G?ND?Z dev...@gunduz.org:
   On Mon, 2010-09-27 at 09:40 -0400, Robert Haas wrote:
Actually, I don't see any reason why not to backpatch it.
  
   I was wondering if it would cause package management headaches for
   people who had already modified their postgresql.conf.
  
   We don't overwrite .conf files during upgrades.
 
  All right, have it your way. ?Done. ?:-)
 
  (Dang this is a lot easier than the old way.)
 
  Uh, I have always been reluctant to backpatch changes to
  postgresql.conf.sample because those changes are going to be installed
  in share/postgresql.conf.sample during a minor upgrade. ?After that, if
  someone diffs their data/postgresql.conf with
  share/postgresql.conf.sample, they will see change that they did not
  make to postgresql.conf.
 
  Not sure you want to revert this changes, but I wanted to be sure people
  understood this behavior.
 
 Yeah, I think the horse has left the barn on these changes, since they
 are in 9.0.1 at this point, but it's certainly something to keep in
 mind.

Yes, I suspected that, but it is an effect I wanted to point out for the
future.

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

  + It's impossible for everything to be true. +

-- 
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] SQL command to edit postgresql.conf, with comments

2010-10-14 Thread Robert Haas
On Thu, Oct 14, 2010 at 12:40 PM, Josh Berkus j...@agliodbs.com wrote:

 Sure. I just lose comments. I'll live with that.

 Actually, as part of this scheme, it would be nice if pg_settings had a
 comment column, which would be optionally set with SET PERMANENT.  Not
 required, but nice to have.

 If we had that, I suspect that a lot fewer people would want a hand-edited
 file.

I have to say that I'm woefully unimpressed by the idea of trying to
do anything with comments other than ignore them, even something this
simple.  There's no obvious way to know which comments go with which
settings.   You can make up a rule, such as on the same line, but
it's not necessarily going to be what people want.  I think it's
better to sidestep the issue entirely.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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


Re: [HACKERS] [JDBC] Support for JDBC setQueryTimeout, et al.

2010-10-14 Thread Kevin Grittner
Robert Haas  wrote:
Kevin Grittner  wrote:
 
 I thought we had decided on the client-side approach, but maybe
 I'm confused. I don't have a position one way or the other, just
 trying to understand the state of the conversation.
 
Well, I've been pretty vocal on supporting a client-side solution,
and Rados*aw clearly is in that camp, but that hardly makes a
consensus.  David still has his patch out there, and Tom's comments
seemed to imply that he supports a solution involving the
statement_timeout GUC, so the question hardly seems settled.
 
Regarding JDBC in the CF process -- other interfaces are handled
there.  I haven't seen one patch this size for JDBC since I've been
involved, let alone two competing patches to implement the same
feature.  Small patches which can be quickly handled don't make sense
to put into the process, but it seemed reasonable for these.
 
-Kevin

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


Re: [HACKERS] SQL command to edit postgresql.conf, with comments

2010-10-14 Thread Robert Haas
On Thu, Oct 14, 2010 at 9:50 AM, Tom Lane t...@sss.pgh.pa.us wrote:
 The fact is that you cannot know the active value anyway without
 checking, because what you did with SET PERMANENT might be overridden
 in various session-local ways.  The proposal for hand-edited versus
 machine-edited files just adds one more layer of possible overrides
 to the existing half-dozen layers, all of which are widely considered
 features not bugs.  So I see no merit in your argument.

You know, this is a good point.  I was really hoping for a single
file, but maybe two files is not so bad as I think it is.  However, I
kind of dislike SET PERMANENT as a command name, partly because I
think it sounds more certain than it really is, and partly because
it's asymmetric with the other, similar GUC-setting commands, which
are:

ALTER ROLE name [ IN DATABASE database_name ] SET
configuration_parameter { TO | = } { value | DEFAULT }
ALTER DATABASE name SET configuration_parameter { TO | = } { value | DEFAULT }

Perhaps ALTER SYSTEM SET configuration_parameter { TO | = } { value |
DEFAULT } ?

A similar syntax exists in Oracle:

http://stanford.edu/dept/itss/docs/oracle/10g/server.101/b10759/statements_2013.htm#i2282157

From what I gather this works out to:

ALTER SYSTEM SCOPE = { MEMORY | SPFILE | BOTH } SET
configuration_paramater = value

(I don't think we can the SCOPE clause because I believe the only way
we have of propagating a GUC through the system is to have all the
backends reread the file.)

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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


[HACKERS] Foreign Visual Studio builds

2010-10-14 Thread Greg Smith
We got an interesting documentation document left by Christian Freund 
recently, in regards to 
http://www.postgresql.org/docs/9.0/interactive/install-windows-full.html 
; it says:


Regarding 16.1.3 - perl mkvcbuild.pl

In case you use a German version of VC change line 69 in Solution.pm to:

   if ($line !~ /^Microsoft\s*\(R\) Visual C\+\+-Projekt-Generator - 
\D+(\d+)\.00\.\d+/)



I'm going to approve the doc comment so that it might help someone else 
that runs into this in the short-term, but I thought it was was worth 
sharing as something that might be improved in the build code instead.  
That regex seems a bit too specific.


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



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


Re: [HACKERS] Re: starting to review the Extend NOT NULL representation to pg_constraint patch

2010-10-14 Thread Bernd Helmle



--On 14. Oktober 2010 10:02:12 -0400 Andrew Geery andrew.ge...@gmail.com 
wrote:



The first failure I get is in the inherit tests (tail of
/src/test/regress/results/inherit.out):

alter table a alter column aa type integer using bit_length(aa);
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
Connection to server was lost

This test consistently breaks in this location and breaks for both
make check and make installcheck.


Okay, can reproduce it on a Linux box here, will be back with a fixed 
version.


--
Thanks

Bernd

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


Re: [HACKERS] Re: starting to review the Extend NOT NULL representation to pg_constraint patch

2010-10-14 Thread Dean Rasheed
On 14 October 2010 17:40, Bernd Helmle maili...@oopsware.de wrote:


 --On 14. Oktober 2010 11:42:27 -0400 Robert Haas robertmh...@gmail.com
 wrote:

 I did a sanity make clean  make  make check before applying the
 patch and all the tests passed.  After applying the patch and doing
 make clean  make  make check, I got a number of failures of the
 form “FAILED (test process exited with exit code 2)”.  The exact
 number of failures varies by run, so I’m wondering if I didn’t do
 something wrong...

 That indicates that PostgreSQL is crashing.  So I think this patch is
 definitely not ready for prime time yet, and needs some debugging.  In
 view of the fact that we are out of time for this CommitFest, I'm
 going to mark this Returned with Feedback in the CommitFest
 application.  Hopefully it will be resubmitted for the next CommitFest
 after further refinement, because I think this is a good and useful
 improvement.

 Yeah, its crashing but it doesn't do it here on my MacBook (passing the
 regression test is one of my top prio when submitting a patch). Must be some
 broken pointer or similar oversight which is triggered on Andrew's box.
 Andrew, which OS and architecture have you tested on?


Yeah, it crashes for me too (opensuse 11.2 64-bit) but only in an
optimised build.

There are a couple of compiler warnings:

tablecmds.c: In function 'ATExecSetNotNull':
tablecmds.c:4747: warning: unused variable 'is_new_constraint'
tablecmds.c: In function 'ATExecDropNotNull':
tablecmds.c:4332: warning: 'found' may be used uninitialized in this function
tablecmds.c:4246: warning: 'children' may be used uninitialized in this function

The last 2 look serious enough to cause problems, but fixing them
didn't cure the crash.

Digging deeper, I get a segfault running src/test/regress/sql/alter_table.sql:

Program received signal SIGSEGV, Segmentation fault.
ATExecSetNotNullInternal (is_local=1 '\001',
is_new_constraint=value optimized out, atttup=value optimized out,
attr_rel=value optimized out, rel=value optimized out)
at tablecmds.c:4847
4847Form_pg_constraint constr =
(Form_pg_constraint) GETSTRUCT(copy_tuple);

Looking in that function, there is a similar found variable that
isn't being initialised (which my compiler didn't warn about).
Initialising that to false, sems to fix the problem and all the
regression tests then pass.

Regards,
Dean

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


Re: [HACKERS] Bug in writeTimeLineHistory

2010-10-14 Thread Simon Riggs
Agreed, committed and backpatched.

On Thu, 2010-10-14 at 14:11 +0900, Fujii Masao wrote:
 Hi,
 
 --
   if (recoveryTarget == RECOVERY_TARGET_XID)
   snprintf(buffer, sizeof(buffer),
%s%u\t%s\t%s transaction %u\n,
(srcfd  0) ?  : \n,
parentTLI,
xlogfname,
recoveryStopAfter ? after : before,
recoveryStopXid);
   if (recoveryTarget == RECOVERY_TARGET_TIME)
   snprintf(buffer, sizeof(buffer),
%s%u\t%s\t%s %s\n,
(srcfd  0) ?  : \n,
parentTLI,
xlogfname,
recoveryStopAfter ? after : before,
timestamptz_to_str(recoveryStopTime));
   else
   snprintf(buffer, sizeof(buffer),
%s%u\t%s\tno recovery target specified\n,
(srcfd  0) ?  : \n,
parentTLI,
xlogfname);
 --
 
 In writeTimeLineHistory, the result of the above first snprintf is always
 overwritten by the following snprintf wrongly. I guess we forgot putting
 else in the second if statement. I attached the very simple patch.
 
 Since this bug was introduced in v9.0, the patch needs to be backported
 to 9.0.
 
 Regards,
 

-- 
 Simon Riggs   www.2ndQuadrant.com
 PostgreSQL Development, 24x7 Support, Training and Services


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


  1   2   >