On 12/11/2011 05:29 PM, Torello Querci wrote:
I will try to adjust the patch and submit for the next Commit Fest if
this is ok for you.
I don't think we'll need this, it will take a bit to explain why though.
First, thanks for returning this topic to discussion and keeping up with
all the
On Tue, Dec 13, 2011 at 5:22 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 12/12/2011 03:54 PM, Robert Haas wrote:
>>> There are way too many places that assume that the typmod can
>>> just be discarded. I don't think that's going to fly, because
>>> =(text,text) probably has different sema
- Original message -
> On Dec 12, 2011, at 4:51 PM, Peter van Hardenberg wrote:
>
> > Because we haven't heard from him in a while we've been using PL/V8 to
> > validate a JSON datatype simulated by a DOMAIN with a simple
> > acceptance function. (See below.) This is not ideally performant
Shigeru Hanada writes:
> (2011/12/12 22:59), Robert Haas wrote:
>> ... I feel like we might need a system here that
>> allows for more explicit user control about what to push down vs. not,
>> rather than assuming we'll be able to figure it out behind the scenes.
> Agreed. How about to add a per
On Mon, Dec 12, 2011 at 7:37 PM, Daniel Farina wrote:
> On Mon, Dec 12, 2011 at 4:51 PM, Peter van Hardenberg wrote:>
>> PL/V8 is fast, it's sandboxed, and while it doesn't provide GIN or
>> GIST operators out of the box, maybe those could be motivated by its
>> inclusion.
>
> I also feel that a
On mån, 2011-12-12 at 16:51 -0800, Peter van Hardenberg wrote:
> Because we haven't heard from him in a while we've been using PL/V8 to
> validate a JSON datatype simulated by a DOMAIN with a simple
> acceptance function. (See below.) This is not ideally performant but
> thanks to V8's JIT the JSON
Andrew Dunstan writes:
> On 12/12/2011 03:54 PM, Robert Haas wrote:
>> There are way too many places that assume that the typmod can
>> just be discarded. I don't think that's going to fly, because
>> =(text,text) probably has different semantics from =(json,json).
> And certain places where the
On 12 December 2011 15:59, Pavel Stehule wrote:
> 2011/12/12 Brendan Jurd :
>> I just bumped into a situation where I wanted to do a little macaddr
>> arithmetic in postgres. I note that the inet type has support for
>> bitwise AND, OR and NOT, as well as subtraction, but macaddr has none
>> of t
Excerpts from Daniel Farina's message of lun dic 12 22:37:13 -0300 2011:
> * It'd be nice to pass intermediate in-memory representations rather
> than calling JSON.parse all the time, similar to OPAQUE except sound
> (so bogus pointers cannot be passed). Basically, an "ephemeral type".
> It cou
On Mon, Dec 12, 2011 at 10:54 AM, Julien Tachoires wrote:
> Hi,
>
> 2011/12/10 Jaime Casanova :
>> On Mon, Nov 28, 2011 at 1:32 PM, Julien Tachoires wrote:
>>
2) after CLUSTER the index of the toast table gets moved to the same
tablespace as the main table
>>>
>>
>> there is still a var
On 12/12/2011 08:46 PM, Daniel Farina wrote:
On Mon, Dec 12, 2011 at 5:36 PM, Andrew Dunstan wrote:
The trouble with using JSON.parse() as a validator is that it's probably
doing way too much work. PLV8 is cool, and I keep trying to get enough time
to work on it more, but I don't think it's a
(2011/12/12 22:59), Robert Haas wrote:
> It does seem like this might not be enough information for the FDW to
> make good decisions about pushdown. Even supposing the server on the
> other hand is also PostgreSQL, the collation names might not match
> (if, say, one is running Windows, and the oth
On Mon, Dec 12, 2011 at 5:36 PM, Andrew Dunstan wrote:
> The trouble with using JSON.parse() as a validator is that it's probably
> doing way too much work. PLV8 is cool, and I keep trying to get enough time
> to work on it more, but I don't think it's a substitute for a JSON type with
> a purpose
On Mon, Dec 12, 2011 at 4:51 PM, Peter van Hardenberg wrote:>
> PL/V8 is fast, it's sandboxed, and while it doesn't provide GIN or
> GIST operators out of the box, maybe those could be motivated by its
> inclusion.
I also feel that a big problem with JSON as a data type is that there
is not a pow
On 12/12/2011 07:51 PM, Peter van Hardenberg wrote:
We reached out to Joseph to see if we could help sponsor the project,
but never really heard back from him.
Because we haven't heard from him in a while we've been using PL/V8 to
validate a JSON datatype simulated by a DOMAIN with a simple
ac
On Dec 12, 2011, at 4:51 PM, Peter van Hardenberg wrote:
> Because we haven't heard from him in a while we've been using PL/V8 to
> validate a JSON datatype simulated by a DOMAIN with a simple
> acceptance function. (See below.) This is not ideally performant but
> thanks to V8's JIT the JSON pars
On Dec 12, 2011, at 3:55 PM, Peter van Hardenberg wrote:
> I'd like to make the controversial proposal that the URL prefix should
> be "postgres:" instead of "postgresql:". Postgres is a widely accepted
> nickname for the project, and is eminently more pronounceable. Once
> the url is established
We reached out to Joseph to see if we could help sponsor the project,
but never really heard back from him.
Because we haven't heard from him in a while we've been using PL/V8 to
validate a JSON datatype simulated by a DOMAIN with a simple
acceptance function. (See below.) This is not ideally perf
I wrote:
> Simon Riggs writes:
>> I'll volunteer. Assume you can reuse the flag and I will patch afterwards.
> Thanks for the offer, but after thinking about it a bit more I realized
> that this change is quite trivial, so I just went ahead and did it along
> with the change in XLR_MAX_BKP_BLOCKS
On Mon, Dec 12, 2011 at 2:06 PM, Alexander Shulgin
wrote:
>
>
> psql -d postgresql://user@pw:host:port/dbname?param1=value1¶m2=value2...
>
I'd like to make the controversial proposal that the URL prefix should
be "postgres:" instead of "postgresql:". Postgres is a widely accepted
nickname for th
On 12/12/2011 08:45 AM, Robert Haas wrote:
But I'm skeptical that anything that we only update once per
checkpoint cycle will help much in
calculating an accurate lag value.
I'm sure there is no upper bound on how much WAL lag you can build up
between commit/abort records either; they can be
Hello Hackers,
Attached is a work-in-progress patch for URI connection string syntax support
in libpq. The recent discussion (also pointing to the original one) is here:
http://archives.postgresql.org/message-id/132180-sup-1235@moon
The patch adds support for the following syntax in psq
On 12/12/2011 02:24 PM, Greg Smith wrote:
On 11/16/2011 10:19 AM, Robert Haas wrote:
I haven't read the code yet, but just to get the bikeshedding started,
I think it might be better to call this include_if_exists rather than
running it together as one word.
What's going on, it's like this b
On 12/08/2011 09:18 PM, Joachim Wieland wrote:
On Tue, Nov 15, 2011 at 6:14 PM, Andrew Dunstan wrote:
Updated version with pg_restore included is attached.
The patch applies with some fuzz by now but compiles without errors or warnings.
The feature just works, it is not adding a lot of new
Bruce,
I thought that Joseph Adams was still working on this, sponsored by
Heroku. Joseph?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpre
On 12/12/2011 03:54 PM, Robert Haas wrote:
On Mon, Dec 12, 2011 at 3:38 PM, Simon Riggs wrote:
Rather than fuss with specific data formats, why not implement
something a little more useful?
At present we can have typmods passed as a cstring, so it should be
possible to add typmods onto the T
Simon Riggs writes:
> On Mon, Dec 12, 2011 at 3:42 PM, Tom Lane wrote:
>> It occurs to me also that we could just move the flag from
>> per-WAL-record info bytes to per-page or even per-segment WAL headers.
>> Because we now force a segment switch when starting a backup, the
>> flag would be seen
On Dec 12, 2011, at 12:54 PM, Robert Haas wrote:
> I don't think that's going to fly, because
> =(text,text) probably has different semantics from =(json,json).
No question:
david=# select '{"foo": 1, "bar": 2}'::json = '{"bar": 2, "foo": 1}'::json;
?column?
--
t
(
On mån, 2011-12-12 at 21:08 +, Simon Riggs wrote:
> On Mon, Dec 12, 2011 at 8:54 PM, Robert Haas wrote:
>
> > There are way too many places that assume that the typmod can
> > just be discarded.
>
> If true, that probably ought to be documented cos it sounds fairly important.
>
> Where and
On Mon, Dec 12, 2011 at 4:08 PM, Simon Riggs wrote:
> On Mon, Dec 12, 2011 at 8:54 PM, Robert Haas wrote:
>> There are way too many places that assume that the typmod can
>> just be discarded.
>
> If true, that probably ought to be documented cos it sounds fairly important.
>
> Where and when is
On Mon, Dec 12, 2011 at 8:54 PM, Robert Haas wrote:
> There are way too many places that assume that the typmod can
> just be discarded.
If true, that probably ought to be documented cos it sounds fairly important.
Where and when is it true?
--
Simon Riggs http://www.2ndQua
Marti Raudsepp writes:
> The 'struct Expr' type could have another attribute that stores
> whether its sub-expressions contain stable/volatile functions, and
> whether it only contains of constant arguments. This attribute would
> be filled in for every Expr by eval_const_expressions.
Hmm. I'm a
On Mon, Dec 12, 2011 at 02:24:53PM -0500, Greg Smith wrote:
> On 11/16/2011 10:19 AM, Robert Haas wrote:
> >I haven't read the code yet, but just to get the bikeshedding started,
> >I think it might be better to call this include_if_exists rather than
> >running it together as one word.
>
> What's
Excerpts from Alvaro Herrera's message of lun dic 12 17:20:39 -0300 2011:
> I found that this is caused by mxid_to_string being leaked all over the
> place :-( I "fixed" it by making the returned string be a static that's
> malloced and then freed on the next call. There's still virtsize growth
On Mon, Dec 12, 2011 at 3:38 PM, Simon Riggs wrote:
> Rather than fuss with specific data formats, why not implement
> something a little more useful?
>
> At present we can have typmods passed as a cstring, so it should be
> possible to add typmods onto the TEXT data type.
>
> e.g. TEXT('JSON'), T
On Sun, Dec 4, 2011 at 22:53, Heikki Linnakangas
wrote:
> I wonder if it would be better to add the CacheExpr nodes to the tree as a
> separate pass, instead of shoehorning it into eval_const_expressions? I
> think would be more readable that way, even though a separate pass would be
> more expens
On Mon, Dec 12, 2011 at 7:58 PM, Robert Haas wrote:
> On Mon, Dec 5, 2011 at 3:12 PM, Bruce Momjian wrote:
>> Where are we with adding JSON for Postgres 9.2? We got bogged down in
>> the data representation last time we discussed this.
>
> We're waiting for you to send a patch that resolves all
Robert Haas writes:
> It seems to me (and it may seem differently to other people) that what
> most people who want to trap DDL events really want to do is either
[ detailed analysis, mostly right on spot ]
Yeah, I'm proposing a rather crude tool. I think it's still solving
real problems we h
Noah,
Many thanks for this review. I'm going through items on it; definitely
there are serious issues here, as well as minor things that also need
fixing. Thanks for all the detail.
I'll post an updated patch shortly (probably not today though); in the
meantime, this bit:
Excerpts from Noah M
On 12/12/2011 02:59 PM, Tom Lane wrote:
Peter Eisentraut writes:
On lör, 2011-12-10 at 20:26 -0500, Tom Lane wrote:
Right now, libpq laboriously rebuilds all the .o files it needs from
src/port/ so as to get them with -fpic. It would be nice if we could
clean that up while we're doing this
On mån, 2011-12-12 at 14:47 +0100, Magnus Hagander wrote:
> We're either pretty inconsistent with our output in psql, or I'm not
> completely understanding it.. I was trying to implement a switch that
> would let me put all the output in the query output channel controlled
> by \o, and not just the
Peter Eisentraut writes:
> On lör, 2011-12-10 at 20:26 -0500, Tom Lane wrote:
>> Right now, libpq laboriously rebuilds all the .o files it needs from
>> src/port/ so as to get them with -fpic. It would be nice if we could
>> clean that up while we're doing this. It might be all right to always
On Mon, Dec 5, 2011 at 3:12 PM, Bruce Momjian wrote:
> Where are we with adding JSON for Postgres 9.2? We got bogged down in
> the data representation last time we discussed this.
We're waiting for you to send a patch that resolves all
previously-raised issues. :-)
In all seriousness, I think
On fre, 2011-12-09 at 11:13 -0500, Andrew Dunstan wrote:
> Is there any good reason why we shouldn't build and install a dynamic
> libpgport.so?
Just note, if you do this, you need to carefully manage API, ABI,
soname, symbol list, and all that. Every time you tweak configure's
decision about wh
Yeb Havinga wrote:
> Forgot to copy regression output to expected - attached v7 fixes
> that.
This version addresses all of my concerns. It applies cleanly and
compiles without warning against current HEAD and performs as
advertised. I'm marking it Ready for Committer.
-Kevin
--
Sent via
On lör, 2011-12-10 at 20:26 -0500, Tom Lane wrote:
> > The other
> > thing is we'd need to turn on flags that make the object suitable for a
> > dynamic library (e.g. -fpic).
>
> Right now, libpq laboriously rebuilds all the .o files it needs from
> src/port/ so as to get them with -fpic. It wo
On Mon, Dec 12, 2011 at 5:51 PM, Tom Lane wrote:
> Jesper Krogh writes:
>>> So: is there actually any such compression program out there?
>
>> Perhaps http://pglesslog.projects.postgresql.org/
>
> Hah ... the search facilities on pgfoundry really do leave something to
> be desired :-(
>
> So I gu
On 12/08/2011 11:36 AM, Andrew Dunstan wrote:
On 12/08/2011 11:13 AM, Robert Haas wrote:
Ah, hmm. Well, maybe it's fine the way that you have it. But I'd be
tempted to at least add a sentence to the sgml documentation for each
option referring to the other, e.g. "To dump only schema for al
On 11/16/2011 10:19 AM, Robert Haas wrote:
I haven't read the code yet, but just to get the bikeshedding started,
I think it might be better to call this include_if_exists rather than
running it together as one word.
What's going on, it's like this bikeshed just disappeared. I should
figu
On Mon, Dec 12, 2011 at 11:49 AM, Andres Freund wrote:
>> I haven't yet thought about your specific proposal here in enough to
>> have a fully-formed opinion, but I am a little nervous that this may
>> turn out to be one of those cases where the obvious API ends up
>> working less well than might
On Wed, Dec 7, 2011 at 17:45, Scott Mead wrote:
>
> On Tue, Dec 6, 2011 at 6:38 AM, Magnus Hagander wrote:
>>
>> On Sat, Nov 19, 2011 at 02:55, Scott Mead wrote:
>> >
>> > On Thu, Nov 17, 2011 at 11:58 AM, Scott Mead wrote:
>> >>
>> >> On Wed, Nov 16, 2011 at 4:09 PM, Scott Mead wrote:
>> >>>
On Fri, 2011-12-02 at 15:48 +0400, Alexander Korotkov wrote:
> Rebased with head.
>
Thank you. I have attached a patch that's mostly just cleanup to this
one.
Comments:
* You use the term "ordinal range" quite a lot, which I haven't heard
before. Is that a mathematical term, or do you mean somet
On 12/12/2011 01:34 PM, Greg Smith wrote:
You can see a snapshot of the new doc page I built at
http://http://www.westnet.com/~gsmith/config-setting.html
One minute past send note on brain fade: this section
include '00shared.conf'
include '01memory.conf'
include '02server.conf'
Was a pasto
Attached is an update to my earlier patch. This clears my own bug,
usability concerns, and implementation ideas list on this one.
There's full documentation on this now, including some suggested ways
all these include features might be used. Since there's so much
controversy around the way I
On 12/10/2011 08:26 PM, Tom Lane wrote:
The other
thing is we'd need to turn on flags that make the object suitable for a
dynamic library (e.g. -fpic).
Right now, libpq laboriously rebuilds all the .o files it needs from
src/port/ so as to get them with -fpic. It would be nice if we could
c
Jesper Krogh writes:
>> So: is there actually any such compression program out there?
> Perhaps http://pglesslog.projects.postgresql.org/
Hah ... the search facilities on pgfoundry really do leave something to
be desired :-(
So I guess we should try to preserve the functionality. I think the
m
Alvaro Herrera writes:
> Yeah. I remember mentioning the ability of CREATE SCHEMA to embed all
> sort of object creation commands in a single top-level command, and
> being handwaved away by Jan. "Nobody knows about that", I was told.
In fact CREATE SCHEMA implementation will fire a process uti
The attached patches are cut-off version based on the latest Robert's
updates. The "v8.regtest" adds regression test cases on variable
leaky-view scenarios with/without security-barrier property.
The "v8.option-1" add checks around restriction_selectivity, and prevent
to invoke estimator function
On Monday, December 12, 2011 05:32:45 PM Robert Haas wrote:
> On Sun, Dec 11, 2011 at 1:55 PM, Dimitri Fontaine
>
> wrote:
> > Andres Freund writes:
> >> Hm. I just noticed a relatively big hole in the patch: The handling of
> >> deletion of dependent objects currently is nonexistant because the
On Sat, Dec 10, 2011 at 4:16 PM, Jaime Casanova wrote:
>>> now, if we are now supporting this variants
>>> ALTER TABLE SET TABLE TABLESPACE
>>> ALTER TABLE SET TOAST TABLESPACE
>>>
>>> why not also support ALTER TABLE SET INDEX TABLESPACE which should
>>> have the same behaviour as ALTER INDEX SET
Excerpts from Robert Haas's message of lun dic 12 13:32:45 -0300 2011:
> On Sun, Dec 11, 2011 at 1:55 PM, Dimitri Fontaine
> wrote:
> > Andres Freund writes:
> >> Hm. I just noticed a relatively big hole in the patch: The handling of
> >> deletion of dependent objects currently is nonexistant be
On Sun, Dec 11, 2011 at 1:55 PM, Dimitri Fontaine
wrote:
> Andres Freund writes:
>> Hm. I just noticed a relatively big hole in the patch: The handling of
>> deletion of dependent objects currently is nonexistant because they don't go
>> through ProcessUtility...
>
> That's the reason why we're t
>
>
> So: is there actually any such compression program out there?
> Would anybody really cry if this flag went away?
Perhaps http://pglesslog.projects.postgresql.org/
Jesper
On Mon, Dec 12, 2011 at 3:42 PM, Tom Lane wrote:
> Simon Riggs writes:
>> On Mon, Dec 12, 2011 at 3:17 PM, Tom Lane wrote:
>>> Furthermore, what the XLR_BKP_REMOVABLE bit actually reports is just
>>> whether a backup operation is in progress, and I think we have now (or
>>> easily could) add rep
hello
2011/12/12 Albe Laurenz :
> Pavel Stehule wrote:
>> there is merged patch
>
> Works fine, except that there are still missing const qualifiers
> in copyfuncs.c and equalfuncs.c that lead to compiler warnings.
>
> One thing I forgot to mention:
> I thought there was a consensus to add a WITH(
Hi,
2011/12/10 Jaime Casanova :
> On Mon, Nov 28, 2011 at 1:32 PM, Julien Tachoires wrote:
>
>>> 2) after CLUSTER the index of the toast table gets moved to the same
>>> tablespace as the main table
>>
>
> there is still a variant of this one, i created 3 tablespaces (datos_tblspc):
>
> """
> cre
Pavel Stehule wrote:
> there is merged patch
Works fine, except that there are still missing const qualifiers
in copyfuncs.c and equalfuncs.c that lead to compiler warnings.
One thing I forgot to mention:
I thought there was a consensus to add a WITH() or OPTIONS() clause
to pass options to the c
Simon Riggs writes:
> On Mon, Dec 12, 2011 at 3:17 PM, Tom Lane wrote:
>> Furthermore, what the XLR_BKP_REMOVABLE bit actually reports is just
>> whether a backup operation is in progress, and I think we have now (or
>> easily could) add reporting records to the WAL stream that tell when a
>> bac
On Mon, Dec 12, 2011 at 3:17 PM, Tom Lane wrote:
> Furthermore, what the XLR_BKP_REMOVABLE bit actually reports is just
> whether a backup operation is in progress, and I think we have now (or
> easily could) add reporting records to the WAL stream that tell when a
> backup starts or stops. So e
Am Montag, 12. Dezember 2011, 10:19:46 schrieb Andrew Dunstan:
>
> On 12/12/2011 09:54 AM, Lars Kanis wrote:
> > Am Freitag, 9. Dezember 2011, 15:31:17 schrieb Andrew Dunstan:
> >> Yeah, fair enough. I'll work on that.
> > Many thanks for reviewing, tweaking and commiting the patch!
> > One thing
On 12/12/2011 09:54 AM, Lars Kanis wrote:
Am Freitag, 9. Dezember 2011, 15:31:17 schrieb Andrew Dunstan:
Yeah, fair enough. I'll work on that.
Many thanks for reviewing, tweaking and commiting the patch!
One thing I wonder about, is this snippet. Is the define really needed now?
* The Ming
Back in 2007 (commit a8d539f12498de52453c8113892cbf48cc62478d), we
reduced the maximum number of backup blocks per WAL record from 4 to 3,
in order to permit addition of an XLR_BKP_REMOVABLE flag bit that
purports to show whether it's safe to suppress full-page-image backup
blocks in an external WA
On 12/12/2011 06:43 AM, Mark Cave-Ayland wrote:
configuration, it seems to me that it would be fine to commit a patch
that made everything work, but for the compiler bug. We could refrain
from stating that we officially support that configuration until the
compiler bug is fixed, or even documen
Am Freitag, 9. Dezember 2011, 15:31:17 schrieb Andrew Dunstan:
> Yeah, fair enough. I'll work on that.
Many thanks for reviewing, tweaking and commiting the patch!
One thing I wonder about, is this snippet. Is the define really needed now?
* The Mingw64 headers choke if this is already defined -
On Mon, Dec 12, 2011 at 9:51 AM, Simon Riggs wrote:
> On Mon, Dec 12, 2011 at 2:47 PM, Robert Haas wrote:
>> On Mon, Dec 12, 2011 at 9:24 AM, Simon Riggs wrote:
>>> On Mon, Dec 12, 2011 at 1:45 PM, Robert Haas wrote:
It also strikes me that anything
that is based on augmenting the wal
On Mon, Dec 12, 2011 at 2:47 PM, Robert Haas wrote:
> On Mon, Dec 12, 2011 at 9:24 AM, Simon Riggs wrote:
>> On Mon, Dec 12, 2011 at 1:45 PM, Robert Haas wrote:
>>> It also strikes me that anything
>>> that is based on augmenting the walsender/walreceiver protocol leaves
>>> anyone who is using
On Mon, Dec 12, 2011 at 9:24 AM, Simon Riggs wrote:
> On Mon, Dec 12, 2011 at 1:45 PM, Robert Haas wrote:
>> It also strikes me that anything
>> that is based on augmenting the walsender/walreceiver protocol leaves
>> anyone who is using WAL shipping out in the cold. I'm not clear from
>> the co
On Mon, Dec 12, 2011 at 1:45 PM, Robert Haas wrote:
> It also strikes me that anything
> that is based on augmenting the walsender/walreceiver protocol leaves
> anyone who is using WAL shipping out in the cold. I'm not clear from
> the comments you or Simon have made how important you think that
On Wed, Dec 7, 2011 at 2:34 AM, Shigeru Hanada wrote:
> Sorry for delayed response.
>
> 2011/11/29 Albe Laurenz :
>> I think that this is not always safe even from PostgreSQL to PostgreSQL.
>> If two databases have different collation, "<" on strings will behave
>> differently.
>
> Indeed. I thin
We're either pretty inconsistent with our output in psql, or I'm not
completely understanding it.. I was trying to implement a switch that
would let me put all the output in the query output channel controlled
by \o, and not just the output of the query itself. Because that would
make it possible t
On Sat, Dec 10, 2011 at 7:29 AM, Greg Smith wrote:
> -It adds overhead at every commit, even for people who aren't using it.
> Probably not enough to matter, but it's yet another thing going through the
> often maligned as too heavy pgstat system, often.
The bit about the pgstat system being too
Hi,
I am reading code about cursor and fetch ...
Here is a test:
create table t (a int);
insert into t values (1),(3),(5),(7),(9);
insert into t select a+1 from t;
begin;
declare c cursor for select * from t order by a;
fetch 3 in c;
fetch 3 in c;
fetch 3 in c;
In func "PortalRun", FillPortalSto
On 2011-12-11 16:26, Yeb Havinga wrote:
On 2011-12-06 17:58, Kevin Grittner wrote:
Kevin Grittner wrote:
Yeb Havinga wrote:
I personally tend to believe it doesn't even need to be an error.
There is no technical reason not to allow it. All the user needs
to do is make sure that the combina
On Sat, Dec 10, 2011 at 12:29 PM, Greg Smith wrote:
> "We can send regular special messages from WALSender to WALReceiver that do
> not form part of the WAL stream, so we don't bulk
> up WAL archives. (i.e. don't use "w" messages)."
>
> Here's my understanding of how this would work.
Let me expl
On -10/01/37 20:59, Andrew Dunstan wrote:
This is apparently an optimization bug in the compiler. If I turn
optimization off (CFLAGS=-O0) it goes away. Ick.
So at the moment I'm a bit blocked. I can't really file a bug because
the
compiler can't currently be used to build postgres, I don't have
(2011/12/09 21:16), Etsuro Fujita wrote:
> I updated the patch. Please find attached a patch.
I've examined v5 patch, and got reasonable EXPLAIN results which reflect
collected statistics! As increasing STATISTICS option, estimated rows
become better. Please see attached stats_*.txt for what I
86 matches
Mail list logo
