[BUGS] BUG #4539: to_char(to_timestamp('...','....')) returns the wrong result

[Stuart Green]

The following bug has been logged online:

Bug reference:  4539
Logged by:  Stuart Green
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.2.11
Operating system:   Centos 5
Description:to_char(to_timestamp('...','')) returns the wrong
result
Details: 

The query 

select to_char(to_timestamp('2008-11-14 16:00:00','-MM-DD
HH24:MM:SS'),'day');

is returning monday as the day in all the dbase version I Have test, 8.2.11,
8.2.10, and 8.1.11

The query 

select to_char(to_timestamp('2008-11-14','-MM-DD'),'day');

returns friday, which is correct, if you replace to_timestamp with to_date
it returns friday which is correct.

Specify the 24 hour clock or not in the timestamp query doesn't make a
difference in the result, it still returns monday, when it should be friday.

-- 
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] substring with this pattern works in 8.3.1; does not work in 8.3.4

[Tomasz Ostrowski]

On 2008-11-12 19:07, Chris Wood wrote:

> here is where it works in 8.3.1:
> CONSTRAINT public_phone_ch CHECK (((public_phone = ''::text) OR
> ("substring"(public_phone, '^[0-9]{10}(,[0-9]{10})*$'::text) IS NOT NULL;
> protocalte=> insert into locn values(10, '1231231234') ;

8.3.1 had a bug in substring function which was corrected in 8.3.2:

http://www.postgresql.org/docs/8.3/static/release-8-3-2.html
Fix a corner case in regular-expression substring matching
(substring(string from pattern)) (Tom)

The problem occurs when there is a match to the pattern overall but the
user has specified a parenthesized subexpression and that subexpression
hasn't got a match. An example is substring('foo' from 'foo(bar)?').
This should return NULL, since (bar) isn't matched, but it was
mistakenly returning the whole-pattern match instead (ie, foo).

> and here is where it does not work in 8.3.4:
> ERROR:  new row for relation "locn" violates check constraint
> "public_phone_ch"

http://www.postgresql.org/docs/8.3/static/functions-matching.html#FUNCTIONS-POSIX-REGEXP
The substring function with two parameters, substring(string from
pattern), provides extraction of a substring that matches a POSIX
regular expression pattern. It returns null if there is no match,
otherwise the portion of the text that matched the pattern. But *if*
*the* *pattern* *contains* *any* *parentheses*, *the* *portion* *of*
*the* *text* *that* *matched* *the* *first* *parenthesized*
*subexpression* (the one whose left parenthesis comes first) *is*
*returned*. You can put parentheses around the whole expression if you
want to use parentheses within it without triggering this exception.

So your check should look like this:
  CONSTRAINT public_phone_ch
  CHECK (
(
  (public_phone = ''::text)
  OR
  ("substring"(public_phone, '(^[0-9]{10}(,[0-9]{10})*$)'::text)
  IS NOT NULL))
)
  );

Or much simpler and clear:
  CONSTRAINT public_phone_ch
  CHECK ( public_phone ~ '^$|^[0-9]{10}(,[0-9]{10})*$' )

> I apologize in advance for not testing  on 8.3.5,  but that would be
> very difficult for me.

It is not that difficult:

PGVERSION=2.3.5
mkdir /tmp/postgres
cd /tmp/postgres
wget \
ftp://ftp.postgresql.org/pub/source/v$PGVERSION/postgresql-$PGVERSION.tar.bz2
tar xjf postgresql-$PGVERSION.tar.bz2
cd postgresql-$PGVERSION
./configure --prefix=/tmp/postgres
make install
cd /tmp/postgres/bin
./initdb --no-locale -D /tmp/postgres/data
./postgres -p 54320 -D /tmp/postgres/data &
./psql -p 54320 postgres

postgres=# select version();
 PostgreSQL 8.3.5 on i686-pc-linux-gnu,
 compiled by GCC gcc (GCC) 4.1.2 20070925 (Red Hat 4.1.2-33)

This works for any user (besides root) on any Unix-like system.

Regards
Tometzky
-- 
...although Eating Honey was a very good thing to do, there was a
moment just before you began to eat it which was better than when you
were...
  Winnie the Pooh

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[BUGS] could not read block 77 of relation 1663/16385/388818775

[Alexandra Nitzschke]

Hi,

we encountered the following error while inserting a record into a table:

org.postgresql.util.PSQLException: ERROR: could not read block 77 of relation 1663/16385/388818775: read only 0 of 8192 
bytes


Using postgres 8.3.5

The reported object is an index.
The size of its data file is 630784 bytes.

The output of pg_filedump of block 76 is ok.
The output of pg_filedump of block 77 is the following:

***
* PostgreSQL File/Block Formatted Dump Utility - Version 8.3.0
*
* File: /tmp/388818775
* Options used: -i -f -R 77
*
* Dump created on: Thu Nov 20 11:18:26 2008
***
Error: Premature end of file encountered.


If you like we could send the data file to you.


Regards,

  A. Nitzschke



--
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] could not read block 77 of relation 1663/16385/388818775

[Craig Ringer]

Alexandra Nitzschke wrote:

Hi,

we encountered the following error while inserting a record into a table:

org.postgresql.util.PSQLException: ERROR: could not read block 77 of 
relation 1663/16385/388818775: read only 0 of 8192 bytes


This is probably a problem with your disk or filesystem. Have you 
checked your disks and file system, checked your system logs for disk 
errors, made sure your RAID array is in good condition, etc?


You should be able to fix it by REINDEXing the problem index. You can 
find out which index it is from pg_catalog, though if you just REINDEX 
the table(s) being operated on by the query that should work too.


Consider making a copy of your database and your log files before you 
REINDEX in case one of the developers thinks it might actually be caused 
by a PostgreSQL bug and wants to have a look.


--
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] could not read block 77 of relation 1663/16385/388818775

[Rafael Martinez]

Alexandra Nitzschke wrote:
> Hi,
> 
> we encountered the following error while inserting a record into a table:
> 
> org.postgresql.util.PSQLException: ERROR: could not read block 77 of
> relation 1663/16385/388818775: read only 0 of 8192 bytes
> 
> Using postgres 8.3.5
> 
> The reported object is an index.
> The size of its data file is 630784 bytes.
> 

Hello

You have probably a harware issue and data in your disk is corrupted.

Probably a reindex of this index will fix this problem. But I would take
a backup of this system right away just in case your disk is dying.

regards
-- 
 Rafael Martinez, <[EMAIL PROTECTED]>
 Center for Information Technology Services
 University of Oslo, Norway

 PGP Public Key: http://folk.uio.no/rafael/

-- 
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 #4539: to_char(to_timestamp('...','....')) returns the wrong result

[Heikki Linnakangas]

Stuart Green wrote:

select to_char(to_timestamp('2008-11-14 16:00:00','-MM-DD
HH24:MM:SS'),'day');

is returning monday as the day in all the dbase version I Have test, 8.2.11,
8.2.10, and 8.1.11


Use 'MI' instead of 'MM' for the minutes. to_timestamp is quite lenient, 
and interpretes the 00 in what you meant to be the minutes field as 
month number. As there is no month 0, it uses January.


to_timestamp is much stricter in the upcoming 8.4 release, and will 
throw an error for that query:


postgres=# select to_char(to_timestamp('2008-11-14 16:00:00','-MM-DD 
HH24:MM:SS'),'day');

ERROR:  conflicting values for "MM" field in formatting string
DETAIL:  This value contradicts a previous setting for the same field type.

--
  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

[BUGS] executing SELECT xmlelement(name foo); causes "server closed the connection unexpectedly" Error

[Sushil]

Hi,

I am trying to exploit XML features of PostgreSQL 8.3.0 DB.

I tried executing following query:

SELECT xmlelement(name foo);

from psql prompt.

I received Following error on screen:

server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!>

Environment details are:

OS: *CentOS release 5 (Final)*
DB: *PostgreSQL 8.3.0*

Following is DB server log when the query was submitted:

DEBUG:  forked new backend, pid=4411 socket=8
LOG:  connection received: host=[local]
LOG:  connection authorized: user=postgres database=testdb
DEBUG:  postmaster child[4411]: starting with (
DEBUG:  postgres
DEBUG:  -v196608
DEBUG:  -y
DEBUG:  testdb
DEBUG:  )
DEBUG:  InitPostgres
DEBUG:  StartTransaction
DEBUG:  name: unnamed; blockState:   DEFAULT; state: INPROGR, 
xid/subid/cid: 0/1/0, nestlvl: 1, children: <>
DEBUG:  CommitTransaction
DEBUG:  name: unnamed; blockState:   STARTED; state: INPROGR, 
xid/subid/cid: 0/1/0, nestlvl: 1, children: <>
DEBUG:  StartTransactionCommand
DEBUG:  StartTransaction
DEBUG:  name: unnamed; blockState:   DEFAULT; state: INPROGR, 
xid/subid/cid: 0/1/0, nestlvl: 1, children: <>
LOG:  statement: SELECT xmlelement(name foo);
DEBUG:  parse tree:
DETAIL:  {QUERY :commandType 1 :querySource 0 :canSetTag true 
:utilityStmt <>
:resultRelation 0 :intoClause <> :hasAggs false :hasSubLinks 
false :rtable <>
:jointree {FROMEXPR :fromlist <> :quals <>} :targetList 
({TARGETENTRY :expr
{XMLEXPR :op 1 :name foo :named_args <> :arg_names <> :args <> 
:xmloption 0
:type 0 :typmod 0} :resno 1 :resname xmlelement :ressortgroupref 
0 :resorigtbl
0 :resorigcol 0 :resjunk false}) :returningList <> :groupClause 
<> :havingQual
<> :distinctClause <> :sortClause <> :limitOffset <> :limitCount 
<> :rowMarks
<> :setOperations <>}

DEBUG:  rewritten parse tree:
DETAIL:  ({QUERY :commandType 1 :querySource 0 :canSetTag true 
:utilityStmt <>
:resultRelation 0 :intoClause <> :hasAggs false :hasSubLinks 
false :rtable <>
:jointree {FROMEXPR :fromlist <> :quals <>} :targetList 
({TARGETENTRY :expr
{XMLEXPR :op 1 :name foo :named_args <> :arg_names <> :args <> 
:xmloption 0
:type 0 :typmod 0} :resno 1 :resname xmlelement :ressortgroupref 
0 :resorigtbl
0 :resorigcol 0 :resjunk false}) :returningList <> :groupClause 
<> :havingQual
<> :distinctClause <> :sortClause <> :limitOffset <> :limitCount 
<> :rowMarks
<> :setOperations <>})

DEBUG:  plan:
DETAIL:  {PLANNEDSTMT :commandType 1 :canSetTag true :planTree {RESULT 
:startup_cost
0.00 :total_cost 0.01 :plan_rows 1 :plan_width 0 :targetlist 
({TARGETENTRY
:expr {XMLEXPR :op 1 :name foo :named_args <> :arg_names <> :args <>
:xmloption 0 :type 0 :typmod 0} :resno 1 :resname xmlelement 
:ressortgroupref
0 :resorigtbl 0 :resorigcol 0 :resjunk false}) :qual <> :lefttree <>
:righttree <> :initPlan <> :extParam (b) :allParam (b) 
:resconstantqual <>}
:rtable <> :resultRelations <> :utilityStmt <> :intoClause <> 
:subplans <>
:rewindPlanIDs (b) :returningLists <> :rowMarks <> :relationOids <>
:nParamExec 0}

*postgres: postgres testdb [local] SELECT: symbol lookup error: 
postgres: postgres testdb [local] SELECT: undefined symbol: 
xmlNewTextWriterMemory*
DEBUG:  reaping dead processes
DEBUG:  server process (PID 4411) exited with exit code 127
LOG:  server process (PID 4411) exited with exit code 127
LOG:  terminating any other active server processes
DEBUG:  sending SIGQUIT to process 4401
DEBUG:  sending SIGQUIT to process 4402
DEBUG:  sending SIGQUIT to process 4403
DEBUG:  sending SIGQUIT to process 4404
LOG:  all server processes terminated; reinitializing
DEBUG:  shmem_exit(0)
DEBUG:  invoking IpcMemoryCreate(size=39288832)
DEBUG:  reaping dead processes
LOG:  database system was interrupted; last known up at 2008-11-20 
03:48:07 EST
LOG:  connection received: host=[local]
FATAL:  the database system is in recovery mode
DEBUG:  checkpoint record is at 0/367B0468
DEBUG:  redo record is at 0/367B0468; shutdown TRUE
DEBUG:  next transaction ID: 0/682118; next OID: 81920
DEBUG:  next MultiXactId: 1; next MultiXactOffset: 0
LOG:  database system was not properly shut down; automatic recovery in 
progress
DEBUG:  proc_exit(1)
DEBUG:  shmem_exit(1)
DEBUG:  forked new backend, pid=4413 socket=8
DEBUG:  exit(1)
DEBUG:  reaping dead processes
DEBUG:  server process (PID 4413) exited with exit code 1
LOG:  record with zero length at 0/367B04B0
LOG:  redo is not required
DEBUG:  transaction ID wrap limit is 2147484025, limited by database 
"template1"
DEBUG:  proc_exit(0)
DEBUG:  shmem_exit(0)
DEBUG:  exit(0)
DEBUG:  reaping dead processes
LOG:  autovacuum launcher started
LOG:  database system is ready to accept 

Re: [BUGS] BUG #4529: lc_messages in config ignored

[Bruce Momjian]

Rainer Bauer wrote:
> "pro" wrote:
> 
> >The following bug has been logged online:
> >
> >Bug reference:  4529
> >Logged by:  pro
> >Email address:  [EMAIL PROTECTED]
> >PostgreSQL version: 8.3.*
> >Operating system:   windows xp sp2 eng + rus mui
> >Description:lc_messages in config ignored
> >Details: 
> >
> >messages always in russian language in 8.3.4 and 8.3.5 - utf, cp1251 on
> >earlier versions.
> >but i want english.
> >postgres ignore any definitions:
> >lc_messages = 'C'
> >or
> >lc_messages = 'english.english'
> >
> >in freebsd i have no this bug.
> 
> I have reported this bug about a month ago:
>  but never got
> any response.

Yep, we know it is a bug but haven't found a fix yet.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

-- 
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] executing SELECT xmlelement(name foo); causes "server closed the connection unexpectedly" Error

[Peter Eisentraut]

Sushil wrote:

I am trying to exploit XML features of PostgreSQL 8.3.0 DB.


You should upgrade to the latest 8.3 release, currently 8.3.5.  There 
were some fixes in this area (and other areas).



--
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 #4529: lc_messages in config ignored

[Rainer Bauer]

Hello Bruce,

Thursday, November 20, 2008, 3:20:42 PM, you wrote:
BM> Rainer Bauer wrote:
>> I have reported this bug about a month ago:
>>  but never 
>> got
>> any response.

BM> Yep, we know it is a bug but haven't found a fix yet.

Thanks, at least I know now that the first bug report did not vanish
somewhere.

What I did here was renaming the "de" directory in
C:\Program Files\PostgreSQL\8.3\share\locale
Now I have at least the English message texts (though the LC_NUMERIC
problem is still present).

"pro", you might want to rename the "ru" subdirectory. After
restarting the server all messages should be in English.

Rainer


-- 
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] could not read block 77 of relation 1663/16385/388818775

[Alexandra Nitzschke]

Hi,

we have had similar postgres problems in the past.
Please have a look at Bug 3484.

We didn't resolve the problems metioned in bug 3484. The other postgres 
developers also thought, that there are hardware
problems.
So our customer bought a new server with diffrent hardware configuration ( ... 
and NEW hardware drives ... ).
The error today encountered on the new machine. Just running under heavy load 
since two days.

We ran two file checks. One normal with no error result.
One deep scan (e2fsck -fcn) searching for corrupted blocks. No error was 
reported.

It really looks unlikely having a hardware problem now.

Here are some details about the servers:

*NEW* server:
postgres 8.3.5
SUSE 10.3
Kernel 2.6.22.19-0.1-default
Supermicro-Mainboard + 2x AMD Opteron Dual Core 2218 2,60 GHz
4x 1024MB ECC Registered DDR2 Ram ATP
3Ware 9650 4x SATA

*OLD* server:
postgres 8.3.5
SUSE 10.0
Kernel 2.6.22.6-smp
Intel-Mainboard + 2x Intel XEON 2,80 GHz 2MB FSB800
4x 1024MB ECC Registered DDR2 RAM
3Ware Raid Controller 9500S-4


Regards,

  A. Nitzschke



Craig Ringer schrieb:

Alexandra Nitzschke wrote:

Hi,

we encountered the following error while inserting a record into a table:

org.postgresql.util.PSQLException: ERROR: could not read block 77 of 
relation 1663/16385/388818775: read only 0 of 8192 bytes


This is probably a problem with your disk or filesystem. Have you 
checked your disks and file system, checked your system logs for disk 
errors, made sure your RAID array is in good condition, etc?


You should be able to fix it by REINDEXing the problem index. You can 
find out which index it is from pg_catalog, though if you just REINDEX 
the table(s) being operated on by the query that should work too.


Consider making a copy of your database and your log files before you 
REINDEX in case one of the developers thinks it might actually be caused 
by a PostgreSQL bug and wants to have a look.


--
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] could not read block 77 of relation 1663/16385/388818775

