On 11/24/2011 05:21 AM, Alvaro Herrera wrote:
A coworker also suggested using a different designator:
postgresqli:///path/to/socket:5433/database
postgresqli://:5433/database
This is not unprecedented. An example is how CUPS handles this problem
when connecting printers using URIs:
On 11/25/2011 08:39 AM, Alvaro Herrera wrote:
I was about to commit this when I noticed that the avg values may not be
all that representative of reality after all; consider that it's
computed across the whole duration of the vacuuming operation, including
the index scans ... it'd be possibly
On 11/25/2011 05:10 PM, Robert Haas wrote:
This patch adds a count of the number of buffers dirtied to VACUUM,
but it strikes me that it would be useful to add similar tracking to
pgBufferUsage. Attached is a patch for that. You can see the new
counters through pg_stat_statements or with
On 28 Listopad 2011, 8:54, Greg Smith wrote:
-Have one of the PostgreSQL background processes keep track of a time
estimate on its own, only periodically pausing to sync against the real
time. Then most calls to gettimeofday() can use that value instead. I
was thinking of that idea for
On 11/13/2011 12:13 AM, Simon Riggs wrote:
On Tue, Nov 1, 2011 at 12:11 PM, Simon Riggssi...@2ndquadrant.com wrote:
When I say skip the shutdown checkpoint, I mean remove it from the
critical path of required actions at the end of recovery. We can still
have a normal checkpoint kicked off at
On 11/13/2011 09:45 AM, Jan Urbański wrote:
The first one factors out some bolerplate related to executing SPI
functions in subtransactions (and idea borrowed from pltcl.c).
While I haven't looked at the code, this seems worthwhile from the
description.
The second one is the actual split.
With plenty of people in the US returning to work on Monday after a
modest break last week, I wanted to put out an updated on the active
CommitFest. I just sent out several pleas for help with specific patches
where only a limited chunk of the community is really in a good position
to test the
On 11/25/2011 04:42 PM, Jeff Janes wrote:
It reports space that is free exclusively for updates as being free.
In other words, it considers space free even if it is reserved against
inserts in deference to fillfactor. This is in contrast to
pg_freespace, which only reports space available for
On 2011-11-15 21:50, Peter Eisentraut wrote:
Patch attached.
I cannot get the patch to apply, this is the output of patch -p1
--dry-run on HEAD.
patching file src/include/catalog/pg_type.h
Hunk #1 succeeded at 217 (offset 1 line).
Hunk #2 succeeded at 234 (offset 1 line).
Hunk #3 succeeded
Excerpts from Greg Smith's message of Mon Nov 28 10:08:42 +0200 2011:
On 11/24/2011 05:21 AM, Alvaro Herrera wrote:
A coworker also suggested using a different designator:
postgresqli:///path/to/socket:5433/database
postgresqli://:5433/database
This is not unprecedented. An example
Hi Kaigai-san,
(2011/11/20 2:42), Kohei KaiGai wrote:
I'm still under reviewing of your patch, so the comment is not overall, sorry.
Thanks for the review!
I'm not sure whether the logic of is_foreign_expr() is appropriate.
It checks oid of the function within FuncExpr and OpExpr to disallow
On 28/11/11 11:00, Greg Smith wrote:
On 11/13/2011 09:45 AM, Jan Urbański wrote:
The second one is the actual split. plpython.c has been split into 11
separate files and one header.
Could you comment a bit more about what the goal of this is? We don't
have a reviewer for this patch yet, and I
Hi Fujita-san,
(2011/11/25 17:27), Etsuro Fujita wrote:
I'm still under reviewing, so the following is not all. I'm sorry.
estimate_costs() have been implemented to ask a remote postgres server
for the result of EXPLAIN for a remote query to get its costs such as
startup_cost and total_cost.
On Thu, Nov 17, 2011 at 10:11, Albe Laurenz laurenz.a...@wien.gv.at wrote:
I wrote:
Here it is. I'll add it to the November commitfest.
Here is the second version.
I realized that it is better to set the option on the SSL object
and not on the SSL context so that it is possible to change it
On 11/27/2011 10:30 PM, Mr. Aaron W. Swenson wrote:
On Sun, Nov 27, 2011 at 12:12:41PM -0800, David E. Wheeler wrote:
On Nov 27, 2011, at 6:11 AM, Andrew Dunstan wrote:
Has this been backpatched as well?
It has been to 9.1.
There may be a simple workaround, but it's non-obvious. I think
On Sat, Nov 26, 2011 at 3:36 PM, Peter Eisentraut pete...@gmx.net wrote:
There is a long-standing oddity in psql that running
psql -f foo.sql
returns error messages with file name and line number, like
psql:foo.sql:1: ERROR: syntax error at or near foo
but running
psql foo.sql does
On Sat, Nov 26, 2011 at 7:20 AM, Florian Schwendener fschw...@hsr.ch wrote:
Hi there!
I built the current PostgreSQL 9.1.1 sources under Ubuntu 11.04 (in a VMware
under Win7).
I followed the steps in this guide:
www.thegeekstuff.com/2009/04/linux-postgresql-install-and-configure-from-source
On Mon, Nov 28, 2011 at 8:10 AM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Nov 26, 2011 at 3:36 PM, Peter Eisentraut pete...@gmx.net wrote:
There is a long-standing oddity in psql that running
psql -f foo.sql
returns error messages with file name and line number, like
On Mon, Nov 28, 2011 at 2:54 AM, Greg Smith g...@2ndquadrant.com wrote:
The real problem with this whole area is that we know there are
systems floating around where the amount of time taken to grab timestamps
like this is just terrible.
Assuming the feature is off by default (and I can't
On Mon, Nov 28, 2011 at 8:49 AM, Gurjeet Singh singh.gurj...@gmail.com wrote:
Naysayers can always make a case for backwards-compatibility, or not
breaking the scripts written with the existing behaviour in mind.
I'm having a hard time imagining how this could break anything. What
scenario did
2011/11/28 Shigeru Hanada shigeru.han...@gmail.com:
I agree that allowing users to control which function/operator should be
pushed down is useful, but GUC seems too large as unit of switching
behavior. Routine Mapping, a mechanism which is defined in SQL/MED
standard, would be the answer for
2011/11/27 Dimitri Fontaine dimi...@2ndquadrant.fr:
And, it seems to me the current proposition of the command trigger
does not support to fire triggers on creation of databases, although
permission checks requires Oid of source database that is not also
appeared in pg_database catalog.
I
Kohei KaiGai kai...@kaigai.gr.jp writes:
How does it inherit an opaque private initialized at BEFORE trigger to
AFTER trigger? I checked your patch, however, it seems to me it does
not have a mechanism to deliver something between BEFORE and AFTER.
Right, there's no such facility provided in
On Nov 28, 2011 8:55 AM, Greg Smith g...@2ndquadrant.com wrote:
On 11/27/2011 04:39 PM, Ants Aasma wrote:
On the AMD I saw about 3% performance drop with timing enabled. On the
Intel machine I couldn't measure any statistically significant change.
Oh no, it's party pooper time again.
Hi,
As discussed few days ago it would be beneficial if we could change the v3
backend-client protocol without breaking backwards compatibility.
Here is a working patch that exports a supported_binary_minor constant and a binary_minor session variable and a that can be used by clients to
On 28 Listopad 2011, 15:40, Greg Stark wrote:
On Nov 28, 2011 8:55 AM, Greg Smith g...@2ndquadrant.com wrote:
On 11/27/2011 04:39 PM, Ants Aasma wrote:
On the AMD I saw about 3% performance drop with timing enabled. On the
Intel machine I couldn't measure any statistically significant
Robert Haas robertmh...@gmail.com writes:
On Mon, Nov 28, 2011 at 2:54 AM, Greg Smith g...@2ndquadrant.com wrote:
The real problem with this whole area is that we know there are
systems floating around where the amount of time taken to grab timestamps
like this is just terrible.
Assuming the
2011/11/28 Dimitri Fontaine dimi...@2ndquadrant.fr:
Kohei KaiGai kai...@kaigai.gr.jp writes:
How does it inherit an opaque private initialized at BEFORE trigger to
AFTER trigger? I checked your patch, however, it seems to me it does
not have a mechanism to deliver something between BEFORE and
On Mon, Nov 28, 2011 at 8:55 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Nov 28, 2011 at 8:49 AM, Gurjeet Singh singh.gurj...@gmail.com
wrote:
Naysayers can always make a case
Should've added that I'm not one of them :)
+1 from me on the improvement.
for
On Nov 28, 2011, at 4:56 AM, Andrew Dunstan wrote:
OK, it's done.
Andrew++ Thanks!
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Excerpts from Peter Eisentraut's message of sáb nov 26 17:36:15 -0300 2011:
There is a long-standing oddity in psql that running
psql -f foo.sql
returns error messages with file name and line number, like
psql:foo.sql:1: ERROR: syntax error at or near foo
but running
psql
On Sun, Nov 27, 2011 at 11:54:38PM -0800, Greg Smith wrote:
On 11/27/2011 04:39 PM, Ants Aasma wrote:
On the AMD I saw about 3% performance drop with timing enabled. On the
Intel machine I couldn't measure any statistically significant change.
Oh no, it's party pooper time again. Sorry I
Andres Freund and...@anarazel.de writes:
On Friday, November 18, 2011 10:14:22 PM Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
Replacing the if chain with if; else if; ... resulted in a small
speedup. Replacing it with a switch() in a bigger one.
Cool, but this patch is
On Sat, Nov 26, 2011 at 6:51 PM, Andres Freund and...@anarazel.de wrote:
On Saturday, November 26, 2011 11:39:23 PM Robert Haas wrote:
On Sat, Nov 26, 2011 at 5:28 PM, Andres Freund and...@anarazel.de
wrote:
On Saturday, November 26, 2011 09:52:17 PM Tom Lane wrote:
I'd just as soon
On Tue, Nov 15, 2011 at 2:23 PM, Peter Eisentraut pete...@gmx.net wrote:
The basics here are mainly informed by the SQL standard. One thing from
there I did not implement is checking for permission of a type used in
CAST (foo AS type). This would be doable but relatively complicated,
and in
Kohei KaiGai kai...@kaigai.gr.jp writes:
I found up a similar idea that acquires control on ProcessUtility_hook and
save necessary contextual information on auto variable then kicks the
original ProcessUtility_hook, then it reference the contextual information
from object_access_hook.
In this
Hi Robert
2011/11/28 Robert Haas robertmh...@gmail.com wrote:
You might want to try this question on pgsql-general or pgsql-novice
rather than here; this is a list for discussing the development of
PostgreSQL itself.
Thanks for the hint.
It was actually my advice to post this question here.
Tomas Vondra t...@fuzzy.cz writes:
Another option would be to reimplement the vsyscall, even on platforms
that don't provide it. The principle is actually quite simple - allocate a
shared memory, store there a current time and update it whenever a clock
interrupt happens. This is basically
On 11/27/2011 06:17 PM, Tom Lane wrote:
Peter Eisentrautpete...@gmx.net writes:
I've committed it now, and some buildfarm members are failing with lack
of shared memory, semaphores, or disk space. Don't know what to do with
that or why so many are failing like that. We could create a way
Excerpts from Tom Lane's message of mar nov 22 01:14:33 -0300 2011:
Alvaro Herrera alvhe...@alvh.no-ip.org writes:
We got a very strange nbtree corruption report some time ago. This was
a btree index on a vey high churn table -- entries are updated and
deleted very quickly, so the index
Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
On Friday, November 18, 2011 10:14:22 PM Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
Replacing the if chain with if; else if; ... resulted in a small
speedup. Replacing it with a switch() in a bigger one.
Cool, but
On Sat, 26 Nov 2011 22:36:15 +0200, Peter Eisentraut wrote:
There is a long-standing oddity in psql that running
psql -f foo.sql
returns error messages with file name and line number, like
psql:foo.sql:1: ERROR: syntax error at or near foo
but running
psql foo.sql does not. I suggest we
On Nov 28, 2011, at 3:44 PM, Alvaro Herrera wrote:
I wonder if it would be worthwhile to build some sort of tool to scan
the heap and ensure that there are index entries for all heap items,
just to test the hypothesis. Not that this would enlighten on the
source of the actual problem.
There
Jim Nasby wrote:
On Nov 28, 2011, at 3:44 PM, Alvaro Herrera wrote:
I wonder if it would be worthwhile to build some sort of tool to scan
the heap and ensure that there are index entries for all heap items,
just to test the hypothesis. Not that this would enlighten on the
source of the
On Nov 28, 2011, at 9:29 AM, Tomas Vondra wrote:
I recall a patch similar to this one was submitted by Greg Stark some
time ago. It used the info for different reasons--to try and figure out
whether reads were cached or not--but I believe it withered rather than
being implemented mainly
On 28.11.2011 22:32, Dimitri Fontaine wrote:
Tomas Vondra t...@fuzzy.cz writes:
Another option would be to reimplement the vsyscall, even on platforms
that don't provide it. The principle is actually quite simple - allocate a
shared memory, store there a current time and update it whenever a
On 29.11.2011 02:14, Jim Nasby wrote:
On Nov 28, 2011, at 9:29 AM, Tomas Vondra wrote:
I recall a patch similar to this one was submitted by Greg
Stark some
time ago. It used the info for different reasons--to try and
figure out whether reads were cached or not--but I believe it
withered
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
That sounds good for other interesting things, which entails being able
to have timing information attached to the XID sequence. If we go this
way, how far are we from having a ticker in PostgreSQL?
Those of us who are trying to get rid of
Sorry for taking so long to respong, had a pretty busy day at work. Anyway..
On Mon, Nov 28, 2011 at 9:54 AM, Greg Smith g...@2ndquadrant.com wrote:
Oh no, it's party pooper time again. Sorry I have to be the one to do it
this round. The real problem with this whole area is that we know there
Hi Greg,
On Monday, November 28, 2011 11:13:52 AM Greg Smith wrote:
With plenty of people in the US returning to work on Monday after a
modest break last week, I wanted to put out an updated on the active
CommitFest. I just sent out several pleas for help with specific patches
where only a
Alvaro Herrera alvhe...@commandprompt.com writes:
I wonder if it would be worthwhile to build some sort of tool to scan
the heap and ensure that there are index entries for all heap items,
just to test the hypothesis. Not that this would enlighten on the
source of the actual problem.
Seems
Hi Gurjeet,
On Monday, November 28, 2011 08:55:28 PM Gurjeet Singh wrote:
On Sat, Nov 26, 2011 at 6:51 PM, Andres Freund and...@anarazel.de wrote:
On Saturday, November 26, 2011 11:39:23 PM Robert Haas wrote:
On Sat, Nov 26, 2011 at 5:28 PM, Andres Freund and...@anarazel.de
wrote:
On 11/28/2011 05:38 PM, Andres Freund wrote:
Unless a major reviewer cries, I will - although not a major reviewer
- take a
stab thursday if thats fine with you.
I intended to use that term to suggest the review job itself could
become a major chunk of work, not to try and classify
On Tuesday, November 29, 2011 02:45:50 AM Greg Smith wrote:
On 11/28/2011 05:38 PM, Andres Freund wrote:
Unless a major reviewer cries, I will - although not a major reviewer
- take a
stab thursday if thats fine with you.
I intended to use that term to suggest the review job itself could
On 11/28/2011 05:51 AM, Robert Haas wrote:
On Mon, Nov 28, 2011 at 2:54 AM, Greg Smithg...@2ndquadrant.com wrote:
The real problem with this whole area is that we know there are
systems floating around where the amount of time taken to grab timestamps
like this is just terrible.
Assuming the
Greg Smith g...@2ndquadrant.com writes:
On 11/28/2011 05:51 AM, Robert Haas wrote:
Assuming the feature is off by default (and I can't imagine we'd
consider anything else), I don't see why that should be cause for
concern. If the instrumentation creates too much system load, then
don't use
On Sat, Nov 26, 2011 at 11:02 AM, Andrew Dunstan and...@dunslane.net wrote:
Also, should the malloc() of newval just use pg_malloc() instead?
Yes, also done.
This bit is unnecessary, since pg_malloc() takes care of the error handling:
+ if (!newval)
+
Bruce Momjian wrote:
I was wondering if it wouldn't make more sense to have pg_dumpall supply
its own version of exit_horribly to avoid separate pg_malloc and
pg_strdup ... but then those routines are so tiny that it hardly makes a
difference.
Another thing I wondered when seeing the
David Fetter wrote:
On Mon, Jun 13, 2011 at 03:39:39AM -0500, Jaime Casanova wrote:
On Mon, Jun 6, 2011 at 6:36 AM, Peter Eisentraut pete...@gmx.net wrote:
On tis, 2011-05-17 at 14:11 -0500, Jaime Casanova wrote:
On Tue, May 17, 2011 at 12:19 PM, Robert Haas robertmh...@gmail.com
Alexander Korotkov wrote:
Version of patch with few more comments and some fixes.
Where are we on the idea of better statistics for arrays?
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for
Peter Eisentraut wrote:
How much do we care about applying perltidy, as described in
src/tools/msvc/README, everywhere? I just ran it across the entire
tree, using
perltidy -b -bl -nsfs -naws -l=100 -ole=unix **/*.pl **/*.pm
and it generated 6531 lines of (unified) diff, of which 357 are
Andres Freund wrote:
I would like to see somebody running a benchmark on a machine with
higher concurrency...
Yeah, me too. I don't find it at all hard to believe that we will
see significant performance benefit by changing the PGPROC structure
so that all parts of it can be accessed
Version of patch with few more comments and some fixes.
Where are we on the idea of better statistics for arrays?
I need to finish reviewing the patch: I'll try to send in something
tomorrow night. So far it looks good.
Best,
Nathan
--
Sent via pgsql-hackers mailing list
I was wondering why we mark to_date() as stable and not immutable? It
seems to have been set to stable in 2006 with this patch:
http://archives.postgresql.org/pgsql-committers/2006-11/msg00264.php
Also, mark to_date() and to_char(interval) as stable; although these
Bruce Momjian br...@momjian.us writes:
I was wondering why we mark to_date() as stable and not immutable?
Do you really want to guarantee that it isn't, and never will be,
affected by timezone, datestyle, lc_time, etc? In particular it seems
likely that somebody will eventually complain that
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I was wondering why we mark to_date() as stable and not immutable?
Do you really want to guarantee that it isn't, and never will be,
affected by timezone, datestyle, lc_time, etc? In particular it seems
likely that somebody will
(2011/11/28 20:50), Shigeru Hanada wrote:
(2011/11/25 17:27), Etsuro Fujita wrote:
So, I think it might be better to estimate
such costs by pgsql_fdw itself without EXPLAINing on the assumption that
a remote postgres server has the same abilities for query
On ons, 2011-11-09 at 12:00 -0500, Robert Haas wrote:
On Tue, Nov 8, 2011 at 4:49 PM, Thom Brown t...@linux.com wrote:
I found the following error message misleading:
test=# create table cows2 (LIKE cows);
ERROR: inherited relation cows is not a table
STATEMENT: create table cows2
There was a question recently on a user list about how to configure an
editor to handle psql's editor temp files as SQL files. While this is
doable with an advanced editor by reverse-engineering the file pattern
than psql uses, it would be easier if psql just added an extension
.sql. Since both
2011/11/29 Peter Eisentraut pete...@gmx.net:
There was a question recently on a user list about how to configure an
editor to handle psql's editor temp files as SQL files. While this is
doable with an advanced editor by reverse-engineering the file pattern
than psql uses, it would be easier
On Tue, Nov 29, 2011 at 8:30 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Andres Freund wrote:
I would like to see somebody running a benchmark on a machine with
higher concurrency...
Yeah, me too. I don't find it at all hard to believe that we will
see significant performance
On mån, 2011-11-28 at 02:00 -0800, Greg Smith wrote:
On 11/13/2011 09:45 AM, Jan Urbański wrote:
The first one factors out some bolerplate related to executing SPI
functions in subtransactions (and idea borrowed from pltcl.c).
While I haven't looked at the code, this seems worthwhile from
On lör, 2011-11-26 at 11:21 -0500, Steve Singer wrote:
I've looked over the revised version of the patch and it now seems
fine.
Ready for committer.
I can take it from here.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On mån, 2011-11-28 at 11:41 +0100, Yeb Havinga wrote:
On 2011-11-15 21:50, Peter Eisentraut wrote:
Patch attached.
I cannot get the patch to apply, this is the output of patch -p1
--dry-run on HEAD.
patching file src/include/catalog/pg_type.h
Hunk #1 succeeded at 217 (offset 1 line).
On Sun, Nov 27, 2011 at 12:26 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavan Deolasee pavan.deola...@gmail.com writes:
On Sat, Nov 26, 2011 at 10:43 PM, Robert Haas robertmh...@gmail.com wrote:
Furthermore, it's
hard to understand how this could be a net improvement in the general
case, because
75 matches
Mail list logo
