On Thu, Oct 17, 2013 at 8:57 AM, Amit Kapila wrote:
> On Wed, Oct 16, 2013 at 4:30 AM, Gibheer wrote:
>> On Mon, 14 Oct 2013 11:52:57 +0530
>> Amit Kapila wrote:
>>
>>> On Sun, Oct 13, 2013 at 2:08 PM, Gibheer
>>> wrote:
>>> > On Sun, 13 Oct 2013 11:38:17 +0530
>>> > Amit Kapila wrote:
>>> >
>
On Tue, Oct 15, 2013 at 11:41 AM, KONDO Mitsumasa
wrote:
> (2013/10/15 13:33), Amit Kapila wrote:
>>
>> Snappy is good mainly for un-compressible data, see the link below:
>>
>> http://www.postgresql.org/message-id/CAAZKuFZCOCHsswQM60ioDO_hk12tA7OG3YcJA8v=4yebmoa...@mail.gmail.com
>
> This result
On Fri, Oct 18, 2013 at 9:24 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>
>> A broader complaint I have with this patch is that it almost but
>> not-quite solves a problem I've had a few times in the past: namely,
>> searching through the data directory for data blocks which have LSNs
>> in
On Fri, Oct 18, 2013 at 9:01 PM, Robert Haas wrote:
> On Wed, Oct 9, 2013 at 2:28 PM, Robert Haas wrote:
>> On Sat, Sep 14, 2013 at 3:03 AM, Amit Kapila wrote:
On Monday, July 08, 2013 5:16 PM Andres Freund wrote:
>On 2013-07-08 17:10:43 +0530, Amit Kapila wrote:
>> On Monday, July 0
On Fri, Oct 18, 2013 at 3:43 PM, Stéphan BEUZE
wrote:
> Here I provide more details about the environment where the error occurs:
>
> * ENVIRONMENT
> Client:
> Java Web Application running on JBoss 5.0.0.GA - JDK 1.6.0_24 64bit
>
> Server:
> Postgresql 9.2.4, compiled by Visual C++ build
On Thu, 2013-10-17 at 13:49 +1100, James Sewell wrote:
> The search+bind mode issue is one of documentation location, I have
> fixed it by moving the section to the applied to both list. As the
> patch is to do with post-auth response this is correct.
>
Makes sense.
> As far as the issue when s
On Fri, 2013-10-18 at 16:00 -0300, Alvaro Herrera wrote:
> Please have a look at my patch at
> 20130827215416.gf4...@eldon.alvh.no-ip.org particularly the checkdir.c
> file. Perhaps we'd like to put both these routines (which are related
> to directories) in a single file (directory.c?). In that
I would be more inclined to let GraphViz into the process than Dia; the
former fits *much* better into a Make-based process.
It is worth observing that there are schema diagramming systems (SchemaSpy
is mighty likable) that build diagrams using GraphViz. We have integrated
this into internal depl
On 10/18/13 8:39 AM, Andrew Dunstan wrote:
On 10/18/2013 02:19 AM, Fabien COELHO wrote:
IMHO the current behavior is broken:
decibel@decina:[17:46]~/pgsql/HEAD/i$bin/psql -c 'select 1' -c 'select 2'
?column?
--
2
(1 row)
Another try with one -c but with similar results:
s
On 10/17/13 4:01 PM, Vik Fearing wrote:
On 10/17/2013 06:59 PM, Josh Berkus wrote:
Our project has a serious, chronic problem with giving new
patch-submitters a bad experience, and this patch is a good example of
that. The ultimate result is that people go off to contribute to other
projects wh
On 10/17/13 12:10 PM, Josh Berkus wrote:
On 10/17/2013 10:01 AM, Robert Haas wrote:
But if you're asking my opinion, I think doing it on the function
level is a whole lot better and easier to get right. A flag like the
one I mentioned here can be set for one particular function with the
absolut
On 18.10.2013 23:52, Peter Eisentraut wrote:
> On 10/18/13 5:35 PM, Stephen Frost wrote:
>> I can't see it being a major effort to get it from the wiki into
>> the docs, though perhaps I'm being a bit over-optomistic wrt that.
>
> Hah!
>
> Consider that an image would have to work with the follow
On 18.10.2013 23:35, Stephen Frost wrote:
> Tomas,
>
> * Tomas Vondra (t...@fuzzy.cz) wrote:
>> My impression from that thread was that one of the requirements is
>> reasonable versioning / diff support, and AFAIK that's not a good
>> match for any GUI-based product. So while I like dia and I use
On 2013-10-18 18:46:10 -0400, Stephen Frost wrote:
> As to your point about not wanting to do it for a single image- it seems
> we could potentially say that for every individual image proposed, but
> if we don't keep track of those images anywhere then we may not realize
> that 5 or 10 have actual
* Peter Eisentraut (pete...@gmx.net) wrote:
> In my mind, it's not worth the effort unless we have, say, at least a
> dozen really useful images to add. I don't want to go through this
> entire pain for one image on a pretty minor topic.
These are certainly fair issues- my point was merely that o
On 10/18/2013 02:58 PM, Jaime Casanova wrote:
> well #3 just add a line in postgresql.conf (an include_if_exists) and
> current patch gives an error in case it finds the file (i'm suggesting
> to make it a warning instead).
> how does that makes our code more complicated?
Well, that's a couple ext
On Fri, Oct 18, 2013 at 11:32 AM, Josh Berkus wrote:
> Jaime,
>
>> well, after upgrade you should do checks. and even if it happens,
>> after it happens once people will be aware of the change.
>> now, some suggestions were made to avoid the problem. 1) read the file
>> if exists last in the proce
On 10/18/13 5:35 PM, Stephen Frost wrote:
> I can't see it being a major effort to get it from the wiki into the
> docs, though perhaps I'm being a bit over-optomistic wrt that.
Hah!
Consider that an image would have to work with the following
toolchains/output formats:
- standalone HTML output
On 2013-10-18 14:16:04 -0700, Josh Berkus wrote:
> On 10/18/2013 01:35 PM, Andres Freund wrote:
> > On 2013-10-18 13:16:52 -0700, Josh Berkus wrote:
> >> I thought changeset extraction was the only thing going into core? What
> >> else do we need?
> >
> > Well, I personally want more in core mid/
Tomas,
* Tomas Vondra (t...@fuzzy.cz) wrote:
> My impression from that thread was that one of the requirements is
> reasonable versioning / diff support, and AFAIK that's not a good match
> for any GUI-based product. So while I like dia and I used it for drawing
> the charts I submitted today, I d
On 10/18/2013 01:35 PM, Andres Freund wrote:
> On 2013-10-18 13:16:52 -0700, Josh Berkus wrote:
>> I thought changeset extraction was the only thing going into core? What
>> else do we need?
>
> Well, I personally want more in core mid/long term, but anyway.
I've lost track of the plan, then.
H
On Fri, Oct 18, 2013 at 09:05:38PM +1300, David Rowley wrote:
> As for signed vs unsigned, I've not looked at all of the places where
> MAXALIGN is used, but I just assumed it was for memory addresses, if this
> is the case then I'm confused why we'd ever want a negative valued memory
> address?
T
On 2013-10-18 13:16:52 -0700, Josh Berkus wrote:
> On 10/18/2013 12:29 PM, Andres Freund wrote:
> > On 2013-10-18 09:32:15 -0700, Josh Berkus wrote:
> >> For that matter, 9.4 is a very good time (relatively speaking) to break
> >> replication tools because the new logical replication is going to ca
On 10/18/2013 12:29 PM, Andres Freund wrote:
> On 2013-10-18 09:32:15 -0700, Josh Berkus wrote:
>> For that matter, 9.4 is a very good time (relatively speaking) to break
>> replication tools because the new logical replication is going to cause
>> everyone to rev their tools anyway.
>
> We're hop
Peter Eisentraut wrote:
[good suggestions for improvement]
I'll send an updated patch on Monday.
Yours,
Laurenz Albe
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2013-10-18 09:32:15 -0700, Josh Berkus wrote:
> For that matter, 9.4 is a very good time (relatively speaking) to break
> replication tools because the new logical replication is going to cause
> everyone to rev their tools anyway.
We're hopefully getting changeset extraction in, but there's li
Peter Eisentraut wrote:
> On 10/16/13 10:10 PM, Noah Misch wrote:
> > dirmod.c perhaps deserves a
> > split into libpgcommon parts (e.g. pgfnames()) and libpgport parts
> > (e.g. pgrename()).
>
> I have also come to this realization. I propose to move pgfnames to
> src/common/pgfnames.c.
Please
On 2013-10-18 08:11:29 -0400, Robert Haas wrote:
> On Mon, Oct 14, 2013 at 9:12 AM, Andres Freund wrote:
> > Attached you can find version 6.4 of the patchset:
>
> So I'm still unhappy with the arbitrary logic in what's now patch 1
> for choosing the candidate key. On another thread, someone men
On 2013-10-14 09:36:03 -0400, Robert Haas wrote:
> > I thought and implemented that in the beginning. Unfortunately it's not
> > enough :(. That's probably the issue that took me longest to understand
> > in this patchseries...
> >
> > Combocids can only fix the case where a transaction actually ha
On 10/16/13 10:10 PM, Noah Misch wrote:
> dirmod.c perhaps deserves a
> split into libpgcommon parts (e.g. pgfnames()) and libpgport parts
> (e.g. pgrename()).
I have also come to this realization. I propose to move pgfnames to
src/common/pgfnames.c.
> Hopefully there's not much more.
I have al
Hi all,
The attached patch is a continuation of Robert's work [1].
I made some changes:
- use of Latches instead of pg_usleep, so we don't have to wakeup regularly.
- call HandleStartupProcInterrupts() before CheckForStandbyTrigger()
because might change the trigger file's location
- compute reco
On 10/17/2013 09:45 AM, Robert Haas wrote:
>>> According to http://en.wikipedia.org/wiki/UnixWare, UnixWare is not
>>> dead, although there have been no new releases in 5 years.
Gee, I wonder why?
I'll point out that SCO laid off all of its packagers three or four
years ago. So nobody is packagi
On Fri, Oct 18, 2013 at 8:04 PM, Peter Geoghegan wrote:
> On Fri, Oct 18, 2013 at 9:55 AM, Ants Aasma wrote:
>> FWIW, I think that if we approach coding lock free algorithms
>> correctly - i.e. "which memory barriers can we avoid while being
>> safe", instead of "which memory barriers we need to
On 2013-10-18 18:36:03 +0200, Stefan Kaltenbrunner wrote:
> On 10/18/2013 06:29 PM, Andres Freund wrote:
> > On 2013-10-18 18:24:58 +0200, Stefan Kaltenbrunner wrote:
> >> hmm there are still some operating systems that "officially" support the
> >> alpha architecture which will likely result in pr
On Fri, Oct 18, 2013 at 9:55 AM, Ants Aasma wrote:
> FWIW, I think that if we approach coding lock free algorithms
> correctly - i.e. "which memory barriers can we avoid while being
> safe", instead of "which memory barriers we need to add to become
> safe" - then supporting Alpha isn't a huge amo
On Thu, Oct 17, 2013 at 3:10 PM, Robert Haas wrote:
> On Thu, Oct 17, 2013 at 12:22 AM, Noah Misch wrote:
>> Removing support for alpha is a different animal compared to removing support
>> for non-gcc MIPS and most of the others in your list. A hacker wishing to
>> restore support for another M
On Fri, Oct 18, 2013 at 11:32 AM, Josh Berkus wrote:
>
>> exactly as it is now, if it sees the recovery trigger file, then it
>> starts ArchiveRecovery and after it finish delete the file (the only
>> difference) and increment the timeline
>
> OK, so if I'm doing a PITR recovery, I just put the re
On 10/18/2013 06:29 PM, Andres Freund wrote:
> On 2013-10-18 18:24:58 +0200, Stefan Kaltenbrunner wrote:
>> On 10/18/2013 02:41 PM, Robert Haas wrote:
>>> On Thu, Oct 17, 2013 at 5:41 PM, Peter Eisentraut wrote:
On 10/17/13 12:45 PM, Robert Haas wrote:
> The attached patch, which I propos
Jaime,
>> Except that we'll want 9.4's -R to do something, probably create a file
>> called conf.d/replication.conf. Mind you, it won't need the same wonky
>> quoting stuff.
>>
>
> Currently the patch uses -R to create the recovery trigger file
Right, I'm saying that we'll want to do better tha
On 2013-10-18 18:24:58 +0200, Stefan Kaltenbrunner wrote:
> On 10/18/2013 02:41 PM, Robert Haas wrote:
> > On Thu, Oct 17, 2013 at 5:41 PM, Peter Eisentraut wrote:
> >> On 10/17/13 12:45 PM, Robert Haas wrote:
> >>> The attached patch, which I propose to apply relatively soon if nobody
> >>> objec
On 10/18/2013 02:41 PM, Robert Haas wrote:
> On Thu, Oct 17, 2013 at 5:41 PM, Peter Eisentraut wrote:
>> On 10/17/13 12:45 PM, Robert Haas wrote:
>>> The attached patch, which I propose to apply relatively soon if nobody
>>> objects, removes the IRIX port.
>>
>> +1
>
> Done. And here's a patch f
On 10/17/2013 01:41 PM, Vik Fearing wrote:
>> > Perhaps; but it has also been an example of the benefits of having
>> > tight review.
> FWIW, I agree. I have been impressed by the rigorous review process of
> this project ever since I started following it.
>
OK, good! That makes me feel bette
All,
So, I did an informal survey last night a SFPUG, among about 30
PostgreSQL DBAs and developers. While hardly a scientific sample, it's
a data point on what we're looking at for servers.
Out of the 30, 6 had one or more production instances of PostgreSQL
running on machines or VMs with less
On 18 Říjen 2013, 17:52, Tom Lane wrote:
> "Tomas Vondra" writes:
>> 2) Is there any particular reason why
>> PlanForeignModify/BeginForeignModify
>> require the fdw_private to be a List*, and not a generic pointer?
>
> That data has to be copiable by copyObject(), which a generic void* is
> not.
Robert Haas escribió:
> A broader complaint I have with this patch is that it almost but
> not-quite solves a problem I've had a few times in the past: namely,
> searching through the data directory for data blocks which have LSNs
> in the future. This has come up a few times for me, and this too
"Tomas Vondra" writes:
> 2) Is there any particular reason why PlanForeignModify/BeginForeignModify
> require the fdw_private to be a List*, and not a generic pointer?
That data has to be copiable by copyObject(), which a generic void* is
not. We could perhaps have made it Node* instead, but tha
On Fri, Oct 18, 2013 at 1:34 AM, Dean Rasheed wrote:
>> Personally, I think this is too fancy anyway. I'd just complete all
>> views and foreign tables and be done with it. We don't inspect
>> permissions either, for example. This might be too confusing for users.
>
> Yeah, I think you're proba
On Wed, Oct 9, 2013 at 2:28 PM, Robert Haas wrote:
> On Sat, Sep 14, 2013 at 3:03 AM, Amit Kapila wrote:
>>>On Monday, July 08, 2013 5:16 PM Andres Freund wrote:
On 2013-07-08 17:10:43 +0530, Amit Kapila wrote:
> On Monday, July 08, 2013 4:26 PM Andres Freund wrote:
> > On 2013-07-08
=?ISO-8859-1?Q?St=E9phan_BEUZE?= writes:
>> So the question is about used extensions or contrib. (it can be loaded
>> by server, or in a session with LOAD, it can be auto-explain,
>> pg_stat_statement, ).
> I don't use any used extensions or contrib.
Well, you're doing *something* that you h
On Tue, Sep 17, 2013 at 6:16 PM, Marko Tiikkaja wrote:
> On 2013-09-17 12:53, Dean Rasheed wrote:
>>
>> Thanks for the review. Those changes all look sensible to me.
>>
>> Here's an updated patch incorporating all your fixes, and rebased to
>> apply without offsets.
>
>
> Looks good to me. Markin
Hi,
I've been exploring the new FDW API in the past few days, and I'm slightly
confused by the fdw_private fields. A few comments:
1) Generally all the API functions pass data using fields in the nodes
(e.g. GetForeignRelSize uses baserel->fdw_private etc.), but
PlanForeignModify simply returns t
On Fri, Oct 18, 2013 at 9:39 AM, Tim Kane wrote:
> Just to be pedantic, commit message shows
> "support for Tru64 ended in 201."
>
> I think you mean 2012.
Duh, I'm a dork. Thanks.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via
On Fri, Oct 18, 2013 at 7:11 AM, Robert Haas wrote:
> On Mon, Oct 14, 2013 at 9:12 AM, Andres Freund wrote:
>> Attached you can find version 6.4 of the patchset:
>
> So I'm still unhappy with the arbitrary logic in what's now patch 1
> for choosing the candidate key. On another thread, someone m
Just to be pedantic, commit message shows
"support for Tru64 ended in 201."
I think you mean 2012.
On 18/10/2013 13:41, "Robert Haas" wrote:
>On Thu, Oct 17, 2013 at 5:41 PM, Peter Eisentraut wrote:
>> On 10/17/13 12:45 PM, Robert Haas wrote:
>>> The attached patch, which I propose
On 10/18/2013 02:19 AM, Fabien COELHO wrote:
IMHO the current behavior is broken:
decibel@decina:[17:46]~/pgsql/HEAD/i$bin/psql -c 'select 1' -c
'select 2'
?column?
--
2
(1 row)
Another try with one -c but with similar results:
sh> psql -c "SELECT 1; SELECT 'hello';"
>From the following mail, copy behaviour between stdin and normal file having
>some inconsistency.
http://www.postgresql.org/message-id/ce85a517.4878e%tim.k...@gmail.com
The issue was that if copy execute "from stdin", then it goes to the server to
execute the command and then server req
Those extensions are installed in the system, so you can install them in
PostgreSQL.
You may also have contrib run by servers without being pure extension.
So the question is about used extensions or contrib. (it can be loaded
by server, or in a session with LOAD, it can be auto-explain,
pg_sta
On 10/18/2013 04:02 AM, KONDO Mitsumasa wrote:
> I submit patch adding min and max execute statement time in pg_stat_statement
> in
> next CF.
>
> pg_stat_statement have execution time, but it is average execution time and
> does
> not provide detail information very much. So I add min and max e
On Thu, Oct 17, 2013 at 5:41 PM, Peter Eisentraut wrote:
> On 10/17/13 12:45 PM, Robert Haas wrote:
>> The attached patch, which I propose to apply relatively soon if nobody
>> objects, removes the IRIX port.
>
> +1
Done. And here's a patch for removing the alpha architecture and
Tru64 UNIX (aka
On 10/16/2013 01:17 PM, ankit bhardwaj wrote:
I am new to postgre sql .And i want to add some new feature to postgresql
As a startup i have taken the project to add syntax for table partitioning
Welcome to the list!
There has been some previous work done on adding this syntax, but I have
not
On Mon, Oct 14, 2013 at 9:12 AM, Andres Freund wrote:
> Attached you can find version 6.4 of the patchset:
So I'm still unhappy with the arbitrary logic in what's now patch 1
for choosing the candidate key. On another thread, someone mentioned
that they might want the entire old tuple, and that
> > What PostgreSQL version is this?
>
> I'm using "Postgresql 9.2.4, compiled by Visual C++ build 1600,
> 64-bit"
> > Are there any triggers on any of these tables?
>
> There are no triggers.
>
> > Any noteworthy extensions installed?
>
> Here is the results returned by "select * from
> pg_
On Fri, Oct 18, 2013 at 1:13 PM, Jaime Casanova wrote:
>>> = Code & functionality =
>>
>>> + {"restore_command", PGC_POSTMASTER, WAL_ARCHIVE_RECOVERY,
>>> + {"archive_cleanup_command", PGC_POSTMASTER, WAL_ARCHIVE_RECOVERY,
>>> + {"recovery_end_command", PGC_POSTMASTER, WAL_ARCHIV
You may find additional answers in my last email.
However, I'll try to adress some of your questions.
a. Are there any new connections happening, how this table is getting
populated?
Check my last email.
b. How did you concluded that above sql statement leads to error,
because this e
Here I provide more details about the environment where the error occurs:
* ENVIRONMENT
Client:
Java Web Application running on JBoss 5.0.0.GA - JDK 1.6.0_24 64bit
Server:
Postgresql 9.2.4, compiled by Visual C++ build 1600, 64bit
Client and Server run on the same platform:
Windows
On Fri, Oct 18, 2013 at 1:39 AM, Robert Haas wrote:
> On Fri, Oct 11, 2013 at 1:14 AM, Noah Misch wrote:
> > On Thu, Oct 10, 2013 at 03:23:30PM +0200, Andres Freund wrote:
> >> On 2013-10-10 08:59:47 -0400, Robert Haas wrote:
> >> > On Tue, Oct 8, 2013 at 6:24 PM, Andres Freund
> wrote:
> >> >
Hi,
I submit improvement of pg_stat_statement usage patch in CF3.
In pg_stat_statement, I think buffer hit ratio is very important value. However,
it is difficult to calculate it, and it need complicated SQL. This patch makes
it
more simple usage and documentation.
> -bench=# SELECT query, call
I submit patch adding min and max execute statement time in pg_stat_statement in
next CF.
pg_stat_statement have execution time, but it is average execution time and does
not provide detail information very much. So I add min and max execute statement
time in pg_stat_statement columns. Usage is al
On 18/10/13 18:01, Amit Kapila wrote:
On Wed, Oct 16, 2013 at 5:55 PM, Stéphan BEUZE
wrote:
The following query is performed concurrently by two threads logged in with
two different users:
WITH raw_stat AS (
SELECT
host(client_addr) as client_addr,
pid ,
69 matches
Mail list logo
