On Thu, May 16, 2013 at 4:34 PM, hubert depesz lubaczewski
wrote:
> =$ pg_ctl -D $( pwd ) -m fast restart
> waiting for server to shut down done
> server stopped
> server starting
> postgres cannot access the server configuration file
> "/home/test/test/slave/test/slave/postgresql.conf": No
On Thu, May 16, 2013 at 3:33 PM, Josh Kupershmidt wrote:
> Backtrace looks like this:
My mistake -- the last backtrace was from an idle client before the
crash. Thank you andres and wulczer for the correction. Here is the
interesting one:
(gdb) bt
#0 has_unnamed_full_join_using (jtnode=0x0)
I am pretty sure this is an easily-reproducible crash on git head
(well, as of a2a480af889b5), helpfully confirmed on IRC by wulczer and
deko. I reproduced the crash myself on OS X and 64-bit Debian.
---
create table foo (a int);
CREATE RULE notify_foo_updates AS ON UPDATE TO foo DO NOTIFY foo;
\d
On Wed, Mar 13, 2013 at 4:01 AM, wrote:
> Hi,
> I'm using PostgreSQL 9.0.1 and driver PostgreSQL 9.0 JDBC4 and my OS
> is Ubuntu.I'm using serial type for auto-incrementing column id in my table
> everything works fine .when i stop my application and restart the
> application its fine but
[Moving to -hackers]
On Sat, Feb 23, 2013 at 2:51 PM, Pavel Stehule wrote:
> so
>
> * --conditional-drops replaced by --if-exists
Thanks for the fixes, I played around with the patch a bit. I was sort
of expecting this example to work (after setting up the regression
database with `make install
On Tue, Feb 19, 2013 at 6:00 AM, Pavel Stehule wrote:
> 2013/2/16 Pavel Stehule :
>> 2013/2/16 Tom Lane :
>>> I think it has come up before. I wouldn't object to a pg_dump option to
>>> add IF EXISTS to all the drop commands (though changing the default
>>> behavior would be more controversial).
On Wed, Jan 23, 2013 at 6:21 AM, Ben Morgan wrote:
> Given this, when using the psql command \d, I expect to see all the tables,
> and the view as well as the table. But instead the objects in the front-most
> schema mask the other objects.
>
> I'm submitting this as a bug, because it seems to be
On Sat, Oct 13, 2012 at 3:56 PM, Thom Brown wrote:
> I have noticed that, using pg_ctl, if you start Postgres using a
> relative path, then attempt to restart it from anywhere else, it
> fails.
Yeah, I was complaining about the same problem here:
http://archives.postgresql.org/pgsql-bugs/2011-
On Tue, Jul 3, 2012 at 11:41 PM, Tom Lane wrote:
> j...@well.com writes:
>> When I do
>> \ir ../bar.sql
>> I get the bar.sql file in the CWD.
>
> AFAICS, it works fine when \ir is used interactively. However,
> you seem to be using it from a script:
>
>> $ psql -aX greg -f foo.sql
>
> and then in
Hi all,
I noticed that configuring Postgres with a BLCKSZ smaller than default
was causing 'make check' give an interesting error on git head. You
should be able to see this with a simple:
./configure --enable-debug --enable-cassert --with-blocksize=4 &&
make check
which, among a few other s
On Thu, Jun 14, 2012 at 1:34 PM, Ryan Kelly wrote:
> On Wed, Jun 13, 2012 at 07:17:11PM +, phb.e...@free.fr wrote:
>> paf=# \db
>>
>> ERROR: column "spclocation" does not exist
>>
>> LINE 3: spclocation AS "Location"
>>
>> ^
>>
> Are you using the psql provided by 9.2 beta 2? Or
On Sat, Jun 9, 2012 at 2:40 AM, Dean Rasheed wrote:
> I noticed this while testing 9.2, but it seems to go back to at least
> 8.3. Tab completion of function arguments doesn't work if the function
> is schema-qualified or double-quoted. So for example,
Good idea, would you like to submit for the
On Fri, Jun 1, 2012 at 4:23 PM, Anna Zaks wrote:
> I opened an analyzer Bugzilla report for this issue in case you 'd
> like to follow up there:
> http://llvm.org/bugs/show_bug.cgi?id=13010
Thanks, I'll try to schedule another run tonight and post additional
details on that ticket.
On Fri, Jun
On Fri, Jun 1, 2012 at 11:38 AM, Anna Zaks wrote:
> Josh,
>
> What kid of machine are you using? Please, let me know how long it
> took after it's done (It takes about one and a half hours on mine).
It just finished, actually: took about 7 hours to run, not counting
the time the machine was aslee
On Thu, May 31, 2012 at 10:06 PM, Tom Lane wrote:
> zaks.a...@gmail.com writes:
>> There are two memory leaks in dumputils (v9.2.0beta1):
>
>> 1)
>> File: src/bin/scripts/dumputils.c
>> Location: line 604, column 11
>> Description: Memory is never released; potential leak of memory
>>
On Wed, May 2, 2012 at 11:21 AM, Bruce Momjian wrote:
> On Wed, May 02, 2012 at 12:59:58PM +, stu...@stuartbishop.net wrote:
>> # CREATE SEQUENCE "\foo";
>> CREATE SEQUENCE
>> # \ds "\
>
> I am unable to reproduce this failure on my copy of 9.1.3. Have you
> perhaps changed any server setting
On Mon, Apr 23, 2012 at 8:16 AM, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 6609
> Logged by: biju george
> Email address: biju.geo...@ust-global.com
> PostgreSQL version: Unsupported/Unknown
> Operating system: Linux
> Description:
>
> I ha
On Wed, Mar 21, 2012 at 10:12 AM, wrote:
> Operating system: OS X Snow Leopard
> I've installed pg from the www.kyngchaos.com site.
If the problem was caused by that installer, you'll have to contact
them to fix their package. FYI, the Postgres packages for OS X
supported here can be found at
On Fri, Mar 9, 2012 at 8:50 PM, wrote:
> CREATE EXTENSION ltree;
> ERROR: permission denied to create extension "ltree"
> HINT: Must be superuser to create this extension.
>
> Why does ltree require superuser privledge? Is it dangerous and allow
> circumventing server security? No mention of t
On Mon, Jan 2, 2012 at 2:52 AM, wrote:
> This is a documentation bug (or feature request), not a software bug.
For future reference, the pgsql-docs list is probably the best place
for such concerns.
> There seems to be no discussion of transactional DDL in the manual itself
> (that I could fin
[Moving back on-list. Tom generously offered to look at the server in
question, since it seemed likely that a testcase would be difficult or
impossible to reproduce in this case]
On Fri, Dec 2, 2011 at 12:07 AM, Tom Lane wrote:
>
> Well, poking around in the process at the moment of SIGBUS, I fin
On Wed, Nov 30, 2011 at 10:50 PM, Tom Lane wrote:
> Josh Kupershmidt writes:
>> On Wed, Nov 30, 2011 at 9:17 PM, Tom Lane wrote:
> It might be worth recompiling at -O0, first to see if that changes the
> behavior and second to see if it changes the reported stack trace.
Her
On Wed, Nov 30, 2011 at 9:17 PM, Tom Lane wrote:
> Can you try that on 9.1 branch tip to see if it's already fixed?
Hrm, don't think that helped - I get the same error in the logs using
a checkout of branch REL9_1_STABLE.
Josh
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To
Hi all,
I have a new 9.1.1 hot standby machine (VM). It consistently starts
up, goes through recovery through these same WAL segments, and then
gets a "Bus error":
2011-11-30 20:57:37 EST LOG: database system was interrupted while in
recovery at log time 2011-11-30 09:37:11 EST
2011-11-30 20:57:
On Sat, Nov 19, 2011 at 12:34 AM, Michael Smolsky
> Now waiting for 9.2 package to ship for Ubuntu...
Oh - 9.2 won't be released for a while; I tested on a recent git
checkout of the main branch.
It's possible that the next 9.1 point release (9.1.2) would contain
this fix, but I haven't verified
On Fri, Nov 18, 2011 at 4:53 PM, Michael Smolsky wrote:
> Could you please also confirm that variable expansion works correctly for
> psql's \i command as well?
>
> Test case (type on psql client prompt):
>
> \set my_dir /some/path/to/sql/script/dir
> \i :my_dir/my-script.sql
>
> I expect the pars
On Fri, Nov 18, 2011 at 1:12 PM, M wrote:
>
> When psql expands a :variable into a string it appends a space to the
> expansion string. For example:
>
> psql (8.4.9)
> Type "help" for help.
>
> testdb=> \set my_home /home/crazy
> testdb=> \echo :my_home/my-script.sql
> /home/crazy /my-script.sql
>
On Sat, Oct 22, 2011 at 12:13 PM, Tom Lane wrote:
> I think the reason it has a problem is that this is what's left in
> postmaster.opts:
>
> /home/tgl/pgsql/bin/postgres "-D" "baz"
>
> (which is an accurate representation of the command line from startup)
> and that -D switch gets fed to the post
I've noticed that I occasionally see errors from "pg_ctl restart" claiming:
postgres cannot access the server configuration file ... No such
file or directory
depending on what directory I execute "pg_ctl restart" from, and where
the postmaster was originally started from. I boiled this problem
On Wed, Sep 28, 2011 at 10:51 AM, Alvaro Herrera
wrote:
> Excerpts from depstein's message of mié sep 28 07:21:17 -0300 2011:
>> Anyway, the procedure that we used (based on
>> http://en.dklab.ru/lib/dklab_postgresql_enum/) does the necessary
>> checks before removing enum values.
Not exactly; th
On Mon, Aug 15, 2011 at 11:31 PM, Kyle Fox wrote:
> I used the installer to install Postgres 9.0 on my Mac, and now every 10
> seconds a dialog message flashes and immediately disappears, and STEALS
> FOCUS.
The focus-stealing sounds like a problem coming from the EDB installer
you said you used
[Moving to -docs]
On Mon, May 2, 2011 at 12:00 PM, Pavel Stehule wrote:
> Hello
>
> one czech user reported a bug in documentation -
> http://www.postgresql.org/docs/8.4/static/plpgsql-trigger.html
>
> NEW
>
> Data type RECORD; variable holding the new database row for
> INSERT/UPDATE operatio
On Wed, Mar 9, 2011 at 9:04 AM, sandyt wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5921
> Logged by: sandyt
> Email address: sa...@mcw.co.il
> PostgreSQL version: 8.3.8
> Operating system: windows 2008 server (64 bit)
> Description: pg_dump a
[moving to pgsql-docs]
On Wed, Jan 5, 2011 at 8:04 AM, Antje Petersen wrote:
> According to the documentation
> createuser --no-superuser and
> createuser --no-createrole is the default.
> This is not true. The default is to be asked
> Shall the new role be a superuser? (y/n)
> Shall the new role
On Thu, Oct 28, 2010 at 8:03 PM, Jeff Davis wrote:
> I don't really see a "bug" here. Is this causing you some kind of
> problem?
I happened to notice it while fixing up some code using multi-line
strings which had forgotten to put spaces in the SQL across lines. I
was just surprised Postgres did
On Thu, Oct 28, 2010 at 8:01 PM, Tom Lane wrote:
> "Josh Kupershmidt" writes:
>> I noticed that Postgres in many cases will happily tokenize WHERE clauses
>> having no space between a condition and "AND" or "OR".
>
> This has nothing to do w
The following bug has been logged online:
Bug reference: 5732
Logged by: Josh Kupershmidt
Email address: schmi...@gmail.com
PostgreSQL version: 8.3 and HEAD
Operating system: Linux and OS X
Description:parsing of: "WHERE mycol=123AND ..."
Details:
I no
37 matches
Mail list logo