[Craig Ringer]

Alexandra Nitzschke wrote:
> Hi,
> 
> we have had similar postgres problems in the past.
> Please have a look at Bug 3484.
> 
> We didn't resolve the problems metioned in bug 3484. The other postgres
> developers also thought, that there are hardware
> problems.
> So our customer bought a new server with diffrent hardware configuration
> ( ... and NEW hardware drives ... ).
> The error today encountered on the new machine. Just running under heavy
> load since two days.

Yes, that does seem somewhat unlikely, especially if in both cases
you've only seen issues with PostgreSQL. However, I'm a bit confused
about the fact that you're seeing apparent corruption all over the place
- your earlier report mentions damaged blocks across a number of
relations, and this one is a bad index. You'd expect this sort of thing
to come up a lot on the list, so it must be assumed that there's
something a bit unusual or different about your configuration that's
either triggering a hard-to-hit bug in PostgreSQL, or that's damaging
PostgreSQL's data somehow.

Is there any chance you have EVER hard-killed the postmaster manually
(eg with "kill -9" or "kill -KILL")? If you do that and don't also kill
the backends, it's my understanding that BAD things may happen
especially if you then attempt to relaunch the postmaster.

Do you use _any_ 3rd party C extensions? Contrib modules? It doesn't
have to be in the same database, another database on the same machine
could be bad too.

