On Sun, Nov 27, 2011 at 12:26 AM, Tom Lane wrote:
> Pavan Deolasee writes:
>> On Sat, Nov 26, 2011 at 10:43 PM, Robert Haas wrote:
>>> Furthermore, it's
>>> hard to understand how this could be a net improvement in the general
>>> case, because now both B and F are copying everything twice (once
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
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:
htt
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 worthwhil
On Tue, Nov 29, 2011 at 8:30 AM, Kevin Grittner
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 benefit by changing t
2011/11/29 Peter Eisentraut :
> 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
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
On ons, 2011-11-09 at 12:00 -0500, Robert Haas wrote:
> On Tue, Nov 8, 2011 at 4:49 PM, Thom Brown 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 (LIKE
(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
Tom Lane wrote:
> Bruce Momjian 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 comp
Bruce Momjian 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 since to_char can
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
appear
>> 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 (pgsql-hackers@p
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 thro
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 3
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 http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be
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 wrote:
> > > On tis, 2011-05-17 at 14:11 -0500, Jaime Casanova wrote:
> > >> On Tue, May 17, 2011 at 12:19 PM, Robert Haas
> > >> wrote:
> > >> >
> > >> > Th
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
On Sat, Nov 26, 2011 at 11:02 AM, Andrew Dunstan 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)
+ {
+
Greg Smith 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 it: simple as
On 11/28/2011 05:51 AM, Robert Haas wrote:
On Mon, Nov 28, 2011 at 2:54 AM, Greg Smith 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 def
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 itse
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 reviewers.
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 wrote:
> > On Saturday, November 26, 2011 11:39:23 PM Robert Haas wrote:
> > > On Sat, Nov 26, 2011 at 5:28 PM, Andres Freund
> >
> > wrote:
> > > > On Saturday, November 2
Alvaro Herrera 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 like the hypothesis coul
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
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 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 are
> systems floa
Dimitri Fontaine 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 idle-state process wakeup
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 i
On 28.11.2011 22:32, Dimitri Fontaine wrote:
> "Tomas Vondra" 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
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 main
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
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.
The
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 w
Tom Lane wrote:
> Andres Freund writes:
> > On Friday, November 18, 2011 10:14:22 PM Tom Lane wrote:
> >> Andres Freund 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 impos
Excerpts from Tom Lane's message of mar nov 22 01:14:33 -0300 2011:
> Alvaro Herrera 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 grows very large a
On 11/27/2011 06:17 PM, Tom Lane wrote:
Peter Eisentraut 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 to
omit the test
"Tomas Vondra" 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 what Greg s
Hi Robert
2011/11/28 Robert Haas 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. A quick search
retr
Kohei KaiGai 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 case that would
On Tue, Nov 15, 2011 at 2:23 PM, Peter Eisentraut 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 practice som
On Sat, Nov 26, 2011 at 6:51 PM, Andres Freund wrote:
> On Saturday, November 26, 2011 11:39:23 PM Robert Haas wrote:
> > On Sat, Nov 26, 2011 at 5:28 PM, Andres Freund
> wrote:
> > > On Saturday, November 26, 2011 09:52:17 PM Tom Lane wrote:
> > >> I'd just as soon keep the fields in a logical
Andres Freund writes:
> On Friday, November 18, 2011 10:14:22 PM Tom Lane wrote:
>> Andres Freund 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 impossible to validate by eye. Cou
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. Sorr
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
>
>
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
On Mon, Nov 28, 2011 at 8:55 AM, Robert Haas wrote:
> On Mon, Nov 28, 2011 at 8:49 AM, Gurjeet Singh
> wrote:
> > Naysayers can always make a case
>
Should've added that I'm not one of them :)
+1 from me on the improvement.
> for backwards-compatibility, or not
> > breaking the scripts writt
2011/11/28 Dimitri Fontaine :
> Kohei KaiGai 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 f
Robert Haas writes:
> On Mon, Nov 28, 2011 at 2:54 AM, Greg Smith 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
On 28 Listopad 2011, 15:40, Greg Stark wrote:
> On Nov 28, 2011 8:55 AM, "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.
>>
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 enab
On Nov 28, 2011 8:55 AM, "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 have
Kohei KaiGai 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 there. But it see
2011/11/27 Dimitri Fontaine :
>> 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 have to have a
2011/11/28 Shigeru Hanada :
> 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 this issue. It ca
On Mon, Nov 28, 2011 at 8:49 AM, Gurjeet Singh 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 you have in mind?
>
On Mon, Nov 28, 2011 at 2:54 AM, Greg Smith 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 imagine we'd
consider
On Mon, Nov 28, 2011 at 8:10 AM, Robert Haas wrote:
> On Sat, Nov 26, 2011 at 3:36 PM, 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: synt
On Sat, Nov 26, 2011 at 7:20 AM, Florian Schwendener 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
>
> It see
On Sat, Nov 26, 2011 at 3:36 PM, 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.
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 it
On Thu, Nov 17, 2011 at 10:11, Albe Laurenz 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
> per connectio
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_co
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 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 disall
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.
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 a
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 in
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/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. pl
On 11/13/2011 12:13 AM, Simon Riggs wrote:
On Tue, Nov 1, 2011 at 12:11 PM, Simon Riggs 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 that time, but that no
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 sl
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 EXPLAI
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 use
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:
http://
75 matches
Mail list logo
