from 9.3devel (this morning):
There is a small bug in pg_basebackup: it displays a truncated part of what
seems to be the new
$PGDATA (the source code has 'filename' there, but I don't see what's supposed
to be in there).
The truncated name in parentheses only shows up during the filling of
Le vendredi 14 décembre 2012 23:02:11, Tom Lane a écrit :
In a fully-built source tree:
$ cd pgsql/src/backend/parser
$ make
make: Nothing to be done for `all'.
... okay so far ...
$ rm gram.o
rm: remove regular file `gram.o'? y
$ make
make: Nothing to be done for `all'.
WTF?
A
We discussed this idea in the past [1] and Robert recently again
mentioned this in another thread [2]. Please see a rebased/revised
patch attached with the mail. This is mostly similar to what I's
submitted in [1] except some additions to also compute visibility
cut-off XID. I also removed a
On Sat, Dec 15, 2012 at 11:39 AM, Erik Rijkers e...@xs4all.nl wrote:
from 9.3devel (this morning):
Is this different from 9.2 and earlier?
There is a small bug in pg_basebackup: it displays a truncated part of what
seems to be the new
$PGDATA (the source code has 'filename' there, but I
On Sat, Dec 15, 2012 at 01:23:38AM -0500, Peter Eisentraut wrote:
In the plperl and plpython makefiles we look for a shared library of
libperl or libpython, and if it's not found, we check for
allow_nonpic_in_shlib, and if that's yes, then we proceed anyway.
Apparently, and IIRC, this was set
On Sat, December 15, 2012 14:10, Magnus Hagander wrote:
On Sat, Dec 15, 2012 at 11:39 AM, Erik Rijkers e...@xs4all.nl wrote:
from 9.3devel (this morning):
The truncated name in parentheses only shows up during the filling of the
new PGDATA; when 100%
is
reached that part of the displayed
=?iso-8859-15?q?C=E9dric_Villemain?= ced...@2ndquadrant.com writes:
Le vendredi 14 décembre 2012 23:02:11, Tom Lane a écrit :
$ rm gram.o
rm: remove regular file `gram.o'? y
$ make
make: Nothing to be done for `all'.
WTF?
A previous patch changed the .SECONDARY from an if() section to
On 15 December 2012 12:42, Pavan Deolasee pavan.deola...@gmail.com wrote:
We discussed this idea in the past [1] and Robert recently again
mentioned this in another thread [2]. Please see a rebased/revised
patch attached with the mail. This is mostly similar to what I's
submitted in [1] except
Kevin Grittner kgri...@mail.com writes:
Tom Lane wrote:
the parser tables are basically number-of-tokens wide by
number-of-states high. (In HEAD there are 433 tokens known to the
grammar, all but 30 of which are keywords, and 4367 states.)
Splitting the grammar into multiple grammars is
Peter Eisentraut pete...@gmx.net writes:
In the plperl and plpython makefiles we look for a shared library of
libperl or libpython, and if it's not found, we check for
allow_nonpic_in_shlib, and if that's yes, then we proceed anyway.
Apparently, and IIRC, this was set up in a time when those
On Sat, Dec 15, 2012 at 9:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
=?iso-8859-15?q?C=E9dric_Villemain?= ced...@2ndquadrant.com writes:
Le vendredi 14 décembre 2012 23:02:11, Tom Lane a écrit :
$ rm gram.o
rm: remove regular file `gram.o'? y
$ make
make: Nothing to be done for `all'.
WTF?
Simon Riggs si...@2ndquadrant.com writes:
Doing that only makes sense when we're running a SELECT. Setting the
all visible bit immediately prior to an UPDATE that clears it again is
pointless effort, generating extra work for no reason.
On the other hand, the HOT prune operation itself is
Hello
I tested some usage of LATERAL clause, and I found so LATERAL doesn't
respects difference between VOLATILE and IMMUTABLE functions.
Is this behave expected?
-- unexpected
postgres=# select * from generate_series(1,3) g(v), LATERAL (SELECT random()) x;
;
v │ random
Pavel Stehule pavel.steh...@gmail.com writes:
Is this behave expected?
-- unexpected
postgres=# select * from generate_series(1,3) g(v), LATERAL (SELECT random())
x;
;
vrandom
---+--
1 0.63025646051392
2 0.63025646051392
3 0.63025646051392
(3 rows)
2012/12/15 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
Is this behave expected?
-- unexpected
postgres=# select * from generate_series(1,3) g(v), LATERAL (SELECT
random()) x;
;
vrandom
---+--
1 0.63025646051392
2
On Fri, 2012-12-14 at 17:03 -0500, Tom Lane wrote:
Having the layer is a good thing, eg so that USE_ASSERT_CHECKING
can control it, or so that somebody can inject a different behavior
if they want.
You could also (or at least additionally) map !USE_ASSERT_CHECKING to
NDEBUG. This would also
On Fri, 2012-12-14 at 15:32 -0500, Andrew Dunstan wrote:
Here's a patch for that.
It appears that your change has caused new compiler warnings:
encnames.c:9:1: warning: Assert redefined
In file included from encnames.c:8:
../../../src/include/postgres_fe.h:36:1: warning: this is the location of
I'm going to use PL/Python as an example, but I would also like to know
if this could be applicable to other languages.
When you do
CREATE FUNCTION foo(...) ... LANGUAGE plpythonu
AS $$
source code here
$$;
it internally creates a source file that contains
---
def
On Sat, 2012-11-17 at 12:02 -0600, Karl O. Pinc wrote:
Feel free to reject. I sent in the patch to
try out the idea. It's a bit crazy, but I didn't
think too crazy to share with the list.
I'm going to set this patch as returned with feedback for now. I'm all
for adding more help to the
On Mon, 2012-12-10 at 20:48 -0600, Karl O. Pinc wrote:
On 11/14/2012 02:35:54 PM, Karl O. Pinc wrote:
On 11/13/2012 08:50:55 PM, Peter Eisentraut wrote:
On Sat, 2012-09-29 at 01:16 -0500, Karl O. Pinc wrote:
This patch makes some sweeping statements.
Unfortunately, they are wrong.
On Sun, Dec 16, 2012 at 3:18 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
Doing that only makes sense when we're running a SELECT. Setting the
all visible bit immediately prior to an UPDATE that clears it again is
pointless effort, generating extra work for
21 matches
Mail list logo