Do you have any unusual workload? What is your workload like?

What procedural languages, if any, do you use? Pl/PgSQL? Pl/Perl?
Pl/Java? Pl/Python? etc. Again, in any database, not just your problem
one. If you use any other than Pl/PgSQL please also note the version of
the language interpreter/tools and in the case of Java the JVM vendor &
install method.

Does your site possibly have dodgy power? Are the servers on a UPS?

Have the servers had any crashes, kernel panics, unexpected reboots, or
hard poweroffs?

(Not that it should matter, but): Have you hard killed any backends
(kill -9 / SIGKILL)?

If you run a RAID verify using tw_cli or through the 3dm web interface,
does it report any block mismatches in the array?

--
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] could not read block 77 of relation 1663/16385/388818775

[Heikki Linnakangas]

Craig Ringer wrote:

Is there any chance you have EVER hard-killed the postmaster manually
(eg with "kill -9" or "kill -KILL")? If you do that and don't also kill
the backends, it's my understanding that BAD things may happen
especially if you then attempt to relaunch the postmaster.


There is safeguards against that. If postmaster dies, the backends 
should die quickly and gracefully too. And postmaster refuses to restart 
 until all the backends have died and detached from the shared memory 
segment.


In addition to Craig's question: have you ever experienced sudden power 
loss, or operating system crash on these machines? Have you done "kill 
-9 postmaster", "pg_ctl stop -m immediate", or similar? PostgreSQL 
should recover with no data corruption, of course, but if there's a bug 
somewhere, it would help to know where to look.


