On Thu, Apr 12, 2012 at 05:49, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Apr 11, 2012 at 5:36 PM, Peter Eisentraut wrote:
>>> I'd still review it, but I'd be able to spend say 3 minutes on review
>>> and 30 seconds on committing it, versus 3 minutes on review, 3 minutes
>>> on research, a
Hi,
Cumulative reaction to all the responses first:
Whoa! :)
I was under the impression that a majority of us felt that the current
mechanism was inadequate. Also if you go through the nabble thread, the
fact that CREATE TABLE did not support such constraints was considered to
be an annoyance. A
Robert Haas writes:
> On Wed, Apr 11, 2012 at 5:36 PM, Peter Eisentraut wrote:
>> I'd still review it, but I'd be able to spend say 3 minutes on review
>> and 30 seconds on committing it, versus 3 minutes on review, 3 minutes
>> on research, and 8 minutes on bookkeeping.
> Well, I am not averse
On Wed, Apr 11, 2012 at 5:36 PM, Peter Eisentraut wrote:
> On ons, 2012-04-11 at 14:29 -0400, Tom Lane wrote:
>> I hear you ... but, given that the source material is a mailing-list
>> thread, *somebody* has to do all that work to produce an acceptable
>> commit. And if you're just going to commi
On Wed, Apr 11, 2012 at 5:40 PM, Bruce Momjian wrote:
> On Wed, Apr 04, 2012 at 07:26:58PM -0700, Harold Giménez wrote:
> > There could be incoming connections for a number of
> > reasons: either the user or the user's applications are reestablishing
> > connections, or something like collectd on
On Wed, Apr 04, 2012 at 07:26:58PM -0700, Harold Giménez wrote:
> Hi all,
>
> I've written a pg_upgrade wrapper for upgrading our users (heroku)
> to postgres 9.1. In the process I encountered a specific issue that
> could easily be improved. We've had this process work consistently
> for many use
On Sat, Apr 07, 2012 at 01:13:23PM +0300, Peter Eisentraut wrote:
> On ons, 2012-04-04 at 19:26 -0700, Harold Giménez wrote:
> > It would also be nice if the invocation of pg_ctl didn't pipe its
> > output to /dev/null. I'm sure it would contain information that would
> > directly point at the root
I wrote:
> I've looked into this:
> http://archives.postgresql.org/pgsql-bugs/2012-04/msg00058.php
> and concluded that it's not very practical to fix it properly
> right now. A real fix will involve rearranging things so that
> construction of the filter-condition list happens at Path creation
>
I've looked into this:
http://archives.postgresql.org/pgsql-bugs/2012-04/msg00058.php
and concluded that it's not very practical to fix it properly
right now. A real fix will involve rearranging things so that
construction of the filter-condition list happens at Path creation
time, not createplan
On ons, 2012-04-11 at 14:29 -0400, Tom Lane wrote:
> I hear you ... but, given that the source material is a mailing-list
> thread, *somebody* has to do all that work to produce an acceptable
> commit. And if you're just going to commit what that somebody sends
> you without further review, then y
On Wed, Apr 11, 2012 at 05:14:51PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Wed, Apr 11, 2012 at 09:50:43PM +0100, Thom Brown wrote:
> >> On 11 April 2012 21:46, Bruce Momjian wrote:
> >>> Arguably:
> >>>backend_start -> session_start
> >>>query_start -> statment_star
On Wed, Apr 11, 2012 at 11:11:18PM +0200, Magnus Hagander wrote:
> >> > Should we make any of these changes?
> >>
> >> Sounds like a lot of potential breakage to solve something I don't
> >> think is a problem. Besides, isn't the door for 9.2 changes now
> >> closed and bolted?
> >
> > Well, we re
Bruce Momjian writes:
> On Wed, Apr 11, 2012 at 09:50:43PM +0100, Thom Brown wrote:
>> On 11 April 2012 21:46, Bruce Momjian wrote:
>>> Arguably:
>>>backend_start -> session_start
>>>query_start -> statment_start
>> Sounds like a lot of potential breakage to solve something I don
On Wed, Apr 11, 2012 at 23:04, Bruce Momjian wrote:
> On Wed, Apr 11, 2012 at 09:50:43PM +0100, Thom Brown wrote:
>> On 11 April 2012 21:46, Bruce Momjian wrote:
>> > Since we are wacking around pg_stat_activity for 9.2, what do people
>> > think about these column names?
>> >
>> > backen
On 11 April 2012 21:58, Peter Eisentraut wrote:
> On ons, 2012-04-11 at 21:42 +0100, Thom Brown wrote:
>> Could you clarify what you're defining to be a client application and
>> a server application? This could be confusing as we already have
>> sections under Reference called "PostgreSQL Client
On Wed, Apr 11, 2012 at 09:50:43PM +0100, Thom Brown wrote:
> On 11 April 2012 21:46, Bruce Momjian wrote:
> > Since we are wacking around pg_stat_activity for 9.2, what do people
> > think about these column names?
> >
> > backend_start | timestamp with time zone |
> > xact_sta
On ons, 2012-04-11 at 21:42 +0100, Thom Brown wrote:
> > G. Additional Supplied Applications
> >
> > with two subsections Client and Server Applications, and one refentry
> > per application. That would end up looking much like the SPI chapter.
>
> Could you clarify what you're defining to be a c
On 11 April 2012 21:46, Bruce Momjian wrote:
> Since we are wacking around pg_stat_activity for 9.2, what do people
> think about these column names?
>
> backend_start | timestamp with time zone |
> xact_start | timestamp with time zone |
> query_start | times
Since we are wacking around pg_stat_activity for 9.2, what do people
think about these column names?
backend_start| timestamp with time zone |
xact_start | timestamp with time zone |
query_start | timestamp with time zone |
Arguably:
backend_star
On 11 April 2012 21:29, Peter Eisentraut wrote:
> On ons, 2012-04-04 at 21:53 +0300, Peter Eisentraut wrote:
>> I think it would be useful to split this up into three sections:
>
>> F.1. Extensions
>> F.2. Client Applications
>> F.3. Server Applications
>
>> where the first looks like now and the
On ons, 2012-04-04 at 21:53 +0300, Peter Eisentraut wrote:
> I think it would be useful to split this up into three sections:
> F.1. Extensions
> F.2. Client Applications
> F.3. Server Applications
> where the first looks like now and the other two contain the refentry
> pages.
> We could also c
Robert Haas writes:
> +1 for fixing up the syntax before 9.2 goes out the door. I think the
> original syntax was misguided to begin with.
Well, it was fine in isolation, but once you consider how to make CREATE
TABLE do this too, it's hard to avoid the conclusion that you need to
attach the mod
On Wed, Apr 11, 2012 at 2:45 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Excerpts from Nikhil Sontakke's message of mié abr 11 15:07:45 -0300 2012:
>>> This patch removes the support for :
>>>
>>> ALTER TABLE ONLY constraint_rename_test ADD CONSTRAINT con2 CHECK (b > 0);
>>>
>>> and uses
>>>
On 04/11/2012 03:06 PM, Tom Lane wrote:
I'd propose "CHECK NO INHERIT", though, as (a) it seems better English
and (b) it avoids creating any new keyword.
I could live with that too.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
Excerpts from Andrew Dunstan's message of mié abr 11 15:51:51 -0300 2012:
>
> On 04/11/2012 02:45 PM, Tom Lane wrote:
> > Alvaro Herrera writes:
> >> Excerpts from Nikhil Sontakke's message of mié abr 11 15:07:45 -0300 2012:
> >>> This patch removes the support for :
> >>>
> >>> ALTER TABLE ONL
On 04/11/2012 02:45 PM, Tom Lane wrote:
Alvaro Herrera writes:
Excerpts from Nikhil Sontakke's message of mié abr 11 15:07:45 -0300 2012:
This patch removes the support for :
ALTER TABLE ONLY constraint_rename_test ADD CONSTRAINT con2 CHECK (b> 0);
and uses
ALTER TABLE constraint_rename
Alvaro Herrera writes:
> Excerpts from Nikhil Sontakke's message of mié abr 11 15:07:45 -0300 2012:
>> This patch removes the support for :
>>
>> ALTER TABLE ONLY constraint_rename_test ADD CONSTRAINT con2 CHECK (b > 0);
>>
>> and uses
>>
>> ALTER TABLE constraint_rename_test ADD CONSTRAINT co
Excerpts from Nikhil Sontakke's message of mié abr 11 15:07:45 -0300 2012:
> This patch removes the support for :
>
> ALTER TABLE ONLY constraint_rename_test ADD CONSTRAINT con2 CHECK (b > 0);
>
> and uses
>
> ALTER TABLE constraint_rename_test ADD CONSTRAINT con2 CHECK ONLY (b > 0);
>
> Is t
Peter Eisentraut writes:
> Just as a personal view, if people were to send me doc or "trivial"
> patches in git-am format, with proper commit message, and Acked or
> Signed-off etc. lines from recognized contributors, and proper
> References: mail header linked to the discussion or "suggestion"
>
On Wed, Apr 11, 2012 at 12:35 PM, Fujii Masao wrote:
> On Thu, Apr 12, 2012 at 12:56 AM, Fujii Masao wrote:
>> On Wed, Apr 11, 2012 at 3:31 PM, 乔志强 wrote:
>>> So in sync streaming replication, if master delete WAL before sent to the
>>> only standby, all transaction will fail forever,
>>> "the
Hi,
So, I have a patch for this. This patch introduces support for
CHECK ONLY syntax while doing a CREATE TABLE as well as during the usual
ALTER TABLE command.
Example:
create table atacc7 (test int, test2 int CHECK ONLY (test>0), CHECK
(test2>10));
create table atacc8 () inherits (atacc7);
p
On Wed, Apr 11, 2012 at 1:39 PM, Joshua Berkus wrote:
>> Ultimately, we're herding cats here. I don't think you're going to
>> get
>> the community to suddenly be willing to march in lockstep instead.
>
> If you, Peter, Simon, Robert, Heikki, Magnus, Peter G., Greg, Bruce and
> Andrew agreed on
Peter Eisentraut writes:
> On lör, 2012-04-07 at 10:38 -0400, Tom Lane wrote:
>> Hm. So are you now suggesting we should get rid of one-argument
>> bytea_agg and replace it with two-argument string_agg(bytea,bytea)?
>> I could support that, since we've not released bytea_agg yet.
> Yes, that lo
On lör, 2012-04-07 at 10:38 -0400, Tom Lane wrote:
> > Nevertheless, the problem would now be that adding string_agg(bytea)
> > would effectively forbid adding string_agg(bytea, delim) in the
> future.
> > So making a two-argument string_agg(bytea, bytea) now seems like the
> > best solution anyway
On ons, 2012-04-11 at 12:48 -0400, Tom Lane wrote:
> > However, the real criteria don't matter as much as coming up with a
> set of criteria we're all willing to obey, whatever they are.
>
> Ultimately, we're herding cats here. I don't think you're going to
> get the community to suddenly be will
> Ultimately, we're herding cats here. I don't think you're going to
> get
> the community to suddenly be willing to march in lockstep instead.
If you, Peter, Simon, Robert, Heikki, Magnus, Peter G., Greg, Bruce and Andrew
agreed on a calendar-driven, mostly unambiguous process and adhered to t
On ons, 2012-04-11 at 06:04 -0400, Greg Smith wrote:
> Compare with:
>
> -Submitter suggests doc change
> -No one has a strong opinion on it, may not be picked up at all
> -Submitter adds to the next CF
> -Wait for review
> -[Possible repost update with reviewer changes]
> -Ready for committer
> -
On Wed, Apr 11, 2012 at 11:49 AM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of mié abr 11 12:44:02 -0300 2012:
>> Me neither, but I don't know how far it scales. Having certain people
>> who are defined as, say, doc-only committers will not only make it
>> clear to those people
Joshua Berkus writes:
> From my observation, the CF process ... in fact, all development
> processes we've had in Postgres ... have suffered from only one
> problem: lack of consensus on how the process should work. For
> example, we've *never* had consensus around the criteria for kicking
> a pa
On Wed, Apr 11, 2012 at 18:29, Josh Kupershmidt wrote:
> On Wed, Apr 11, 2012 at 8:59 AM, Peter Geoghegan
> wrote:
>> On 11 April 2012 15:35, Magnus Hagander wrote:
>
>>> For example, Thom (and others) could collect a number of typo fixes in
>>> their own repo and then just ask for a merge.The
On Thu, Apr 12, 2012 at 12:56 AM, Fujii Masao wrote:
> On Wed, Apr 11, 2012 at 3:31 PM, 乔志强 wrote:
>> So in sync streaming replication, if master delete WAL before sent to the
>> only standby, all transaction will fail forever,
>> "the master tries to avoid a PANIC error rather than termination
"Etsuro Fujita" writes:
> This is a little patch to fix a typo in contrib/file_fdw.
I think that comment is fine as-is.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.or
On Wed, Apr 11, 2012 at 8:59 AM, Peter Geoghegan wrote:
> On 11 April 2012 15:35, Magnus Hagander wrote:
>> For example, Thom (and others) could collect a number of typo fixes in
>> their own repo and then just ask for a merge.The advantage over just
>> staging multiple commits and then submitti
Robert Haas writes:
> On Wed, Apr 11, 2012 at 11:38 AM, Tom Lane wrote:
>> We've frequently had, and still have today, committers who are
>> understood to have limited areas of expertise and are given commit
>> bits on the honor system to not break what they don't know well.
>> I don't have any p
On 4/11/12, Fujii Masao wrote:
> On Wed, Apr 11, 2012 at 3:31 PM, 乔志强 wrote:
>> So in sync streaming replication, if master delete WAL before sent to the
>> only standby, all transaction will fail forever,
>> "the master tries to avoid a PANIC error rather than termination of
>> replication." but
Tom Lane wrote:
> What I'd be interested to see is number of lines changed per unit
> time; that would be a much better measure of patch rate IMHO.
Based on `git diff --shortstat` between tags, for the whole tree,
this is what shows up:
files
git tag changed insertions
On 11 April 2012 15:35, Magnus Hagander wrote:
> Might it be worthwhile to allow some sort of "staging repository" and
> actually start using the git stuff a bit more around this? E.g. we
> could have a "docs repo" somewhere where more people have commit bits,
> and then they are just regularly me
On Wed, Apr 11, 2012 at 3:31 PM, 乔志强 wrote:
> So in sync streaming replication, if master delete WAL before sent to the
> only standby, all transaction will fail forever,
> "the master tries to avoid a PANIC error rather than termination of
> replication." but in sync replication, termination of
All,
>From my observation, the CF process ... in fact, all development processes
>we've had in Postgres ... have suffered from only one problem: lack of
>consensus on how the process should work. For example, we've *never* had
>consensus around the criteria for kicking a patch out of a commitf
On 4/11/12, Kevin Grittner wrote:
> Michael Nolan wrote:
>> On 4/11/12, 乔志强 wrote:
>
>>> But when a transaction larger than 1GB...
>>
>> Then you may need WAL space larger than 1GB as well. For
>> replication to work, it seems likely that you may need to have
>> sufficient WAL space to handle a
Excerpts from Robert Haas's message of mié abr 11 12:44:02 -0300 2012:
> Me neither, but I don't know how far it scales. Having certain people
> who are defined as, say, doc-only committers will not only make it
> clear to those people what they're expected to commit, but also clear
> to everyon
On Wed, Apr 11, 2012 at 11:38 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Apr 11, 2012 at 10:35 AM, Magnus Hagander
>> wrote:
>>> Might it be worthwhile to allow some sort of "staging repository" and
>>> actually start using the git stuff a bit more around this?
>
>> ... As far as I ca
Robert Haas writes:
> On Wed, Apr 11, 2012 at 10:35 AM, Magnus Hagander wrote:
>> Might it be worthwhile to allow some sort of "staging repository" and
>> actually start using the git stuff a bit more around this?
> ... As far as I can see, this basically amounts to
> bundling lots of unrelated
On Wed, Apr 11, 2012 at 10:35 AM, Magnus Hagander wrote:
> Since the topic is somewhat drifting here anyway.. :-)
>
> Might it be worthwhile to allow some sort of "staging repository" and
> actually start using the git stuff a bit more around this? E.g. we
> could have a "docs repo" somewhere wher
Michael Nolan wrote:
> On 4/11/12, 乔志强 wrote:
>> But when a transaction larger than 1GB...
>
> Then you may need WAL space larger than 1GB as well. For
> replication to work, it seems likely that you may need to have
> sufficient WAL space to handle a row, possibly the entire
> transaction..
Excerpts from Magnus Hagander's message of mié abr 11 11:35:10 -0300 2012:
> For example, Thom (and others) could collect a number of typo fixes in
> their own repo and then just ask for a merge.The advantage over just
> staging multiple commits and then submitting a patch would be that
> multipl
On 04/10/2012 08:43 PM, Greg Smith wrote:
On 04/10/2012 01:28 PM, Robert Haas wrote:
The fact is that we have no shortage of committers - there are 19
people who have access to push code into our master git repository. A
handful of those people have basically completely left the project and
t
On Tue, Apr 10, 2012 at 10:41 PM, Atri Sharma wrote:
>>>Well. maybe I spoke too soon...JNI is probably the best route. Since
>>>SPI is off the table, all we're really pulling in from pl/java is the
>>>(non-trivial) proper installation of a jvm into a postgres process.
>>>pl/java is essentially a
Hi all,
In continuation to the discussion regarding my JDBC wrapping FDW,I have been
talking to members of the community and I have two approaches on which I
would request your suggestions and opinions:
>I think we are back on the initial approach I proposed(hooking directly
into the JVM and ex
On 4/11/12, 乔志强 wrote:
>
>> Yes, increase wal_keep_segments. Even if you set wal_keep_segments to 64,
>> the amount of disk space for WAL files is only 1GB, so there is no need to
>> worry so much, I think. No?
>
> But when a transaction larger than 1GB...
Then you may need WAL space larger than
On Tue, Apr 10, 2012 at 10:41 PM, Atri Sharma wrote:
>>Well. maybe I spoke too soon...JNI is probably the best route. Since
>>SPI is off the table, all we're really pulling in from pl/java is the
>>(non-trivial) proper installation of a jvm into a postgres process.
>>pl/java is essentially a wrap
On Wed, Apr 11, 2012 at 16:24, Tom Lane wrote:
> Greg Smith writes:
>> On 04/10/2012 09:14 PM, Robert Haas wrote:
>>> I wouldn't object to creating some doc-only committers. OTOH, I would
>>> object to anyone making non-trivial documentation enhancements without
>>> posting their patches first a
On 11 April 2012 03:26, Tom Lane wrote:
> [ scratches head... ] That's supposed to be total lines of code in our
> source tree? What's the big drop in late 2009, then?
I had wondered about that myself - all I can tell you is that I used
the tool as advertised, without any adornments. This parti
Greg Smith writes:
> On 04/10/2012 09:14 PM, Robert Haas wrote:
>> I wouldn't object to creating some doc-only committers. OTOH, I would
>> object to anyone making non-trivial documentation enhancements without
>> posting their patches first and having a second person look it over,
>> so how much
On Wed, Apr 11, 2012 at 01:53:06AM +0100, Peter Geoghegan wrote:
> On 11 April 2012 01:16, Tom Lane wrote:
> > Peter Geoghegan writes:
> >> On 11 April 2012 00:35, Robert Haas wrote:
> >>> If people need something like that, couldn't they create it by hashing
> >>> the normalized query text with
On 04/10/2012 09:14 PM, Robert Haas wrote:
I wouldn't object to creating some doc-only committers. OTOH, I would
object to anyone making non-trivial documentation enhancements without
posting their patches first and having a second person look it over,
so how much difference is there, really?
Hi all,
(2012/03/07 3:39), Tom Lane wrote:
> A bigger issue with postgresql_fdw_validator is that it supposes that
> the core backend is authoritative as to what options libpq supports,
> which is bad design on its face. It would be much more sensible for
> dblink to be asking libpq what options
On Tue, Apr 10, 2012 at 8:12 PM, Robert Haas wrote:
> However exactly
> the list turns out, there is no question that non-committers have been
> quite successful in getting significant feature enhancements committed
> in each of the last three releases, and I'm pretty confident it goes
> back a lo
Excerpts from Alvaro Herrera's message of lun abr 09 16:41:50 -0300 2012:
> There are three minor things that need to be changed for this to be
> committable:
Committed this patch after some more editorialization; in particular the
test was rewritten so that instead of trying to connect, it uses
This is a little patch to fix a typo in contrib/file_fdw.
Best regards,
Etsuro Fujita
file_fdw_typo_fix.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-ha
70 matches
Mail list logo