Hello,
initdb using the latest HEAD (9.4dev) fails with:
[amit@centos64vm postgresql]$ initdb -D ~/dev/pgdata/
The files belonging to this database system will be owned by user amit.
This user must also own the server process.
The database cluster will be initialized with locale en_US.utf8.
The
Build using:
CFLAGS=-g -O0 ./configure --with-pam --enable-cassert --enable-debug
--prefix=/home/amit/dev/pginstall/
--
Amit Langote
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Aug 1, 2013 at 3:52 PM, Amit Langote amitlangot...@gmail.com wrote:
Build using:
CFLAGS=-g -O0 ./configure --with-pam --enable-cassert --enable-debug
--prefix=/home/amit/dev/pginstall/
--
Amit Langote
Umm, I guess I forgot to make clean before building with the latest
HEAD. Now, I
On 31.05.2012 08:06, Erik Rijkers wrote:
On Thu, May 31, 2012 03:30, Robert Haas wrote:
On Wed, May 30, 2012 at 6:00 PM, Erik Rijkerse...@xs4all.nl wrote:
directory
2012-05-30 23:40:57.909 CEST 3909 CONTEXT: writing block 5152 of relation
base/21268/26569
xlog redo multi-insert
On Thu, May 31, 2012 at 1:06 AM, Erik Rijkers e...@xs4all.nl wrote:
In my test, I run the bash code (the bits that I posted earlier) in a while
loop so that the table
is CREATEd, COPYied into, and DROPped every few seconds -- perhaps that
wasn't clear. That loop
is necessary; a few
On 31 May 2012 12:14, Robert Haas robertmh...@gmail.com wrote:
On Thu, May 31, 2012 at 1:06 AM, Erik Rijkers e...@xs4all.nl wrote:
In my test, I run the bash code (the bits that I posted earlier) in a while
loop so that the table
is CREATEd, COPYied into, and DROPped every few seconds --
On Thu, May 31, 2012 13:14, Robert Haas wrote:
On Thu, May 31, 2012 at 1:06 AM, Erik Rijkers e...@xs4all.nl wrote:
In my test, I run the bash code (the bits that I posted earlier) in a while
loop so that the
table
is CREATEd, COPYied into, and DROPped every few seconds -- perhaps that
On Thu, May 31, 2012 at 7:49 AM, Erik Rijkers e...@xs4all.nl wrote:
On Thu, May 31, 2012 13:14, Robert Haas wrote:
On Thu, May 31, 2012 at 1:06 AM, Erik Rijkers e...@xs4all.nl wrote:
In my test, I run the bash code (the bits that I posted earlier) in a while
loop so that the
table
is
Robert Haas robertmh...@gmail.com writes:
The one thing that still seems a little odd to me is that this caused
a pin count to get orphaned. It seems reasonable that ignoring the
AccessExclusiveLock could result in not-found errors trying to open a
missing relation, and even fsync requests on
On Thu, May 31, 2012 at 9:51 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
The one thing that still seems a little odd to me is that this caused
a pin count to get orphaned. It seems reasonable that ignoring the
AccessExclusiveLock could result in not-found
On 26.05.2012 12:21, Erik Rijkers wrote:
But when that if-block is added the client crashes after a while (sometimes
almost immediately; it
never survives longer then 20 minutes):
2012-05-26 10:44:22.617 CEST 10274 ERROR: could not fsync file
base/21268/32807: No such file
or directory
On Wed, May 30, 2012 at 1:07 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
There's something wrong with the way AccessExclusiveLocks work on a standby.
I did begin; truncate foo; -- leave the xact open in the master, and
waited until the xlog records are shipped to the
On Wed, May 30, 2012 at 1:47 PM, Robert Haas robertmh...@gmail.com wrote:
The process holding the AccessExclusiveLock is the startup process. It's
holding the lock on behalf of the transaction in the master. But something's
wrong, and the AccessExclusiveLock doesn't stop a regular backend from
On Wed, May 30, 2012 at 2:52 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, May 30, 2012 at 1:47 PM, Robert Haas robertmh...@gmail.com wrote:
The process holding the AccessExclusiveLock is the startup process. It's
holding the lock on behalf of the transaction in the master. But
On Wed, May 30, 2012 22:25, Robert Haas wrote:
On Wed, May 30, 2012 at 2:52 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, May 30, 2012 at 1:47 PM, Robert Haas robertmh...@gmail.com wrote:
The process holding the AccessExclusiveLock is the startup process. It's
holding the lock on behalf
On Wed, May 30, 2012 at 6:00 PM, Erik Rijkers e...@xs4all.nl wrote:
(I double-checked that I got your latest commit in)
I'm afraid it's not yet resolved; the sync-slave still crashes almost
immediately:
master logfile says:
2012-05-30 23:30:07.846 CEST 3918 LOG: standby wal_receiver_01 is
On Thu, May 31, 2012 03:30, Robert Haas wrote:
On Wed, May 30, 2012 at 6:00 PM, Erik Rijkers e...@xs4all.nl wrote:
directory
2012-05-30 23:40:57.909 CEST 3909 CONTEXT: writing block 5152 of relation
base/21268/26569
xlog redo multi-insert (init): rel 1663/21268/26581; blk 3852; 35
pg 9.2 git master
AMD 8120 (8-core) / 6 GB memory / Centos 6.2
I have experimented a bit with dropping a table from master, then querying that
table from a
sync-rep slave. It is a little worrying that this, the first test I tried,
crashes the slave.
There are two instance on one machine,
Hi together,
I'm currently debugging my developed AM and are running into this problem:
TRAP: FailedAssertion(!(((bool) (((void*)(tid) != ((void *)0))
((tid)-ip_posid != 0, File: indexam.c, Line: 488)
Can anybody explain what it means? I'm having difficulties to understand
what went wrong.
[ Forgot the list. ]
2011/5/12, Yves Weißig weis...@rbg.informatik.tu-darmstadt.de:
I'm currently debugging my developed AM and are running into this problem:
TRAP: FailedAssertion(!(((bool) (((void*)(tid) != ((void *)0))
((tid)-ip_posid != 0, File: indexam.c, Line: 488)
Can anybody
Hello -hackers,
I've found a bug with 8.2beta1:
1) Log message:
LOG: duration: 9.144 ms bind unnamed: UPDATE table_list SET description
= $1 WHERE id = cas_get_table_id ( $2,$3 )
DETAIL: parameters: $1 = '\tag{image SRC=/vizier/new2.gif}3rd release of
DENIS (2005Sep)', $2 =
Sergey E. Koposov [EMAIL PROTECTED] writes:
I've found a bug with 8.2beta1:
Can you put together a self-contained test case for this? The planner
is evidently generating an incorrect plan from that messy view, but
trying to reverse-engineer the complete scenario from what you've told
us looks
On Sat, 7 Oct 2006, Tom Lane wrote:
Sergey E. Koposov [EMAIL PROTECTED] writes:
I've found a bug with 8.2beta1:
Can you put together a self-contained test case for this? The planner
I'll try, but it will be quite hard.
is evidently generating an incorrect plan from that messy view, but
On Sat, 7 Oct 2006, Sergey E. Koposov wrote:
cas=# explain UPDATE table_list SET description = 'tag{image
SRC=/vizier/new2.gif}3rd release of DENIS (2005Sep)' WHERE id =
cas_get_table_id ('cas_data_sega','b_denis_denis5' );
QUERY PLAN
Sergey E. Koposov [EMAIL PROTECTED] writes:
Will it be enough to provide the testcase for just that 'expain UPDATE' ?
Whatever makes it crash ;-)
My guess is that there's some rewriter interaction involved, which means
that the rule itself is part of the problem --- you'll likely not be
able to
On Sat, 7 Oct 2006, Tom Lane wrote:
Sergey E. Koposov [EMAIL PROTECTED] writes:
Will it be enough to provide the testcase for just that 'expain UPDATE' ?
Whatever makes it crash ;-)
So, the database schema with little data and a few functions is here
On Sat, 7 Oct 2006, Sergey E. Koposov wrote:
And the java program crashing the backend is attached. (it is generally
one prepared statement , which i didn't succeded to crash from psql) (it's
possible to rewrite it in C with libpq, but I cannot do that very easily).
As I did before, I send
Tom Lane [EMAIL PROTECTED] writes:
Sergey E. Koposov [EMAIL PROTECTED] writes:
I've found a bug with 8.2beta1:
Can you put together a self-contained test case for this? The planner
is evidently generating an incorrect plan from that messy view, but
trying to reverse-engineer the complete
Sergey E. Koposov [EMAIL PROTECTED] writes:
As I did before, I send the strace ouput showing what jdbc is sending to the
backend.
Thanks. I've been able to reproduce it now, and I think the plan is
actually OK, but for some reason the wrong rtable list is getting sent
along to the executor.
Sergey E. Koposov [EMAIL PROTECTED] writes:
And the java program crashing the backend is attached. (it is generally
one prepared statement , which i didn't succeded to crash from psql)
Right, because the bug was in exec_bind_message, which you can't invoke
from psql :-(. Fixed, but we really
On Sat, 7 Oct 2006, Tom Lane wrote:
Sergey E. Koposov [EMAIL PROTECTED] writes:
And the java program crashing the backend is attached. (it is generally
one prepared statement , which i didn't succeded to crash from psql)
Right, because the bug was in exec_bind_message, which you can't invoke
31 matches
Mail list logo
