General discussion

Chetan Suttraway | 1 Aug 2011 08:28

Re: PostgreSQL installation in Windows 7: Error 1935

On Mon, Aug 1, 2011 at 3:00 AM, Aakash Goel <catchyouraakash <at> gmail.com> wrote:

Hi,

I am having some trouble installing the db on my Windows 7 machine.

Whenever I try to install from postgresql-9.0.4-1-windows_x64.exe, I get these errors:

http://i.imgur.com/gNCrR.png

http://i.imgur.com/yEVxT.png

Any help is appreciated. Thanks,

Aakash

Please refer the below links:
1.
http://archives.postgresql.org/pgsql-bugs/2010-10/msg00107.php

2.
http://answers.microsoft.com/en-us/office/forum/office_2007-office_install/error-1935-when-installing-microsoft-office-2007/303b4ab8-abac-413b-8275-af358feef934

3.
http://blogs.msdn.com/astebner/archive/2005/11/10/491653.aspx
http://forums.techarena.in/vista-help/797226.htm
source: http://forums.enterprisedb.com/posts/list/1840.page

Please share the related findings.

Regards,
Chetan

--

EnterpriseDB Corporation
The Enterprise PostgreSQL Company

Website: www.enterprisedb.com

EnterpriseDB Blog : http://blogs.enterprisedb.com

Follow us on Twitter : http://www.twitter.com/enterprisedb

headers

Deniz Atak | 1 Aug 2011 08:27

Re: ERROR: could not read block 4707 of relation 1663/16384/16564: Success

Deepak, Tom thanks for answering.

Tom, we have psql 8.1.18. So you are right, this weird message is because of the old version. I will check with my colleague about the possible reasons. What can I do if there is a messed up table?

Regards,
Deniz

On Sat, Jul 30, 2011 at 11:45 PM, Tom Lane <tgl <at> sss.pgh.pa.us> wrote:

Deniz Atak <denizatak <at> gmail.com> writes:
> I am using postgresql on Glassfish server and I have EJB 3.0 for ORM. I am
> trying to run a query in PSQL but receiving following error:

> Local Exception Stack:
> Exception [EclipseLink-4002] (Eclipse Persistence Services -
> 2.0.0.v20091031-r5713): org.eclipse.persistence.exceptions.DatabaseException
> Internal Exception: org.postgresql.util.PSQLException: ERROR: could not read
> block 4707 of relation 1663/16384/16564: Success

What Postgres server version is that?

If it's 8.2 or older, this probably indicates a partial block at the end
of the file. Newer versions produce a more sensible error message for
the case, but that's just cosmetic --- the real problem is a messed-up
table. Have you had a filesystem corruption or an out-of-disk-space
condition on this machine?

regards, tom lane

headers

kalyan kumar | 1 Aug 2011 07:35

Database backup to network folder

Hi,

I am using Postgre SQL 8.3, where I want to backup my entire database. For the same I am using pg_dump.exe. I am able to take the backup of my database in to my local machine. If I want to take the backup into network folder, how to pass "-f" parameter to pg_dump.exe. I am using SMB to implement file copy to network folder.

Thanks in advance.

Regards

Kalyan Kumar Sai

headers

D M | 1 Aug 2011 09:08

Re: ERROR: could not read block 4707 of relation 1663/16384/16564: Success

I am not sure how big your table is one way we implemented here was we selected the clean rows and outputted it to a csv file. And the rows affected we had to load from the backup, luckily we had the clean backup.

Ex: assume you have 1,2,3,4,5....100 rows and the corrupted is between 60-70. I outputted clean rows from 1-59 and 71-100 to a csv file and loaded in a new table. The corrupted was loaded back from a table. This just One of doing it. There might be more the experts here can answer very well. I am interested to see others answers as well.

My way is time consuming and if you have a very large table or tables affected it's a nightmare to fix them.

Good luck with your recovery.

Thanks

Deepak

On Jul 31, 2011, at 11:27 PM, Deniz Atak <denizatak <at> gmail.com> wrote:

Deepak, Tom thanks for answering.

Tom, we have psql 8.1.18. So you are right, this weird message is because of the old version. I will check with my colleague about the possible reasons. What can I do if there is a messed up table?

Regards,
Deniz

On Sat, Jul 30, 2011 at 11:45 PM, Tom Lane <tgl <at> sss.pgh.pa.us> wrote:

Deniz Atak <denizatak <at> gmail.com> writes:
> I am using postgresql on Glassfish server and I have EJB 3.0 for ORM. I am
> trying to run a query in PSQL but receiving following error:

> Local Exception Stack:
> Exception [EclipseLink-4002] (Eclipse Persistence Services -
> 2.0.0.v20091031-r5713): org.eclipse.persistence.exceptions.DatabaseException
> Internal Exception: org.postgresql.util.PSQLException: ERROR: could not read
> block 4707 of relation 1663/16384/16564: Success

What Postgres server version is that?

If it's 8.2 or older, this probably indicates a partial block at the end
of the file. Newer versions produce a more sensible error message for
the case, but that's just cosmetic --- the real problem is a messed-up
table. Have you had a filesystem corruption or an out-of-disk-space
condition on this machine?

regards, tom lane

headers

Simon Riggs | 1 Aug 2011 09:36

Re: repmgr and archive_mode

On Sat, Jul 30, 2011 at 7:57 AM, Toby Corkindale
<toby.corkindale <at> strategicdata.com.au> wrote:

> Many thanks for clearing that up! I hadn't realised that you could only change one of the two options on the fly.

The streaming rep options require a restart also...

-- 
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

--

-- 
Sent via pgsql-general mailing list (pgsql-general <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

headers

Tomas Vondra | 1 Aug 2011 12:21

Re: ERROR: could not read block 4707 of relation 1663/16384/16564: Success

On 1 Srpen 2011, 8:27, Deniz Atak wrote:
> Deepak, Tom thanks for answering.
>
> Tom, we have psql 8.1.18. So you are right, this weird message is because
> of
> the old version. I will check with my colleague about the possible
> reasons.
> What can I do if there is a messed up table?

First of all, you should find out what caused the mess. This could be
really difficult as it might be a rare hw or sw glitch. Anyway consider
upgrading to 8.1.23 if possible.

If you have a fresh backup (i.e. one with all the data in the table), just
restore it and use it. You may even use just this particular table (just
move it using COPY).

If you need to recover the data, you'll have to play a bit with it as you
need to 'skip' all the corrupted blocks. The  query reports block 4707 is
corrupted - how many blocks does the relation have?

You can skip the blocks using 'ctid' column, which is basically "(block
id, item id)" so to skip block 4707 you can do this

SELECT * FROM table WHERE (ctid < '(4707,0)'::ctid OR ctid >=
'(4708,0)'::ctid)

and if fails with another "could not read block" error, put there another
such condition.

Tomas

--

-- 
Sent via pgsql-general mailing list (pgsql-general <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

headers

Deniz Atak | 1 Aug 2011 13:55

Re: ERROR: could not read block 4707 of relation 1663/16384/16564: Success

Hi Thomas,

thanks for your answer. We decided not to go further with this error, because soon we will have another product that replaces this one. Because I want to learn more about this topic, I did the following:

Before I write your code, I tried:
select oid,ctid,relname from pg_class where ctid='(4707,0)';

but it resulted in:
oid | ctid | relname
-----+------+---------
(0 rows)

Isn't there suppose to be a ctid of '(4707,0)'? Or did I misunderstand what you have written?

Regards,
Deniz

On Mon, Aug 1, 2011 at 1:21 PM, Tomas Vondra <tv <at> fuzzy.cz> wrote:

On 1 Srpen 2011, 8:27, Deniz Atak wrote:
> Deepak, Tom thanks for answering.
>
> Tom, we have psql 8.1.18. So you are right, this weird message is because
> of
> the old version. I will check with my colleague about the possible
> reasons.
> What can I do if there is a messed up table?

First of all, you should find out what caused the mess. This could be
really difficult as it might be a rare hw or sw glitch. Anyway consider
upgrading to 8.1.23 if possible.

If you have a fresh backup (i.e. one with all the data in the table), just
restore it and use it. You may even use just this particular table (just
move it using COPY).

If you need to recover the data, you'll have to play a bit with it as you
need to 'skip' all the corrupted blocks. The query reports block 4707 is
corrupted - how many blocks does the relation have?

You can skip the blocks using 'ctid' column, which is basically "(block
id, item id)" so to skip block 4707 you can do this

