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 encoura
>
>
>
>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 t
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 worse
> ...
> > 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
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
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 relea
...
> 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 r
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 ru
>
>
>
>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 c
"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 on
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] | (
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
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 co
Peter Eisentraut wrote:
>
> Marc G. Fournier writes:
>
> > CVS tags have been conssitent since v7.1 ...
>
> Allow me to consider that a joke:
>
> REL7_2_BETA1
> REL7_1_STABLE
> REL7_1_BETA3
> REL7_1_BETA2
> REL7_1_BETA
> REL7_1_2
> REL7_1
>
> So,
>
> Where is REL7_1_1? Where is REL7_1_BETA1
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 pr
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 lib
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
w
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
> sch
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 ha
>
>
>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 im
>
>
>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
kerne
Marc G. Fournier writes:
> CVS tags have been conssitent since v7.1 ...
Allow me to consider that a joke:
REL7_2_BETA1
REL7_1_STABLE
REL7_1_BETA3
REL7_1_BETA2
REL7_1_BETA
REL7_1_2
REL7_1
So,
Where is REL7_1_1? Where is REL7_1_BETA1? What does REL7_1_BETA belong
to? What ever happened to be
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]
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.
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 wa
25 matches
Mail list logo
