-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
> please send function xfunc. Your code looks well.
> please try sql function
> ...
> has it same behave like plpgsql function?
Yes, result is the same - it returns 2008-11-01
I made further investigation - it seems the problem is here betwee
2009/9/9 Martin Edlman :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello,
>
>> please send function xfunc. Your code looks well.
>> please try sql function
>> ...
>> has it same behave like plpgsql function?
>
> Yes, result is the same - it returns 2008-11-01
>
> I made further investig
vyouzhi escribió:
> #!/usr/bin/env python
> #coding=utf-8
> import _pg
> import threading
>
> con =
> _pg.connect(host='127.0.0.1',user='work',dbname='work',passwd='123',port=543
> 2)
>
> def link_url():
> global con
> for i in range(100):
> print i
> stock_sql = "INSERT
The following bug has been logged online:
Bug reference: 5045
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 c
On Wed, Sep 9, 2009 at 5:41 AM, mahmoud badr wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5045
> Logged by: mahmoud badr
> Email address: alien_...@yahoo.com
> PostgreSQL version: 8.4
> Operating system: windows
> Description:java developer
For those of you who are still looking at this, I tried to reproduce the issue
by holding one of the WAL files open with another program (just opened it with
the cygwin build of less.exe for windows). That didn't do the trick. It
prevented unlink or rename from working at all. I wrote a progr
Luke Koops wrote:
> For those of you who are still looking at this, I tried to reproduce the
> issue by holding one of the WAL files open with another program (just opened
> it with the cygwin build of less.exe for windows). That didn't do the trick.
> It prevented unlink or rename from workin
Heikki Linnakangas writes:
> One option is to rename the file before deleting it.
I was under the impression that renaming would fail in the same cases
where deletion fails, ie something else holding the file open ...
regards, tom lane
--
Sent via pgsql-bugs mailing lis
Tom,
If you first delete the file and it goes into deletion pending, then
subsequent attempts to rename or delete will fail.
Heikki is proposing that the file be renamed before it is first deleted.
-Luke
> -Original Message-
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Luke Koops writes:
> Heikki is proposing that the file be renamed before it is first
> deleted.
Indeed, and what I'm saying is that that will still fail if some
unhelpful program is holding the file open without FILE_SHARE_DELETE.
Which is what I understood your case to be ...
My case is that a backend was holding the file open. It was not some other
unhelpful program. That's why I had to write a program that held the file open
with the same flags that postgres uses (including FILE_SHARE_DELETE).
We have a process that wrote to the DB, and then for many days it only
Tom Lane wrote:
> Luke Koops writes:
>> Heikki is proposing that the file be renamed before it is first
>> deleted.
>
> Indeed, and what I'm saying is that that will still fail if some
> unhelpful program is holding the file open without FILE_SHARE_DELETE.
> Which is what I understood yo
Heikki Linnakangas writes:
> No, it's a backend that's holding the file open, with FILE_SHARE_DELETE.
If that's the only case we care about covering, then rename might be
enough. I was just wondering what it would take to solve the more
general problem of something holding it open with the wrong
I have applications that require IEEE floating-point data
to remain unchanged to the last bit after a dump/restore
cycle. Currently on all our linux systems, pg_dump uses
8 significant figures (FLT_DIG + 2) to dump 32-bit reals
and 17 significant figures (DBL_DIG + 2) to dump 64-bit
doubles, wh
Keh-Cheng Chu writes:
> While 17 decimal digits are sufficient to guarantee the
> complete recovery of all 64-bit double values, some 32-bit
> reals actually require NINE significant figures.
Hm, annoying. Seems like we could do one of two things:
1. Increase the max extra_float_digits value
On Wed, Sep 9, 2009 at 6:04 PM, Tom Lane wrote:
> Keh-Cheng Chu writes:
>> While 17 decimal digits are sufficient to guarantee the
>> complete recovery of all 64-bit double values, some 32-bit
>> reals actually require NINE significant figures.
>
> Hm, annoying. Seems like we could do one of two
Tom Lane wrote:
> Heikki Linnakangas writes:
>> No, it's a backend that's holding the file open, with FILE_SHARE_DELETE.
>
> If that's the only case we care about covering, then rename might be
> enough. I was just wondering what it would take to solve the more
> general problem of something hol
17 matches
Mail list logo
