> Robert Haas writes:
> > On Mon, Dec 13, 2010 at 9:16 PM, Tom Lane wrote:
> It seems like what we need at this point is a detailed, non-arm-waving
> design for what Jan would do in pl/python if hstore were in core. Then
> we can look at it and see exactly what we'd lose from keeping hstore out
2010/12/14 Tom Lane :
> Pavel Stehule writes:
>>> On Mon, Dec 13, 2010 at 9:16 PM, Tom Lane wrote:
and (b) how do you identify which type OID
is really hstore? ("The one named hstore" is the wrong answer.)
COM architecture uses a uuid, but Microsoft leaves this idea.
can we identify
On Tue, Dec 14, 2010 at 15:31, Shigeru HANADA wrote:
>> - BeginCopyFrom(rel, filename, attnamelist, options) : CopyState
>> - EndCopyFrom(cstate) : void
>> - NextCopyFrom(cstate, OUT values, OUT nulls, OUT tupleOid) : bool
>> - GetCopyExecutorState(cstate) : EState *
>> - CopyFromErrorCallback(arg
On Tue, 14 Dec 2010 12:01:36 +0900
Itagaki Takahiro wrote:
> On Tue, Dec 14, 2010 at 01:25, Andrew Dunstan wrote:
> > On 12/13/2010 11:12 AM, Tom Lane wrote:
> > In that case I guess I'll need to do what Shigeru-san has done, and copy
> > large parts of copy.c.
>
> I found file_fdw would require
Pavel Stehule writes:
>> On Mon, Dec 13, 2010 at 9:16 PM, Tom Lane wrote:
>>> and (b) how do you identify which type OID
>>> is really hstore? Â ("The one named hstore" is the wrong answer.)
> we can search a OID function descriptor. If you know a name and
> parameter's type, then isn't a proble
2010/12/14 Robert Haas :
> On Mon, Dec 13, 2010 at 10:10 AM, Shigeru HANADA
> wrote:
>> I've revised fdw_core patch along your proposal and subsequent
>> discussion, and tried to fix FDW patches pgsql_fdw and file_fdw
>> according to fdw_core. Attached is a WIP which includes changes
>> below.
>
2010/12/14 Robert Haas :
> On Mon, Dec 13, 2010 at 9:16 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Can we arrange to pg_dlopen() the hstore module instead of linking
>>> against it directly? Seems like that might let you use it when
>>> available without making it a hard requirement.
>>
>> T
I've attached an updated patch that fixes a failure when compiling on
gcc/linux. The no-op inline installCrashDumpHandler() for unsupported
platforms was not declared static, so it was not being optimized out of
objects it wasn't used in and was causing symbol collisions during linkage.
"make
On Dec 13, 2010, at 7:19 PM, Robert Haas wrote:
> If we decree that Python dictionaries map
> onto hstore, does that mean they DON'T map onto json, or Pavel's
> hand-wavy proposal for associative arrays? Because from 10,000 feet
> it sure isn't obvious why hstore would be preferable to either of
(2010/12/14 13:31), Robert Haas wrote:
> 2010/12/13 KaiGai Kohei:
>> (2010/12/14 12:53), Robert Haas wrote:
>>> 2010/12/13 KaiGai Kohei:
(2010/12/14 12:10), Robert Haas wrote:
> 2010/12/13 KaiGai Kohei:
>> The starter version is not intended to use in production system,
>
> Wel
2010/12/13 KaiGai Kohei :
> (2010/12/14 12:53), Robert Haas wrote:
>> 2010/12/13 KaiGai Kohei:
>>> (2010/12/14 12:10), Robert Haas wrote:
2010/12/13 KaiGai Kohei:
> The starter version is not intended to use in production system,
Well, what's the point, then? I thought we had en
(2010/12/14 12:53), Robert Haas wrote:
> 2010/12/13 KaiGai Kohei:
>> (2010/12/14 12:10), Robert Haas wrote:
>>> 2010/12/13 KaiGai Kohei:
The starter version is not intended to use in production system,
>>>
>>> Well, what's the point, then? I thought we had enough infrastructure
>>> in place a
Itagaki Takahiro writes:
> On Tue, Dec 14, 2010 at 12:47, Tom Lane wrote:
>> lo_import is superuser-only. Â If we design this feature so that it will
>> forever have to be superuser-only, to get a behavior that I think we
>> don't even *want*, I believe we're making a serious error.
> CREATE EXT
On Tue, Dec 14, 2010 at 12:47, Tom Lane wrote:
> lo_import is superuser-only. If we design this feature so that it will
> forever have to be superuser-only, to get a behavior that I think we
> don't even *want*, I believe we're making a serious error.
CREATE EXTENSION and pg_read_file() is also
2010/12/13 KaiGai Kohei :
> (2010/12/14 12:10), Robert Haas wrote:
>> 2010/12/13 KaiGai Kohei:
>>> The starter version is not intended to use in production system,
>>
>> Well, what's the point, then? I thought we had enough infrastructure
>> in place at this point to build a simple system that, wh
On Mon, Dec 13, 2010 at 10:21 PM, Itagaki Takahiro
wrote:
>> I don't have any problem with a separate patch to try to improve some
>> of these issues, but this is supposedly part of the extensions work,
>> yet (1) most of what's here has little to do with extensions and (2)
>> extensions don't nee
On Tue, Nov 30, 2010 at 9:15 AM, David Fetter wrote:
>> Patch attached. If you think my changes are ok,
>> please change the patch status to "Ready for Committer".
>
> Done :)
I have committed part of this patch. The rest is attached. I don't
know that there's any problem with it, but I ran out
Itagaki Takahiro writes:
> On Tue, Dec 14, 2010 at 12:02, Robert Haas wrote:
>> As Tom says, this is clearly not going to fly on security grounds.
> If it's a security hole, lo_import() should be also a hole
> because we can use lo_import() and SELECT * FROM pg_largeobject
> for the same purpose
(2010/12/14 12:10), Robert Haas wrote:
> 2010/12/13 KaiGai Kohei:
>> The starter version is not intended to use in production system,
>
> Well, what's the point, then? I thought we had enough infrastructure
> in place at this point to build a simple system that, while it
> wouldn't meet every use
On Tue, Dec 14, 2010 at 12:02, Robert Haas wrote:
> On Mon, Dec 13, 2010 at 9:41 PM, Itagaki Takahiro
>> So, the most important part of this patch is allowing to read any
>> files in the server file system. The current pg_read_file() allows
>> to read only files under $PGDATA and pg_log.
>
> As To
On Mon, Dec 13, 2010 at 10:17 PM, Tom Lane wrote:
> I agree with that in general, but we do not have a very viable solution
> for letting independent extensions interact.
Can we create one?
> It seems like what we need at this point is a detailed, non-arm-waving
> design for what Jan would do in
Robert Haas writes:
> On Mon, Dec 13, 2010 at 9:16 PM, Tom Lane wrote:
>> That doesn't deal with the issues of (a) what is a reasonable fallback
>> when the module's not there,
> Well, if you were passed an hstore argument, and hstore can't be
> loaded, wouldn't throwing an error be fairly reaso
On Mon, Dec 13, 2010 at 4:52 PM, Josh Berkus wrote:
> On 12/13/10 9:37 AM, Robert Haas wrote:
>> - synchronous replication - and...
>> - synchronous replication, transaction-controlled - If we want to get
>> this feature into 9.1, we had better get a move on. But I don't
>> currently have it in m
2010/12/13 KaiGai Kohei :
> The starter version is not intended to use in production system,
Well, what's the point, then? I thought we had enough infrastructure
in place at this point to build a simple system that, while it
wouldn't meet every use case, would be useful to some people for
limited
On Mon, Dec 13, 2010 at 9:16 PM, Tom Lane wrote:
> Robert Haas writes:
>> Can we arrange to pg_dlopen() the hstore module instead of linking
>> against it directly? Seems like that might let you use it when
>> available without making it a hard requirement.
>
> That doesn't deal with the issues
On Mon, Dec 13, 2010 at 9:41 PM, Itagaki Takahiro
wrote:
> Hmm, I've expected that the EXTENSION patch would use the SQL functions
> like as SPI_exec("SELECT pg_execute_sql(pg_read_file($1))", ...), but
> it actually uses internal functions and nested DirectFunctionCalls.
> So, the most important
On Mon, Dec 13, 2010 at 10:10 AM, Shigeru HANADA
wrote:
> I've revised fdw_core patch along your proposal and subsequent
> discussion, and tried to fix FDW patches pgsql_fdw and file_fdw
> according to fdw_core. Attached is a WIP which includes changes
> below.
This actually doesn't apply cleanl
Itagaki Takahiro writes:
> On Tue, Dec 14, 2010 at 10:53, Robert Haas wrote:
>> I'm looking at this patch and I'm confused. Â Why do we need this at
>> all? Â pg_read_binary_file() seems like it might be useful to somebody,
>> but I don't see what it has to do with extensions. Â And the rest of
>
On Tue, Dec 14, 2010 at 10:53, Robert Haas wrote:
> I'm looking at this patch and I'm confused. Why do we need this at
> all? pg_read_binary_file() seems like it might be useful to somebody,
> but I don't see what it has to do with extensions. And the rest of
> this doesn't appear to provide an
Marko Tiikkaja writes:
> On 2010-12-14 1:08 AM +0200, Szymon Guz wrote:
>> In my opinion changing current behavior is not a good idea. I know some
>> software that relies on current behavior and this would break it. Maybe add
>> that as an option, or add another type of advisory lock?
> Oh, I for
> Oh, I forgot to mention. The patch doesn't change any existing
> behaviour; the new behaviour can be invoked only by adding a new boolean
> argument:
>
> SELECT pg_advisory_lock(1, false);
>
> The lock space is the same though, but I don't feel strongly about it.
I could use this, and I thin
Robert Haas writes:
> Can we arrange to pg_dlopen() the hstore module instead of linking
> against it directly? Seems like that might let you use it when
> available without making it a hard requirement.
That doesn't deal with the issues of (a) what is a reasonable fallback
when the module's not
(2010/12/14 10:41), Robert Haas wrote:
> 2010/12/13 KaiGai Kohei:
I counted number of lines of the sepgsql module that implement
only currently supported hooks. It has 3.2KL of code not.
>>>
>>> Uh, wow. That's rather surprising. I thought that it would be
>>> measured in hundreds of li
On Mon, Dec 13, 2010 at 9:36 AM, Dimitri Fontaine
wrote:
> Do you want another patch version from me?
I'm looking at this patch and I'm confused. Why do we need this at
all? pg_read_binary_file() seems like it might be useful to somebody,
but I don't see what it has to do with extensions. And
2010/12/13 KaiGai Kohei :
>>> I counted number of lines of the sepgsql module that implement
>>> only currently supported hooks. It has 3.2KL of code not.
>>
>> Uh, wow. That's rather surprising. I thought that it would be
>> measured in hundreds of lines. Aren't the hooks that we implemented a
Robert Haas wrote:
- instrument checkpoint sync calls - I plan to commit this in the next
48 hours. (Hopefully Greg Smith will do the cleanup I suggested, if
not I'll do it.)
Yes, doing that tonight so you can have a simple (hopefully) bit of work
to commit tomorrow.
- MERGE command - R
(2010/12/14 9:32), Robert Haas wrote:
> 2010/12/13 KaiGai Kohei:
It is a good news for me also, because I didn't imagine SE-PostgreSQL
module getting upstreamed, even if contrib module.
OK, I'll focus on the works to merge the starter-version of SE-PostgreSQL
as a contrib m
On 2010-12-14 2:35 AM +0200, Simon Riggs wrote:
On Tue, 2010-12-14 at 01:14 +0200, Marko Tiikkaja wrote:
Oh, I forgot to mention. The patch doesn't change any existing
behaviour; the new behaviour can be invoked only by adding a new boolean
argument:
SELECT pg_advisory_lock(1, false);
Don't
On 12/13/2010 07:35 PM, Simon Riggs wrote:
Same lock space is good. Easy to separate if required.
Explicitly nameable lock spaces would be even better, since if multiple
applications use them you get strange and unmanageable contention.
Yeah. I have a table of lock names for different locks,
On Fri, Oct 8, 2010 at 11:10 AM, Simon Riggs wrote:
> This patch is a rough WIP, mostly stripping out and streamlining. It
> doesn't work yet, but people say they like to see me working, so here
> 'tis.
It's been two months since you posted this. Any update?
I'd like to actually review the two
On Wed, Sep 15, 2010 at 8:39 AM, Fujii Masao wrote:
> I rebased the patch against current HEAD because it conflicted with
> recent commits about a latch.
Can you please rebase this again? It no longer applies.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL C
On Thu, Dec 9, 2010 at 11:54 PM, Fujii Masao wrote:
> In previous discussion, some people wanted the "wait-forever" option which
> blocks all the transactions on the master until sync'd standby has appeared,
> in order to reduce the risk of data loss in synchronous replication.
>
> What I'm not cl
On Tue, 2010-12-14 at 01:14 +0200, Marko Tiikkaja wrote:
> On 2010-12-14 1:08 AM +0200, Szymon Guz wrote:
> > On 13 December 2010 23:52, Marko
> > Tiikkajawrote:
> >> So, thoughts?
> >>
> > In my opinion changing current behavior is not a good idea. I know some
> > software that relies on current
2010/12/13 KaiGai Kohei :
>>> It is a good news for me also, because I didn't imagine SE-PostgreSQL
>>> module getting upstreamed, even if contrib module.
>>>
>>> OK, I'll focus on the works to merge the starter-version of SE-PostgreSQL
>>> as a contrib module in the last commit fest.
>>>
>>> Proba
On Sun, 2010-12-12 at 10:15 +, Simon Riggs wrote:
> > Also, I'm not totally convinced it's correct when xmin > xmax,
> despite
> > Simon's follow-up commit to fix that. Shouldn't it advance
> > latestRemovedXid to xmin in that case? Or maybe it's ok as it is
> because
> > we know that xmax c
On Mon, Dec 13, 2010 at 7:17 PM, Robert Haas wrote:
> 2010/12/7 KaiGai Kohei :
>> Thanks for your reviewing.
>>
>> The attached patch is a revised version.
>> I don't have any objections to your comments.
>
> This failed to update the security_label docs, but I don't think it's
> a requirement tha
2010/12/7 KaiGai Kohei :
> Thanks for your reviewing.
>
> The attached patch is a revised version.
> I don't have any objections to your comments.
This failed to update the security_label docs, but I don't think it's
a requirement that a hook have regression testing the way we require
for an SQL s
(2010/12/14 1:03), Robert Haas wrote:
> On Mon, Dec 13, 2010 at 8:32 AM, KaiGai Kohei wrote:
>> (2010/12/13 21:53), Robert Haas wrote:
>>> 2010/12/12 KaiGai Kohei:
I'd like to see opinions what facilities should be developed
to the current v9.1 development cycle.
>>>
>>> It seems to
On 12/13/2010 04:34 PM, Tom Lane wrote:
Andrew Dunstan writes:
Further digging shows some weirdness. This doesn't appear to be
compiler-related. I've rolled back all the way to gcc 3.5. It is
triggered by the following line in pg_regress.c, commenting out of which
causes the problem to go awa
On 2010-12-14 1:08 AM +0200, Szymon Guz wrote:
On 13 December 2010 23:52, Marko Tiikkajawrote:
So, thoughts?
In my opinion changing current behavior is not a good idea. I know some
software that relies on current behavior and this would break it. Maybe add
that as an option, or add another typ
On 13 December 2010 23:52, Marko Tiikkaja wrote:
> Hi,
>
> I often find myself wanting advisory locks that are automatically released
> when the transaction ends, so here's a small patch trying to do just that.
> I don't know much about the lock system so the patch is in the state "it
> looks lik
Hi,
I often find myself wanting advisory locks that are automatically
released when the transaction ends, so here's a small patch trying to do
just that. I don't know much about the lock system so the patch is in
the state "it looks like this would work". Any comments on the
technical detai
On Mon, Dec 13, 2010 at 5:45 PM, Tomas Vondra wrote:
>> I'll suggest again how to decide *which* columns to cross: whichever
>> columns are combined in composite indexes. In version 2, allow the DBA
>> to specify combinations.
> I think this is a bit early to discuss this, given the fact that we
On Mon, Dec 13, 2010 at 2:50 AM, Jan Urbański wrote:
> It would be cool to be able to transparently use hstores as Python
> dictionaries and vice versa. It would be easy enough with hstore as a
> core type, but with hstore as an addon it's not that easy.
>
> There was talk about including hstore i
2010/12/13 Josh Berkus :
> Tomas,
>
>> (a) find out what statistics do we need to collect and how to use it
>> (b) implement a really stupid inefficient solution
>> (c) optimize in iterations, i.e. making it faster, consuming less
>> space etc.
>
> I'll suggest again how to decide *whic
Dne 13.12.2010 22:50, Josh Berkus napsal(a):
> Tomas,
>
>> (a) find out what statistics do we need to collect and how to use it
>> (b) implement a really stupid inefficient solution
>> (c) optimize in iterations, i.e. making it faster, consuming less
>> space etc.
>
> I'll suggest aga
2010/12/13 Dmitriy Igrishin :
>
>
> 2010/12/14 Pavel Stehule
>>
>> 2010/12/13 Dmitriy Igrishin :
>> >
>> >
>> > 2010/12/13 Pavel Stehule
>> >>
>> >> 2010/12/13 Dmitriy Igrishin :
>> >> >
>> >> >
>> >> > 2010/12/13 Pavel Stehule
>> >> >>
>> >> >> 2010/12/13 Dmitriy Igrishin :
>> >> >> > There are
loureir...@gmail.com (Daniel Loureiro) writes:
>> You can believe whatever you want, that doesn't make it true.
> completely agree. Like yours, Its just my point of view, not the reality.
>
> I agree with some points here, but I wondering how many good ideas are
> killed with the thought: "this wil
j...@nasby.net (Jim Nasby) writes:
> On Dec 10, 2010, at 6:18 PM, Jeff Janes wrote:
>> On Fri, Dec 10, 2010 at 3:09 PM, Hamza Bin Sohail wrote:
>>>
>>> Hello hackers,
>>>
>>> I think i'm at the right place to ask this question.
>>>
>>> Based on your experience and the fact that you have written
2010/12/14 Pavel Stehule
> 2010/12/13 Dmitriy Igrishin :
> >
> >
> > 2010/12/13 Pavel Stehule
> >>
> >> 2010/12/13 Dmitriy Igrishin :
> >> >
> >> >
> >> > 2010/12/13 Pavel Stehule
> >> >>
> >> >> 2010/12/13 Dmitriy Igrishin :
> >> >> > There are a lot of operators and functions to work with hst
On 12/13/10 9:37 AM, Robert Haas wrote:
> - synchronous replication - and...
> - synchronous replication, transaction-controlled - If we want to get
> this feature into 9.1, we had better get a move on. But I don't
> currently have it in my time budget to deal with this.
I thought we'd covered mo
Tomas,
> (a) find out what statistics do we need to collect and how to use it
> (b) implement a really stupid inefficient solution
> (c) optimize in iterations, i.e. making it faster, consuming less
> space etc.
I'll suggest again how to decide *which* columns to cross: whichever
colu
Andrew Dunstan writes:
> Further digging shows some weirdness. This doesn't appear to be
> compiler-related. I've rolled back all the way to gcc 3.5. It is
> triggered by the following line in pg_regress.c, commenting out of which
> causes the problem to go away (although of course it causes th
On Mon, Dec 13, 2010 at 22:29, Andrew Dunstan wrote:
>
>
> On 12/13/2010 01:12 PM, Tom Lane wrote:
>>
>> Andrew Dunstan writes:
>>>
>>> On 12/13/2010 12:01 PM, Tom Lane wrote:
It smells a little bit like an optimization bug. Does dialing down to
-O0 make it go away?
>>>
>>> Sadly,
On 12/13/2010 01:12 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 12/13/2010 12:01 PM, Tom Lane wrote:
It smells a little bit like an optimization bug. Does dialing down to
-O0 make it go away?
Sadly, no. I'm testing downgrading the compiler now.
Mph. FWIW, I see that my last build of Po
On Dec 12, 2010, at 8:48 PM, Jim Nasby wrote:
>> There might be some advantage in having it move buffers
>> to a freelist that's just protected by a simple spinlock (or at least,
>> a lock different from the one that protects the clock sweep). The
>> idea would be that most of the time, backends j
"David E. Wheeler" writes:
> On Dec 13, 2010, at 12:04 PM, Dimitri Fontaine wrote:
>> So, who's in to finish up and commit this patch in this round? :)
>
> I'll try to do another review this week.
Thanks!
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Tom Lane wrote:
> argue that there was a regression. It's certainly a performance bug
> though: nobody would expect that giving a query *more* work_mem would
> cause it to run many times slower.
I wouldn't be that surprised - otherwise it'd just be hard-coded to
something large.
Especially since
2010/12/13 Dmitriy Igrishin :
>
>
> 2010/12/13 Pavel Stehule
>>
>> 2010/12/13 Dmitriy Igrishin :
>> >
>> >
>> > 2010/12/13 Pavel Stehule
>> >>
>> >> 2010/12/13 Dmitriy Igrishin :
>> >> > There are a lot of operators and functions to work with hstore.
>> >> > Does it worth it to implement similar
On Dec 13, 2010, at 12:04 PM, Dimitri Fontaine wrote:
> So, who's in to finish up and commit this patch in this round? :)
> I certainly am ready to support last minute changes, given some are
> required. And if they are too big for the schedule, better shake the
> patch out now rather than let it
2010/12/13 Pavel Stehule
> 2010/12/13 Dmitriy Igrishin :
> >
> >
> > 2010/12/13 Pavel Stehule
> >>
> >> 2010/12/13 Dmitriy Igrishin :
> >> > There are a lot of operators and functions to work with hstore.
> >> > Does it worth it to implement similar things only to make it
> >> > possible using o
On Mon, Dec 13, 2010 at 12:48 AM, aaliya zarrin wrote:
> When pg_is_in_recovery in the table changes to zero(status change)??
> At the time when recovery stops?
Ah... yep.
> If switch over has to be done then, after receivibg the signal and telling
> the postgres to run the startup process (got_
On Mon, Dec 13, 2010 at 5:48 AM, aaliya zarrin wrote:
> drainSelfPipe() function will read the data and remove it from the
> descriptor?
Yes...
> Coz the signal (SIGUSR1) is writing sata to selfPipe descriptor but unable
> to wake up latch on select system call.
The signal won't cause the selec
Robert Haas writes:
> We're now just a day or two from the end of this CommitFest and there
> are still a LOT of open patches - to be specific, 23.Here's a brief
> synopsis of where we are with the others, all IMO of course.
Thanks for doing this!
> - Extensions - Still under active discussion,
On Mon, Dec 13, 2010 at 2:19 PM, David Fetter wrote:
> On Mon, Dec 13, 2010 at 12:37:52PM -0500, Robert Haas wrote:
>> We're now just a day or two from the end of this CommitFest and there
>> are still a LOT of open patches - to be specific, 23.Here's a brief
>> synopsis of where we are with the o
Dne 13.12.2010 18:59, Joshua Tolley napsal(a):
> On Sun, Dec 12, 2010 at 07:10:44PM -0800, Nathan Boley wrote:
>> Another quick note: I think that storing the full contingency table is
>> wasteful since the marginals are already stored in the single column
>> statistics. Look at copulas [2] ( FWIW
On Mon, Dec 13, 2010 at 12:37:52PM -0500, Robert Haas wrote:
> We're now just a day or two from the end of this CommitFest and there
> are still a LOT of open patches - to be specific, 23.Here's a brief
> synopsis of where we are with the others, all IMO of course.
[snip]
> - Writeable CTEs - I th
Dne 13.12.2010 16:38, Tom Lane napsal(a):
> The reason that this wasn't done years ago is precisely that nobody's
> figured out how to do it with a tolerable amount of stats data and a
> tolerable amount of processing time (both at ANALYZE time and during
> query planning). It's not hard to see wh
Dne 13.12.2010 16:34, Tom Lane napsal(a):
> Tomas Vondra writes:
>> Well, until this point we've discussed failure cases involving 'AND'
>> conditions. What about 'OR' conditions? I think the current optimizer
>> computes the selectivity as 's1+s2 - s1*s2' (at least that's what I
>> found in backe
On Mon, 2010-12-13 at 17:15 +, Peter Geoghegan wrote:
> On 13 December 2010 16:08, Robert Haas wrote:
> > On Mon, Dec 13, 2010 at 10:49 AM, Simon Riggs wrote:
> >> 2. pg_validate_foreign_key('constraint name');
> >> Returns immediately if FK is valid
> >> Returns SETOF rows that violate the c
On 13.12.2010 20:30, Tom Lane wrote:
Can we fix it so that each child page is updated, and its downlink
inserted, as a separate atomic action? That'd require each intermediate
state to be consistent and crash-safe, but I think you really need the
intermediate states to be consistent anyway becau
Heikki Linnakangas writes:
> On 13.12.2010 19:48, Tom Lane wrote:
>> Yeah. Wouldn't the original page-split record have been carrying full
>> page images already?
> Yes.
> BTW, the original split record doesn't run into the limit because it
> doesn't use the backup-block mechanism, it contains
On 13.12.2010 19:48, Tom Lane wrote:
Heikki Linnakangas writes:
On 13.12.2010 19:19, Greg Stark wrote:
If it's only the backup blocks that matter couldn't you generate noop
WAL records with just the full page image in them. Once all those are
generated then generate the actual split operation
On Dec 13, 2010, at 8:06 AM, Oleg Bartunov wrote:
> My most serious pro about hstore in core is a better dump/restore
> support. Also, since we have so much better hstore and people started
> to use it in their projects, it'd be great to have built-in feature in
> PostgreSQL, which mimic key-va
Andrew Dunstan writes:
> On 12/13/2010 12:01 PM, Tom Lane wrote:
>> It smells a little bit like an optimization bug. Does dialing down to
>> -O0 make it go away?
> Sadly, no. I'm testing downgrading the compiler now.
Mph. FWIW, I see that my last build of Postgres for Fedora 14 would
have been
2010/12/13 Dmitriy Igrishin :
>
>
> 2010/12/13 Pavel Stehule
>>
>> 2010/12/13 Dmitriy Igrishin :
>> > There are a lot of operators and functions to work with hstore.
>> > Does it worth it to implement similar things only to make it
>> > possible using operator [] ?
>>
>> yes
>>
>> >
>> > 2010/12/1
On Mon, Dec 13, 2010 at 12:55 PM, Andrew Dunstan wrote:
>
>
> On 12/13/2010 12:37 PM, Robert Haas wrote:
>>
>> - SQL/MED - core functionality - Seems clear to move this to the next
>> CF and keep working on it.
>
> [...]
>>
>> - SQL/MED - file_fdw - Discussion is ongoing, but I see no harm in
>> m
Andrew Dunstan writes:
> On 12/13/2010 12:16 PM, BRUSSER Michael wrote:
>> Would it be a completely crazy idea if I try to modify Postgres to look at
>> some env. var
>> (similar to PGDATA) and if exists and path is valid look there for the
>> timezone files?
> Yes, that's only the first probl
On Sun, Dec 12, 2010 at 07:10:44PM -0800, Nathan Boley wrote:
> Another quick note: I think that storing the full contingency table is
> wasteful since the marginals are already stored in the single column
> statistics. Look at copulas [2] ( FWIW I think that Josh Tolley was
> looking at this a cou
On 12/13/2010 12:01 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 11/01/2010 10:10 PM, Itagaki Takahiro wrote:
BTW, with out without the above fix, regression test failed with
weird error if the server is built with gcc 4.5. However, server
can run if I started it manually with PGPORT or -o
On 12/13/2010 12:37 PM, Robert Haas wrote:
- SQL/MED - core functionality - Seems clear to move this to the next
CF and keep working on it.
[...]
- SQL/MED - file_fdw - Discussion is ongoing, but I see no harm in
marking this Returned with Feedback for now in anticipation of a new
version bef
Heikki Linnakangas writes:
> On 13.12.2010 19:19, Greg Stark wrote:
>> If it's only the backup blocks that matter couldn't you generate noop
>> WAL records with just the full page image in them. Once all those are
>> generated then generate the actual split operation and since all the
>> pages hav
On 13.12.2010 19:19, Greg Stark wrote:
On Mon, Dec 13, 2010 at 3:14 PM, Tom Lane wrote:
I think you need to refactor the operation so that there's one WAL
record per child page, or something along that line. I concede this
might be diffcult :-(
If it's only the backup blocks that matter coul
We're now just a day or two from the end of this CommitFest and there
are still a LOT of open patches - to be specific, 23.Here's a brief
synopsis of where we are with the others, all IMO of course.
- fix for seg picksplit function - I don't have confidence this change
is for the best and can't ta
On Fri, Dec 10, 2010 at 11:16 PM, Robert Haas wrote:
> I think the first patch (relpersistence-v4.patch) is ready to commit,
So I've now committed it.
> and the third patch to allow synchronous commits to become
> asynchronous when it doesn't matter (relax-sync-commit-v1.patch)
Jeff Janes revie
2010/12/13 Pavel Stehule
> 2010/12/13 Dmitriy Igrishin :
> > There are a lot of operators and functions to work with hstore.
> > Does it worth it to implement similar things only to make it
> > possible using operator [] ?
>
> yes
>
> >
> > 2010/12/13 Pavel Stehule
> >>
> >> >>
> >> >> name and
On Mon, Dec 13, 2010 at 05:15:29PM +, Peter Geoghegan wrote:
> On 13 December 2010 16:08, Robert Haas wrote:
> > On Mon, Dec 13, 2010 at 10:49 AM, Simon Riggs wrote:
> >> 2. pg_validate_foreign_key('constraint name');
> >> Returns immediately if FK is valid
> >> Returns SETOF rows that violat
On 12/13/2010 12:16 PM, BRUSSER Michael wrote:
Here is what you should do:
1. Build Postgres with --prefix set to some empty directory.
2. Run install.
3. Bundle up the resulting install tree as part of your tarball. Do not
editorialize upon the relative locations of its contents.
4. Drop the
On Mon, Dec 13, 2010 at 3:14 PM, Tom Lane wrote:
> I think you need to refactor the operation so that there's one WAL
> record per child page, or something along that line. I concede this
> might be diffcult :-(
If it's only the backup blocks that matter couldn't you generate noop
WAL records wi
Here is what you should do:
1. Build Postgres with --prefix set to some empty directory.
2. Run install.
3. Bundle up the resulting install tree as part of your tarball. Do not
editorialize upon the relative locations of its contents.
4. Drop the install tree wherever you want on the target machi
1 - 100 of 160 matches
Mail list logo
