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
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 Win
On Tue, Sep 15, 2009 at 9:21 AM, Andreas Kuckartz 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: Binar
Heikki Linnakangas 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 for anything the the redo functi
On Tue, Sep 8, 2009 at 11:38 PM, vyou zhi 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 while
Tom Lane wrote:
> Heikki Linnakangas 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 for anythi
Heikki Linnakangas writes:
> Tom Lane wrote:
>> Actually, the entire thing is misdesigned from the get-go. AFAICS
>> it shouldn't even have its own WAL record type --- it should be using
>> log_newpage().
> Yeah, that would be even simpler. The WAL records it currenctly writes
> are more compact
Robert Haas writes:
> On Tue, Sep 8, 2009 at 11:38 PM, vyou zhi 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 sounds like a bug in PyGreSQL
Simon Riggs 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 functionality is tested aga
On Tue, 2009-09-15 at 14:31 -0400, Tom Lane wrote:
> Simon Riggs 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 n
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 ou
Simon Riggs 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 with
>> full_page_
On Tue, 2009-09-15 at 15:34 -0400, Tom Lane wrote:
> Simon Riggs 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 f
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 atta
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 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 page is logged.
> I saw t
On Tue, Sep 15, 2009 at 4:41 PM, Simon Riggs 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 public test suites
> 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 corrupti
postgres bee 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 they're not, you ha
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 cl
On Tue, Sep 15, 2009 at 3:26 PM, Joseph Shraibman 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: [jdbc]
On Sun, Sep 6, 2009 at 4:48 PM, Ilian Georgiev 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
> Description: U
Craig Ringer 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 rarely triggered Pg bug (ie:
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 th
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();
28 matches
Mail list logo
