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
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
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
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 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?
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
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 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
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 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 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
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 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
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
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
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..
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
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 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
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 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
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 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
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
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 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
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 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
"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 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
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
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 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
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
> -
> 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 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
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
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 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
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 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
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"
>
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
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
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
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 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
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
>>>
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 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
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
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: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
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 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 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 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
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 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
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 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
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
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
>
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
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 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 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
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
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
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
70 matches
Mail list logo
