Re: [HACKERS] Issues with two-server Synch Rep
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
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
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?
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
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.
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
* 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
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
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
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
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.
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
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?
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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.
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 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 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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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.
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
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
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
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.
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
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 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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
--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
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
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 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
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
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
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
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.
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
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
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
--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
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
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
