Tom Lane wrote:
Yujin aloudno...@mail.ru 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
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
On Mon, 2009-09-14 at 22:58 -0700, John R Pierce wrote:
and, if you're doing RAID with desktop grade disks, its quite possible
for the drive to spontaneously decide a sector error requires a data
relocation but not have the 'good' data to relocate, and not return an
error code in time for
Simon Riggs wrote:
In recovery of GIN operations using CVS HEAD I see consistently
TRAP: FailedAssertion(!(((bool) ((spcNode) != ((Oid) 0, File:
tablespace.c, Line: 116)
Looking at code, new list page WAL record is a GIN record type and at
line 115 in gin/ginfast.c I see that the
On Tue, 2009-09-15 at 09:41 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
In recovery of GIN operations using CVS HEAD I see consistently
TRAP: FailedAssertion(!(((bool) ((spcNode) != ((Oid) 0, File:
tablespace.c, Line: 116)
Looking at code, new list page WAL record is a
The following bug has been logged online:
Bug reference: 5057
Logged by: Andreas Kuckartz
Email address: a.kucka...@ping.de
PostgreSQL version: 8.2.14
Operating system: Windows
Description:Binaries missing
Details:
Only PostgreSQL 8.2 and above are supported on
On Tue, Sep 15, 2009 at 9:21 AM, Andreas Kuckartz a.kucka...@ping.de wrote:
The following bug has been logged online:
Bug reference: 5057
Logged by: Andreas Kuckartz
Email address: a.kucka...@ping.de
PostgreSQL version: 8.2.14
Operating system: Windows
Description:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
This means that the WAL replay of that record type has never been tested
correctly :-(. Looking closer at writeListPage(), why does it always
include 'workspace' in the WAL record, even if a full-page-image is
taken? It's not used
On Tue, Sep 8, 2009 at 11:38 PM, vyou zhi vyou...@gmail.com wrote:
hi all:
i use Python and PyGreSQL to link PostgreSQL
but the Python give me the error
the error here :
...
95
93
95
97
94
96
94
message type 0x43 arrived from server
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
This means that the WAL replay of that record type has never been tested
correctly :-(. Looking closer at writeListPage(), why does it always
include 'workspace' in the WAL record, even if a full-page-image is
Robert Haas robertmh...@gmail.com writes:
On Tue, Sep 8, 2009 at 11:38 PM, vyou zhi vyou...@gmail.com wrote:
i use Python and PyGreSQL to link PostgreSQL
but the Python give me the error
message type 0x43 arrived from server while idle
message type 0x5a arrived from server while idle
This
Simon Riggs si...@2ndquadrant.com writes:
On Tue, 2009-09-15 at 09:41 +0300, Heikki Linnakangas wrote:
This means that the WAL replay of that record type has never been tested
correctly :-(.
This must have been added after mid-Feb this year. I notice there are a
few places where
On Tue, 2009-09-15 at 14:31 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Tue, 2009-09-15 at 09:41 +0300, Heikki Linnakangas wrote:
This means that the WAL replay of that record type has never been tested
correctly :-(.
This must have been added after mid-Feb this
The following bug has been logged online:
Bug reference: 5058
Logged by: Joseph Shraibman
Email address: j...@selectacast.net
PostgreSQL version: 8.2.14
Operating system: Linux
Description:[jdbc] Silent failure with executeUpdate()
Details:
I was trying to figure
Simon Riggs si...@2ndquadrant.com writes:
On Tue, 2009-09-15 at 14:31 -0400, Tom Lane wrote:
I've pointed out before that the regression tests are not particularly
meant to provide an exhaustive test of WAL recovery. In this particular
case, so far as I can tell the bug is only observable
On Tue, 2009-09-15 at 15:34 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Tue, 2009-09-15 at 14:31 -0400, Tom Lane wrote:
I've pointed out before that the regression tests are not particularly
meant to provide an exhaustive test of WAL recovery. In this particular
Tom Lane wrote:
BTW, there's more than one bug here :-(. Heikki found one, but the
code is also attaching the buffer indicator to the wrong rdata entry
--- the record header, not the workspace, is what gets suppressed
if the full page is logged.
I saw that, but I figured it should be
On Tue, 2009-09-15 at 12:09 -0400, Tom Lane wrote:
I'm working on this now.
Thanks to you and Heikki for fixing this while I worked around it.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Tom Lane wrote:
BTW, there's more than one bug here :-(. Heikki found one, but the
code is also attaching the buffer indicator to the wrong rdata entry
--- the record header, not the workspace, is what gets suppressed
if the full
On Tue, Sep 15, 2009 at 4:41 PM, Simon Riggs si...@2ndquadrant.com wrote:
I guess if you or another committer spends some time writing a test
framework that is useful and that you can trust, I'm sure many people
will add to it. That'll be true for any of the major/complex areas not
covered by
Was there any particular event that marked the onset of these issues?
Anything in the system logs (dmesg / syslog etc) around that time?
Unfortunately, cannot recall anything abnormal.
Was Pg forcibly killed and restarted, or the machine hard-reset? (This
_shouldn't_ cause data corruption,
postgres bee postgres_...@live.com writes:
But I do have one overriding question - since postgres is still running on
the same hardware, wouldn't it rule out hardware as the primary suspect?
Uh, no. One of the principal characteristics of hardware problems is
that they're intermittent. (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
postgres bee wrote:
Correct me if I am wrong, but I thought one of the, if not the most, primary
tasks for relational databases is to ensure that no data loss ever occurs.
Which is why I was initially surprised that the issue did not get enough
importnace. But now it seems more like the
Craig Ringer wrote:
PostgreSQL has to trust the hardware and the OS to do their jobs. If the
OS is, unbeknownst to PostgreSQL, flipping the high bit in any byte
Might not even be the OS - it could be the stars (through cosmic rays).
http://www.eetimes.com/news/98/1012news/ibm.html
'This
On Tue, Sep 15, 2009 at 3:26 PM, Joseph Shraibman j...@selectacast.net wrote:
The following bug has been logged online:
Bug reference: 5058
Logged by: Joseph Shraibman
Email address: ...@selectacast.net
PostgreSQL version: 8.2.14
Operating system: Linux
Description:
On Sun, Sep 6, 2009 at 4:48 PM, Ilian Georgiev georgiev.il...@gmail.com wrote:
The following bug has been logged online:
Bug reference: 5042
Logged by: Ilian Georgiev
Email address: georgiev.il...@gmail.com
PostgreSQL version: 8.1.10
Operating system: Windows XP
Craig Ringer cr...@postnewspapers.com.au writes:
[ long summary of all the weird and wonderful ways things can break ]
... unless an event is noticed that is associated with the corruption, or
some way to reproduce it is found, there's no way to tell whether any
given incident could be a
On Tue, 2009-09-15 at 19:26 +, Joseph Shraibman wrote:
The following bug has been logged online:
Bug reference: 5058
Logged by: Joseph Shraibman
Email address: j...@selectacast.net
PostgreSQL version: 8.2.14
Operating system: Linux
Description:[jdbc]
The following bug has been logged online:
Bug reference: 5059
Logged by: Kenaniah Cerny
Email address: kenan...@gmail.com
PostgreSQL version: 8.4.1
Operating system: Centos5.2
Description:Planner ignores estimates when planning an IN ()
subquery
Details:
Consider
If I create a gist index over a box and a circle, the index attributes
appear to both have type box.
I don't see any other, similar situations with other types, and I
haven't investigated the cause yet. Most similar situations work fine.
Regards,
Jeff Davis
postgres=# select version();
31 matches
Mail list logo
