[BUGS] BUG #5054: PDO -> Query returns "" from Boolean type field, if it has false value.
The following bug has been logged online: Bug reference: 5054 Logged by: Yujin Email address: aloudno...@mail.ru PostgreSQL version: 8.3 Operating system: windows XP SP3 Description:PDO -> Query returns "" from Boolean type field, if it has false value. Details: 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. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5053: domain constraints still leak
On Sun, Sep 13, 2009 at 10:28 PM, Tom Lane wrote: > "Andrew Gierth" writes: >> Domain NOT NULL constraints (and probably other constraints too) aren't >> being enforced in some code paths. e.g. > > The example you give seems to tie really closely into the debate about > whether a composite null is identically the same thing as ROW(NULL,NULL) > or not. In short, we have It seems like regardless of this discussion you oughtn't to be able to store a NULL into that table column. But maybe I'm just confused. ...Robert -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5046: java developer
On Wed, Sep 9, 2009 at 5:42 AM, mahmoud badr wrote: > > The following bug has been logged online: > > Bug reference: 5046 > Logged by: mahmoud badr > Email address: alien_...@yahoo.com > PostgreSQL version: 8.4 > Operating system: windows > Description: java developer > Details: > > when trying to create POJOs from Netbeans IDE they aren't ceated when the > DBMS is postgreSQL and they are created if the DBMS is any thing else. > please correct me if i'm wrong. I have no idea, but this sounds like something you need to talk to whoever makes your Netbeans IDE about, rather than the PostgreSQL developers. If you think there's a PostgreSQL bug here you need to tell us what actual SQL statements got executed, what you thought should happen, and what actually happened. ...Robert -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] ERROR: invalid page header in block 502758 of relation base/16388/16403
hi, i got following error while selecting from my db ERROR: invalid page header in block 502758 of relation base/16388/16403 i've found some solution in this thread http://www.mail-archive.com/pgsql-gene...@postgresql.org/msg101644.html but my problem is, that there are multiple files with similar name in the base/16388 directory. 16403 (1Gb) 16403.1 (1Gb) 16403.2 (1Gb) 16403.3 (almost 1 Gb) so the question is, where can i find the right 502758 position (i assume that this is the number of 8k block position). each file with size 1Gb has 131072 of 8k blocks. thanx for help fous -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Re: ERROR: invalid page header in block 502758 of relation base/16388/16403
i forgot the system informations postgresql-server-8.4.0-1PGDG.rhel5 linux kernel 2.6.18-128.4.1.el5xen x86_64 centos release 5.3 (final) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5053: domain constraints still leak
Robert Haas writes: > It seems like regardless of this discussion you oughtn't to be able to > store a NULL into that table column. But maybe I'm just confused. The system is relying on the not-unreasonable assumption that if it extracts a column of type X from someplace, what it has is a valid value of type X. Depending on what we decide about the whole composite-null mess, maybe we will be forced to abandon that assumption ... but I'm sure not going to do so until my back is to the wall. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5054: PDO -> Query returns "" from Boolean type field, if it has false value.
"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 Postgres bug. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] ERROR: invalid page header in block 502758 of relation base/16388/16403
fous velkej writes: > i got following error while selecting from my db > ERROR: invalid page header in block 502758 of relation base/16388/16403 > i've found some solution in this thread > http://www.mail-archive.com/pgsql-gene...@postgresql.org/msg101644.html > but my problem is, that there are multiple files with similar name in > the base/16388 directory. > 16403 (1Gb) > 16403.1 (1Gb) > 16403.2 (1Gb) > 16403.3 (almost 1 Gb) > so the question is, where can i find the right 502758 position (i > assume that this is the number of 8k block position). > each file with size 1Gb has 131072 of 8k blocks. Right, so it would be in the .3 file at block number 109542. regression=# select 502758 / 131072; ?column? -- 3 (1 row) regression=# select 502758 % 131072; ?column? -- 109542 (1 row) regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5053: domain constraints still leak
On Mon, Sep 14, 2009 at 11:16:23AM -0400, Robert Haas wrote: > I haven't read the code in this area, but for what it's worth, I guess > I lean toward the view that treating a row of NULLs as being the same > thing as an undecorated NULL does not make very much sense. I agree; when compared to most languages it doesn't. When compared to the semantics of the other operators in SQL it gets better. I personally think PG should strive to be internally consistent rather than consistency with other (non-SQL based) languages. > If I have > a table row which contains (1, NULL, NULL) and I update the first > column to be NULL, I feel like I now have (NULL, NULL, NULL), not just > NULL. Every other programming language I'm aware of makes this > distinction - for good reasons - and I don't really see any reason why > SQL should do anything different. I'm not aware of any other language that does the automatic "lifting" (to borrow nomenclature from Haskell) that SQL does, allowing NULL appear in *every* type. Java, for example, has null references, but these are very different creatures from nulls in databases--the programmer has to explicitly deal with them all the time and also they only apply to references. Taken another way, each object in a normal imperative language has its own identity, but in a database two rows that "look" the same are the same. Thirdly, IS NULL is defined to look "inside" composite values to see if they're "really" null. Its these differences in semantics that seem to make it all OK. > Under that view, null::test is not itself a test, but denotes the > absence of one. OK, but how can you distinguish NULL from ROW(NULL,NULL)? SELECT v IS NULL, v.a, v.b FROM (SELECT NULL, NULL) v(a,b); Would appear to return the same thing if ROW(NULL,NULL) evaluated to NULL or not. The only time it would show up is when you're trying to save the value into a table and I think this would tend to do the right thing more often. For example: INSERT INTO t (id,rv) SELECT f.id, b FROM foo f LEFT JOIN bar b ON (f.id = b.id); Would fail if any bar's didn't exist, whereas the current behavior is to insert a row with rv containing all null values. You can't test for this case because IS NULL would return the "wrong" thing as it looks inside composites. -- Sam http://samason.me.uk/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5053: domain constraints still leak
Sam Mason wrote: > the deeper problem seems to be that the table was created as: > > create table test (a tstdom); > > and not as: > > create table test (a tstdom not null); Given that tstdom is declared as NOT NULL, is this difference considered a *feature* or is it an implementation quirk? -Kevin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5053: domain constraints still leak
On Mon, Sep 14, 2009 at 10:22 AM, Tom Lane wrote: > Robert Haas writes: >> It seems like regardless of this discussion you oughtn't to be able to >> store a NULL into that table column. But maybe I'm just confused. > > The system is relying on the not-unreasonable assumption that if it > extracts a column of type X from someplace, what it has is a valid value > of type X. Depending on what we decide about the whole composite-null > mess, maybe we will be forced to abandon that assumption ... but I'm > sure not going to do so until my back is to the wall. I haven't read the code in this area, but for what it's worth, I guess I lean toward the view that treating a row of NULLs as being the same thing as an undecorated NULL does not make very much sense. If I have a table row which contains (1, NULL, NULL) and I update the first column to be NULL, I feel like I now have (NULL, NULL, NULL), not just NULL. Every other programming language I'm aware of makes this distinction - for good reasons - and I don't really see any reason why SQL should do anything different. Under that view, null::test is not itself a test, but denotes the absence of one. Trying to store this value in a table can either fail outright (on the theory that you can't store the absence of something in a table), or else we can - as a special case - treat assignment from null to an actual object as a request to assign null to each column (which will fail if there exists a column into which a NULL of the associated column type can't be stored). ...Robert -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5053: domain constraints still leak
On Mon, Sep 14, 2009 at 10:54:07AM -0500, Kevin Grittner wrote: > Sam Mason wrote: > > the deeper problem seems to be that the table was created as: > > > > create table test (a tstdom); > > > > and not as: > > > > create table test (a tstdom not null); > > Given that tstdom is declared as NOT NULL, is this difference > considered a *feature* or is it an implementation quirk? That's why I pointed it out! Based on my reading of the SQL spec (and reading about Codd's descriptions of domains) I'd say it was a bug/implementation quirk. -- Sam http://samason.me.uk/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5053: domain constraints still leak
On Mon, Sep 14, 2009 at 10:22:34AM -0400, Tom Lane wrote: > Robert Haas writes: > > It seems like regardless of this discussion you oughtn't to be able to > > store a NULL into that table column. But maybe I'm just confused. > > The system is relying on the not-unreasonable assumption that if it > extracts a column of type X from someplace, what it has is a valid value > of type X. Yup; the deeper problem seems to be that the table was created as: create table test (a tstdom); and not as: create table test (a tstdom not null); which is how you seem to be treating it. > Depending on what we decide about the whole composite-null > mess, maybe we will be forced to abandon that assumption ... but I'm > sure not going to do so until my back is to the wall. There seems to be a little space yet! This whole issue seems only distantly related to the treatment of null rows to me. I think PG has got its semantics confused along the way somewhere and things need tweaking. The only way I can get it all to work nicely in my head is if ROW(NULL) evaluates to a NULL value (and not a row containing a NULL value, as it does at the moment) and the NULL/NOT NULL constraint on the CREATE DOMAIN is used somehow for the nullness constraint of any columns using this domain. It's the second part that seems to be more critical, but there are various ways of interpreting the meaning. I'm tempted to say that the nullness specified in the domain puts a bound on the amount of nullness available--i.e. it would be impossible to create a nullable column from a domain that specified NOT NULL. The reason it's only a "limit" is that it seems useful to be able to say that a normally nullable domain can't be null for this column in this table. Not sure if this is what people want though. You then get into fun cases like: create domain tstdom as integer; create domain tstdom2 as tstdom; -- Sam http://samason.me.uk/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5047: Not able to connect from Informatica
On Thu, Sep 10, 2009 at 7:17 AM, Rohan jamadagni wrote: > > The following bug has been logged online: > > Bug reference: 5047 > Logged by: Rohan jamadagni > Email address: rohan.jamada...@tcs.com > PostgreSQL version: 8.3.7 > Operating system: Linux Rhel 5.0 > Description: Not able to connect from Informatica > Details: > > Hi > We are trying to connect informatica(on HP-ux) to > postgres server with ODBC driver while configuring we are facing following > error > 1.For psqlodbc-08.04.0100 > pg_config not found (set PG_CONFIG environment variable) > > 2.For psqlodbc-08.01.0200 > error: no suitable ODBC driver manager found > > Please help us resolve the same This sounds like a user question, not a bug. You might want to try here: pgsql-o...@postgresql.org http://archives.postgresql.org/pgsql-odbc/ ...Robert -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5037: jdbc bug \uffff
On Fri, Sep 4, 2009 at 6:02 PM, Rob Resendez wrote: > The following bug has been logged online: > > Bug reference: 5037 > Logged by: Rob Resendez > Email address: rob.resen...@cpsinet.com > PostgreSQL version: 8.3.7 > Operating system: Linux > Description: jdbc bug \u > Details: > > resultSet.getObject() returns \ufffd when I expect to see \u (ÿ). The You might want to try here, as the people who read this list are not necessarily familiar with JDBC. pgsql-j...@postgresql.org http://archives.postgresql.org/pgsql-jdbc/ You'll probably need to provide more details, too. ...Robert -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] GIN needs tonic
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 value of the node is unset.
That means XLOG_GIN_INSERT_LISTPAGE always has specNode == 0 and so
triggers the assertion failure.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5056: SQLDescribeColW for function returning a result set incorrectly setting sql_nullable
The following bug has been logged online:
Bug reference: 5056
Logged by: the6campbells
Email address: the6campbe...@gmail.com
PostgreSQL version: 8.4.1
Operating system: windows
Description:SQLDescribeColW for function returning a result set
incorrectly setting sql_nullable
Details:
create table TSET1 (RNUM integer not null, C1 integer, C2 char(3));
create function PRES ( )
returns setof TSET1 as
'
select RNUM, C1, C2 from TSET1;
' LANGUAGE 'sql'
;
in ODBC test sqlPrepare { call pres } then describe the columns. first
column should be SQL_NO_NULLS not NULLABLE.
Describe Column All:
icol, szColName,
*pcbColName, *pfSqlType, *pcbColDef, *pibScale,
*pfNullable
1, rnum, 4, SQL_INTEGER=4, 10, 0, SQL_NULLABLE=1
2, c1, 2, SQL_INTEGER=4, 10, 0, SQL_NULLABLE=1
3, c2, 2, SQL_WCHAR=-8, 3, 0, SQL_NULLABLE=1
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5056: SQLDescribeColW for function returning a result set incorrectly setting sql_nullable
On Mon, Sep 14, 2009 at 10:40 PM, the6campbells wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5056
> Logged by: the6campbells
> Email address: the6campbe...@gmail.com
> PostgreSQL version: 8.4.1
> Operating system: windows
> Description: SQLDescribeColW for function returning a result set
> incorrectly setting sql_nullable
> Details:
>
> create table TSET1 (RNUM integer not null, C1 integer, C2 char(3));
>
> create function PRES ( )
> returns setof TSET1 as
> '
> select RNUM, C1, C2 from TSET1;
> ' LANGUAGE 'sql'
> ;
>
> in ODBC test sqlPrepare { call pres } then describe the columns. first
> column should be SQL_NO_NULLS not NULLABLE.
>
> Describe Column All:
> icol, szColName,
> *pcbColName, *pfSqlType, *pcbColDef, *pibScale,
> *pfNullable
>
> 1, rnum, 4, SQL_INTEGER=4, 10, 0, SQL_NULLABLE=1
>
> 2, c1, 2, SQL_INTEGER=4, 10, 0, SQL_NULLABLE=1
>
> 3, c2, 2, SQL_WCHAR=-8, 3, 0, SQL_NULLABLE=1
I think you may want to try here, for both this and your previous bug report.
pgsql-o...@postgresql.org
http://archives.postgresql.org/pgsql-odbc/
...Robert
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5055: Invalid page header error
The following bug has been logged online: Bug reference: 5055 Logged by: john martin Email address: postgres_...@live.com PostgreSQL version: 8.3.6 Operating system: Centos 5.2 32 bit Description:Invalid page header error Details: All of a sudden we started seeing page header errors in certain queries. The messages are in the form of "ERROR: invalid page header in block of relation ". The query fails. I found may previous messages in the archives. Most, if not all, replies seemed to indicate hardware errors. I have run all the disk/memory tests like fsync and memtest86 but nothing was found. I have also rebooted is multiple times . I found an unsatisfactory work around that causes, ahem, data loss. We went ahead with it anyway fortunately because the error happened in our dev environment. IOW, we could tolerate the data loss. The work around consists of adding the following parameter to postgresql.conf and restarting postgres. "zero_damaged_pages=TRUE" We no longer see the error messages with the above work around. Needless to say, the work around cannot be used in production. But the database is running on the SAME HARDWARE. Is it possible that it is a postgres bug? I found the issue reported 5 years back to my surprise. http://archives.postgresql.org/pgsql-hackers/2004-09/msg00869.php I am urging the community to investigate the possibility that it may not be hardware related, especially since it was first reported at least 5 years back. Or may be you have decided not to fix if the number of people reporting is very less. I have a very good opinion of postgres quality. While I am not 100% sure it is a bug (only circumstantial evidence), I do think it improves the product quality to fix an annoying old bug. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5055: Invalid page header error
On Mon, 2009-09-14 at 23:17 +, john martin wrote: > All of a sudden we started seeing page header errors in certain queries. Was there any particular event that marked the onset of these issues? Anything in the system logs (dmesg / syslog etc) around that time? [for SATA disks]: does smartctl from the smartmontools package indicate anything interesting about the disk(s)? (Ignore the "health status", it's a foul lie, and rely on the error log plus the vendor attributes: reallocated sector count, pending sector, uncorrectable sector count, etc). Was Pg forcibly killed and restarted, or the machine hard-reset? (This _shouldn't_ cause data corruption, but might give some starting point for looking for a bug). > I am urging the community to investigate the possibility that it may not be > hardware related, especially since it was first reported at least 5 years > back. If anything, the fact that it was first reported 5 years back makes it _more_ likely to be hardware related. Bad hardware eats/scrambles some of your data; Pg goes "oh crap, that page is garbage". People aren't constantly getting their data eaten, though, despite the age of the initial reports. It's not turning up lots. It's not turning up in cases where hardware issues can be ruled out. There doesn't seem to be a strong pattern associating issues to a particular CPU / disk controller / drive etc to suggest it could be Pg triggering a hardware bug or a bug in Pg triggered by a hardware quirk. It doesn't seem to be reproducible and people generally don't seem to be able to trigger the issue repeatedly. Either it's a *really* rare and quirky bug that's really hard to trigger, or it's a variety of hardware / disk issues. If it's a really rare and quirky hard to trigger bug, where do you even start looking without *some* idea what happened to trigger the issue? Do you have any idea what might've started it in your case? *** DID YOU TAKE COPIES OF YOUR DATA FILES BEFORE "FIXING" THEM *** ? -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5055: Invalid page header error
Craig Ringer wrote: [for SATA disks]: does smartctl from the smartmontools package indicate anything interesting about the disk(s)? (Ignore the "health status", it's a foul lie, and rely on the error log plus the vendor attributes: reallocated sector count, pending sector, uncorrectable sector count, etc). 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 the RAID controller or host md-raid to do anything about it. this results in a very sneaky sort of data corruption which goes undetected until some time later. this is the primary reason to use the premium "ES" grade SATA drives rather than the cheaper desktop stuff in a raid, they return sector errors in a timely fashion rather than retrying for many minutes in the background. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5054: PDO -> Query returns "" from Boolean type field, if it has false value.
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 Postgres bug.
regards, tom lane
Does seem to be a PDO bug or some sort:
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, 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 on bugs.php.net.
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
Re: [BUGS] BUG #5054: PDO -> Query returns "" from Boolean type field, if it has false value.
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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5055: Invalid page header error
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 the RAID controller or host md-raid to do > anything about it. this results in a very sneaky sort of data > corruption which goes undetected until some time later. > > > this is the primary reason to use the premium "ES" grade SATA drives > rather than the cheaper desktop stuff in a raid, they return sector > errors in a timely fashion rather than retrying for many minutes in the > background. Ugh, really? What do the desktop drives return in the mean time, when they haven't been able to read a sector properly? Make something up and hope it gets written to soon? That seems too hacky even for desktop HDD firmware, which is saying something. I've generally seen fairly prompt failure responses from desktop-grade drives (and I see a lot of them fail!). While there are usually many layers of OS-driven retries above the drive that delay reporting of errors, the RAID volume the drive is a member of will generally block until a retry succeeds or the OS layers between the software RAID implementation and the disk give up and pass on the disk's error report. That said, I've mostly used Linux's `md' software RAID, which while imperfect seems to be pretty sane in terms of data preservation. -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] GIN needs tonic
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 value of the node is unset.
> That means XLOG_GIN_INSERT_LISTPAGE always has specNode == 0 and so
> triggers the assertion failure.
Yeah, so it seems. The fix should be as simple as:
--- a/src/backend/access/gin/ginfast.c
+++ b/src/backend/access/gin/ginfast.c
@@ -121,6 +121,7 @@ writeListPage(Relation index, Buffer buffer,
rdata[1].len = size;
rdata[1].next = NULL;
+ data.node = index->rd_node;
data.blkno = BufferGetBlockNumber(buffer);
data.rightlink = rightlink;
data.ntuples = ntuples;
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 function. That's
harmless, but bloats the WAL record unnecessary. In fact it might be
better to never do full-page writes for that record type, since it
completely overwrites the page anyway.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