SELECT * FROM table WHERE (ctid < '(4707,0)'::ctid OR ctid >=
'(4708,0)'::ctid)

and if fails with another "could not read block" error, put there another
such condition.

Tomas

headers

Deniz Atak | 1 Aug 2011 10:25

Re: ERROR: could not read block 4707 of relation 1663/16384/16564: Success

Hi Deepak,

thanks for your answer. Do you have any opinion about how can I find the corrupted rows? Do you know how to read:

"could not read block 4707 of relation 1663/16384/16564"

?
Also, there is one interesting thing: a very similar query like this:

select src_ip,round(sum(size)/175) from table where date>'2011.07.29' and l_date<'2011.07.30' and src_ip='255.255.255.255' group by src_ip;

works fine. But this one doesn't:
select src_ip,round((select sum(t1.size) from table t1)) from table where date>'2011.07.29' and date<'2011.07.30' and src_ip='255.255.255.255'
group by src_ip;

Regards,
Deniz

On Mon, Aug 1, 2011 at 10:08 AM, D M <dm.aeqa <at> gmail.com> wrote:

I am not sure how big your table is one way we implemented here was we selected the clean rows and outputted it to a csv file. And the rows affected we had to load from the backup, luckily we had the clean backup.

Ex: assume you have 1,2,3,4,5....100 rows and the corrupted is between 60-70. I outputted clean rows from 1-59 and 71-100 to a csv file and loaded in a new table. The corrupted was loaded back from a table. This just One of doing it. There might be more the experts here can answer very well. I am interested to see others answers as well.

My way is time consuming and if you have a very large table or tables affected it's a nightmare to fix them.

Good luck with your recovery.

Thanks

Deepak

On Jul 31, 2011, at 11:27 PM, Deniz Atak <denizatak <at> gmail.com> wrote:

Deepak, Tom thanks for answering.

Tom, we have psql 8.1.18. So you are right, this weird message is because of the old version. I will check with my colleague about the possible reasons. What can I do if there is a messed up table?

Regards,
Deniz

On Sat, Jul 30, 2011 at 11:45 PM, Tom Lane <tgl <at> sss.pgh.pa.us> wrote:

Deniz Atak <denizatak <at> gmail.com> writes:
> I am using postgresql on Glassfish server and I have EJB 3.0 for ORM. I am
> trying to run a query in PSQL but receiving following error:

> Local Exception Stack:
> Exception [EclipseLink-4002] (Eclipse Persistence Services -
> 2.0.0.v20091031-r5713): org.eclipse.persistence.exceptions.DatabaseException
> Internal Exception: org.postgresql.util.PSQLException: ERROR: could not read
> block 4707 of relation 1663/16384/16564: Success

What Postgres server version is that?

If it's 8.2 or older, this probably indicates a partial block at the end
of the file. Newer versions produce a more sensible error message for
the case, but that's just cosmetic --- the real problem is a messed-up
table. Have you had a filesystem corruption or an out-of-disk-space
condition on this machine?

regards, tom lane

headers

Clodoaldo Neto | 1 Aug 2011 16:09

Error: operator does not exist: integer = integer

postgresql.x86_64                             8.3.14-1PGDG.rhel5
postgresql-server.x86_64                      8.3.14-1PGDG.rhel5

ERROR: operator does not exist: integer = integer
LINE 3:            inner join vendedor as v on a.vendedor_id = v.id
                                                             ^
HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts.

Any ideas?

Regards, Clodoaldo

headers

Tomas Vondra | 1 Aug 2011 16:13

Re: ERROR: could not read block 4707 of relation 1663/16384/16564: Success

On 1 Srpen 2011, 13:55, Deniz Atak wrote:
> Hi Thomas,
>
> thanks for your answer. We decided not to go further with this error,
> because soon we will have another product that replaces this one. Because
> I
> want to learn more about this topic, I did the following:
>
> Before I write your code, I tried:
> select oid,ctid,relname from pg_class where ctid='(4707,0)';

You need to select from the relation with relfileid 16564, not from
pg_class. Use this

SELECT relname FROM pg_class WHERE relfilenode = 16564;

and then select from this relation.

And if you want to see the items on block 4707, you can do something like
this:

SELECT * FROM relation WHERE ctid >= '(4707,0)' AND ctid < '(4708,0)';

although it'll probably fail. Maybe "pageinspect" contrib module will tell
you more about the page
(http://www.postgresql.org/docs/current/static/pageinspect.html).

Tomas

--

-- 
Sent via pgsql-general mailing list (pgsql-general <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

650	May 2013
782	April 2013
633	March 2013
826	February 2013
864	January 2013
834	December 2012
964	November 2012
850	October 2012
951	September 2012
822	August 2012
642	July 2012
734	June 2012
757	May 2012
676	April 2012
977	March 2012
804	February 2012
811	January 2012
908	December 2011
1140	November 2011
1062	October 2011
1104	September 2011
1023	August 2011
865	July 2011
923	June 2011
977	May 2011
1030	April 2011
1067	March 2011
989	February 2011
871	January 2011
1043	December 2010
1200	November 2010
1130	October 2010
1108	September 2010
869	August 2010
1009	July 2010
1325	June 2010
1127	May 2010
1140	April 2010
1179	March 2010
1158	February 2010
1339	January 2010
1152	December 2009
1216	November 2009
1197	October 2009
1221	September 2009
1243	August 2009
1433	July 2009
1404	June 2009
1185	May 2009
1192	April 2009
1360	March 2009
1330	February 2009
1171	January 2009
952	December 2008
1408	November 2008
1473	October 2008
1230	September 2008
1177	August 2008
1228	July 2008
1046	June 2008
1126	May 2008
1426	April 2008
1658	March 2008
1499	February 2008
1578	January 2008
1466	December 2007
1747	November 2007
1679	October 2007
1367	September 2007
1863	August 2007
1225	July 2007
1752	June 2007
1592	May 2007
1262	April 2007
1696	March 2007
1706	February 2007
1911	January 2007
1575	December 2006
1847	November 2006
1573	October 2006
1272	September 2006
1474	August 2006
1152	July 2006
1242	June 2006
1576	May 2006
1357	April 2006
1570	March 2006
1202	February 2006
1705	January 2006
1383	December 2005
1398	November 2005
1900	October 2005
1207	September 2005
813	August 2005
1306	July 2005
1383	June 2005
1350	May 2005
1409	April 2005
1613	March 2005
1496	February 2005
1848	January 2005
1333	December 2004
1508	November 2004
1544	October 2004
1338	September 2004
1628	August 2004
952	July 2004
1215	June 2004
926	May 2004
1184	April 2004
1155	March 2004
1326	February 2004
1650	January 2004
1639	December 2003
1737	November 2003
1549	October 2003
1867	September 2003
1733	August 2003
1611	July 2003
1934	June 2003
1285	May 2003
1568	April 2003
1545	March 2003
1650	February 2003
1621	January 2003
1226	December 2002
1471	November 2002
1429	October 2002
1402	September 2002
1228	August 2002
1854	July 2002
1329	June 2002
1185	May 2002
1048	April 2002
1	December 2000
6	November 2000
5	October 2000
2	September 2000
2	April 2000
1	October 1996

Mon	Tue	Wed	Thu	Fri	Sat	Sun

1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30	31