On Wednesday, February 27, 2013 12:41 AM Heikki Linnakangas wrote:
> On 22.02.2013 12:43, Etsuro Fujita wrote:
> >> 1. "Broken pipe" is not handled in case of psql "\copy" command;
> >> Issue are as follows:
> >> Following are verified on SuSE-Linux 10.2.
> >>
2013/2/26 Stephen Frost :
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Dunno, I think that's going to result in a very large chunk of mostly
>> duplicative code in psql. regprocedurein() is fairly short because it
>> can rely on a ton of code from the parser, but psql won't have that
>> luxury.
>
>
Zoltan,
* Boszormenyi Zoltan (z...@cybertec.at) wrote:
> attached is v30, I hope with everything fixed.
Making progress, certainly.
Given the hack to the API of enable_timeout_after() and the need for
timeout_reset_base_time(), I'm just going to voice my objection to the
"accumulated wait time o
On 2/26/13 9:18 PM, Greg Smith wrote:
$ otool -L `which initdb`
/Users/gsmith/pgwork/inst/latest/bin/initdb:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 159.1.0)
Two last bits of trivia and I'll stop talking to myself. You can get
the full list of things this
I have solved my problem after chasing down some library trivia. It's
the fault of my own shell script, but the cause/effect was surprising to
me. I'll go through some troubleshooting library flow on OS X
documentation below since this was new to me and I wrote down notes.
Maybe this will be
On 2/26/13 6:57 PM, Mark Kirkwood wrote:
This might be a red herring - but I recall having problems using
--enable-depend on older OSX versions (10.5 I think), so *maybe* worth
seeing if leaving that option off and doing a distclean+rebuild changes
anything.
I toggled off both that and not expl
On 26 February 2013 22:16, Greg Smith wrote:
> Here's what I get on the latest repo:
>
> $ psql --version
> psql (PostgreSQL) 9.3devel
> $ initdb --help
> The files belonging to this database system will be owned by user "gsmith".
> This user must also own the server process.
> The database cluste
Greg Smith writes:
> On 2/26/13 6:01 PM, Tom Lane wrote:
>> Greg Smith writes:
>>> $ initdb --help
>>> The files belonging to this database system will be owned by user "gsmith".
>> Hm. Works as expected for me. What platform is this exactly?
> The broken one is OS X Lion 10.7.5, main build t
On 27/02/13 12:41, Greg Smith wrote:
On 2/26/13 5:51 PM, Mark Kirkwood wrote:
So looks like something odd you are doing - are you using any unusual
build options?
The unusual part looks to be the build environment or libraries of this
Mac I'm trying to use. The build options are the normal bo
On 2/26/13 5:51 PM, Mark Kirkwood wrote:
So looks like something odd you are doing - are you using any unusual
build options?
The unusual part looks to be the build environment or libraries of this
Mac I'm trying to use. The build options are the normal boring set:
CONFIGURE = '--prefix=/Us
On Feb 26, 2013, at 3:07 PM, Jan Dubois wrote:
>> Hello ActiveStaters,
>
> The commonly used term is actually Activator. :)
Got it!
> Yes, that is one reason. We then need to apply several patches to build
> things correctly though (to statically link the client libs, deal with
> missing SIGA
Greg Smith writes:
> $ initdb --help
> The files belonging to this database system will be owned by user "gsmith".
Hm. Works as expected for me. What platform is this exactly?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
I looked into the problem described here:
http://www.postgresql.org/message-id/5125087d.8090...@deriva.de
The core of the problem is that plperl's plperl_spi_prepare() sets up
input conversion functions for the parameters of a prepared query
using perm_fmgr_info(), which allocates FmgrInfo structs
Hello ActiveStaters,
I see that the DBD::Pg build always fails:
http://code.activestate.com/ppm/DBD-Pg/
I'm sure this is because PostgreSQL is not installed on any of the PPM build
boxes (smokers?). DBD::mysql, on the other hand, builds fine (most of the time):
http://code.activestate.com/
On 2/26/13 11:19 AM, Robert Haas wrote:
On Mon, Feb 25, 2013 at 10:22 PM, Greg Stark wrote:
On Mon, Feb 25, 2013 at 8:26 PM, Robert Haas wrote:
On Sun, Feb 24, 2013 at 7:27 PM, Jim Nasby wrote:
We actually do that in our application and have discovered that random
sampling can end up signif
Hmm - just did a pull now:
$ initdb --version
initdb (PostgreSQL) 9.3devel
$ initdb --help
initdb initializes a PostgreSQL database cluster.
Usage:
initdb [OPTION]... [DATADIR]
...[snipped rest of help output]
So looks like something odd you are doing - are you using any unusual
build option
> FWIW, I share Peter's poor opinion of this syntax. I can see the
> appeal of not having to write an explicit check of the rowcount
> afterwards, but that appeal is greatly weakened by the strange syntax.
> (IOW, if you were counting me as a + vote, that was only a vote for
> the concept --- on
Here's a happy initdb on 9.1 providing help:
$ psql --version
psql (PostgreSQL) 9.1.8
$ /usr/pgsql-9.1/bin/initdb --help
initdb initializes a PostgreSQL database cluster.
Usage:
initdb [OPTION]... [DATADIR] ...
Here's what I get on the latest repo:
$ psql --version
psql (PostgreSQL) 9.3devel
"Marko Tiikkaja" writes:
> If I'm counting correctly, we have four votes for this patch and two votes
> against it.
> Any other opinions?
FWIW, I share Peter's poor opinion of this syntax. I can see the
appeal of not having to write an explicit check of the rowcount
afterwards, but that appea
Hi,
If I'm counting correctly, we have four votes for this patch and two votes
against it.
Any other opinions?
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hacke
On Wed, Feb 13, 2013 at 06:45:31AM -0800, David Fetter wrote:
> On Sat, Feb 09, 2013 at 11:59:22PM -0800, David Fetter wrote:
> > Folks,
> >
> > Per suggestions and lots of help from Andrew Gierth, please find
> > attached a patch to clean up the call sites for FuncCall nodes, which
> > I'd like t
Andres Freund writes:
> On 2013-02-25 18:15:48 -0500, Peter Eisentraut wrote:
>> compat.c: In function âtimestamptz_to_strâ:
>> compat.c:56:9: error: passing argument 1 of âlocaltimeâ from
>> incompatible pointer type [-Werror]
>> In file included from compat.c:21:0:
>> /usr/include/time.
Andres Freund writes:
> On 2013-02-26 13:57:46 +0100, Andres Freund wrote:
>> On 2013-02-25 11:50:46 +0100, Bernd Helmle wrote:
>>> Looks like the recent refactoring of code into common/ stopped
>>> PGXS builds within the PostgreSQL source tree from working, i get
>>> /Users/bernd/pgsql-dev/instal
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Dunno, I think that's going to result in a very large chunk of mostly
> duplicative code in psql. regprocedurein() is fairly short because it
> can rely on a ton of code from the parser, but psql won't have that
> luxury.
Parsing/tokenizing a CSV string in
Stephen Frost writes:
> * Andrew Dunstan (and...@dunslane.net) wrote:
>> If we're going to mess with this area can I put in a plea to get \ef
>> and \sf to handle full parameter specs? I want to be able to c&p
>> from the \df output to see the function. But here's what happens:
> I was thinking a
* Andrew Dunstan (and...@dunslane.net) wrote:
> If we're going to mess with this area can I put in a plea to get \ef
> and \sf to handle full parameter specs? I want to be able to c&p
> from the \df output to see the function. But here's what happens:
I was thinking along the same lines. This wil
On 02/26/2013 02:12 PM, Tom Lane wrote:
Stephen Frost writes:
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
Minimally \ef needs exact specification - you cannot to edit more
functions in same time. So we have to be able identify if there are no
selected function or if there are more functi
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Well, actually I think Pavel's got a point. What about overloaded
> functions? In \df we don't try to solve that problem, we just print
> them all:
To be honest, I was reading through that code the other night and could
have sworn that I saw us doing some
Folks,
Is there any way this particular issue could cause data corruption
without causing a crash? I don't see a way for it to do so, but I
wanted to verify.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Stephen Frost writes:
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> Minimally \ef needs exact specification - you cannot to edit more
>> functions in same time. So we have to be able identify if there are no
>> selected function or if there are more functions. We can write a
>> auxiliary f
On 22.02.2013 12:43, Etsuro Fujita wrote:
1. "Broken pipe" is not handled in case of psql "\copy" command;
Issue are as follows:
Following are verified on SuSE-Linux 10.2.
1) psql is exiting when "\COPY xxx TO" command is issued
and
command/script is not found
Fujii Masao writes:
> In HEAD, when I ran "pg_basebackup -D hoge -X stream",
> I got the following FailedAssertion error:
> TRAP: FailedAssertion("!((wakeEvents & ((1 << 1) | (1 << 2))) != (1 <<
> 2))", File: "pg_latch.c", Line: 234)
> This error happens after the commit 0b6329130e8e4576e97ff763
Hi,
In HEAD, when I ran "pg_basebackup -D hoge -X stream",
I got the following FailedAssertion error:
TRAP: FailedAssertion("!((wakeEvents & ((1 << 1) | (1 << 2))) != (1 <<
2))", File: "pg_latch.c", Line: 234)
This error happens after the commit 0b6329130e8e4576e97ff763f0e773347e1a88af.
This as
On Tue, Feb 26, 2013 at 12:02 PM, Peter Eisentraut wrote:
> On 2/26/13 11:45 AM, Tom Lane wrote:
>> But let's not break the cases that do work. One
>> of the functions of contrib/ is to serve as models/skeletons for
>> external modules. If we pull out the "useless" PGXS support then we'll
>> jus
On 26.02.2013 18:58, Michael Meskes wrote:
On Tue, Feb 26, 2013 at 05:13:38PM +0200, Heikki Linnakangas wrote:
Any particular reason for ecpg to check that, while the backend
doesn't care? I think we should just remove those checks from the
ecpg grammar.
IIRC this check was added because the c
On 26 February 2013 17:02, Peter Eisentraut wrote:
> Well, this is exactly the problem. Because of this skeleton idea, most
> external extension modules do not build unless you set USE_PGXS=1 before
> building, because they think that they live in contrib by default, which
> is completely bizarre
On Tue, Feb 26, 2013 at 11:50 AM, Heikki Linnakangas
wrote:
> Yeah, I'd guess that it was an oversight. But it goes back all the way to
> Postgres95, so it's a bit too late to change that.
I don't see why. We've plugged holes like this before and will do so
again in the future, I'm sure.
--
Ro
On Mon, Feb 25, 2013 at 10:22 PM, Greg Stark wrote:
> On Mon, Feb 25, 2013 at 8:26 PM, Robert Haas wrote:
>> On Sun, Feb 24, 2013 at 7:27 PM, Jim Nasby wrote:
>>> We actually do that in our application and have discovered that random
>>> sampling can end up significantly skewing your data.
>>
>>
On 2/26/13 11:45 AM, Tom Lane wrote:
> But let's not break the cases that do work. One
> of the functions of contrib/ is to serve as models/skeletons for
> external modules. If we pull out the "useless" PGXS support then we'll
> just be making it that much harder to copy a contrib module and star
On Tue, Feb 26, 2013 at 05:13:38PM +0200, Heikki Linnakangas wrote:
> COPY foo FROM STDOUT
> COPY foo TO STDIN
Does this make sense?
> Any particular reason for ecpg to check that, while the backend
> doesn't care? I think we should just remove those checks from the
> ecpg grammar.
IIRC this che
On 26.02.2013 18:40, Tom Lane wrote:
Heikki Linnakangas writes:
On 26.02.2013 18:23, Tom Lane wrote:
(I assume
the backend will bounce the other cases at some post-grammar stage.)
No. All four combinations of FROM/TO and STDIN/STDOUT are accepted:
Huh. That seems like an odd decision. I
Andres Freund writes:
> Wait what? So I need to make install before I can compile extensions?
> That doesn't seem to be something realistic.
You know, any extension that's not in our source tree out there is
maintained in a way to target all supported versions of PostgreSQL from
the same sources.
On Tue, Feb 26, 2013 at 4:34 PM, Heikki Linnakangas
wrote:
> No. All four combinations of FROM/TO and STDIN/STDOUT are accepted:
...
> postgres=# copy foo to stdin;
> foo
> bar
> postgres=# copy foo to stdout;
> foo
> bar
Hm, so STDIN/STDOUT are just noise words and psql uses stdin for input
and
Andres Freund writes:
> Well, it is broken for xlogdump because it needs a sourcetree arround.
> All I personally really want to do is to replace the usual stanza for
> pg_xlogdump with something like:
> ifdef USE_PGXS
> $(error Building pg_xlogdump with PGXS is not supported)
> else
> ...
Seem
On 2013-02-26 11:33:48 -0500, Tom Lane wrote:
> [ Sigh... ] Why this eagerness to fix what isn't broken?
Well, it is broken for xlogdump because it needs a sourcetree arround.
All I personally really want to do is to replace the usual stanza for
pg_xlogdump with something like:
ifdef USE_PGXS
$
Heikki Linnakangas writes:
> On 26.02.2013 18:23, Tom Lane wrote:
>> (I assume
>> the backend will bounce the other cases at some post-grammar stage.)
> No. All four combinations of FROM/TO and STDIN/STDOUT are accepted:
Huh. That seems like an odd decision. If we agree that that behavior
is d
On 2013-02-26 17:23:01 +0100, Dimitri Fontaine wrote:
> Peter Eisentraut writes:
> > I for one wonder why we even have PGXS support in contrib at all. It's
> > not documented or tested anywhere, so it might as well not exist.
Agreed. I personally think we just should build contrib/ as part of th
Tom Lane writes:
> work today --- in particular, this proposal will break building contrib
> before the main tree has been installed.
True that.
> If somebody wants to set up a buildfarm member that occasionally tests
> PGXS building of contrib/, that's fine with me. But it isn't, and never
> w
On Wed, Feb 27, 2013 at 1:25 AM, Andres Freund wrote:
> Hi,
>
> On 2013-02-27 00:34:54 +0900, Fujii Masao wrote:
>> Hi,
>>
>> When I compiled pg_xlogdump in HEAD, I got the following error.
>>
>> make: *** No rule to make target `rmgrdesc.o', needed by `pg_xlogdump'.
>> Stop.
>>
>> $ uname -a
>>
On 26.02.2013 18:23, Tom Lane wrote:
Heikki Linnakangas writes:
While looking at Fujita Etsuro's patch to allow copy to/from a shell
command, I noticed that the grammar currently allows these:
COPY foo FROM STDOUT
COPY foo TO STDIN
In other words, STDIN and STDOUT can be used completely i
Dimitri Fontaine writes:
> Peter Eisentraut writes:
>> I for one wonder why we even have PGXS support in contrib at all. It's
>> not documented or tested anywhere, so it might as well not exist.
> I think I did about the same comment back when cooking the extension
> patch, and the answer then
Hi,
On 2013-02-27 00:34:54 +0900, Fujii Masao wrote:
> Hi,
>
> When I compiled pg_xlogdump in HEAD, I got the following error.
>
> make: *** No rule to make target `rmgrdesc.o', needed by `pg_xlogdump'. Stop.
>
> $ uname -a
> Darwin hrk.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23
> 1
Heikki Linnakangas writes:
> While looking at Fujita Etsuro's patch to allow copy to/from a shell
> command, I noticed that the grammar currently allows these:
> COPY foo FROM STDOUT
> COPY foo TO STDIN
> In other words, STDIN and STDOUT can be used completely interchangeably.
> However, the e
Peter Eisentraut writes:
> I for one wonder why we even have PGXS support in contrib at all. It's
> not documented or tested anywhere, so it might as well not exist.
I think I did about the same comment back when cooking the extension
patch, and the answer then was all about providing PGXS usage
Hi,
When I compiled pg_xlogdump in HEAD, I got the following error.
make: *** No rule to make target `rmgrdesc.o', needed by `pg_xlogdump'. Stop.
$ uname -a
Darwin hrk.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23
16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64
Regards,
While looking at Fujita Etsuro's patch to allow copy to/from a shell
command, I noticed that the grammar currently allows these:
COPY foo FROM STDOUT
COPY foo TO STDIN
In other words, STDIN and STDOUT can be used completely interchangeably.
However, the ecpg grammar is more strict about that:
On 2013-02-26 13:57:46 +0100, Andres Freund wrote:
> On 2013-02-25 11:50:46 +0100, Bernd Helmle wrote:
> > Looks like the recent refactoring of code into common/ stopped
> > PGXS builds within the PostgreSQL source tree from working, i get
> >
> > /Users/bernd/pgsql-dev/install/HEAD/include/server
On 2013-02-25 11:50:46 +0100, Bernd Helmle wrote:
> Looks like the recent refactoring of code into common/ stopped
> PGXS builds within the PostgreSQL source tree from working, i get
>
> /Users/bernd/pgsql-dev/install/HEAD/include/server/postgres_fe.h:27:32:
> fatal error: common/fe_memutils.h: No
Hi,
On 2013-02-25 18:15:48 -0500, Peter Eisentraut wrote:
> compat.c: In function ‘timestamptz_to_str’:
> compat.c:56:9: error: passing argument 1 of ‘localtime’ from incompatible
> pointer type [-Werror]
> In file included from compat.c:21:0:
> /usr/include/time.h:237:19: note: expected ‘const t
On 2013-02-25 21:13:25 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I propose loosening those restrictions to
> > a) allow repeatedly qualified names like a.b.c
>
> If SET allows it, I guess we can allow it here. But is a grammar change
> really all that is needed to make it work from the
On Tuesday, February 26, 2013 1:36 PM Heikki Linnakangas wrote:
> On 26.02.2013 09:06, Amit Kapila wrote:
> > On Monday, February 25, 2013 11:26 PM Heikki Linnakangas wrote:
> >> On 21.02.2013 16:09, Amit Kapila wrote:
> >>> On Thursday, February 21, 2013 12:46 AM Heikki Linnakangas wrote:
> >> I'v
Hello all, I tried to use GIST_LEAF() macro in union and penalty methods of
GiST and it fails with a terrible error when I run "CREATE INDEX" (in windows
postgresql daemon shuts down). On the other hand, GIST_LEAF() works as expected
in consistent, distance, and picksplit methods. My leaf nodes
On 26.02.2013 09:06, Amit Kapila wrote:
On Monday, February 25, 2013 11:26 PM Heikki Linnakangas wrote:
On 21.02.2013 16:09, Amit Kapila wrote:
On Thursday, February 21, 2013 12:46 AM Heikki Linnakangas wrote:
I've committed those patches, with some further changes. If you have
the
time, pleas
63 matches
Mail list logo
