On 01/10/13 15:17, h...@canwrx.com wrote:
a) My version is Postgres Enterprise Manager version 3.0.0, copyright
2002-2012, the pgAdmin Development Team; and Postgres Plus Advanced Server
9.2
Hi - your product is supported by Enterprisedb
(http://www.enterprisedb.com/). I think you would
On 02/08/13 09:47, Mark Kirkwood wrote:
For the archives, looks like that was the issue, users need to be a
member of a certain group (gid 303) to use sockets (which is exactly
what Alvaro suspected).
Make that gid 3003, sorry.
--
Sent via pgsql-bugs mailing list (pgsql-bugs
On 01/08/13 22:13, f...@libero.it wrote:
Da: mark.kirkw...@catalyst.net.nz
See http://android-dls.com/wiki/index.php?title=Debian_on_G1 near the
bottom they discuss this issue.
Cheers
Mark
Thanks very very much: problem solved, postgresql, apache2, php5 ported on a
50$
small android table w
On 01/08/13 11:08, Mark Kirkwood wrote:
On 01/08/13 10:08, Josh Berkus wrote:
To wit:
[jberkus@pgx-test prepare]$ pgbench -c 4 -C -T 180 -l -r -M prepared
bench
starting vacuum...end.
Client 1 aborted in state 7: ERROR: prepared statement "P0_7" does not
exist
Client 0 aborted
On 01/08/13 10:08, Josh Berkus wrote:
To wit:
[jberkus@pgx-test prepare]$ pgbench -c 4 -C -T 180 -l -r -M prepared bench
starting vacuum...end.
Client 1 aborted in state 7: ERROR: prepared statement "P0_7" does not
exist
Client 0 aborted in state 7: ERROR: prepared statement "P0_7" does not
e
On 01/08/13 09:13, f...@libero.it wrote:
problem:
LOG: could not create IPv6 socket: Permission denied
LOG: could not create IPv4 socket: Permission denied
WARNING: could not create listen socket for "localhost"
FATAL: could not create any TCP/IP sockets
See http://android-dls.com/
On 03/04/13 08:44, dben...@whitepages.com wrote:
The following bug has been logged on the website:
Bug reference: 8034
Logged by: Devin Ben-Hur
Email address: dben...@whitepages.com
PostgreSQL version: 9.2.3
Operating system: Ubuntu Precise
Description:
When a very large sh
Do you have any non default procedural languages installed? I provoked
exactly that error with a similar script which used a PL/R procedure
(see BUGS thread "PL/R Median Busts Commit"...the cause is signal
hi-jacking in that case).
Regards
Mark
On 09/03/13 13:27, Josh Berkus wrote:
Folks,
On 29/01/13 10:29, Mark Kirkwood wrote:
On 25/01/13 13:56, Mark Kirkwood wrote:
On 25/01/13 13:49, Tom Lane wrote:
Mark Kirkwood writes:
On 25/01/13 13:06, Tom Lane wrote:
Unless libR can be coerced into not screwing up our signal handlers,
I'd say that PL/R is broken beyond repair.
On 25/01/13 13:56, Mark Kirkwood wrote:
On 25/01/13 13:49, Tom Lane wrote:
Mark Kirkwood writes:
On 25/01/13 13:06, Tom Lane wrote:
Unless libR can be coerced into not screwing up our signal handlers,
I'd say that PL/R is broken beyond repair. That would be unfortunate.
It looks lik
On 25/01/13 13:49, Tom Lane wrote:
Mark Kirkwood writes:
On 25/01/13 13:06, Tom Lane wrote:
Unless libR can be coerced into not screwing up our signal handlers,
I'd say that PL/R is broken beyond repair. That would be unfortunate.
It looks like Joe has run into something similar with
On 25/01/13 13:06, Tom Lane wrote:
Mark Kirkwood writes:
If I have done this right, then this is the trace for the 1st message...
from my wandering through the calls here it looks like a normal commit,
and something goes a bit weird as SI messages are being processed...
Seems like the
On 25/01/13 10:36, Tom Lane wrote:
Mark Kirkwood writes:
Doh! Yes of course, sorry for the noise. I was busy thinking that the
issue could be tied up with sinval and plan caching (if there is any) in
plr and got excited about seeing something in gdb...and didn't think
carefully about why
On 25/01/13 10:18, Tom Lane wrote:
Mark Kirkwood writes:
Sorry - the others are getting a SIGUSR1 too (just was not so obvious).
SIGUSR1 is not a bug, it's expected cross-session signaling behavior.
regards, tom lane
Doh! Yes of course, sorry for the noise.
On 25/01/13 10:12, Mark Kirkwood wrote:
On 25/01/13 04:14, Joe Conway wrote:
On 01/24/2013 05:21 AM, Mark Kirkwood wrote:
I admit - it sounds unlikely. However a simple scenario (attached) gives
rise to:
This is the wrong place for the bug report on PL/R I think, but I'll
take a look.
On 25/01/13 04:14, Joe Conway wrote:
On 01/24/2013 05:21 AM, Mark Kirkwood wrote:
I admit - it sounds unlikely. However a simple scenario (attached) gives
rise to:
This is the wrong place for the bug report on PL/R I think, but I'll
take a look.
Joe
FYI - 8.4 shows the same behavio
Ah right - sorry, I did a quick look for a mail list on the plr web site
and didn't spot anything.
Thanks
Mark
On 25/01/13 04:14, Joe Conway wrote:
On 01/24/2013 05:21 AM, Mark Kirkwood wrote:
I admit - it sounds unlikely. However a simple scenario (attached) gives
rise to:
This i
I admit - it sounds unlikely. However a simple scenario (attached) gives
rise to:
WARNING: AbortTransaction while in COMMIT state
PANIC: cannot abort transaction 880983, it was already committed
Essentially we are doing:
BEGIN;
DROP TABLE IF EXISTS tab0;
CREATE TEMP TABLE tab0 ( id INTEGER P
On 04/10/12 19:06, Simon Riggs wrote:
On 4 October 2012 05:32, Mark Kirkwood wrote:
I am seeing the situation where the reported flush location for the sync
standby (standby1 below) is *behind* the reported current xlog location of
the primary. This is Postgres 9.1.5 , and I was under the
I am seeing the situation where the reported flush location for the sync
standby (standby1 below) is *behind* the reported current xlog location
of the primary. This is Postgres 9.1.5 , and I was under the impression
that transactions initiated on the master do not commit until the
correspondin
On 09/09/12 14:01, Kevin Grittner wrote:
wrote:
The TWO most important factors in hindering us to convert to
Postgres are the following:
Parallel execution of queries.
No Table Partitioning
Not a bug, so off-topic for this list. If you need help figuring
out how best to use PostgreSQL, or
On 27/04/12 13:11, Josh Berkus wrote:
On 4/26/12 5:50 PM, Tom Lane wrote:
Josh Berkus writes:
Summary: despite pg_reload(), log directory, filename and destination
don't change
Looking at the code, it's really hard to see how this could possibly
happen, unless maybe the process is blocking re
On 11/11/11 20:51, Torsten Zuehlsdorff wrote:
So either your statement is wrong or the manual. ;) If there is the
possibility to lose data just because of this kind of
missconfiguration, we should accept Roberts patch.
Greetings,
Torsten
Robert's patch is based on a complete mis-assessmen
On 28/10/11 15:42, Finlay Thompson wrote:
After upgrading the postgresql*-8.4 packages on ubuntu, to version 8.4.9,
the script suddenly stopped working, and consuming all the ram (16GB) on the
computer (i7).
If there is one query exhausting all ram, then it could be tricky to
catch it in the
On 30/09/11 10:08, Dickson S. Guedes wrote:
2011/9/29 Peter Geoghegan:
On 29 September 2011 21:59, Merlin Moncure wrote:
hm -- works for me (9.1.0)
It works for me on REL9_1_STABLE too, unsurprisingly, as I would think
it highly unlikely that such a glaring bug would slip into a stable
releas
On 17/04/11 02:58, Tom Lane wrote:
Greg Stark writes:
The planner uses various heuristics to avoid combinatoric growth
wherever it can but there's no way to completely avoid it.
Yeah. The collapse_limit variables can be seen as another heuristic to
deal with this type of problem: they artific
On 15/04/11 16:35, Mark Kirkwood wrote:
Here's a simplified example using synthetic data (see attached to
generate if desired):
For anyone else who might be want to play with this:
Patch with correction to make the directory reassignment work correctly,
plus an additional comment i
On 16/04/11 04:43, Tom Lane wrote:
Mark Kirkwood writes:
I've recently seen examples of star-like queries using vast amounts of
memory in one of our production systems. Here's a simplified example
using synthetic data (see attached to generate if desired):
SET geqo_threshold
On 16/04/11 01:59, Kevin Grittner wrote:
Mark Kirkwood wrote:
Here's a simplified example using synthetic data (see attached to
generate if desired):
Doesn't work for me:
kgrittn@kgrittn-desktop:~/work/starjoin$ ./gendata.pl
generate cat
cannot open cat.dat: No such file or di
I've recently seen examples of star-like queries using vast amounts of
memory in one of our production systems. Here's a simplified example
using synthetic data (see attached to generate if desired):
SET geqo_threshold = 14;
SET from_collapse_limit = 14;
SET join_collapse_limit = 14;
EXPLAIN
S
On 08/03/11 13:03, Mark Kirkwood wrote:
On 08/03/11 12:55, Mark Kirkwood wrote:
On 23/02/11 10:18, Mark Kirkwood wrote:
On 23/02/11 00:26, Greg Stark wrote:
It's also possible there's a bug of course. If someone was using that
buffer and somehow failed to notify the vacuum that
On 08/03/11 12:55, Mark Kirkwood wrote:
On 23/02/11 10:18, Mark Kirkwood wrote:
On 23/02/11 00:26, Greg Stark wrote:
It's also possible there's a bug of course. If someone was using that
buffer and somehow failed to notify the vacuum that they were done it
would wait for a very
On 23/02/11 10:18, Mark Kirkwood wrote:
On 23/02/11 00:26, Greg Stark wrote:
It's also possible there's a bug of course. If someone was using that
buffer and somehow failed to notify the vacuum that they were done it
would wait for a very long time (forever?). However if vacuum
On 23/02/11 03:27, Robert Haas wrote:
On Tue, Feb 22, 2011 at 6:26 AM, Greg Stark wrote:
Actually it's not waiting for the LockBuffer LWLock. it's waiting
until your query unpins the buffer it wants. Vacuum tries to get an
exclusive lock on the buffer, if it gets it then it checks if anyone
is
On 23/02/11 00:26, Greg Stark wrote:
It's also possible there's a bug of course. If someone was using that
buffer and somehow failed to notify the vacuum that they were done it
would wait for a very long time (forever?). However if vacuum
eventually continued when the query was canceled then it
On 22/02/11 19:47, Heikki Linnakangas wrote:
A long query on the same table can block vacuum. Vacuum needs to take
a so-called "cleanup lock" on each page, which means that it has to
wait until no other backend holds a pin on the page. A long-running
query can keep a page pinned for a long ti
This is 8.3.14 on Debian Lenny x86-64.
I'm seeing a hung vacuum:
postgres=# select procpid, query_start,waiting, current_query from
pg_stat_activity where current_query like '%VACUUM%';
procpid | query_start | waiting
|
current_query
On 04/02/11 15:11, Craig Ringer wrote:
On 02/03/2011 11:15 PM, Matt Zinicola wrote:
I re-compiled with '--enable-debug' and got the symbols. The
pastebin is at
http://pastebin.com/xMhEHFdT
That's really interesting. It's getting a NULL path pointer when - I
think - it tries to determine t
On 29/10/10 10:27, Tom Lane wrote:
Were there similar warnings on the master? Uninitialized-page warnings
are expected in certain error-recovery scenarios, but I'd be a little
worried if the slave appeared to be out of sync with the master.
I don't see any in the
On 29/10/10 04:32, Alvaro Herrera wrote:
Excerpts from Mark Kirkwood's message of jue oct 28 02:20:56 -0300 2010:
I'm guessing the index error is due to the uninitialized table pages
(the index "content_node_node_type_id_inserted_idx" is on the "node"
table).
Not necessarily ... You s
I'm seeing this on a Pitrtools managed warm standby box that we
periodically bring the db fully up on in order to test if the standby is
good.
After the standby is up, then a db wide VACUUM produces:
2010-10-28 17:20:51 NZDT WARNING: relation "node" page 248500 is
uninitialized --- fixing
20
The discussion on -performance about disk caching reminded me that the
useful fsync test utility does not seem to compile (git master on Ubuntu
10.04):
$ make
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing
-fwrapv -g -I../.
That is not what is being said (or perhaps I should say not what is
being meant)! Essentially you need to help us help you. Given that VPATH
builds seem to work for the rest of us, you need to help us see what
(possibly unusual) thing(s) you did that have got such a build confused.
The guys he
On 04/08/10 16:55, Tom Lane wrote:
You're right, I did. Perhaps the presence of prebuilt docs in the
source tree confuses something --- anybody wanna test?
The files that seem to be causing the confusion are:
/doc/src/sgml/html-stamp
/doc/src/sgm/man-stamp
A src tree 'maintainer-clean'
On 04/08/10 03:35, Tom Lane wrote:
"Dmtiriy Igrishin" writes:
Description:Documentation is not installs from VPATH build.
When 'configure' executed in a directory outside the source tree the
documentation is not installs later nevertheless the "gmake install-docs" or
"gma
On 23/07/10 14:34, vamsi krishna wrote:
Hi
I am running a query on postgres and got the following error:
ERROR: out of memory
DETAIL: Failed on request of size 8
Hmm - looks like your system needs more memory to complete the query
(ahem - would help to see the query, plus EXPLAIN outp
On 10/06/10 02:17, Tom Lane wrote:
Mark Kirkwood writes:
It seems that the nub of this issue is that there are conceptually two
types of =, one for datatype specific comparison, and one for optimizer
statistical information calculation. However the system allows only the
first, so if you
On 09/06/10 17:14, Tom Lane wrote:
Robert Haas writes:
It's possible. I don't really see a reason not to add an = operator
for XML - does anyone else?
Yes, that was considered and rejected, IIRC. What is your definition
of equality for xml?
Yes - but in that previous discussi
On 09/06/10 15:22, Robert Haas wrote:
On Thu, Jun 3, 2010 at 7:16 PM, Mark Kirkwood
wrote:
Maybe I gave this guy a bad title - is it a concern that the 'width'
estimate is so far off for xml datatypes (because of no = op)? It seemed to
me that this could result in some bad pl
On 27/05/10 13:37, Mark Kirkwood wrote:
On 25/05/10 16:43, Mark Kirkwood wrote:
Today I ran into some interesting consequences of the xml data type
being without an "=" operator. One I thought I'd post here because it
has a *possible* planner impact. I'm not sure it is act
On 25/05/10 16:43, Mark Kirkwood wrote:
Today I ran into some interesting consequences of the xml data type
being without an "=" operator. One I thought I'd post here because it
has a *possible* planner impact. I'm not sure it is actually a bug as
such, but this seemed th
On 26/05/10 15:51, Robert Haas wrote:
I'm not sure that it's very productive to refer to the behavior of our
code as insane.
Not meaning to single you out Robert, but typically folk are honest with
their impression of the code without worrying about feather ruffling too
much e.g: searchi
Today I ran into some interesting consequences of the xml data type
being without an "=" operator. One I thought I'd post here because it
has a *possible* planner impact. I'm not sure it is actually a bug as
such, but this seemed the best forum to post in initially:
test=# \d bug
Table "
Alvaro Herrera wrote:
Daniel J. Baldev escribió:
All I want to do is to delete a database, but I don't know how to
actually input the dropdb command and what other stuff I need to
open...can you help? I think my problem will be very simple for
someone who understands this
Are you using
Mike Landis wrote:
At 09:09 PM 1/7/2010, you wrote:
I suspect they do not. Its all in the permissions.
There's no user account control enabled on this Vista machine,
therefore effectively wide open, hence different platform behavior or
at least a difference between the behavior in pgAdmin
(I forgot to cc -bugs...)
Mike Landis wrote:
Two things strike me as odd about that...
1) What's the logic behind the owner of a table not automatically
getting a readonly privilege like SELECT?
Owner always has select on a table they have created.
2) I think it would be more logical to ref
Mike Landis wrote:
Pick a database and table that exists, configure the string
cconstants, compile and run the attached cpp, get 0 instead of 1 (that
you get in pgAdmin...
Where's can I download the libpq source? Maybe I can find and/or fix
the problem myself.
Your program works fine for m
Philip Graham wrote:
The following bug has been logged online:
Bug reference: 5244
Logged by: Philip Graham
Email address: phi...@lightbox.org
PostgreSQL version: 8.3.8
Operating system: Linux
Description:Attempting to rollback to a savepoint after receiving an
error
David Fetter wrote:
On Fri, Oct 30, 2009 at 08:51:57PM -0700, John R Pierce wrote:
Tom Lane wrote:
There is special-purpose software out there that can compute
exactly with rational numbers, but you aren't likely to find it
embedded in any general-purpose tools like databases --- the
us
Federico wrote:
The following bug has been logged online:
Bug reference: 5096
Logged by: Federico
Email address: federicoaagui...@gmail.com
PostgreSQL version: 8.4
Operating system: OpenSuSE 11.1
Description:Error installing edb_apachephp.bin
Details:
Hello, when
I wrote:
Trying out some code with Php 5.3.1-dev:
$sql = "SELECT false";
$stmt = $dbh->query($sql);
$result = $stmt->fetch(PDO::FETCH_NUM);
print(" " . $result[0] . "\n");
reproduces what Yujin is seeing...
After a bit of digging through the PDO code, I see what is happening.
the ->fetch
Mark Kirkwood wrote:
I guess it must be something funny with how PDO represents the bool
type...(will have a look at the PDO code). But this needs to be raised
on bugs.php.net.
FYI - a related bug is : http://bugs.php.net/bug.php?id=33876
--
Sent via pgsql-bugs mailing list (pgsql-bugs
Tom Lane wrote:
"Yujin" writes:
When i get query from table with bolean type fields, that have false value ,
function PDO -> fetch return that fields with not "0" value , but empty
string.
Are you sure the field is actually false, and not null?
If so, this is a PDO bug, not a Postgr
Tom Lane wrote:
Given that RC freeze is nearly upon us for 8.4, and that we need a
reasonably non-invasive fix for 8.3 anyway, I propose that for now
we just deal with the syncscan issue by tweaking heap_rescan so that
rs_startblock doesn't get changed. It looks like that's about a
three-line pa
Short Desc: Cursor with hold emits the same row more than once across
commits in 8.3.7
Os : Debian Etch amd64 / Ubuntu Jaunty amd64
Pg : 8.3.7
Build options: Official package and also compiled from source with
--enable-integer-datetimes
Detailed Desc:
A construction of the form
DECLARE cur CU
John R Pierce wrote:
chris wood wrote:
At a detailed level (which is NOT the direction I want this thread to
go) I do not agree with your statement that my proposal has no “hope
of ACID compliance or transactional integrity”. When the “slices” are
stored back to the cloud, this is the equivale
Bruce Momjian wrote:
The comment I have from Tom Lane on this patch is:
band-aid solution to just one aspect of problem ...
so I am afraid I am going to have to reject it. Sorry.
No problem, thanks for passing along the feedback - I was primarily
interested in that (as I figured th
I encountered this bug recently - and thought I'd have a try at seeing
what might fix it.
Taking an exclusive lock on the to-be-dropped table immediately (i.e in
RemoveRel) seems to be enough to prevent the drop starting while an
index is being created in another session. So it "fixes" the iss
Tom Lane wrote:
Would those of you with access to other DBMSes try this:
create table tab (col integer);
select 1 from tab having 1=0;
select 1 from tab having 1=1;
insert into tab values(1);
insert into tab values(2);
select 1 from tab having 1=0;
select 1 from tab having 1=1;
I claim that a SQL-c
Your name :Mark Kirkwood
Your email address :[EMAIL PROTECTED]
System Configuration
-
Architecture (example: Intel Pentium) :Intel Pentuim
Operating System (example: Linux 2.0.26 ELF) :Linux 2.2.14-5.0 ELF
(Redhat 6.2)
PostgreSQL
70 matches
Mail list logo
