On Sun, 1 Jan 2006, Greg Stark wrote:
>
> "Qingqing Zhou" <[EMAIL PROTECTED]> writes:
>
> > The problem of above is if a signal sneaks in, these syscalls will fail.
> > With a retry, we can fix it.
>
> It's a bit stickier than that but only a bit. If you just retry then you're
> saying users have
On 2005-12-31, Martijn van Oosterhout wrote:
> You do bring up the possibility of secondary sort functions. Functions
> which are not involved in testing for equality, but provide addition
> sorting so that even in a case-insensetive sort, the different
> variations in case appear together. "All v
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> The problem of above is if a signal sneaks in, these syscalls will fail.
> With a retry, we can fix it.
It's a bit stickier than that but only a bit. If you just retry then you're
saying users have to use kill -9 to get away from the situation. For
"Greg Stark" <[EMAIL PROTECTED]> wrote
>
> Well NFS is only going to affect filesystem calls. If there are other
> syscalls
> that can signal EINTR on some obscure platform where Postgres isn't
> handling
> it then that's just a run-of-the-mill porting issue.
>
Ok, NFS just affects filesystem c
Doug Royer <[EMAIL PROTECTED]> writes:
> The 'intr' option to NFS is not the same as EINTR. It
> it means 'if the server does not respond for a while,
> then return an EINTR', just like any other disk read()
> or write() does when it fails to reply.
No, you're thinking of 'soft'. 'intr' (which i
As a user and a list lurker I very much like Bruce's proposed ALTER
TABLE syntax. COPY LOCK (and the variants I can imagine being required
for all the other types of cases) don't seem as appealing.
And ALTER TABLE seems to make it clear it is an object level change,
feels like it fits the inte
EINTR on read() or write() is not unique to NFS.
It can happen on many file systems - it is just seen
less frequently on most of them.
The code should be able to handle ANY valid read()
and write() errno. And EINTR is documented on Linux, BSD,
Solaris (1 and 2), and POSIX.
Even the Linux man pa
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> In experimenting I needed to set this at 20 for it to bite much. If we
> wanted to fine tune it I'd be inclined to say that we wanted
> 20*connections buffers for the first, say, 50 or 100 connections and 10
> or 16 times for each connection over tha
Rod Taylor <[EMAIL PROTECTED]> writes:
> Are there issues with having an archive_command which does things with
> NFS based filesystems?
Well, whatever command you use for archive_command -- probably just "cp" if
you're using NFS would hang if the NFS server went away. What would happen
then mig
On Sat, 31 Dec 2005, Greg Stark wrote:
>
> Qingqing Zhou <[EMAIL PROTECTED]> writes:
>
> >
> > Is that by default the EINTR is truned off in NFS? If so, I don't see that
> > will be a problem. Sorry for my limited knowledge, is there any
> > requirements/benefits that people turn on EINTR?
>
> Th
Qingqing Zhou <[EMAIL PROTECTED]> writes:
> On Sat, 31 Dec 2005, Greg Stark wrote:
>
> >
> > I don't think that's reasonable. The NFS intr option breaks the traditional
> > unix filesystem semantics which breaks a lot of older or naive programs. But
> > that's no reason to decide that Postgres c
On Sat, Dec 31, 2005 at 04:46:02PM -0500, Qingqing Zhou wrote:
> Is that by default the EINTR is truned off in NFS? If so, I don't see that
> will be a problem. Sorry for my limited knowledge, is there any
> requirements/benefits that people turn on EINTR?
I wont speak for anyone else, but the rea
On Sat, 31 Dec 2005, Greg Stark wrote:
>
> I don't think that's reasonable. The NFS intr option breaks the traditional
> unix filesystem semantics which breaks a lot of older or naive programs. But
> that's no reason to decide that Postgres can't handle the new semantics.
>
Is that by default t
Qingqing Zhou <[EMAIL PROTECTED]> writes:
> On Sat, 31 Dec 2005, Tom Lane wrote:
> >
> > What I'd rather do is document prominently that running a DB over NFS
> > isn't recommended, and running it over NFS with interrupts allowed is
> > just not going to work.
>
> Agreed. IO syscalls is not the
On Sat, Dec 31, 2005 at 02:54:18PM -0500, Tom Lane wrote:
> The example of case-insensitive sorting suggests that we need to assume
> that sort comparison functions can make finer-grained comparisons than
> the associated "equals" operator does. The current infrastructure
> forces these to be exac
Martijn van Oosterhout writes:
> On Sat, Dec 31, 2005 at 12:58:19AM -0500, Greg Stark wrote:
>> Two things are either the same or they aren't, and that can't change
>> based on context.
> So someone who wants a case-insensetive search actually doesn't want
> "Foo" to equal "foo"?
That nice simp
On Sat, 2005-12-31 at 14:40 -0500, Tom Lane wrote:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > Qingqing Zhou <[EMAIL PROTECTED]> writes:
> >> I have patched IO routines in backend/storage that POSIX says EINTR is
> >> possible except unlink(). Though POSIX says EINTR is not possible, during
> >> m
On Sat, 31 Dec 2005, Tom Lane wrote:
>
> What I'd rather do is document prominently that running a DB over NFS
> isn't recommended, and running it over NFS with interrupts allowed is
> just not going to work.
>
Agreed. IO syscalls is not the only problem for NFS -- if we can't fix
them in a run,
Greg Stark <[EMAIL PROTECTED]> writes:
> Qingqing Zhou <[EMAIL PROTECTED]> writes:
>> I have patched IO routines in backend/storage that POSIX says EINTR is
>> possible except unlink(). Though POSIX says EINTR is not possible, during
>> many regressions, I found it sometimes sets this errno on NFS
Bruce Momjian wrote:
> > The --single-transaction mode would apply even if the dump was created
> > using an earlier version of pg_dump. pg_dump has *not* been altered at
> > all. (And I would again add that the idea was not my own)
>
> I assume you mean this:
>
> http://archives.postgresq
On Sat, Dec 31, 2005 at 12:58:19AM -0500, Greg Stark wrote:
> I think this is a mistake -- the same mistake that got us into trouble with
> Turkish.
>
> Hashing depends on the concept of equality which is integral to the type. Two
> things are either the same or they aren't, and that can't change
21 matches
Mail list logo
