On Tue, Jun 14, 2011 at 1:25 PM, Simon Riggs wrote:
>
> We can work out the various paths through the traffic cop to see when
> a plan will be a "one-shot" - planned and then executed immediately,
> then discarded.
>
> In those cases we can take advantage of better optimisations. Most
> interestin
2011/6/21 Brendan Jurd :
> On 21 June 2011 14:34, Pavel Stehule wrote:
>> I don't understand to using a macro
>>
>> #define token_is_keyword(t, k) (!t->quoted && strcmp(t->string, k) == 0)
>>
>> because you disallowed a quoting?
>
> Well, a token can only be treated as a special keyword if it is
On 2011-06-20 22:11, Noah Misch wrote:
On Sun, Jun 19, 2011 at 06:30:41PM +0200, Jesper Krogh wrote:
I hope this hasn't been forgotten. But I cant see it has been committed
or moved
into the commitfest process?
If you're asking about that main patch for $SUBJECT rather than those
isolationteste
On 21 June 2011 14:34, Pavel Stehule wrote:
> I don't understand to using a macro
>
> #define token_is_keyword(t, k) (!t->quoted && strcmp(t->string, k) == 0)
>
> because you disallowed a quoting?
Well, a token can only be treated as a special keyword if it is unquoted.
As an example, in the 'd
2011/6/21 Brendan Jurd :
> On 21 June 2011 13:51, Pavel Stehule wrote:
>> I have one question. I can't find any rules for work with tokens, etc,
>> where is quotes allowed and disallowed?
>>
>> I don't see any other issues.
>
> I'm not sure I understand your question, but quotes are allowed
> anyw
On 21 June 2011 13:51, Pavel Stehule wrote:
> I have one question. I can't find any rules for work with tokens, etc,
> where is quotes allowed and disallowed?
>
> I don't see any other issues.
I'm not sure I understand your question, but quotes are allowed
anywhere and they always act to remove a
On 06/20/2011 01:34 PM, Tom Lane wrote:
I was trying to illustrate how to have minimal turnaround time
when testing a small code change. Rebuilding from scratch is slow
enough that you lose focus while waiting. (Or I do, anyway.)
I just keep upgrading to the fastest CPU I can possibly jus
2011/6/20 Alvaro Herrera :
> Excerpts from Alvaro Herrera's message of lun jun 20 12:19:37 -0400 2011:
>> Excerpts from Pavel Stehule's message of lun jun 20 11:34:25 -0400 2011:
>>
>> > b) probably you can simplify a memory management using own two
>> > persistent memory context - and you can swap
While testing the fix for this one, I found another bug. Patches for
both are attached.
The first patch addresses this bug by re-adding SXACT_FLAG_ROLLED_BACK,
in a more limited form than its previous incarnation.
We need to be able to distinguish transactions that have already
called ReleasePred
On 21 June 2011 11:11, Alvaro Herrera wrote:
> I realize I took out most of the fun of this patch from you, but -- are
> you still planning to do some more exhaustive testing of it? I checked
> some funny scenarios (including include files and groups) but it's not
> all that unlikely that I misse
Excerpts from Brendan Jurd's message of lun jun 20 20:06:39 -0400 2011:
> On 21 June 2011 06:06, Alvaro Herrera wrote:
> > Excerpts from Alvaro Herrera's message of lun jun 20 12:19:37 -0400 2011:
> >> Excerpts from Pavel Stehule's message of lun jun 20 11:34:25 -0400 2011:
> >>
> >> > b) probably
On 21 June 2011 06:06, Alvaro Herrera wrote:
> Excerpts from Alvaro Herrera's message of lun jun 20 12:19:37 -0400 2011:
>> Excerpts from Pavel Stehule's message of lun jun 20 11:34:25 -0400 2011:
>>
>> > b) probably you can simplify a memory management using own two
>> > persistent memory context
On Mon, Jun 20, 2011 at 11:55 PM, Simon Riggs wrote:
> I agree we shouldn't do anything about the name lookups for 9.1
> That is SearchCatCache using RELNAMENSP lookups, to be precise, as
> well as triggers and few other similar call types.
Name lookups give ERRORs that look like this...
relati
On Mon, Jun 20, 2011 at 10:56 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Jun 19, 2011 at 5:13 PM, Simon Riggs wrote:
>>> We scan pg_class in two ways: to rebuild a relcache entry based on a
>>> relation's oid (easy fix). We also scan pg_class to resolve the name
>>> to oid mapping. The
Robert Haas writes:
> On Sun, Jun 19, 2011 at 5:13 PM, Simon Riggs wrote:
>> We scan pg_class in two ways: to rebuild a relcache entry based on a
>> relation's oid (easy fix). We also scan pg_class to resolve the name
>> to oid mapping. The name to oid mapping is performed *without* a lock
>> on
Folks,
I noticed that we have some nice new speed optimizations (more
properly, de-pessimizations) for partitioned tables in 9.1.
Anybody care to look over the table partitioning stuff on the wiki and
check it for relevance?
http://wiki.postgresql.org/wiki/Table_partitioning
I think I may be ab
On Mon, Jun 20, 2011 at 22:44, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Jun 20, 2011 at 22:20, Peter Eisentraut wrote:
>>> A better way might be that translators simply work on a clone of the
>>> source repository, which is then merged (as in, git merge) at release
>>> time. There a
Excerpts from Tom Lane's message of lun jun 20 16:44:20 -0400 2011:
> Magnus Hagander writes:
> > On Mon, Jun 20, 2011 at 22:20, Peter Eisentraut wrote:
> >> A better way might be that translators simply work on a clone of the
> >> source repository, which is then merged (as in, git merge) at rel
On 2011-06-20 19:22, Marti Raudsepp wrote:
AIUI that is defined to be a little vague, but includes denormalized numbers
that would undergo any rounding at all. It says that on overflow the
conversion should return the appropriate HUGE_VAL variant, and set ERANGE.
On underflow it returns a rea
On Mon, Jun 20, 2011 at 09:15:51PM +0200, Florian Pflug wrote:
> On Jun20, 2011, at 19:57 , Noah Misch wrote:
> > I tested this patch using two systems, a CentOS 5 box with
> > libxml2-2.6.26-2.1.2.8.el5_5.1 and an Ubuntu 8.04 box with libxml2
> > 2.6.31.dfsg-2ubuntu1.6. Both failed to build with
Magnus Hagander writes:
> On Mon, Jun 20, 2011 at 22:20, Peter Eisentraut wrote:
>> A better way might be that translators simply work on a clone of the
>> source repository, which is then merged (as in, git merge) at release
>> time. There are some issues with that to figure out, but it sounds
Fujii Masao writes:
> Anyway, you seem to have forgotten to fix the example of archive_command
> in "24.3.5.1. Standalone Hot Backups".
> archive_command = 'test ! -f /var/lib/pgsql/backup_in_progress ||
> cp -i %p /var/lib/pgsql/archive/%f < /dev/null'
You're right, I didn't see that one.
On Mon, Jun 20, 2011 at 22:20, Peter Eisentraut wrote:
> On mån, 2011-06-20 at 13:13 -0400, Alvaro Herrera wrote:
>> Excerpts from Michael Meskes's message of lun jun 20 09:54:36 -0400 2011:
>> > On Mon, Jun 20, 2011 at 09:15:52AM -0400, Robert Haas wrote:
>> > > Yep. Peter overrides them just be
On mån, 2011-06-20 at 13:13 -0400, Alvaro Herrera wrote:
> Excerpts from Michael Meskes's message of lun jun 20 09:54:36 -0400 2011:
> > On Mon, Jun 20, 2011 at 09:15:52AM -0400, Robert Haas wrote:
> > > Yep. Peter overrides them just before each release.
> >
> > Aren't there better ways to imple
On Sun, Jun 19, 2011 at 06:30:41PM +0200, Jesper Krogh wrote:
> I hope this hasn't been forgotten. But I cant see it has been committed
> or moved
> into the commitfest process?
If you're asking about that main patch for $SUBJECT rather than those
isolationtester changes specifically, I can't sp
Hi,
Apologies for any inconvenience and thank you to those who have already
completed the survey. We will keep the survey open for another couple of
weeks. But, we do hope you will consider responding to the email request
below (sent 2 weeks ago).
Thanks,
Dr. Jeffrey Carver
Assistant Professor
U
Florian Pflug wrote:
On Jun20, 2011, at 20:58 , Tom Lane wrote:
Darren Duncan writes:
I still think that the most elegant solution is for stuff like collation to just
be built-in to the base types that the range is ranging over, meaning we have a
separate text base type for each text collatio
Hello
I am sending a updated patch
>
> Coding Review
> -
>
>
> In tupdesc.c
>
> line 202 the existing code is performing a deep copy of ConstrCheck. Do you
> need to copy nkeys and conkey here as well?
>
> Then at line 250 ccname is freed but not conkey
>
fixed
>
> postgres_ext
On Jun20, 2011, at 20:58 , Tom Lane wrote:
> Darren Duncan writes:
>> I still think that the most elegant solution is for stuff like collation to
>> just
>> be built-in to the base types that the range is ranging over, meaning we
>> have a
>> separate text base type for each text collation, an
Hi
Thanks for the extensive review, it's very much appreciated!
On Jun20, 2011, at 19:57 , Noah Misch wrote:
> I tested this patch using two systems, a CentOS 5 box with
> libxml2-2.6.26-2.1.2.8.el5_5.1 and an Ubuntu 8.04 box with libxml2
> 2.6.31.dfsg-2ubuntu1.6. Both failed to build with this
Greg Smith wrote:
> The idea that any of this will run automatically is a dream at
> this point, so saying you want to automatically recover from
> problems with the mechanism that doesn't even exist yet is a bit
> premature.
Well, I certainly didn't mean it to be a reason not to move forward
Darren Duncan writes:
> I still think that the most elegant solution is for stuff like collation to
> just
> be built-in to the base types that the range is ranging over, meaning we have
> a
> separate text base type for each text collation, and the text operators are
> polymorphic over all t
Kevin Grittner wrote:
But its not hard to imagine an application mix where this
feature could cause a surprising ten-fold performance drop after
someone does a table scan which could persist indefinitely. I'm not
risking that in production without a clear mechanism to
automatically recover from
Itagaki Takahiro wrote:
Anyway, I'm not sure we need to include the query mode into the pgbench's
codes. Instead, how about providing "a sample script" as a separate sql
file? pgbench can execute any script files with -f option.
When you execute using "-f", it doesn't correctly detect databa
Tom Lane wrote:
Florian Pflug writes:
On Jun20, 2011, at 19:16 , Merlin Moncure wrote:
On Mon, Jun 20, 2011 at 11:21 AM, Jeff Davis wrote:
hm, what if there *was( only one range type per base type, but in the
various contexts where specific ordering and collation was important
you could optio
Hi Florian,
I tested this patch using two systems, a CentOS 5 box with
libxml2-2.6.26-2.1.2.8.el5_5.1 and an Ubuntu 8.04 box with libxml2
2.6.31.dfsg-2ubuntu1.6. Both failed to build with this error:
xml.c: In function `pg_xml_init':
xml.c:934: error: `xmlStructuredErrorContext' undeclared (firs
Florian Pflug writes:
> On Jun20, 2011, at 19:16 , Merlin Moncure wrote:
>> On Mon, Jun 20, 2011 at 11:21 AM, Jeff Davis wrote:
>> hm, what if there *was( only one range type per base type, but in the
>> various contexts where specific ordering and collation was important
>> you could optionally
Alvaro Herrera writes:
> Excerpts from Greg Smith's message of lun jun 20 00:25:08 -0400 2011:
>> The peg utility script I use makes a reinstall as simple as:
>>
>> stop
>> peg build
> But you're building the entire server there, which was Tom's point --
> you only need to build and reinstall th
On Jun20, 2011, at 19:16 , Merlin Moncure wrote:
> On Mon, Jun 20, 2011 at 11:21 AM, Jeff Davis wrote:
> hm, what if there *was( only one range type per base type, but in the
> various contexts where specific ordering and collation was important
> you could optionally pass them in? Meaning, the s
On Jun20, 2011, at 19:22 , Alvaro Herrera wrote:
> Excerpts from Florian Pflug's message of lun jun 20 06:55:42 -0400 2011:
>> The latter (i.e. regexp literals enclosed by /../) probably isn't
>> desirably for postgres, but the former definitely is (i.e. distinguishing
>> regexp's and text in the t
Excerpts from Greg Smith's message of lun jun 20 00:25:08 -0400 2011:
> Greg Stark wrote:
> > I've always wondered what other people do to iterate quickly.
>
> I'd have bet money you had an elisp program for this by now!
Yeah :-)
> The peg utility script I use makes a reinstall as simple as:
>
Joe Conway wrote:
-- Start of PGP signed section.
> On 06/17/2011 01:05 PM, Tom Lane wrote:
> > Peter Eisentraut writes:
> >> Is this a bug fix that should be backpatched?
> >
> > I pinged Joe Conway about this. He is jetlagged from a trip to the Far
> > East but promised to take care of it soon
Excerpts from Florian Pflug's message of lun jun 20 06:55:42 -0400 2011:
> The latter (i.e. regexp literals enclosed by /../) probably isn't
> desirably for postgres, but the former definitely is (i.e. distinguishing
> regexp's and text in the type system). Please see the thread
> "Adding a distin
Florian Pflug writes:
> On Jun20, 2011, at 18:16 , Tom Lane wrote:
>> This is already known to happen: there are cases where the postmaster
>> and a backend can come to different conclusions about whether a setting
>> is valid (eg, because it depends on database encoding). Whether that's
>> a bug
Robert Haas wrote:
> I'm currently on the other end of the spectrum: ignore and
> consider for 9.2.
I guess part of my point was that if we can't safely get something
into the initial 9.1 release, it doesn't mean we necessarily need to
wait for 9.2. Bugs can be fixed along the way in minor re
On Mon, Jun 20, 2011 at 11:21 AM, Jeff Davis wrote:
> On Mon, 2011-06-20 at 16:01 +0200, Florian Pflug wrote:
>> Hm, I'm starting to wonder if there isn't a way around that. It seems that
>> this restriction comes from the desire to allow functions with the
>> polymorphic signature
>> (ANYELEMEN
Excerpts from Michael Meskes's message of lun jun 20 09:54:36 -0400 2011:
> On Mon, Jun 20, 2011 at 09:15:52AM -0400, Robert Haas wrote:
> > Yep. Peter overrides them just before each release.
>
> Aren't there better ways to implement this, like git submodules? This
> redundancy seem awkward to m
On Mon, Jun 20, 2011 at 9:54 AM, Michael Meskes wrote:
> On Mon, Jun 20, 2011 at 09:15:52AM -0400, Robert Haas wrote:
>> Yep. Peter overrides them just before each release.
>
> Aren't there better ways to implement this, like git submodules? This
> redundancy seem awkward to me.
Dunno. I just w
On Mon, Jun 20, 2011 at 9:42 AM, Kevin Grittner
wrote:
> Simon Riggs wrote:
>
>> I'm looking for opinions ranging from fix-now-and-backpatch thru
>> to ignore and discuss for 9.2.
>
> If it's a pre-existing bug I would think that one option would be to
> put it into the next bug-fix release of ea
On Jun20, 2011, at 18:16 , Tom Lane wrote:
> Florian Pflug writes:
>> The code the actually implements the "check settings first, apply later"
>> logic
>> isn't easy to read. Now, assume that this code has a bug. Then, with your
>> patch applied, we might end up with the postmaster applying a set
On Jun20, 2011, at 18:28 , David E. Wheeler wrote:
> I don't suppose there's a special quoting to be had for patterns? Perhaps one
> of these (modulo SQL parsing issues);
>
>/pattern/
>{pattern}
>qr/pattern/
>qr'pattern'
>R/pattern/
>R'pattern'
Pretty daring suggestion, I
On Jun 19, 2011, at 4:56 PM, Florian Pflug wrote:
> Hm, it seems we either all have different idea about how such
> a pattern type would be be defined, or have grown so accustomed to
> pg's type system that we've forgotten how powerful it really
> is ;-) (For me, the latter is surely true...).
>
On Mon, 2011-06-20 at 16:01 +0200, Florian Pflug wrote:
> Hm, I'm starting to wonder if there isn't a way around that. It seems that
> this restriction comes from the desire to allow functions with the
> polymorphic signature
> (ANYELEMENT, ANYELEMENT) -> ANYRANGE.
>
> The only such function I c
Excerpts from Pavel Stehule's message of lun jun 20 11:34:25 -0400 2011:
> b) probably you can simplify a memory management using own two
> persistent memory context - and you can swap it. Then functions like
> free_hba_record, clean_hba_list, free_lines should be removed.
Yeah, I reworked the pa
Florian Pflug writes:
> The code the actually implements the "check settings first, apply later" logic
> isn't easy to read. Now, assume that this code has a bug. Then, with your
> patch applied, we might end up with the postmaster applying a setting (because
> it didn't abort early) but the backe
Greg Smith wrote:
> On 06/19/2011 06:15 PM, Kevin Grittner wrote:
>> I think the point is that if, on a fresh system, the first access
>> to a table is something which uses a tables scan -- like select
>> count(*) -- that all indexed access would then tend to be
>> suppressed for that table. Aft
Hi, I'm used to work with PostgreSQL on Windows but now I've moved to OS X
and I'm having problems to create a service to auto start a new server
(instance) of PostgreSQL.
Firstly I used the PostgreSQL installer to create the first server and the
postgres user, then I used initdb to create another
On Monday, June 20, 2011 17:11:14 Greg Stark wrote:
> On Mon, Jun 20, 2011 at 4:01 PM, Florian Pflug wrote:
> > Are you sure? Isn't mmap()ing /dev/null a way to *allocate* memory?
> >
> > Or at least this is what I always thought glibc does when you malloc()
>
> It mmaps /dev/zero actually.
As t
sorry
> a) you don't use macro "token_matches" consistently
should be
a) you don't use macro "token_is_keyword" consistently
it should be used for all keywords
Regards
Pavel Stehule
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
h
Hello Brendan,
I checked your patch, it is applied cleanly and I don't see any mayor
problem. This patch does all what is expected.
I have two minor comments
a) you don't use macro "token_matches" consistently
func: parse_hba_line
<-->if (strcmp(token->string, "local") == 0)
should be
Greg Stark writes:
> On Mon, Jun 20, 2011 at 3:17 PM, Tom Lane wrote:
>> Given the need to deal with multiple collations for collatable types,
>> I'd say it's not so much "unfortunate" as "utterly unworkable". At
>> least unless you give up the notion of binding the collation into the
>> type de
Florian Pflug Monday 20 of June 2011 17:07:55
> On Jun20, 2011, at 17:05 , Radosław Smogura wrote:
> > I'm sure at 99%. When I ware "playing" with mmap I preallocated,
> > probably, about 100GB of memory.
>
> You need to set vm.overcommit_memory to "2" to see the difference. Did
> you do that?
>
On Jun20, 2011, at 17:02 , Alexey Klyukin wrote:
> On Jun 18, 2011, at 5:40 PM, Florian Pflug wrote:
>> On Jun16, 2011, at 22:34 , Alexey Klyukin wrote:
>>> Attached is the v2 of the patch to show all parse errors at postgresql.conf.
>>> Changes (per review and suggestions from Florian):
>>>
>>> -
On Mon, Jun 20, 2011 at 04:16:58PM +0200, Florian Pflug wrote:
> On Jun20, 2011, at 15:27 , Radosław Smogura wrote:
> > 1. mmap some large amount of anonymous virtual memory (this will be maximum
> > size of shared memory).
> > ...
> > Point 1. will no eat memory, as memory allocation is delayed a
On Mon, Jun 20, 2011 at 4:01 PM, Florian Pflug wrote:
> Are you sure? Isn't mmap()ing /dev/null a way to *allocate* memory?
>
> Or at least this is what I always thought glibc does when you malloc()
It mmaps /dev/zero actually.
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
On Mon, Jun 20, 2011 at 3:17 PM, Tom Lane wrote:
> Given the need to deal with multiple collations for collatable types,
> I'd say it's not so much "unfortunate" as "utterly unworkable". At
> least unless you give up the notion of binding the collation into the
> type definition ... which has oth
On Monday, June 20, 2011 17:05:48 Radosław Smogura wrote:
> Florian Pflug Monday 20 of June 2011 17:01:40
>
> > On Jun20, 2011, at 16:39 , Radosław Smogura wrote:
> > > Florian Pflug Monday 20 of June 2011 16:16:58
> > >
> > >> On Jun20, 2011, at 15:27 , Radosław Smogura wrote:
> > >>> 1. mmap
On Jun20, 2011, at 17:05 , Radosław Smogura wrote:
> I'm sure at 99%. When I ware "playing" with mmap I preallocated, probably,
> about 100GB of memory.
You need to set vm.overcommit_memory to "2" to see the difference. Did
you do that?
You can do that either with "echo 2 > /proc/sys/vm/overcomm
Florian Pflug Monday 20 of June 2011 17:01:40
> On Jun20, 2011, at 16:39 , Radosław Smogura wrote:
> > Florian Pflug Monday 20 of June 2011 16:16:58
> >
> >> On Jun20, 2011, at 15:27 , Radosław Smogura wrote:
> >>> 1. mmap some large amount of anonymous virtual memory (this will be
> >>> maximum
Florian,
On Jun 18, 2011, at 5:40 PM, Florian Pflug wrote:
> On Jun16, 2011, at 22:34 , Alexey Klyukin wrote:
>> Attached is the v2 of the patch to show all parse errors at postgresql.conf.
>> Changes (per review and suggestions from Florian):
>>
>> - do not stop on the first error during postma
On Jun20, 2011, at 16:39 , Radosław Smogura wrote:
> Florian Pflug Monday 20 of June 2011 16:16:58
>> On Jun20, 2011, at 15:27 , Radosław Smogura wrote:
>>> 1. mmap some large amount of anonymous virtual memory (this will be
>>> maximum size of shared memory). ...
>>> Point 1. will no eat memory,
* Florian Pflug:
> I think this breaks with strict overcommit settings
> (i.e. vm.overcommit_memory = 2 on linux). To fix that, you'd need a
> way to tell the kernel (or glibc) to simply reserve a chunk of virtual
> address space for further user. Not sure if there's a API for that...
mmap with P
Dan Ports wrote:
> It looks the problem comes from the change a couple days ago that
> removed the SXACT_FLAG_ROLLED_BACK flag and changed the
> SxactIsRolledBack checks to SxactIsDoomed. That's the correct
> thing to do everywhere else, but gets us in trouble here. We
> shouldn't be ignoring do
2011/6/20 Robert Haas :
> On Mon, Jun 20, 2011 at 9:15 AM, Cédric Villemain
> wrote:
>> The feature does not work exactly as expected because the write limit
>> is rounded per 8kB because we write before checking. I believe if one
>> write a file of 1GB in one pass (instead of repetitive 8kB incre
Florian Pflug Monday 20 of June 2011 16:16:58
> On Jun20, 2011, at 15:27 , Radosław Smogura wrote:
> > 1. mmap some large amount of anonymous virtual memory (this will be
> > maximum size of shared memory). ...
> > Point 1. will no eat memory, as memory allocation is delayed and in 64bit
> > platf
Robert Haas writes:
> On Mon, Jun 20, 2011 at 2:33 AM, Jeff Davis wrote:
>> Yes, we cannot have two range types with the same base type. That is a
>> consequence of the polymorphic type system, which needs to be able to
>> determine the range type given the base type.
> Boy, that's an unfortunat
On Jun20, 2011, at 15:27 , Radosław Smogura wrote:
> 1. mmap some large amount of anonymous virtual memory (this will be maximum
> size of shared memory).
> ...
> Point 1. will no eat memory, as memory allocation is delayed and in 64bit
> platforms you may reserve quite huge chunk of this, and in
On Jun20, 2011, at 15:19 , Robert Haas wrote:
> On Mon, Jun 20, 2011 at 2:33 AM, Jeff Davis wrote:
>> On Sun, 2011-06-19 at 21:29 +0200, Florian Pflug wrote:
>>> If I'm not mistaken about this, that would imply that we also cannot
>>> have two range types with the same base type, the same opclass,
On Mon, Jun 20, 2011 at 09:15:52AM -0400, Robert Haas wrote:
> Yep. Peter overrides them just before each release.
Aren't there better ways to implement this, like git submodules? This
redundancy seem awkward to me.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot
On Sun, Jun 19, 2011 at 11:33:02PM -0700, Jeff Davis wrote:
> On Sun, 2011-06-19 at 21:29 +0200, Florian Pflug wrote:
> > If I'm not mistaken about this, that would imply that we also
> > cannot have two range types with the same base type, the same
> > opclass, but different collations. Which seem
Simon Riggs wrote:
> I'm looking for opinions ranging from fix-now-and-backpatch thru
> to ignore and discuss for 9.2.
If it's a pre-existing bug I would think that one option would be to
put it into the next bug-fix release of each supported major release
in which it is manifest. Of course,
Hello,
I had some idea with hugepagse, and I read why PostgreSQL doesn't
support POSIX (need of nattach). During read about POSIX/SysV I found
this (thread about dynamic chunking shared memory).
http://archives.postgresql.org/pgsql-hackers/2010-08/msg00586.php
When playing with mmap I done s
On Mon, Jun 20, 2011 at 2:14 PM, Robert Haas wrote:
> If this is a pre-existing bug, then it's not clear to me why we need
> to do anything about it at all right now. I mean, it would be nice to
> have a fix, but it's hard to imagine that any proposed fix will be
> low-risk, and I don't remember
On Mon, Jun 20, 2011 at 9:15 AM, Cédric Villemain
wrote:
> The feature does not work exactly as expected because the write limit
> is rounded per 8kB because we write before checking. I believe if one
> write a file of 1GB in one pass (instead of repetitive 8kB increment),
> and the temp_file_limi
On Mon, Jun 20, 2011 at 2:33 AM, Jeff Davis wrote:
> On Sun, 2011-06-19 at 21:29 +0200, Florian Pflug wrote:
>> If I'm not mistaken about this, that would imply that we also cannot
>> have two range types with the same base type, the same opclass,
>> but different collations. Which seems rather un
2011/6/17 Cédric Villemain :
> 2011/6/17 Mark Kirkwood :
>> On 17/06/11 13:08, Mark Kirkwood wrote:
>>>
>>> On 17/06/11 09:49, Cédric Villemain wrote:
I have issues applying it.
Please can you remove trailing space?
Also, you can generate a cool patch like this :
get g
2011/6/20 Michael Meskes :
> On Mon, Jun 20, 2011 at 03:03:37PM +0300, Devrim GÜNDÜZ wrote:
>> On Mon, 2011-06-20 at 11:58 +, Michael Meskes wrote:
>> >
>> > Fixed string in German translation that causes segfault.
>> >
>> > Applied patch by Christoph Berg to replace placeholder
>> > "%s" by c
On Sun, Jun 19, 2011 at 5:13 PM, Simon Riggs wrote:
> On Fri, Jun 17, 2011 at 11:41 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Thu, Jun 16, 2011 at 6:54 PM, Tom Lane wrote:
4. Backend #2 visits the new, about-to-be-committed version of
pgbench_accounts' pg_class row just before
On Mon, Jun 20, 2011 at 03:03:37PM +0300, Devrim GÜNDÜZ wrote:
> On Mon, 2011-06-20 at 11:58 +, Michael Meskes wrote:
> >
> > Fixed string in German translation that causes segfault.
> >
> > Applied patch by Christoph Berg to replace placeholder
> > "%s" by correct string.
>
> AFAIK this wo
Hello
I have not any newest patch related to GROUPING SETS. The last version
of this patch is probably correct, but it is not well tested.
Actually, this patch has not quality to production usage :(. It is
just concept. You can test it.
Regards
Pavel Stehule
2011/6/18 Mariano Mara :
> Hi hacker
Hi, thanks for chiming in.
On Sat, Jun 11, 2011 at 22:08, Jeroen Vermeulen wrote:
> AIUI that is defined to be a little vague, but includes denormalized numbers
> that would undergo any rounding at all. It says that on overflow the
> conversion should return the appropriate HUGE_VAL variant, and
On Mon, 2011-06-20 at 11:58 +, Michael Meskes wrote:
>
> Fixed string in German translation that causes segfault.
>
> Applied patch by Christoph Berg to replace placeholder
> "%s" by correct string.
AFAIK this won't have any effect. This change needs to go to through
pgtranslation project.
Hello
2011/6/20 Simon Riggs :
> On Mon, Jun 20, 2011 at 10:49 AM, Pavel Stehule
> wrote:
>
>> this patch significantly reduce a ccache searching. On my test - bubble sort
>
> It sounds good, but also somewhat worrying.
>
> The first cache is slow, so we add another cache to avoid searching
> the
On Jun20, 2011, at 03:16 , Greg Stark wrote:
> On Fri, Jun 17, 2011 at 3:49 PM, Florian Pflug wrote:
>>> The regex is always to the right of the operator.
>>
>> Which is something you have to remember... It's not in any
>> way deducible from "foo ~ bar" alone.
>
> Except that it's always been th
On Mon, Jun 20, 2011 at 10:49 AM, Pavel Stehule wrote:
> this patch significantly reduce a ccache searching. On my test - bubble sort
It sounds good, but also somewhat worrying.
The first cache is slow, so we add another cache to avoid searching
the first cache.
What is making the first cache
The behaviour of date_part function is opaque for infinity intervals.
For example
date_part('epoch', 'infinity'::date) and date_part('year',
'infinity'::date) return zero but is supposed to return 'infinity',
date_part('day', 'infinity'::date) returns zero, should it return 'NaN'
instead?
--
S
Hello
this patch significantly reduce a ccache searching. On my test - bubble sort
postgres=# \sf buble
CREATE OR REPLACE FUNCTION public.buble(integer[])
RETURNS integer[]
LANGUAGE plpgsql
AS $function$
declare
unsorted bool := true;
aux int;
begin
while unsorted
loop
unsorted := f
On Sun, Jun 19, 2011 at 09:10:02PM -0400, Robert Haas wrote:
> Is this an open item for 9.1beta3?
Yes. I've put it on the list.
The SxactGlobalXmin and its refcount were getting out of sync with the
actual transaction state. This is timing-dependent but I can reproduce it
fairly reliably under co
On Sun, Jun 19, 2011 at 10:13 PM, Simon Riggs wrote:
> pre-existing bug
I've been able to reproduce the bug on 9.0 stable as well, using the
OP's test script.
Multiple errors like this...
ERROR: relation "pgbench_accounts" does not exist
STATEMENT: alter table pgbench_accounts set (fillfactor
New version of patch. There are some bugfixes, minor refactoring, comments
(unfortunatelly, not all the code is covered by comments yet). Also
"fastbuild" parameter was added to the GiST index. It allows to test index
building with and without fast build without postgres recompile.
--
With bes
1 - 100 of 101 matches
Mail list logo