--
  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

Re: [BUGS] could not read block 77 of relation 1663/16385/388818775

[Tom Lane]

Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Craig Ringer wrote:
>> Is there any chance you have EVER hard-killed the postmaster manually
>> (eg with "kill -9" or "kill -KILL")?

> There is safeguards against that. If postmaster dies, the backends 
> should die quickly and gracefully too. And postmaster refuses to restart 
>   until all the backends have died and detached from the shared memory 
> segment.

A sufficiently bull-headed DBA can defeat those safeguards though ---
from memory, manually removing postmaster.pid and then starting a new
postmaster while old backends remain alive is the ticket to data
corruption.

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] executing SELECT xmlelement(name foo); causes "server closed the connection unexpectedly" Error

[Sushil]

I tried installing following RPMs

postgresql-8.3.5-1PGDG.rhel5.x86_64.rpm
postgresql-libs-8.3.5-1PGDG.rhel5.x86_64.rpm
postgresql-server-8.3.5-1PGDG.rhel5.x86_64.rpm

still this issue is appearing.

is there any thing i am missing?

Please advise.

Thanks,

Peter Eisentraut wrote:
> Sushil wrote:
>> I am trying to exploit XML features of PostgreSQL 8.3.0 DB.
>
> You should upgrade to the latest 8.3 release, currently 8.3.5.  There 
> were some fixes in this area (and other areas).
>
>

The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy the original message all 
copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email.

Please do not print this email unless it is absolutely necessary.begin:vcard
fn:Sushil Dive
n:;Sushilchandra Dive
org:Vertex Software Pvt Ltd;Delivery
adr:;;;Pune;MH;;IN
email;internet:[EMAIL PROTECTED]
tel;work:+91 20 6604 1500 Ex. 554
x-mozilla-html:TRUE
version:2.1
end:vcard


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs