Christopher Kings-Lynne wrote:
What exactly is the advantage in using VIEWs? I get the impression that the
SELECT query it is based on is cached (ie. a cached query plan).
I had the same impression but I've been told (with explanations) that
the query plan for a view is not cached in any
Brent Verner [EMAIL PROTECTED] writes:
| Unless someone can point out a situation where retrying connect()
| after EINTR is actively bad, my inclination is to accept the patch.
I've found numerous examples where connect() is retried after EINTR,
infact it appears to be fairly common.
David Ford [EMAIL PROTECTED] writes:
Please wait a day before applying the patch, I want to make it a bit
more clean/readable and make sure I covered everything in fe-connect.c,
BTW, reading the HPUX man page for connect I find the following relevant
error codes:
[EALREADY]
After further thought, though, it's unclear to me why this solves
David's problem. If he's got a repeating SIGALRM on a cycle short
enough to interrupt a connect(), seems like it'd just fail again
on the next try.
Ok, a few things. The connect() call is just an interface to the
kernel.
This does not actually *say* that the appropriate behavior after EINTR
is to retry, but reading between the lines one might infer that it will
work like the nonblocking case, wherein a retry of connect tries to link
to the existing connection attempt, not start a new one.
What's more important
David Ford writes:
Libpq doesn't deal with system calls being interrupted in the slightest.
None of the read/write or socket calls handle any errors. Even benign
returns i.e. EINTR are treated as fatal errors and returned. Not to
malign, but there is no reason not to continue on and
Bill Studenmund writes:
I guess to get at my point, I can ask this question, Will schema support
invalidate existing PostgreSQL database designs.
I would like the answer to be no. I would like our users to be able to
dump a pre-schema-release db, upgrade, and then restore into a
David Ford [EMAIL PROTECTED] writes:
Thus a simplified loop should look like this:
No, it should *not* look like that. The fe-connect.c code is designed
to move on as soon as it's convinced that the kernel has accepted the
connection request. We use a non-blocking connect() call and later
Peter Eisentraut [EMAIL PROTECTED] writes:
Libpq certainly does deal with system calls being interrupted: It does
not allow them to be interrupted. Take a look into the file pqsignal.c to
see why.
??? Are you momentarily confusing backend and frontend libpq?
AFAICT the client-side libpq
On Fri, 26 Oct 2001, Peter Eisentraut wrote:
Bill Studenmund writes:
I guess to get at my point, I can ask this question, Will schema support
invalidate existing PostgreSQL database designs.
I would like the answer to be no. I would like our users to be able to
dump a
Hi!
Would you please give me some comments about this subject? This proposal
was sent to you, attached to a previous mail, few weeks ago.
I'll appreciate so much your opinion, because we are using the
PostgreSQL for an important project at the University, and the
incorporation of this piece of
On Friday 26 October 2001 04:14 pm, Hannu Krosing wrote:
And in linux kernel tradition there would be no non-beta 7.3 and the
beta
for 7.2 would be 7.1.299 or something, and there would also be numerous
brown paper bag releases ;)
We have had our share of 'brown paper bag' releases, too.
We removed 'configure --enable-unicode', right? I didn't see any commit
message about it and want to add it to the HISTORY file. If I missed
anything else in HISTORY, please let me know.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] |
The **SA_RESTART** flag is always set by the underlying system in
POSIX mode so that interrupted system calls will fail with return value
of -1 and the *EINTR* error in /errno/ instead of getting restarted.
libpq's pqsignal.c doesn't turn off SA_RESTART for SIGALRM. Further,
pqsignal.c
No, it should *not* look like that. The fe-connect.c code is designed
to move on as soon as it's convinced that the kernel has accepted the
connection request. We use a non-blocking connect() call and later
wait for connection complete by probing the select() status. Looping
on the
Sergio Pili [EMAIL PROTECTED] writes:
A) It is related with situations where more than one rule is involved
and the seccond one requires completion of the first one. In our sort
of problems this happens frequently. This can be solved adding the
notion of disablement of the first rule within
Hi all!
I wanted to propose a possible rationalization of the PostgreSQL naming
scheme, as briefly outlined below. The following suggestion may seem like a
trivial improvement to some, but to me it is a matter of polish and
consistency.
One possible renaming / reorganization: (feedback
...
If you come up with something that all thinkers can agree, I'm sure it
will be used from now on.
I *think* that somewhere there is a list of things to do to prepare a
release. If that isn't in the sgml doc set, it should be. And if it
doesn't mention the naming convention for beta and
On Thursday 25 October 2001 12:48 pm, Marc G. Fournier wrote:
... is now packaged ... mirrors will pick it up soon, but if anyone wants
to do a quick check, its in /pub/beta ...
Attempting to build an initial RPMset here Will upload when I get a good
build -- although I may have to
David Ford [EMAIL PROTECTED] writes:
[ much ]
I think you are missing the point. I am not saying that we shouldn't
deal with EINTR; rather I am raising what I think is a legitimate
question: *what* is the most appropriate response? My reading of
HP's gloss suggests that we could treat EINTR
...
If you come up with something that all thinkers can agree, I'm sure it
will be used from now on.
I *think* that somewhere there is a list of things to do to prepare a
release. If that isn't in the sgml doc set, it should be. And if it
doesn't mention the naming convention for beta
Actually, now that I look at this another time, there's an interesting
question to ask: have you compiled with USE_SSL?
The USE_SSL case definitely is broken, since it invokes the connect()
in blocking mode, but fails to retry on EINTR, which it clearly should
do in that mode. (What's even
I think you are missing the point. I am not saying that we shouldn't
deal with EINTR; rather I am raising what I think is a legitimate
question: *what* is the most appropriate response? My reading of
HP's gloss suggests that we could treat EINTR the same as EINPROGRESS,
ie, consider the
23 matches
Mail list logo
