Re: [HACKERS] EOL for 7.4?
On Thu, 2009-11-12 at 23:16 +, Greg Sabino Mullane wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 needs significant preparation for them. Announcing an EOL early in time would give them the required time before the version used disappears. So, should we announce it for June? No, it should be longer. June is practically around the corner as far as business planning is concerned. Make it a year. Since it's mid November, why not just say 2011? If a business wants support they can buy it. There is no reason for this community to continue supporting it. And yes, i'm +1 for having a rule for EOL, like 5 versions are supported. If we released on a consistent schedule, this *might* be possible. But we don't, so we can't say something like this. We can say 5 years from release though. Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering If the world pushes look it in the eye and GRR. Then push back harder. - Salamander -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Application name patch - v3
Hi Dave,
On Thursday 22 October 2009 15:07:13 Dave Page wrote:
Updated patch attached. Per discussion, this:
- Changes the envvar name to PGAPPNAME
- Removes support for setting application_name in the startup packet,
and instead sends an explicit SET command as part of the connection
setup in PQconnectPoll. In order to avoid adding to the
application-visible connection states, this is overloaded on the
CONNECTION_SETENV state which is only used in the v2 protocol at
present and seems like an ideal fit for such a similar use.
I had some free time so I started to take a look at that patch:
+ PostgresPollingStatusType
+ pqAppnamePoll(PGconn *conn)
...
+ case APPNAME_STATE_OPTION_WAIT:
...
+ else
+ {
+ /* Query finished, so we're done */
+ conn-setenv_state = APPNAME_STATE_IDLE;
+ return PGRES_POLLING_OK;
+ }
+ break;
+ }
Shouldnt that set appname_state?
The attached patch fixes this and also a couple occurances of trailing
whitespace.
What about pg_dump/psql setting fallback_application_name?
Andres
From 962861a38ea28c769bb28c18f3142f0339e97f5c Mon Sep 17 00:00:00 2001
From: Andres Freund and...@anarazel.de
Date: Fri, 13 Nov 2009 00:28:44 +0100
Subject: [PATCH] Dave Page: Application name patch - v3
---
doc/src/sgml/config.sgml | 16 +++
doc/src/sgml/libpq.sgml | 37 +
doc/src/sgml/monitoring.sgml | 12 +-
src/backend/catalog/system_views.sql |3 +-
src/backend/postmaster/pgstat.c | 56 ++--
src/backend/utils/adt/pgstatfuncs.c | 16 ++-
src/backend/utils/error/elog.c| 16 +++
src/backend/utils/misc/guc.c | 11 ++
src/backend/utils/misc/postgresql.conf.sample |1 +
src/include/catalog/pg_proc.h |2 +-
src/include/pgstat.h |4 +
src/include/utils/guc.h |2 +
src/interfaces/libpq/fe-connect.c | 177 -
src/interfaces/libpq/libpq-int.h | 12 ++
src/test/regress/expected/rules.out |2 +-
15 files changed, 338 insertions(+), 29 deletions(-)
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index eb2071f..87e6dac 100644
*** a/doc/src/sgml/config.sgml
--- b/doc/src/sgml/config.sgml
*** local0.*/var/log/postgresql
*** 2881,2886
--- 2881,2901
variablelist
varlistentry
+ termvarnameapplication_name/varname (typestring/type)/term
+ indexterm
+primaryvarnameapplication_name/ configuration parameter/primary
+ /indexterm
+ listitem
+para
+ The varnameapplication_name/varname is typically set by an
+ application upon connection to the server. The value will be included
+ in CSV logs and may be included in the varnamelog_line_prefix/varname.
+ In addition, it will be included in the literalpg_stat_activity/ view.
+/para
+ /listitem
+ /varlistentry
+
+ varlistentry
termvarnamedebug_print_parse/varname (typeboolean/type)/term
termvarnamedebug_print_rewritten/varname (typeboolean/type)/term
termvarnamedebug_print_plan/varname (typeboolean/type)/term
*** CREATE TABLE postgres_log
*** 3325,3330
--- 3340,3346
query text,
query_pos integer,
location text,
+ application_name text,
PRIMARY KEY (session_id, session_line_num)
);
/programlisting
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 86affb0..e4576e6 100644
*** a/doc/src/sgml/libpq.sgml
--- b/doc/src/sgml/libpq.sgml
***
*** 249,254
--- 249,281
/listitem
/varlistentry
+ varlistentry id=libpq-connect-application-name xreflabel=application_name
+ termliteralapplication_name/literal/term
+ listitem
+ para
+Allows an application to specify a value for the literalapplication_name/
+ configuration variable, the value of which may be included in logging
+ output and monitoring data from views such as literalpg_stat_activity/.
+ /para
+ /listitem
+ /varlistentry
+
+ varlistentry id=libpq-connect-fallback-application-name xreflabel=fallback_application_name
+ termliteralfallback_application_name/literal/term
+ listitem
+ para
+Allows an application to specify a fallback value for the
+ literalapplication_name/ configuration variable. This value
+ is used if neither the literalapplication_name/ connection
+ string option or envarPGCLIENTENCODING/envar are set,
+ which offers the application
Re: [HACKERS] Listen / Notify rewrite
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Tom Lane writes: Yes. Particularly those complaining that they want to have very large payload strings --- that's pretty much a dead giveaway that it's not being used as a condition signal. I don't want large but I do think an arbitrary limit of 128 is odd without some justfication. I could do 128, but would probably be happier with a bit more room. Now you might say that yeah, that's the point, we're trying to enable using NOTIFY in a different style. The problem is that if you are trying to use NOTIFY as a queue, you will soon realize that it has the wrong semantics for that --- in particular, losing notifies across a system crash or client crash is OK for a condition notification, not so OK for a message queue. The difference is that the former style assumes that the authoritative data is in a table somewhere, so you can still find out what you need to know after reconnecting. If you are doing messaging you are likely to think that you don't need any backing store for the system state. That's putting an awful lot of assumptions on what people are going to do in the future, and also not being imaginative enough for circumstances in which a payload which is not system crash survivable is a completely acceptable condition. In most of my use cases, even desired. People wanting a real queue can continue to use something other than NOTIFY. So while a payload string for NOTIFY has been on the to-do list since forever, I have to think that Greg's got a good point questioning whether it is actually a good idea. Absolutely is a good idea. Agent M asks: The notification count could be a secondary payload which does not affect the first, but I guess I'm the only one complaining about the coalescing... Er...this thread is only a few hours old. For the record, I'm fine with the coalescing as we do now (at least as far as my own selfish purposes :) - -- Greg Sabino Mullane g...@turnstep.com PGP Key: 0x14964AC8 200911121836 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAkr8nCwACgkQvJuQZxSWSsjQIgCgjH60LlZYEek9FwcD+/w4IHYQ PWwAnR0YxdSBm5iBa+G+T1VpIP4qjJsx =Ju0P -END PGP SIGNATURE- -- Sent 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 committers
Kevin Grittner kevin.gritt...@wicourts.gov writes: On the subject topic, I have to say that I don't see where Robert hasn't met the qualifications mentioned so far on this thread as required to promote someone to the committer level; are there some requirements which exist but haven't been mentioned? He hasn't actually written all that much *code* ... yet, anyway. Historically, we've promoted people to being committers when (a) the existing committers got tired of applying patches from them and (b) their patches were usually going in without significant modification. (a) speaks to whether you do enough work regularly enough that there's actually a benefit to the project from giving you the keys to the car, and (b) speaks to whether you're ready in terms of technical knowledge of the code base. (I'm not saying you have to be competent in the whole PG code base, just whatever part you like to work on.) Now those criteria were developed to deal mainly with people committing their own patches. What we have at the moment is a lot of patches coming in from people who aren't ready to be committers, and maybe don't ever want to be. The question is how to do an adequate job of reviewing their patches, when only a fraction of the existing committers are willing to put time into reviewing other people's patches. (Let's face it, that's a lot less fun than writing your own code.) While I'm not against promoting more committers to deal with the influx of patches, the only way I know for people to get to the skill level of being fully competent reviewers is to have done a lot of patch writing themselves. Years ago, somebody (I think one of the original Berkeley crew) remarked this project doesn't need a lot of people with a little time, it needs a few people with a lot of time. I'm afraid that's still true, and it's still hard to find those people. 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] Patch committers
On Thu, Nov 12, 2009 at 6:53 PM, Tom Lane t...@sss.pgh.pa.us wrote: Now those criteria were developed to deal mainly with people committing their own patches. What we have at the moment is a lot of patches coming in from people who aren't ready to be committers, and maybe don't ever want to be. The question is how to do an adequate job of reviewing their patches, when only a fraction of the existing committers are willing to put time into reviewing other people's patches. (Let's face it, that's a lot less fun than writing your own code.) I kind of like reviewing, actually. It's a good way to get familiar with new parts of the code. That's part of the coolness of open source: other people do a lot of your work for you. Of course, that doesn't mean I would want to ONLY review other people's patches and never write any of my own. While I'm not against promoting more committers to deal with the influx of patches, the only way I know for people to get to the skill level of being fully competent reviewers is to have done a lot of patch writing themselves. Years ago, somebody (I think one of the original Berkeley crew) remarked this project doesn't need a lot of people with a little time, it needs a few people with a lot of time. I'm afraid that's still true, and it's still hard to find those people. No, I think it's hard to find those people's salaries. I feel like I've managed a fairly good stream of patches given that this is something I do mostly between 8 PM and midnight after working a full day and in between other things that I need to get done, but if I were getting paid to hack on PostgreSQL full time (or even one or two days a week) that stream would be a whole lot bigger. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Python 3.1 support
On Nov 12, 2009, at 12:54 PM, Peter Eisentraut wrote: Here's the patch to support Python =3.1 with PL/Python. :\ I was hoping to be able to use Python 3 to draw a clear distinction between plpython and the would-be plpython3 that I've been working on. I understand that you're not in favor of a brand new implementation for Python 3. Despite my dislike for that position(well, it would seem to be in opposition to my initiative, so naturally =), I don't entirely disagree with your rationale[wrt doing things more incrementally]. For me, plpython has never been what I would call a pleasure to use, and many of the gripes that I have with it are, IMO, entrenched far enough into the implementation that any efforts to change it would(should? =) cause unacceptable breakage in user applications(?). Well, as far as additional Python interfaces are concerned, a lot of redundant functionality, but that's not even the half of it. [I was hoping to get to a status message this weekend, but it seems like I should follow-up here. =] So here's where I'm at: -- Mostly documentation improvements since I last pinged -hackers. Still, *sigh*, filling in documentation and fighting bugs as I go. Currently resolving a bug instantiating MD arrays from nested lists. Once I'm finished with the docs, I'm going to start looking for refcount leaks. No major additions or changes are planned, but I have been making some minor additions as I write more docs. Overview/Features: http://wiki.postgresql.org/wiki/WIP:plpython3 Documentation: http://python.projects.postgresql.org/pldocs/plpython3.html git repo[see the plpython3 branch]: http://git.postgresql.org/gitweb?p=plpython3.git;a=summary Most of the documented interfaces have tests. I only have two platforms at my disposal, so I do fear that this will not just work on all of PG's supported platforms. Specifically, I've ran the tests on freebsd/amd64 and Mac10.6/intel(of course 10.5 as well for some earlier revisions). [err, actually, it's been a while since I ran the tests on freebsd.] -- plpython3 is turning out to be kinda beefy(~974K diff[eh, there is some fluff in there]), and I can't say that I've seen much interest in it, so I can't really blame anyone if -hackers ends up taking a pass on it. (python3 is too far away for most folk to care? folk are content with plpython?) eh, cheers, either way. =) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Listen / Notify rewrite
On 11/12/09 8:30 AM, Tom Lane wrote: So while a payload string for NOTIFY has been on the to-do list since forever, I have to think that Greg's got a good point questioning whether it is actually a good idea. Sure, people will abuse it as a queue. But people abuse arrays when they should be using child tables, use composite types to make data non-atomic, and use dblink when they really should be using schema. Does the potential for misuse mean that we should drop the features? No. Payloads are also quite useful even in a lossy environment, where you understand that LISTEN is not a queue. For example, I'd like to be using LISTEN/NOTIFY for cache invalidation for some applications; if it misses a few, or double-counts them, it's not an issue. However, I'd like to be able to send message like players_updated|45321 where 45321 is the ID of the player updated. --Josh Berkus -- Sent 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 committers
Josh Berkus wrote: paying attention to and which they shouldn't. I *thought* that Bruce was doing that for AsterData, but apparently not. Josh, two days ago you complained I that I mentioned 'search_path' when we were talking about postgresql.conf, now you have another complaint about me. Did you get appointed network nanny recently? I never got that email. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] New VACUUM FULL
Alvaro Herrera alvhe...@commandprompt.com wrote: BTW I think the vacstmt.options change, which seems a reasonable idea to me, could be extracted from the patch and applied separately. That'd reduce the size of the patch somewhat. It's a good idea. I separated the part into the attached patch. It replaces VacuumStmt's vacuum, full, analyze, and verbose fields into one options flag field. The only user-visible change is to support VACUUM (options) syntax: VACUUM ( FULL, FREEZE, VERBOSE, ANALYZE ) table (columns) We don't bother with the order of options in this form :) There is a debatable issue that we can use VACUUM (VERBOSE) table (col) in the abobe syntax. Columns are specified but no ANALYZE option there. An ANALYZE option is added automatically in the current implementation, but we should have thrown an syntax error in such case. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center vacuum-options_20091113.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] write ahead logging in standby (streaming replication)
On Fri, Nov 13, 2009 at 1:49 AM, Greg Smith g...@2ndquadrant.com wrote: This a distressingly common thing people get wrong about replication. You can either have synchronous replication, which as you say has to be slow: you must wait for an fsync ACK from the secondary and a return trip before you can say something is committed on the primary. Or you can get better performance by not waiting for all of those things, but the minute you do that it's *not* synchronous replication anymore. You can't get high-performance and true synchronous behavior; you have to pick one. The best you can do if you need both is work on accelerating fsync everywhere using the standard battery-backed write cache technique. I'm not happy that such frequent fsyncs would harm even semi-synchronous replication (i.e., you must wait for a *recv* ACK from the secondary and a return trip before you can say something is committed on the primary. This corresponds to the DRBD's protocol B) rather than synchronous one. Personally, I think that semi-synchronous replication is sufficient for HA. 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] Patch committers
Tom Lane wrote: While I'm not against promoting more committers to deal with the influx of patches, the only way I know for people to get to the skill level of being fully competent reviewers is to have done a lot of patch writing themselves. The dynamic going on right now is that many people who might otherwise be writing their own patches are instead doing patch review to try and keep the project as a whole moving forward. I actually had two off-list discussions about that just today, that topic pops up pretty regularly as I talk with contributors at all levels. Since most people have an upper limit on how much community time they can spend, every minute spent reviewing is one you're not working on your own patches during. The way you're describing the qualification process, it would be easy to conclude that there's a reviewer ladder, and a developer ladder, and only climbing the latter leads to being a committer--that no matter how much review you do, it doesn't really count as a committer grade skill. I'm not sure that's the message you want to be sending, because anyone who dreams of being a committer is going to stay as far away from doing review as they can if that notion spreads. Based on the growing frustration with doing review doesn't leave me with time for my own patches I keep hearing, that perception is already something to be wary of. If the primary criteria is generating patches that apply with minimal changes, you could make a case that someone who's gotten skilled enough as a reviewer to only pass through patches of that quality should get some recognition even if they didn't write them. That's clearly a useful subset of the skills needed to commit patches only if they look to be ready for it. -- Greg Smith2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Listen / Notify rewrite
On Thu, Nov 12, 2009 at 8:44 PM, Josh Berkus j...@agliodbs.com wrote: On 11/12/09 8:30 AM, Tom Lane wrote: So while a payload string for NOTIFY has been on the to-do list since forever, I have to think that Greg's got a good point questioning whether it is actually a good idea. Sure, people will abuse it as a queue. But people abuse arrays when they should be using child tables, use composite types to make data non-atomic, and use dblink when they really should be using schema. Does the potential for misuse mean that we should drop the features? No. I agree. We frequently reject features on the basis that someone might do something stupid with them. It's lame and counterproductive, and we should stop. The world contains infinite amounts of lameness, but that's the world's problem, not ours. There is zero evidence that this feature is only useful for stupid purposes, and some evidence (namely, the opinions of esteemed community members) that it is useful for at least some non-stupid purposes. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] write ahead logging in standby (streaming replication)
* Fujii Masao masao.fu...@gmail.com [091112 20:52]: Personally, I think that semi-synchronous replication is sufficient for HA. Often, but that's not synchronous replication so don't call it such... -- Aidan Van Dyk Create like a god, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave. signature.asc Description: Digital signature
Re: [HACKERS] Patch committers
On Thu, Nov 12, 2009 at 8:55 PM, Greg Smith g...@2ndquadrant.com wrote: I'm not sure that's the message you want to be sending, because anyone who dreams of being a committer is going to stay as far away from doing review as they can if that notion spreads. To say nothing of CommitFest management. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] write ahead logging in standby (streaming replication)
Fujii Masao wrote: Personally, I think that semi-synchronous replication is sufficient for HA. Whether or not you think it's sufficient for what you have in mind, synchronous replication requires a return ACK from the secondary before you say things are committed on the primary. If you don't do that, it's not true sync replication anymore; it's asynchronous replication. Plenty of people decide that a local commit combined with a promise to synchronize as soon as possible to the slave is good enough for their apps, which as you say is getting referred to as semi-synchronous replication nowadays. That's an awful name though, because it's not true--that's asynchronous replication, just aiming for minimal lag. It's OK to say that's what you want, but you can't say it's really a synchronous commit anymore if you do things that way. -- Greg Smith2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] next CommitFest
Robert Haas wrote: On Thu, Nov 12, 2009 at 1:25 PM, Albert Cervera i Areny alb...@nan-tic.com wrote: A Dijous, 12 de novembre de 2009, Euler Taveira de Oliveira va escriure: Simon Riggs escreveu: So, I propose that we simply ignore patches from developers until they have done sufficient review to be allowed to develop again. Is it really impolite for a first-contributor, no? I don't think so, as long as it's properly explained. Personally, I would not propose to impose this rule of first-time contributors, or even second-time contributors. But by about patch #3 I think everyone should be pitching in. I hate to ask, but how would we enforce this? Do we no longer apply patches for 3rd-time submitters who have not reviewed? That seems to be hurting us more than them. Are we prepared to discard valid patches for this reason? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] write ahead logging in standby (streaming replication)
On Fri, Nov 13, 2009 at 10:58 AM, Aidan Van Dyk ai...@highrise.ca wrote: * Fujii Masao masao.fu...@gmail.com [091112 20:52]: Personally, I think that semi-synchronous replication is sufficient for HA. Often, but that's not synchronous replication so don't call it such... Hmm, though I'm not sure about your definition of synchronous, if the primary waits for a *redo* ACK from the standby before returning a success of a transaction to a client, you can call SR synchronous? This is one of TODO items of SR for v8.5. 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] EOL for 7.4?
On Thu, Nov 12, 2009 at 11:16 PM, Greg Sabino Mullane g...@turnstep.com wrote: And yes, i'm +1 for having a rule for EOL, like 5 versions are supported. If we released on a consistent schedule, this *might* be possible. But we don't, so we can't say something like this. We've already done this. I think we said three years but I'm too lazy to go search right now. It's as meaningless now as it was then. The reality is we back branch as far back as is convenient and stop when we run into a major problem that isn't fixable in old versions. 7.4 and even 8.0 are already EOL in the sense that they're past your arbitrary cutoff and there's no guarantee that we'll keep releasing fixes but there's no particular reason to stop yet. Really I think you guys are on the wrong track trying to map Postgres releases to commercial support terms. None of the Postgres releases are supported in the sense that there's no warranty and no promises, it's all best effort. If you want a promise of anything then pay someone for that service. As with any open source software if you're running 7-year-old versions of the software you can't seriously expect the developers to take any interest in bugs you discover which don't affect current releases. Other projects don't release back branches at all. The most the developers are likely to do if your bugs require serious engineering is declare that the version you're using is too old. -- 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] Listen / Notify rewrite
and we should stop. The world contains infinite amounts of lameness, but that's the world's problem, not ours. There is zero evidence that +1 this feature is only useful for stupid purposes, and some evidence (namely, the opinions of esteemed community members) that it is useful for at least some non-stupid purposes. The unexpected application of a feature can be creative or innovative, which I firmly believe is something this community embraces. How many ways can a screw driver be used ... think MacGyver :) Deteriming whether it's creative vs. stupid would require an understanding of the context in which it was applied. For example, using our screw driver to remove a splinter would be rather stupid, IMHO ;) -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.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] EOL for 7.4?
On Fri, Nov 13, 2009 at 02:22:01AM +, Greg Stark wrote: Really I think you guys are on the wrong track trying to map Postgres releases to commercial support terms. None of the Postgres releases are supported in the sense that there's no warranty and no promises, it's all best effort. If you want a promise of anything then pay someone for that service. As with any open source software if you're running 7-year-old versions of the software you can't seriously expect the developers to take any interest in bugs you discover which don't affect current releases. Other projects don't release back branches at all. The most the developers are likely to do if your bugs require serious engineering is declare that the version you're using is too old. Claiming to support versions that are too old is giving users a false sense of comfort. Encouraging users to use these versions is actually harming them as when this happens they will be stuck with either living with the bug or doing an immediate unplanned upgrade. I suggest we announce now that both 7.4 and 8.0 will EOL when 8.5 is expected to ship, or to comfort those who never use .0 versions when 8.5.1 ships. -dg -- David Gould da...@sonic.net 510 536 1443510 282 0869 If simplicity worked, the world would be overrun with insects. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] write ahead logging in standby (streaming replication)
On Fri, Nov 13, 2009 at 11:15 AM, Greg Smith g...@2ndquadrant.com wrote: Whether or not you think it's sufficient for what you have in mind, synchronous replication requires a return ACK from the secondary before you say things are committed on the primary. If you don't do that, it's not true sync replication anymore; it's asynchronous replication. Plenty of people decide that a local commit combined with a promise to synchronize as soon as possible to the slave is good enough for their apps, which as you say is getting referred to as semi-synchronous replication nowadays. That's an awful name though, because it's not true--that's asynchronous replication, just aiming for minimal lag. It's OK to say that's what you want, but you can't say it's really a synchronous commit anymore if you do things that way. Umm... what is your definition of synchronous? I'm planning to provide four synchronization modes as follows, for v8.5. Does this fit in your thought? The primary waits ... before returning success of a transaction; * nothing - asynchronous replication * recv ACK - semi-synchronous replication * fsync ACK - semi-synchronous replication * redo ACK - synchronous replication Or, in synchronous replication, we must wait a fsync and a redo ACK? 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] EOL for 7.4?
daveg wrote: On Fri, Nov 13, 2009 at 02:22:01AM +, Greg Stark wrote: Really I think you guys are on the wrong track trying to map Postgres releases to commercial support terms. None of the Postgres releases are supported in the sense that there's no warranty and no promises, it's all best effort. If you want a promise of anything then pay someone for that service. As with any open source software if you're running 7-year-old versions of the software you can't seriously expect the developers to take any interest in bugs you discover which don't affect current releases. Other projects don't release back branches at all. The most the developers are likely to do if your bugs require serious engineering is declare that the version you're using is too old. Claiming to support versions that are too old is giving users a false sense of comfort. Encouraging users to use these versions is actually harming them as when this happens they will be stuck with either living with the bug or doing an immediate unplanned upgrade. I suggest we announce now that both 7.4 and 8.0 will EOL when 8.5 is expected to ship, or to comfort those who never use .0 versions when 8.5.1 ships. I question whether it makes sense to EOL a version just to encourage people to upgrade --- that logic really seems beyond our scope. It might be practical to do it, but I see it taking us in a direction that we might want to avoid. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
On Thu, Nov 12, 2009 at 9:40 PM, Bruce Momjian br...@momjian.us wrote: daveg wrote: On Fri, Nov 13, 2009 at 02:22:01AM +, Greg Stark wrote: Really I think you guys are on the wrong track trying to map Postgres releases to commercial support terms. None of the Postgres releases are supported in the sense that there's no warranty and no promises, it's all best effort. If you want a promise of anything then pay someone for that service. As with any open source software if you're running 7-year-old versions of the software you can't seriously expect the developers to take any interest in bugs you discover which don't affect current releases. Other projects don't release back branches at all. The most the developers are likely to do if your bugs require serious engineering is declare that the version you're using is too old. Claiming to support versions that are too old is giving users a false sense of comfort. Encouraging users to use these versions is actually harming them as when this happens they will be stuck with either living with the bug or doing an immediate unplanned upgrade. I suggest we announce now that both 7.4 and 8.0 will EOL when 8.5 is expected to ship, or to comfort those who never use .0 versions when 8.5.1 ships. I question whether it makes sense to EOL a version just to encourage people to upgrade --- that logic really seems beyond our scope. It might be practical to do it, but I see it taking us in a direction that we might want to avoid. I don't agree with because we want to force people to upgrade, but I do agree with Dave Gould's point about giving a false sense of comfort (I made this same point upthread somewhere, I think). ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] write ahead logging in standby (streaming replication)
On Fri, Nov 13, 2009 at 2:37 AM, Fujii Masao masao.fu...@gmail.com wrote: Umm... what is your definition of synchronous? I'm planning to provide four synchronization modes as follows, for v8.5. Does this fit in your I think my definition would be that a query against the replica will produce the same result as a query against the master -- and that that will be the case even after a system failure. That might not necessarily mean that the log entry is fsynced on the replica, only that it's fsynced in a location where the replica will have access to it when it runs recovery. I do have a different question though. What do you plan to do if there's a failure when they're out of sync? The master hasn't responded to the commit yet because it's still waiting on the replica to respond but it has already recorded the commit itself. When it comes back up it's out of sync with the replica and has to resend those records? What if the replica has already received it and it was the confirmation which was lost? -- 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] next CommitFest
On Thu, Nov 12, 2009 at 9:15 PM, Bruce Momjian br...@momjian.us wrote: Robert Haas wrote: On Thu, Nov 12, 2009 at 1:25 PM, Albert Cervera i Areny alb...@nan-tic.com wrote: A Dijous, 12 de novembre de 2009, Euler Taveira de Oliveira va escriure: Simon Riggs escreveu: So, I propose that we simply ignore patches from developers until they have done sufficient review to be allowed to develop again. Is it really impolite for a first-contributor, no? I don't think so, as long as it's properly explained. Personally, I would not propose to impose this rule of first-time contributors, or even second-time contributors. But by about patch #3 I think everyone should be pitching in. I hate to ask, but how would we enforce this? Do we no longer apply patches for 3rd-time submitters who have not reviewed? That seems to be hurting us more than them. Are we prepared to discard valid patches for this reason? We just wouldn't assign round-robin reviewers to such patches. If someone wants to volunteer, more power to them, but we would encourage people to focus their efforts on the patches of people who were themselves reviewing. It's important to keep in mind that valid is not a boolean. Some patches are perfect the day they roll in, but not too many. It takes work to get them committable, and I don't see why anyone should have an expectation that they can have that help for themselves without doing the same thing for other people. All that having been said, the real shortage ATM is of committers rather than reviewers. We have plenty of them, but many of them commit almost nothing. I don't want to minimize the contributions of the non-Tom committers, but Tom is numerically far and away committing more than anyone else, and not small patches, either. Beyond the fact that it makes the CommitFest slow, long, and not too much fun for Tom, it also means that Tom has less time available to do things that Only Tom Can Do. I venture to say that there will be Great Excitement about the enhancements to the EPQ machinery and PL/pgsql that Tom has recently effected. Well, if Tom hadn't had to single-handedly handle so many patches last CF, maybe he would have done something else cool, too. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Aggregate ORDER BY patch
Herewith a patch to implement agg(foo ORDER BY bar) with or without DISTINCT, etc. No artificial restrictions are imposed on what syntactical combinations are allowed. However, ORDER BY is not allowed with aggregates used as window functions (as per the existing restriction on DISTINCT). Included are regression tests but not docs yet, those will follow shortly in a separate patch (to save having to keep redoing the code patch like last time). Caveat: as discussed earlier, this patch changes the behaviour of array_agg(DISTINCT x) when applied to NULL inputs. Formerly, the NULLs were unconditionally skipped; now, they are treated just like DISTINCT or GROUP BY normally do. The previous restriction of agg(DISTINCT ...) to single-argument aggregates is removed. However, there is still a separate code path for aggregates that use DISTINCT or ORDER BY with only one input column, for performance reasons. If a non-default ordering operator is used in combination with DISTINCT, then the notion of equality used for the DISTINCT comparisons is the one that belongs to the ordering, rather than the default. -- Andrew. aorder-20091113.patch.gz Description: agg order by patch -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
On Fri, Nov 13, 2009 at 2:35 AM, daveg da...@sonic.net wrote: I suggest we announce now that both 7.4 and 8.0 will EOL when 8.5 is expected to ship, or to comfort those who never use .0 versions when 8.5.1 ships. What would this mean? How would it be different than the status quo? -- 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] actualised funcs typmod patch
Hello I am sorry. I'll send a actualised version today. Pavel 2009/11/13 Alvaro Herrera alvhe...@commandprompt.com: Pavel Stehule escribió: Hello actualised version: enhance check inside sql function What is this against? It has a few suspicious chunks, such as *** *** 358,364 funcexpr-funcid = funcid; funcexpr-funcresulttype = rettype; ! funcexpr-funcresulttypmod = -1; // TODO STEHULE funcexpr-funcretset = retset; funcexpr-funcformat = COERCE_EXPLICIT_CALL; funcexpr-args = fargs; --- 365,371 funcexpr-funcid = funcid; funcexpr-funcresulttype = rettype; ! funcexpr-funcresulttypmod = rettypmod; funcexpr-funcretset = retset; funcexpr-funcformat = COERCE_EXPLICIT_CALL; funcexpr-args = fargs; This ended up in ./src/backend/parser/parse_func.c.rej There are other rejects and I'm not sure if I should fix them (at least the first couple look trivial, though it's against a bunch of code that last changed in Aug. last year) or ask for a better version ... -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Listen / Notify rewrite
On Nov 12, 2009, at 5:57 PM, Robert Haas wrote: On Thu, Nov 12, 2009 at 8:44 PM, Josh Berkus j...@agliodbs.com wrote: On 11/12/09 8:30 AM, Tom Lane wrote: So while a payload string for NOTIFY has been on the to-do list since forever, I have to think that Greg's got a good point questioning whether it is actually a good idea. Sure, people will abuse it as a queue. But people abuse arrays when they should be using child tables, use composite types to make data non-atomic, and use dblink when they really should be using schema. Does the potential for misuse mean that we should drop the features? No. I agree. We frequently reject features on the basis that someone might do something stupid with them. It's lame and counterproductive, and we should stop. The world contains infinite amounts of lameness, but that's the world's problem, not ours. There is zero evidence that this feature is only useful for stupid purposes, and some evidence (namely, the opinions of esteemed community members) that it is useful for at least some non-stupid purposes. Speaking as a consumer of this feature, my (mild) concern is not that by adding functionality it will make it possible to do new things badly, it's that it might make it harder (or impossible) to do currently supported things as well. I like the current notify. It's a good match for handling table based queues or for app-level-cache invalidation. Any changes that make it less good at that would be a step backwards. The more complex and flexible and heavier the changes, the more that concerns me. (Though a small payload - I'd settle for at least an integer - would be convenient, to allow invalidation of 20 different caches without needing 20 different LISTENs). Cheers, Steve -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] TRIGGER with WHEN clause
Itagaki Takahiro wrote: Here is a updated TRIGGER with WHEN cluase patch. I adjusted it to work with recent parser cleanup (*OLD* and *NEW*). I would like to volunteer for reviewing the patch in RR-stage. It seems to me an interesting feature. -- OSS Platform Development Division, NEC KaiGai Kohei kai...@ak.jp.nec.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] CTE containing ambiguous columns
Suppose you do this: create table animals (id serial primary key, name varchar not null); Then you can do this: with beings as (select * from animals) select * from beings where id = 1; But not this: with beings as (select * from animals a1, animals a2) select * from beings where id = 1; Because: ERROR: column reference id is ambiguous at character 82 STATEMENT: with beings as (select * from animals a1, animals a2) select * from beings where id = 1; ERROR: column reference id is ambiguous LINE 1: ...m animals a1, animals a2) select * from beings where id = 1; ^ My email program will probably mangle this, so the error cursor here is point to id = 1, at the end, and saying that's ambiguous. Which is sorta kinda true, but the usual remedy of qualifying it with a relation name (here, beings.id) fails. And you can't quantify it with a1.id or a2.id either, they're out of scope. In some sense, the real problem is with select *, because that is what is expanding into a non-unique list of column names. But you don't actually trigger an error unless you try to reference one; the same query works fine without the where clause. I'm not sure if there's anything useful we can do about this, but it definitely threw me for a loop. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] next CommitFest
Robert Haas wrote: Personally, I would not propose to impose this rule of first-time contributors, or even second-time contributors. ?But by about patch #3 I think everyone should be pitching in. I hate to ask, but how would we enforce this? ?Do we no longer apply patches for 3rd-time submitters who have not reviewed? ?That seems to be hurting us more than them. ? Are we prepared to discard valid patches for this reason? We just wouldn't assign round-robin reviewers to such patches. If someone wants to volunteer, more power to them, but we would encourage people to focus their efforts on the patches of people who were themselves reviewing. It's important to keep in mind that valid is not a boolean. Some patches are perfect the day they roll in, but not too many. It takes work to get them committable, and I don't see why anyone should have an expectation that they can have that help for themselves without doing the same thing for other people. OK, but the problem I see there is that the reviewers are there to assist the committers; if no one reviews something, it just makes more work for the committers. All that having been said, the real shortage ATM is of committers rather than reviewers. We have plenty of them, but many of them commit almost nothing. I don't want to minimize the contributions of the non-Tom committers, but Tom is numerically far and away committing more than anyone else, and not small patches, either. Beyond the fact that it makes the CommitFest slow, long, and not too much fun for Tom, it also means that Tom has less time available to do things that Only Tom Can Do. I venture to say that there will be Great Excitement about the enhancements to the EPQ machinery and PL/pgsql that Tom has recently effected. Well, if Tom hadn't had to single-handedly handle so many patches last CF, maybe he would have done something else cool, too. Totally agree. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] next CommitFest
On Thu, Nov 12, 2009 at 11:31 PM, Bruce Momjian br...@momjian.us wrote: Robert Haas wrote: Personally, I would not propose to impose this rule of first-time contributors, or even second-time contributors. ?But by about patch #3 I think everyone should be pitching in. I hate to ask, but how would we enforce this? ?Do we no longer apply patches for 3rd-time submitters who have not reviewed? ?That seems to be hurting us more than them. ? Are we prepared to discard valid patches for this reason? We just wouldn't assign round-robin reviewers to such patches. If someone wants to volunteer, more power to them, but we would encourage people to focus their efforts on the patches of people who were themselves reviewing. It's important to keep in mind that valid is not a boolean. Some patches are perfect the day they roll in, but not too many. It takes work to get them committable, and I don't see why anyone should have an expectation that they can have that help for themselves without doing the same thing for other people. OK, but the problem I see there is that the reviewers are there to assist the committers; if no one reviews something, it just makes more work for the committers. That wasn't my intention. I really was assuming that we would just let those patches drop on the floor, and that they would not be picked up either by reviewers or committers. I don't think this would cause as many problems in practice as perhaps you fear, because I think it will just motivate people to act as reviewers. Writing a patch is typically more time-consuming than reviewing one, at least IME, with some exceptions of course. I wouldn't spend 20 hours writing a patch and then let it fall out because I wasn't willing to spend 2 or 3 hours reviewing someone else's patch, and I don't think other regular contributors will either. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] [PATCH] Largeobject Access Controls (r2432)
The attached patch is a revised version of large object privileges based on the feedbacks at the last commit fest. List of updates: * Rebased to the latest CVS HEAD * Add pg_largeobject_aclcheck_snapshot() interface. In the read-only access mode, large object feature uses query's snaphot, not only SnapshotNow. This behavior also should be applied on accesses to its metadata. When it makes its access control decision, it has to fetch database acls from the system catalog. In this time, we scan the pg_largeobject_metadata with a snapshot of large object descriptor. (Note that it is SnapshotNow in read-write mode.) It enables to resolve the matter when access rights are changed during large objects are opened. * Add pg_dump support. * Replace all the largeobject by large object from user visible messages and documentation. * Remove ac_largeobject_*() routines because we decided not to share same entry points between DAC and MAC. * Add a description of large object privileges in SGML. * Add a definition of pg_largeobject_metadata in SGML. * \lo_list command supports both of v8.5 and prior version. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei kai...@ak.jp.nec.com sepgsql-02-blob-8.5devel-r2432.patch.gz Description: application/gzip -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] write ahead logging in standby (streaming replication)
Fujii Masao wrote: Umm... what is your definition of synchronous? I'm planning to provide four synchronization modes as follows, for v8.5. Does this fit in your thought? The primary waits ... before returning success of a transaction; * nothing - asynchronous replication * recv ACK - semi-synchronous replication * fsync ACK - semi-synchronous replication * redo ACK - synchronous replication Or, in synchronous replication, we must wait a fsync and a redo ACK? Right, those are the possibilities, all four of them have valid use cases in the field and are worth implementing. I don't like the label semi-synchronous replication myself, but it's a valuable feature to implement, and that is unfortunately the term other parts of the industry use for that approach. But everyone needs to be extremely careful with the terminology here: if you say synchronous replication, that *only* means what you're labeling redo ACK (WAL ACK really). Synchronous replication should not be used as a group term that includes the semi-synchronous variations, which are in fact asynchronous despite their marketing name. If someone means semi-synchronous, but they say synchronous thinking it's a shared term also applicable to the semi-synchronous variations here, that's just going to be confusing for everyone. -- Greg Smith2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] next CommitFest
Robert Haas wrote: We just wouldn't assign round-robin reviewers to such patches. ?If someone wants to volunteer, more power to them, but we would encourage people to focus their efforts on the patches of people who were themselves reviewing. ?It's important to keep in mind that valid is not a boolean. ?Some patches are perfect the day they roll in, but not too many. ?It takes work to get them committable, and I don't see why anyone should have an expectation that they can have that help for themselves without doing the same thing for other people. OK, but the problem I see there is that the reviewers are there to assist the committers; ?if no one reviews something, it just makes more work for the committers. That wasn't my intention. I really was assuming that we would just let those patches drop on the floor, and that they would not be picked up either by reviewers or committers. I don't think this would cause as many problems in practice as perhaps you fear, because I think it will just motivate people to act as reviewers. Writing a patch is typically more time-consuming than reviewing one, at least IME, with some exceptions of course. I wouldn't spend 20 hours writing a patch and then let it fall out because I wasn't willing to spend 2 or 3 hours reviewing someone else's patch, and I don't think other regular contributors will either. OK, but that is certainly a different system than we have now. In your system, committers would be told to ignore patches that were submitted by repeated patch submitters who never review, or even we just never put on the commit fest page. I am just trying to nail down exactly how that would work --- that's a pretty Draconian system. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] SE-PgSQL/lite (r2429)
KaiGai Kohei wrote: In the v8.4 development cycle, I got a suggestion to reduce a burden of reviewer to split off a few functionalities, such as security_context system column and row-level access controls. I lost track of this patch and related bits somewhere along the way, had to triage my unread mail a few times. Could someone summarize how it now fits into plans for more general row-level access controls in the database? I know incompatibilities between the SEPosgreSQL model for row filtering and thoughts for a more general permissions feature that did something similar were a major design issue in the early 8.4 versions of SEPostgreSQL, and that as you say you've been working on that. I'm not sure what relationship there is between those two today though, or exactly where the general non-SELinux row filtering is at on the roadmap. -- Greg Smith2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] write ahead logging in standby (streaming replication)
On Fri, Nov 13, 2009 at 11:54 AM, Greg Stark gsst...@mit.edu wrote: I think my definition would be that a query against the replica will produce the same result as a query against the master -- and that that will be the case even after a system failure. That might not necessarily mean that the log entry is fsynced on the replica, only that it's fsynced in a location where the replica will have access to it when it runs recovery. Agreed. I do have a different question though. What do you plan to do if there's a failure when they're out of sync? The master hasn't responded to the commit yet because it's still waiting on the replica to respond but it has already recorded the commit itself. When it comes back up it's out of sync with the replica and has to resend those records? What if the replica has already received it and it was the confirmation which was lost? If the connection is not closed, the resending is not required because TCP would guarantee that such records arrive at the standby someday. Otherwise, the standby re-connects to the primary, and asks for the missing records, so the resending would be done. Since only the missing records are requested, the already received records don't reach the standby again, I think. 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] next CommitFest
On Thu, Nov 12, 2009 at 11:50 PM, Bruce Momjian br...@momjian.us wrote: Robert Haas wrote: We just wouldn't assign round-robin reviewers to such patches. ?If someone wants to volunteer, more power to them, but we would encourage people to focus their efforts on the patches of people who were themselves reviewing. ?It's important to keep in mind that valid is not a boolean. ?Some patches are perfect the day they roll in, but not too many. ?It takes work to get them committable, and I don't see why anyone should have an expectation that they can have that help for themselves without doing the same thing for other people. OK, but the problem I see there is that the reviewers are there to assist the committers; ?if no one reviews something, it just makes more work for the committers. That wasn't my intention. I really was assuming that we would just let those patches drop on the floor, and that they would not be picked up either by reviewers or committers. I don't think this would cause as many problems in practice as perhaps you fear, because I think it will just motivate people to act as reviewers. Writing a patch is typically more time-consuming than reviewing one, at least IME, with some exceptions of course. I wouldn't spend 20 hours writing a patch and then let it fall out because I wasn't willing to spend 2 or 3 hours reviewing someone else's patch, and I don't think other regular contributors will either. OK, but that is certainly a different system than we have now. In your system, committers would be told to ignore patches that were submitted by repeated patch submitters who never review, or even we just never put on the commit fest page. I think they would probably get added to the CommitFest page and then marked Rejected with a suitable explanation. I am just trying to nail down exactly how that would work --- that's a pretty Draconian system. I don't really agree, but obviously I respect your opinion, and clearly, this is not a policy that can be implemented without some degree of consensus. I fear, however, that if we don't motivate regular contributors to also review, then we will have a shortage of reviewers, especially highly-qualified reviewers. If there is no stigma attached to submitting patches and never volunteering to review, then even people who have reviewed in the past may eventually decide it isn't worth the effort. I am personally quite tired of reviewing patches for people who don't in turn review mine (or someone's). It makes me feel like not working on this project. If we can solve that problem without implementing a policy of this type, that is good. I would much prefer to run by the honor system rather than having to threaten to drop patches, but only if the honor system actually works. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] write ahead logging in standby (streaming replication)
On Fri, Nov 13, 2009 at 1:49 PM, Greg Smith g...@2ndquadrant.com wrote: Right, those are the possibilities, all four of them have valid use cases in the field and are worth implementing. I don't like the label semi-synchronous replication myself, but it's a valuable feature to implement, and that is unfortunately the term other parts of the industry use for that approach. BTW, MySQL and DRBD use the term semi-synchronous: http://forge.mysql.com/wiki/ReplicationFeatures/SemiSyncReplication http://www.drbd.org/users-guide/s-replication-protocols.html 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] [PATCH] SE-PgSQL/lite (r2429)
Greg Smith wrote: KaiGai Kohei wrote: In the v8.4 development cycle, I got a suggestion to reduce a burden of reviewer to split off a few functionalities, such as security_context system column and row-level access controls. I lost track of this patch and related bits somewhere along the way, had to triage my unread mail a few times. Could someone summarize how it now fits into plans for more general row-level access controls in the database? I know incompatibilities between the SEPosgreSQL model for row filtering and thoughts for a more general permissions feature that did something similar were a major design issue in the early 8.4 versions of SEPostgreSQL, and that as you say you've been working on that. I'm not sure what relationship there is between those two today though, or exactly where the general non-SELinux row filtering is at on the roadmap. At least, I don't have a plan to submit a patch for row-level access controls in the v8.5 development cycle. We should focus on the lite version here. On that basis, I shall propose the row-level access controls after the current efforts getting closed. I found a uncertain term in your comment. It seems to me the model has two meanings in this context. - The way to make access control decision (allowed? or denied?). - The granularity of access controls (tables? columns? or tuples?). I think you are saying about the latet point. In my plan, I'll propose a feature something like Oracle Virtual Private Database which filters violated rows based on the decision making function. (e.g tbl.username = getpgusername() ) Needless to say, it is a general non-SELinux feature. But, if we have such a PG-VPD, it is not difficult to implement a decision making function based on SELinux. Is it correct for the answer? Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei kai...@ak.jp.nec.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] next CommitFest
Robert Haas wrote: That wasn't my intention. I really was assuming that we would just let those patches drop on the floor, and that they would not be picked up either by reviewers or committers. Surely it should depend on the nature of the patch. For an extreme strawman, segfault fixes almost certainly shouldn't be dropped. Same for docs patches that clarify the product. I think the majority of my contributions to open source this decade have been of that nature (a few links to examples in postgres and postgis follow). Maybe a better policy would be: if you reviewed patches, a reviewer will be assigned -- if you didn't, your patch is at the mercy of reviewers volunteering to review it based on their own interest in your patch that way patches that the community really wants could get in anyway. http://postgis.refractions.net/pipermail/postgis-users/2005-April/007762.html http://archives.postgresql.org/pgsql-performance/2009-03/msg00252.php http://postgis.refractions.net/pipermail/postgis-users/2005-April/007704.html http://postgis.refractions.net/pipermail/postgis-devel/2005-April/001341.html -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] write ahead logging in standby (streaming replication)
Hi Greg and Fujii, Just a point on terminology: there's a difference in the usage of semi-synchronous between DRBD and MySQL semi-synchronous replication, which was originally developed by Google. In the Google case semi-synchronous replication is a quorum algorithm where clients receive a commit notification only after at least one of N slaves has received the replication event. In the DRBD case semi-synchronous means that events have reached the slave but are not necessarily durable. There's no quorum. Of these two usages the Google semi-sync approach is the more interesting because it avoids the availability problems associated with fully synchronous operation but gets most of the durability benefits. Cheers, Robert On 11/12/09 9:29 PM PST, Fujii Masao masao.fu...@gmail.com wrote: On Fri, Nov 13, 2009 at 1:49 PM, Greg Smith g...@2ndquadrant.com wrote: Right, those are the possibilities, all four of them have valid use cases in the field and are worth implementing. I don't like the label semi-synchronous replication myself, but it's a valuable feature to implement, and that is unfortunately the term other parts of the industry use for that approach. BTW, MySQL and DRBD use the term semi-synchronous: http://forge.mysql.com/wiki/ReplicationFeatures/SemiSyncReplication http://www.drbd.org/users-guide/s-replication-protocols.html 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] write ahead logging in standby (streaming replication)
Fujii Masao wrote: On Fri, Nov 13, 2009 at 1:49 PM, Greg Smith g...@2ndquadrant.com wrote: Right, those are the possibilities, all four of them have valid use cases in the field and are worth implementing. I don't like the label semi-synchronous replication myself, but it's a valuable feature to implement, and that is unfortunately the term other parts of the industry use for that approach. BTW, MySQL and DRBD use the term semi-synchronous: http://forge.mysql.com/wiki/ReplicationFeatures/SemiSyncReplication http://www.drbd.org/users-guide/s-replication-protocols.html Yeah, that's the other parts of the industry I was referring to. MySQL uses semi-synchronous to distinguish between its completely asynchronous default replication mode and one where it provides a somewhat safer implementation. The description reads more as asynchronous with some synchronous elements, not one style of synchronous implementation. None of their documentation wanders into the problem area here by calling it a true synchronous solution when it's really not--MySQL Cluster is their synchronous vehicle. It's fine to adopt the term semi-synchronous, as it's become quite popular and people are going to label the PG implementation with it regardless of what is settled on here. But we should all try to be careful to use it as correctly as possible. -- Greg Smith2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] SE-PgSQL/lite (r2429)
KaiGai Kohei wrote: I found a uncertain term in your comment. It seems to me the model has two meanings in this context. - The way to make access control decision (allowed? or denied?). - The granularity of access controls (tables? columns? or tuples?). What I meant by the SEPosgreSQL model for row filtering was the original implementation you had, where row filtering was handled by code specific to SEPostgreSQL, not something generic enough to be used for other purposes. I wasn't sure what if anything from there was still in the patch, and you answered that clearly enough. Thanks for clarifying where things are at. -- Greg Smith2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] CTE containing ambiguous columns
Robert Haas robertmh...@gmail.com writes: Suppose you do this: create table animals (id serial primary key, name varchar not null); Then you can do this: with beings as (select * from animals) select * from beings where id = 1; But not this: with beings as (select * from animals a1, animals a2) select * from beings where id = 1; No different from regression=# select * from (animals a1 cross join animals a2) x where id = 1; ERROR: column reference id is ambiguous LINE 1: ...ct * from (animals a1 cross join animals a2) x where id = 1; ^ There's no way to access the a1/a2 aliases here, either; and that rule goes back to SQL92 or maybe further. 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] Patch committers
Greg Smith g...@2ndquadrant.com writes: Since most people have an upper limit on how much community time they can spend, every minute spent reviewing is one you're not working on your own patches during. The way you're describing the qualification process, it would be easy to conclude that there's a reviewer ladder, and a developer ladder, and only climbing the latter leads to being a committer--that no matter how much review you do, it doesn't really count as a committer grade skill. Well, we only instituted the commitfest system last year; before that there wasn't any formal concept of people reviewing patches at all. Nobody has yet been promoted to committer on the basis of their reviewing work, but I don't wish to suggest that it couldn't happen. I'm not sure that's the message you want to be sending, because anyone who dreams of being a committer is going to stay as far away from doing review as they can if that notion spreads. Based on the growing frustration with doing review doesn't leave me with time for my own patches I keep hearing, that perception is already something to be wary of. I'll let you in on a secret: it feels about like that in the committer trenches too. At this point it seems that one of the major practical reasons for appointing new committers would be their willingness to help with review/commit of incoming patches. If anyone is thinking there's a ladder they can climb that doesn't have that responsibility at the top, I'm afraid they're mistaken. 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] CommitFest 2009-09, two weeks on
On Thu, Nov 12, 2009 at 03:07:27PM -0500, Robert Haas wrote: If you want to submit patches in a series like this one, they need to be considered standalone, I think. The Linux kernel devs work differently than us here. Zoltan broke them up because Michael asked him to do so. Actually these patchsets add different features. I see no reason why they should be done as one patch. However, I haven't had the time to look into the latest ones, but at least that was the situation when I asked Zoltan to split the patch. 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 ICQ: 179140304, AIM/Yahoo/Skype: michaelmeskes, Jabber: mes...@jabber.org VfL Borussia! Forca Barca! 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] CommitFest 2009-11 Call for Reviewers
On Thu, Nov 12, 2009 at 04:52:20PM -0300, Alvaro Herrera wrote: FWIW I committed the parts of one of these patches that touched the core Thanks for your help. grammar mostly, because I think those might have been holding Michael back a bit. Hopefully that'll make it easier for him to review the No, not really. I don't mind reviewing and committing to the core grammar at all. What holds me back is simply my lack of time. 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 ICQ: 179140304, AIM/Yahoo/Skype: michaelmeskes, Jabber: mes...@jabber.org VfL Borussia! Forca Barca! 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] EOL for 7.4?
On Fri, Nov 13, 2009 at 02:47:56AM +, Greg Stark wrote: On Fri, Nov 13, 2009 at 2:35 AM, daveg da...@sonic.net wrote: I suggest we announce now that both 7.4 and 8.0 will EOL when 8.5 is expected to ship, or to comfort those who never use .0 versions when 8.5.1 ships. What would this mean? How would it be different than the status quo? I suppose it would mean posting periodic prominent notices, moving the sources to the OLD directory, that sort of thing. I thought that was the topic of this thread? -dg -- David Gould da...@sonic.net 510 536 1443510 282 0869 If simplicity worked, the world would be overrun with insects. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
