On Wed, 2013-02-13 at 08:38 +0100, Pavel Stehule wrote:
> 5) Open question
>
> * I think so doc is not fully correct
>
> http://www.postgresql.org/message-id/CAFj8pRBf6suKewDCiXiGy=NeYY_Ns9CAZemomvRYsAQ=upl...@mail.gmail.com
Fixed that and committed.
> * syntax
>
> when I try some variants I g
On Sunday, February 17, 2013 8:44 PM Phil Sorber wrote:
> On Sun, Feb 17, 2013 at 1:35 AM, Amit kapila
> wrote:
> > On Tuesday, February 12, 2013 2:49 AM Heikki Linnakangas wrote:
> > On 04.02.2013 17:32, Alvaro Herrera wrote:
> >> Phil Sorber wrote:
> >>> On Mon, Feb 4, 2013 at 10:16 AM, Alvaro H
Hi,
On 02/15/2013 10:46 PM, Cédric Villemain wrote:
Hello,
I'm also interested in this topic.
> > I'm also interested in this topic and work on system-time temporal
> > extension. Here I wrote down design of my solution few months ago
> > https://wiki.postgresql.org/wiki/SQL2011Temporal. Th
On Thursday 14 February 2013, Manlio Perillo wrote:
> Il 14/02/2013 14:06, Albe Laurenz ha scritto:
> > Manlio Perillo wrote:
> >> Sorry for the question, but where can I find the libpq test suite?
> >> I can not find it in the PostgreSQL sources; it seems that there are
> >> only some examples, in
On 02/17/2013 01:19 PM, David E. Wheeler wrote:
On Feb 17, 2013, at 6:33 AM, Andrew Dunstan wrote:
No, then we don't have a variadic version. You are going to have to accept that
we can't make one function name cover all of this.
Well, for me, I would rather specify an array than call a fun
On 16 February 2013 01:01, Kevin Grittner wrote:
> Unless something else comes up in review or I get feedback to the
> contrary I plan to deal with the above-mentioned issues and commit
> this within a week or two.
At the moment it's not possible to rename a column without using ALTER
TABLE on an
On 17.2.2013 06:46, Alvaro Herrera wrote:
> Tomas Vondra wrote:
>
>> I've been thinking about this (actually I had a really weird dream about
>> it this night) and I think it might work like this:
>>
>> (1) check the timestamp of the global file -> if it's too old, we need
>> to send an inquir
On 2013-02-17 19:52:16 +, Peter Geoghegan wrote:
> On 17 February 2013 19:39, anara...@anarazel.de wrote:
> > What patch are you talking about? I have no knowledge about any pending
> > valgrind patches except one I made upstream apply to make pg inside
> > valgrind work on amd64.
>
> Noah
Peter Geoghegan schrieb:
>On 17 February 2013 18:52, anara...@anarazel.de
>wrote:
>> You already need a suppression file to use valgrind sensibly, its
>easy enough to add it there. Perhaps we should add one to the tree?
>
>Perhaps you should take the time to submit a proper Valgrind patch
>fir
On 17 February 2013 18:52, anara...@anarazel.de wrote:
> You already need a suppression file to use valgrind sensibly, its easy enough
> to add it there. Perhaps we should add one to the tree?
Perhaps you should take the time to submit a proper Valgrind patch
first. The current approach of apply
Tom Lane schrieb:
>Boszormenyi Zoltan writes:
>> Then, why isn't memcpy() skipped if the source and dest are the same?
>> It would be a micro-optimization but a valid one.
>
>No, it'd be more like a micro-pessimization, because the test would be
>wasted effort in the vast majority of calls. T
Tom Lane schrieb:
>Andres Freund writes:
>> On 2013-02-17 15:10:35 +, Greg Stark wrote:
>>> Peter G is sitting near me and reminded me that this issue came up
>in the
>>> past. Iirc the conclusion then is that we're calling memcpy where
>the
>>> source and destination pointers are sometime
On Feb 17, 2013, at 6:33 AM, Andrew Dunstan wrote:
> No, then we don't have a variadic version. You are going to have to accept
> that we can't make one function name cover all of this.
Well, for me, I would rather specify an array than call a function with a
different name. But it’s six of on
On Sun, Feb 17, 2013 at 4:26 PM, Tom Lane wrote:
> No, it'd be more like a micro-pessimization, because the test would be
> wasted effort in the vast majority of calls. The *only* reason to do
> this would be to shut up valgrind, and that seems annoying.
In terms of runtime I strongly suspect th
On Sat, Feb 16, 2013 at 4:42 PM, Andres Freund wrote:
> I propose extending the EXTERNAL varlenas to be able to point to memory
> instead just to disk. It seem apt to use EXTERNAL for this as they
> aren't stored in the normal heap tuple but somewhere else.
> Unfortunately there is no backward-com
Shigeru Hanada writes:
> On Sun, Feb 17, 2013 at 8:44 AM, Tom Lane wrote:
>> These don't seem to me like names that we ought to be
>> exposing at the SQL command level. Why not just "schema", "table",
>> "column"? Or perhaps "schema_name", "table_name", "column_name" if you
>> feel it's essenti
Boszormenyi Zoltan writes:
> Then, why isn't memcpy() skipped if the source and dest are the same?
> It would be a micro-optimization but a valid one.
No, it'd be more like a micro-pessimization, because the test would be
wasted effort in the vast majority of calls. The *only* reason to do
this
2013-02-17 16:32 keltezéssel, Tom Lane írta:
Andres Freund writes:
On 2013-02-17 15:10:35 +, Greg Stark wrote:
Peter G is sitting near me and reminded me that this issue came up in the
past. Iirc the conclusion then is that we're calling memcpy where the
source and destination pointers are
Andres Freund writes:
> On 2013-02-17 15:10:35 +, Greg Stark wrote:
>> Peter G is sitting near me and reminded me that this issue came up in the
>> past. Iirc the conclusion then is that we're calling memcpy where the
>> source and destination pointers are sometimes identical. Tom decided ther
On 2013-02-17 15:10:35 +, Greg Stark wrote:
> Peter G is sitting near me and reminded me that this issue came up in the
> past. Iirc the conclusion then is that we're calling memcpy where the
> source and destination pointers are sometimes identical. Tom decided there
> was really no realistic
On Sun, Feb 17, 2013 at 1:35 AM, Amit kapila wrote:
> On Tuesday, February 12, 2013 2:49 AM Heikki Linnakangas wrote:
> On 04.02.2013 17:32, Alvaro Herrera wrote:
>> Phil Sorber wrote:
>>> On Mon, Feb 4, 2013 at 10:16 AM, Alvaro Herrera
>>> wrote:
Phil Sorber wrote:
> On Mon, Feb 4, 201
Noah Misch wrote:
> On Sat, Feb 16, 2013 at 09:53:14AM -0800, Kevin Grittner wrote:
> I agree that making the dump fail on this account is bad.
I would argue that this is an overstatement of the issue except for
restores that use the single-transaction switch and pg_upgrade
without the hard link
Peter G is sitting near me and reminded me that this issue came up in the
past. Iirc the conclusion then is that we're calling memcpy where the
source and destination pointers are sometimes identical. Tom decided there
was really no realistic architecture where that wouldn't work. We're not
calling
On 02/16/2013 07:50 PM, David E. Wheeler wrote:
On Feb 16, 2013, at 12:47 PM, Andrew Dunstan wrote:
To answer David's point, there is no point in having both
get(json,text)
get(json, variadic text[])
since the second can encompass the first, and having both would make calls
ambiguo
==24373== Source and destination overlap in strncpy(0x28b892f5, 0x28b892f5, 64)
==24373==at 0x402A8F2: strncpy (mc_replace_strmem.c:477)
==24373==by 0x7D563F: namestrcpy (name.c:221)
==24373==by 0x46DF31: TupleDescInitEntry (tupdesc.c:473)
==24373==by 0x889EC3: resolve_polymorphic_t
In access/transam/xlog.c we give the OS buffer caching a hint that we
won't need a WAL file any time soon with
posix_fadvise(openLogFile, 0, 0, POSIX_FADV_DONTNEED);
before closing the WAL file, but only if we don't have walsenders.
That's reasonable because the walsender will reopen that sam
Hello
I try to play with different implementations of plpgsql deep checking.
The most important task of deep checking is creating plans for all
queries and expressions in function. The prerequisite for this task is
knowledge of data types of all variables. Record and row types is
break, but there
27 matches
Mail list logo
