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';
?column?
--
hello
(1 row)
On 18/10/13 18:01, Amit Kapila wrote:
On Wed, Oct 16, 2013 at 5:55 PM, Stéphan BEUZE
stephan.be...@douane.finances.gouv.fr wrote:
The following query is performed concurrently by two threads logged in with
two different users:
WITH raw_stat AS (
SELECT
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
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,
On Fri, Oct 18, 2013 at 1:39 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Oct 11, 2013 at 1:14 AM, Noah Misch n...@leadboat.com 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,
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:
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
On Fri, Oct 18, 2013 at 1:13 PM, Jaime Casanova ja...@2ndquadrant.com wrote:
= Code functionality =
+ {restore_command, PGC_POSTMASTER, WAL_ARCHIVE_RECOVERY,
+ {archive_cleanup_command, PGC_POSTMASTER, WAL_ARCHIVE_RECOVERY,
+ {recovery_end_command, PGC_POSTMASTER,
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
On Mon, Oct 14, 2013 at 9:12 AM, Andres Freund and...@2ndquadrant.com 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
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 Thu, Oct 17, 2013 at 5:41 PM, Peter Eisentraut pete...@gmx.net 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
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 execute
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,
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
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';
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 robertmh...@gmail.com wrote:
On Thu, Oct 17, 2013 at 5:41 PM, Peter Eisentraut pete...@gmx.net wrote:
On 10/17/13 12:45 PM, Robert Haas wrote:
The
On Fri, Oct 18, 2013 at 7:11 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Oct 14, 2013 at 9:12 AM, Andres Freund and...@2ndquadrant.com 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
On Fri, Oct 18, 2013 at 9:39 AM, Tim Kane tim.k...@gmail.com 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
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
On Tue, Sep 17, 2013 at 6:16 PM, Marko Tiikkaja ma...@joh.to 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. Marking
=?ISO-8859-1?Q?St=E9phan_BEUZE?= stephan.be...@douane.finances.gouv.fr 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,
On Wed, Oct 9, 2013 at 2:28 PM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Sep 14, 2013 at 3:03 AM, Amit Kapila amit.kapil...@gmail.com 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
On Fri, Oct 18, 2013 at 1:34 AM, Dean Rasheed dean.a.rash...@gmail.com 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
Tomas Vondra t...@fuzzy.cz 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*
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 tool
On 18 Říjen 2013, 17:52, Tom Lane wrote:
Tomas Vondra t...@fuzzy.cz 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
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 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 better.
So,
On 10/18/2013 02:41 PM, Robert Haas wrote:
On Thu, Oct 17, 2013 at 5:41 PM, Peter Eisentraut pete...@gmx.net 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
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 pete...@gmx.net wrote:
On 10/17/13 12:45 PM, Robert Haas wrote:
The attached patch, which I propose to apply relatively soon if nobody
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 than that
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 pete...@gmx.net wrote:
On 10/17/13 12:45 PM, Robert Haas wrote:
The attached patch, which I
On Fri, Oct 18, 2013 at 11:32 AM, Josh Berkus j...@agliodbs.com 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
On Thu, Oct 17, 2013 at 3:10 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Oct 17, 2013 at 12:22 AM, Noah Misch n...@leadboat.com 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
On Fri, Oct 18, 2013 at 9:55 AM, Ants Aasma a...@cybertec.at 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
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 problems for
On Fri, Oct 18, 2013 at 8:04 PM, Peter Geoghegan p...@heroku.com wrote:
On Fri, Oct 18, 2013 at 9:55 AM, Ants Aasma a...@cybertec.at 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
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 packaging
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
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 also
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 has create
On 2013-10-18 08:11:29 -0400, Robert Haas wrote:
On Mon, Oct 14, 2013 at 9:12 AM, Andres Freund and...@2ndquadrant.com 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
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 have a
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
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 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 hopefully
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 cause
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?
The
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.
Hmmm
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
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/long term,
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 Fri, Oct 18, 2013 at 11:32 AM, Josh Berkus j...@agliodbs.com 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
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 extra
* 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
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 actually
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 used it
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 following
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
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
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:
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
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
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
On Fri, Oct 18, 2013 at 3:43 PM, Stéphan BEUZE
stephan.be...@douane.finances.gouv.fr 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,
On Fri, Oct 18, 2013 at 9:01 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Oct 9, 2013 at 2:28 PM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Sep 14, 2013 at 3:03 AM, Amit Kapila amit.kapil...@gmail.com wrote:
On Monday, July 08, 2013 5:16 PM Andres Freund wrote:
On 2013-07-08
On Fri, Oct 18, 2013 at 9:24 PM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
On Tue, Oct 15, 2013 at 11:41 AM, KONDO Mitsumasa
kondo.mitsum...@lab.ntt.co.jp wrote:
(2013/10/15 13:33), Amit Kapila wrote:
Snappy is good mainly for un-compressible data, see the link below:
69 matches
Mail list logo
