On Wed, May 24, 2006 at 12:16:13AM +0200, Florian G. Pflug wrote:
> >BSD signal semantics (what postgres uses) make all system calls
> >restart across signals. Thus, a system call can never return EINTR
> >unless you have non-blocking I/O enabled. These programs would be
> >confused by unexpected E
Martijn van Oosterhout wrote:
On Mon, May 22, 2006 at 12:52:33PM -0400, Greg Stark wrote:
"Rafael Martinez, Guerrero" <[EMAIL PROTECTED]> writes:
Why do you think 'intr' is a bad thing, from man pages:
" If an NFS file operation has a major timeout and it is
hard mounted, then allo
On Mon, May 22, 2006 at 12:52:33PM -0400, Greg Stark wrote:
> "Rafael Martinez, Guerrero" <[EMAIL PROTECTED]> writes:
>
> > Why do you think 'intr' is a bad thing, from man pages:
> > " If an NFS file operation has a major timeout and it is
> > hard mounted, then allow signals to inte
"Rafael Martinez, Guerrero" <[EMAIL PROTECTED]> writes:
> Why do you think 'intr' is a bad thing, from man pages:
> " If an NFS file operation has a major timeout and it is
> hard mounted, then allow signals to interupt the file operation and
> cause it to return EINTR to the cal
On Mon, 2006-05-22 at 04:12, Rafael Martinez, Guerrero wrote:
> On Mon, 2006-05-22 at 10:25, Greg Stark wrote:
> > Using TCP with NFS is only really helpful when you have a high latency high
> > bandwidth link which isn't going to be a terribly positive environment for
> > postgres.
> >
>
> Well,
SODA Noriyuki <[EMAIL PROTECTED]> writes:
> On 22 May 2006 03:00:55 -0400, Greg Stark <[EMAIL PROTECTED]> said:
> + gcircle_tbl | t
> + gpolygon_tbl| t
>> This seems pretty mystifying. Perhaps it's leftover stuff from the
>> tablespace that failed to get dropped?
> No.
> Because
Am Montag, 22. Mai 2006 11:30 schrieb Rafael Martinez, Guerrero:
> Our experience with NFS on linux is that not always works as is suppose
> to do. Yes, it works ok in many cases and yes, it works ok for some type
> of applications but it does not work for the level of reliability and
> integrity w
On Mon, May 22, 2006 at 04:34:34PM +0900, SODA Noriyuki wrote:
> These two "tablespace not empty" results both came from NFS mounts.
> (I should have said that explicitly, sorry.)
> So, this means the REMOVE RPC sometimes may overtake other RPCs?
> Hmm...
Maybe an explicit fsync() is needed on the
On Mon, 2006-05-22 at 11:00, Peter Eisentraut wrote:
> Am Montag, 22. Mai 2006 09:17 schrieb Rafael Martinez, Guerrero:
> > To have a database on a NFS filesystem is a disaster waiting to happen,
> > specially if the NFS server is running on Linux. Not to talk on the
> > performance penalty of runn
On Mon, 2006-05-22 at 10:25, Greg Stark wrote:
> Using TCP with NFS is only really helpful when you have a high latency high
> bandwidth link which isn't going to be a terribly positive environment for
> postgres.
>
Well, having a protocol that by definition says that datagrams may
arrive out of
Am Montag, 22. Mai 2006 09:17 schrieb Rafael Martinez, Guerrero:
> To have a database on a NFS filesystem is a disaster waiting to happen,
> specially if the NFS server is running on Linux. Not to talk on the
> performance penalty of running the database via NFS.
With all due respect, this is a bu
"Rafael Martinez, Guerrero" <[EMAIL PROTECTED]> writes:
> I would say that anything is better than NFS for running a database. But
> if you absolutely have to use NFS, run NFS via TCP not UDP, use hard and
> turn off all cache . In the server side we are talking about 'sync'
> and 'no_wdelay'
> On 22 May 2006 03:00:55 -0400, Greg Stark <[EMAIL PROTECTED]> said:
> That said I would have expected a good NFS server to still live up to
> everything important as long as the server doesn't actually crash or get shut
> down at any point.
> I certainly would have expected tmpfs to live up
On Mon, 2006-05-22 at 06:15, SODA Noriyuki wrote:
Hei
> We've encountered failures of "make check", when we put PostgreSQL
> data directory on a NFS filesystem or a tmpfs filesystem.
> It doesn't always fail, but fails occasionally.
>
To have a database on a NFS filesystem is a disaster waiting
SODA Noriyuki <[EMAIL PROTECTED]> writes:
> NFS server:
> OS version: Fedora Core 3 Linux
> "async" is specified in /etc/exports, thus the server violates
> the NFS protocol, and replys to requests before it stores
> changes to its disk.
The reason the protocol is speced the wa
Thanks for the reply.
> On Mon, 22 May 2006 01:05:38 -0400, Tom Lane <[EMAIL PROTECTED]> said:
> SODA Noriyuki <[EMAIL PROTECTED]> writes:
>> We've encountered failures of "make check", when we put PostgreSQL
>> data directory on a NFS filesystem or a tmpfs filesystem.
>> It doesn't always f
SODA Noriyuki <[EMAIL PROTECTED]> writes:
> We've encountered failures of "make check", when we put PostgreSQL
> data directory on a NFS filesystem or a tmpfs filesystem.
> It doesn't always fail, but fails occasionally.
Is the NFS filesystem mounted fail-soft?
As a rule, database people will tel
Hi,
We've encountered failures of "make check", when we put PostgreSQL
data directory on a NFS filesystem or a tmpfs filesystem.
It doesn't always fail, but fails occasionally.
Is this expected behavior of PostgreSQL?
If it's expected, what is the reason of this symptom?
I grep'ed the source cod
18 matches
Mail list logo
