would be better raising this
issue with them!
Cheers
Mark
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Randomly, you are unable to use ctrl-c/ctrl-v/ctrl-x shortcut keys in
the pgadmin edit window, but you can use the right click menu.
You can make the shortcut keys work again by clicking in another widget
in the same editor window and then clicking back to the main edit box.
Video link to sho
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
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
;P0_7" does not
exist
Client 3 aborted in state 7: ERROR: prepared statement "P0_7" does not
exist
Client 2 aborted in state 7: ERROR: prepared statement "P0_7" does not
exist
transaction type: TPC-B (sort of)
Strange - work for me (9.4devel pulled just now).
Cheers
Ma
id-dls.com/wiki/index.php?title=Debian_on_G1 near the
bottom they discuss this issue.
Cheers
Mark
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
stands the
memory allocation system better than I do will need to comment about how
that might work :-)
Cheers
Mark
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
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 wro
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
LR median
function) makes the error vanish, so its either PLR or the specific PLR
median function causing the grief.
Regards
Mark
create or replace function r_median(_float8) returns float as '
median(arg1)
' language 'plr';
CREATE AGGREGATE median (
sfunc = plr_a
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
0 | streaming
(5 rows)
Cheers
Mark
[1] Looking at the code for pg_stat_replication, it appears to take the
sync rep lock while reporting, so in theory should be exactly right...I
should perhaps check what pg_current_xlog_location does...
--
Sent via pgsql-bugs mailing list (pgsql-b
native than abusing inheritance?
2/ Is anyone working on parallel query execution?
Regards
Mark
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Hello Magnus,
Thanks a lot for your time checking my email.
Am 15.06.2012 07:56, schrieb Magnus Hagander:
On Wed, Jun 13, 2012 at 2:45 AM, wrote:
The following bug has been logged on the website:
Bug reference: 6689
Logged by: Mark
Email address: m...@it
On 10/06/12 22:08, Tom Lane wrote:
mthorn...@optrak.com writes:
The following bug has been logged on the website:
Bug reference: 6685
Logged by: Mark Thornton
Email address: mthorn...@optrak.com
PostgreSQL version: 9.1.4
Operating system: Ubuntu 12.04
Description:
Executing
file in the new location.
Regards
Mark
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
I agree the query is a little odd, but I like backwards compatibility!
Postgres 8.4.1
--
CREATE VIEW v_members AS
SELECT
1 as member_id,
100 as tenant_id,
3732 as conference_id,
200 as uid
FROM
(select 1 as uid_user, 2 as uid_contact) as m;
SELECT
u.tenan
On 03/16/12 13:48, Alex Hunsaker wrote:
On Thu, Mar 15, 2012 at 16:13, Bruce Momjian wrote:
On Tue, Mar 06, 2012 at 09:08:25PM -0700, Alex Hunsaker wrote:
[ Calling a plperl trigger function from a plperl function ]
Yeah, there were some optimization done for 9.1 to try and make calls
a bit f
; Does this patch make it better?
> http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=bb65cb8cdf864e61bc939d3c4b28bbd43d926700
That solves the problem. Thanks!
--Mark Langsdorf
Calxeda, Inc.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
The following bug has been logged on the website:
Bug reference: 6462
Logged by: Mark Langsdorf
Email address: mark.langsd...@calxeda.com
PostgreSQL version: 9.0.6
Operating system: Fedora fc15
Description:
I'm trying to build 9.0.6 for Fedora 15 on an ARM (Cort
Thank you for your reply.
On Feb 3, 2012, at 9:31 AM, Dharmendra Goyal wrote:
> On Fri, Feb 3, 2012 at 10:37 PM, Mark Phillips
> wrote:
> After considering your remarks and modifying the app install script, the app
> installation completes normally with a functioning PostgreSQL
does not result in the appearance of the "PostgreSQL"
user account in the os x GUI.
To recap the questions:
1. are the errors reported in the postgres install log of a type to cause a
malfunction for end users?
2. how can I suppress the appearance of the user account "PostgreSQL"
The following bug has been logged on the website:
Bug reference: 6405
Logged by: Mark Phillips
Email address: mark.phill...@mophilly.com
PostgreSQL version: 9.1.2
Operating system: Mac OS X 10.7
Description:
for a stand alone app that uses postgres, the app installer
The following bug has been logged on the website:
Bug reference: 6404
Logged by: Mark Phillips
Email address: mark.phill...@mophilly.com
PostgreSQL version: 9.1.2
Operating system: Mac OS X 10.7
Description:
for a stand alone app that uses postgres, the app installer
e mis-assessment risk and
misunderstanding of sane network configuration. No-one can sensibly
support a position to redefine 'localhost' to mean what it should never
mean.
regards
Mark
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your sub
up then
getting (most of) the query text from pg_stat_activity would enable you
to track down the offending sql in your load script.
regards
Mark
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
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
Thanks - worked a treat. Might be useful to have the installer check
for the existence of the VC++ runtime - just a suggestion...
Mark Lamberton
On Thu, Sep 1, 2011 at 2:47 AM, Mark Lamberton
wrote:
The following bug has been logged online:
Bug reference: 6191
Logged by
The following bug has been logged online:
Bug reference: 6191
Logged by: Mark Lamberton
Email address: m...@penguinsystems.com.au
PostgreSQL version: 9.0.4-1
Operating system: Windows 7
Description:One click installer fails
Details:
Problem signature:
Problem
indefinitely if the transactions
never complete due to pooler issues.)
Expected behavior would be -T would mean a hard cut off.
Thoughts ?
-Mark
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
The following bug has been logged online:
Bug reference: 6029
Logged by: mark
Email address: m...@remidata.com
PostgreSQL version: 9.0.2
Operating system: RHEL 6.0 x86_64
Description:packaged installer fails to configure ldap
Details:
The source code installation
The following bug has been logged online:
Bug reference: 5998
Logged by: Mark Reid
Email address: m...@markreid.org
PostgreSQL version: 8.3.5
Operating system: Debian Etch
Description:CLUSTER and "ERROR: missing chunk number 0 for toast
value"
Detail
earch), and I've been encouraging a
redesign in that area anyway as I don't believe it is necessary to
require so many joins to achieve what they wish to do - so this is
really the clincher for a redesign.
I will get 'em to reduce the *collapse limits too.
Thanks to all of you
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
vailable...sigh). However for these semi ad-hoc systems it is hard to
prevent dumb queries altogether!
regards
Mark
starjoin.tar.gz
Description: GNU Zip compressed data
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
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
> -Original Message-
> From: Robert Haas [mailto:robertmh...@gmail.com]
> Sent: Thursday, March 03, 2011 9:04 AM
> To: mark
> Cc: Fujii Masao; pgsql-bugs@postgresql.org
> Subject: Re: [BUGS] BUG #5851: ROHS (read only hot standby) needs to be
> restarted manually
or potentially quite some time.
Mark
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ed then it seems likely
it was working as intended.
Greg, thanks for clarifying this.
Unfortunately this time around I canceled the vacuum and then the query.
However *next* time I'll get rid of the query 1st and see what happens.
Cheers
Mark
--
Sent via pgsql-bugs mailing l
site, there is no
call for queries that run this long (i.e way longer than the timeout for
the respective page rendering).
Thanks for the clarification (assuming I've understood correctly of
course...).
Cheers
Mark
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To
vacuum, but any suggestions for getting more diag
info for next time?
regards
Mark
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
PATH=/usr/local/pgsql/bin:$PATH
$ export LD_LIBRARY_PATH=/usr/local/pgsql/lib
$ initdb -D /data/postgres
$ pg_ctl -D /data/postgres start;
$ psql
I'm guessing that there are older libraries or binaries earlier in your
various env paths, and these are tripping up postgres.
Cheers
Mark
--
Se
> -Original Message-
> From: Fujii Masao [mailto:masao.fu...@gmail.com]
> Sent: Tuesday, February 08, 2011 4:00 PM
> To: mark
> Cc: Robert Haas; pgsql-bugs@postgresql.org
> Subject: Re: [BUGS] BUG #5851: ROHS (read only hot standby) needs to be
> restarted manually
On Sun, Jan 30, 2011 at 12:45 PM, mark wrote:
>
>
>> -Original Message-
>> From: Robert Haas [mailto:robertmh...@gmail.com]
>> Sent: Sunday, January 30, 2011 12:19 PM
>> To: mark
>> Cc: pgsql-bugs@postgresql.org
>> Subject: Re: [BUGS] BUG #5851
> -Original Message-
> From: Robert Haas [mailto:robertmh...@gmail.com]
> Sent: Sunday, January 30, 2011 12:19 PM
> To: mark
> Cc: pgsql-bugs@postgresql.org
> Subject: Re: [BUGS] BUG #5851: ROHS (read only hot standby) needs to be
> restarted manually in somecases
urately ? (or a
value that high isn't be accepted?)
I have reloaded configs and still seeing 0's
I assume you would suggest I turn that number down... a lot.
..: Mark
> -Original Message-
> From: Robert Haas [mailto:robertmh...@gmail.com]
> Sent: Friday, Januar
The following bug has been logged online:
Bug reference: 5851
Logged by: Mark
Email address: dvlh...@gmail.com
PostgreSQL version: 9.0.2 x86_64
Operating system: CentOS release 5.5 (Final) | 2.6.18-194.17.1.el5 #1 SMP
X86_64
Description:ROHS (read only hot standby
The following bug has been logged online:
Bug reference: 5734
Logged by: Mark Stosberg
Email address: m...@summersault.com
PostgreSQL version: 9.0.1
Operating system: FreeBSD
Description:autovacuum_enabled input should be validated,
standardized.
Details:
The
t happens if we start it up
and try a VACUUM - however the dbas may have set the box up as a slave
again before we noticed the memory errors (so possibly deleted the old
master).
Cheers
Mark
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your sub
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).
ifact of log shipping?
The is 8.3.11 on Debian Lenny x86-64.
Thanks
Mark
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
it fix it for me.
regards
Mark
diff --git a/src/tools/fsync/test_fsync.c b/src/tools/fsync/test_fsync.c
index 3c9c6b6..28c2119 100644
--- a/src/tools/fsync/test_fsync.c
+++ b/src/tools/fsync/test_fsync.c
@@ -63,7 +63,7 @@ main(int argc, char *argv[])
for (i = 0; i < XLOG_SEG_SIZE
Hi Ashesh
Yes, this appears to be the issue that the password in the pgpass.conf file for
the postgres user had not been changed when the windows account password was
reset.
Problem now resolved.
Many thanks
Mark Llewellyn
From: Ashesh Vashi [mailto:ashesh.va
here like to fix stuff - but cannot fix your bug unless you
help by supplying what has been asked for.
Best wishes
Mark
On 21/09/10 08:37, Graham Swallow wrote:
Noone else has missing files, in the wrong places,
Its not their problem.
All of the files on all of your machines, are in the right
The following bug has been logged online:
Bug reference: 5650
Logged by: Mark Llewellyn
Email address: mark_llewel...@adp.com
PostgreSQL version: 9.0 RC1
Operating system: Windows XP
Description:Postgres service showing as stopped when in fact it is
running
Details
iner-clean' removes then, but any lesser level of
clean doesn't. Hmm - shouldn't a VPATH build look at its *own*
doc/src/sgml/*-stamp files to see if it needs to build the docs? Note
that it does *create* them in there after a successful build...
Cheers
Mark
--
Sent via pgsql
f a downloaded one then
it work work fine (suspect Tom used a checked out tree) Tom?
Cheers
Mark
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
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
alculation. However the system allows only the
first, so if you don't (or can't) have one then you lose some possibly
important optimization data.
regards
Mark
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresq
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
misleading (e.g user error or not
reading the docs), but I don't think we should try (too hard anyway) to
smother any strong criticism.
regards
Mark
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
g at least
an "=" operator to enable some minimal stats to be available for xml
columns.
regards
Mark
e you using pgAdmin? If so, just right-click on the database and
select "delete/drop".
Probably too late to be mentioning this... but Daniel, are you sure that
the database is not needed by anything?
regards
Mark
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
:
DELETE FROM b WHERE id = 1;
The record from table a disappears, but the record in table b is still
there. Of course this is a very stupid construction, but I would expect some
kind of error / warning message instead. Now it is possible to corrupt your
data.
Best regards,
Mark Kazemier
obert suggested, try
doing 'SELECT user' in both.
Also note that Pgadmin user PQexec and PQgetValue...
Cheers
Mark
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ld produce different answers.
I suspect they do not. Its all in the permissions.
Cheers
Mark
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
cally 'postgres' to eliminate this
possibility.
With respect to the libpq source, it is in the source tarball from the
Postgresql website (directory src/interfaces/libpq ).
regards
Mark
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes t
= 0;
}
echo 'Cur Id: ',$curId,"\n";
Running this code it hangs after echoing 'Rolling back', but only hangs
every other execution (assuming the sequence was deleted first).
I think you need to be using $pdo->exec instead of $pdo->query for
everythi
What is the most ideal/optimal platform for postgresql? Linux
(distro?), freebsd, windows, etc.
consider memory management, file system performance, threading model
etc.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgre
not allow one customer to impact
others.
That's it for now.
Hope someone can provide helpful answers.
Thanks,
Mark W.
oper
subset, is countable and hence has Lebesgue measure zero on the real
line.
;)
LOL - fortunately (going by the bug) he is not trying to compute a
measure (i.e integrate) from a set of 'em.
Mark
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to you
t include where gatenforce lives.
regards
Mark
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
sql
version of this example returns a string "0" from PDO, so gives a 0 for
false in a more expected/intuitive way...
regards
Mark
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
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
sult[0] . "\n");
reproduces what Yujin is seeing, whereas replacing $sql with:
$sql = "SELECT false::int4";
gives a 0 in the result array. I guess it must be something funny with
how PDO represents the bool type...(will have a look at the PDI code).
But this needs to be raised
You're correct. When I run this from psql it returns the correct result. When I
run it from DBVisualizer, which I normally use, it adjust the result to my
local time zone. Thanks for looking into it. Sorry about bugging you with that.
Thanks,
Mark
On 9/2/09 10:24 PM, "Tom Lane"
I have my timezone set to GMT so there really shouldn't be any time zone
adjustments.
Mark
On 9/2/09 10:01 PM, "Tom Lane" wrote:
"Mark Douglas" writes:
> The following use of DATE_TRUNC returns the wrong value. I called the
> function on 2009-09-02. It sho
The following bug has been logged online:
Bug reference: 5031
Logged by: Mark Douglas
Email address: m...@steelhousemedia.com
PostgreSQL version: 8.4.0
Operating system: Ubunto Linux
Description:DATE_TRUNC returns the wrong value when specifying MONTH
Details:
The
three-line patch. The question of how cursors should behave with
respect to volatile functions can be documented and left for another
time.
Sounds like a good approach.
Mark
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.post
eration program for this
dataset if required.
regards
Mark
cursor-bug.tar.gz
Description: GNU Zip compressed data
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Sat, 02 May 2009 14:47:48 GMT, Tom Lane wrote
> Mark writes:
> > I understand the rationale for relocatable packages. So,
> > I guess hardlinks are out. But, barring hardlinks,
> > perhaps, in the existence of a symlink, a simple 'readlink'
> > f
-Original Message-
From: pgsql-bugs-ow...@postgresql.org
[mailto:pgsql-bugs-ow...@postgresql.org] On Behalf Of Tom Lane
Sent: vrijdag 1 mei 2009 23:57
To: Mark; pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #4787: Hardlink (ln) causes startup failure with
bizarre
-Original Message-
From: pgsql-bugs-ow...@postgresql.org
[mailto:pgsql-bugs-ow...@postgresql.org] On Behalf Of Tom Lane
Sent: vrijdag 1 mei 2009 17:46
To: Mark Kramer
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #4787: Hardlink (ln) causes startup failure with
bizarre
1 - 100 of 153 matches
Mail list logo
