On the other hand, I like hints on how to do things better ;)
David
Thomas Lockhart wrote:
>>So, is you vote for or against the elog(NOTICE)?
>>
>>
>
>OK, if we are still voting, then I'll mention that I generally dislike
>the idea of notices of this kind. And would not like this notice in
anoncvs, the lock cleared in the last hour. It didn't actually do any
waiting, it aborted almost immediately.
David
Bruce Momjian wrote:
>David Ford wrote:
>
>
>>$ cvs -z3 up -d -P
>>cvs [server aborted]: read lock failed - giving up
>>
>>Hmm, been th
$ cvs -z3 up -d -P
cvs [server aborted]: read lock failed - giving up
Hmm, been this way for a while now, something need budging? :)
-d
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unre
Gotcha. 'twas the first time I encountered it, I wasn't expecting it.
Thank you for the clarification. I hadn't paid attention to that
paragraph when I read over it.
David
Tom Lane wrote:
>David Ford <[EMAIL PROTECTED]> writes:
>
>
>>heakin=> \z
&
; results in all rights being granted. You must revoke and
grant again in order to get the correct rights set.
If this rights bug has been fixed, I'll upgrade, but I don't consider it
a big problem since I am well aware of the bug.
David
Bruce Momjian wrote:
>David Ford wrote:
>
... while talking to sss.pgh.pa.us.:
>> MAIL From:<[EMAIL PROTECTED]>
>>>
>>>
<<< 550 5.7.1 Probable spam from 68.9.71.221 refused - see
http://www.five-ten-sg.com/blackhole.php?68.9.71.221
554 5.0.0 Service unavailable
Tom, if you block everyone on cable, dialup, dsl, and adsl, then
tr.
Am I missing something?
Thanks,
David
Tom Lane wrote:
>David Ford <[EMAIL PROTECTED]> writes:
>
>
>>So reentrancy in libpq basically is put on hold until 7.3.
>>
>>
>
>Only if you insist on using "crypt", which is deprecated anyway.
>
nd finally..
http://archives.postgresql.org/pgsql-bugs/2002-01/msg00153.php
So reentrancy in libpq basically is put on hold until 7.3.
David
Dann Corbit wrote:
>Are you using crypt on the connection?
>
>Unfortunately, crypt is not reentrant.
>
>
>
>>-Original Messa
Is libpq/PQconnectdb() reentrant? I've tried repeatedly over time and
it seems to incur segfaults every single time.
-d
Dann Corbit wrote:
>The libpq functions are reentrant. These will be useful for just about
>any project.
>
>
---(end of broadcast)--
Last year we had a drawn out discussion about this and I created a patch
for it. I never noticed that the patch didn't go in until I installed
7.2 the other day and realised that fe-connect.c never was fixed.
Here is the patch again. It is against CVS 3/16/2002. This time I only
rewrote the
>
>
>
>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
>
>
>
>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
nteed and b) is not guaranteed.
David
Peter Eisentraut wrote:
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 a
>
>
>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
>
>
>
>It wouldn't surprise me in the least if this behavior is
>platform-dependent. It may well be that David's kernel will allow
>connect() to be interrupted by SIGALRM while yours won't. (Which
>reminds me that neither of you specified what platforms you were
>testing on. For shame.) Or may
on and handle EINTR.
David
p.s. you cant use sleep() or alarm() functions and have a timer event as
well. The only POSIX compliant function that doesn't trample signal
timer events is nanosleep().
Brent Verner wrote:
On 25 Oct 2001 at 17:08 (-0400), David Ford wrote:
| I'm fresh in th
I'm fresh in the code, but this has solved my issues with PQconnect*
failing when interrupted by signals. Some of it is sloppy and not to my
liking yet, but I'm still digging through to see if anything else needs
touched. Comments appreciated.
Honestly, I'm a bit surprised that this issue ha
I've got a bit of a problem. I added a fast SIGALRM handler in my
project to do various maintenance and this broke PQconnectStart().
Oct 23 21:56:36 james BlueList: connectDBStart() -- connect() failed:
Interrupted system call ^IIs the postmaster running (with -i) at
'archives.blue-labs.org'
Not possible to accept both forms at present and issue a notice that
LIMIT m,n is deprecated?
If LIMIT m,n is found, internally re-write it to LIMIT m OFFSET n and
press on.
This should appease everyone and still allow the 'proper' form to be
implemented right now. There isn't just the quest
Vince Vielhaber wrote:
>On Fri, 24 Aug 2001, David Ford wrote:
>
>>It's all in the configuration. I slam mails around dozens of machines
>>in seconds using sendmail and I process a lot of mail.
>>
>
>So have you patched for the latest of the many sendmail ro
Tom Lane wrote:
>>The last worthwhile item on this guy's list is changing ownership of a
>>database. Well, I haven't yet had to do this: can we do this easily?
>>
>It could be better. See recent "Multiple Servers" thread over in
>pg-admin, notably
>http://fts.postgresql.org/db/mw/msg.html?mid=
Vince Vielhaber wrote:
>ooohh I've been raggin on
>Marc on that one for well over a year, maybe two.. I started using
>qmail when it was still in .7something beta and never looked back. The
>folks at Security Focus have moved all of the lists to ezml
Ian Lance Taylor wrote:
>Both qmail and postfix radically outperform sendmail for large mailing
>list delivery on identical hardware. It seems strange to me to say
>that there is no sendmail issue when sendmail itself is the issue.
>The queuing structure sendmail uses is simply wrong when a sing
>
>
>You are seeing sendmail's poorly designed queuing behaviour in action.
>sendmail limits itself by outgoing messages, rather than outgoing
>deliveries. This causes one slow delivery to hold up many fast
>deliveries.
>
Again, all in the configurationrinse, repeat.
Simply change your queu
>
>
>All the delay seems to be in transferring the message from
>postgresql.org to webmail.postgresql.org ... which are the same
>machine, or at least the same IP address. What's up with that?
>
Looks like sendmail? Change your queue runs to be more aggressive. I
have an mc file on http://blu
Ian Lance Taylor wrote:
>>Mailing lists don't scale well to large numbers of subscribers. I see this
>>delay constantly,on multiple lists. The bigger the list gets, the slower the
>>list gets (and the more loaded the server gets, right Marc? :-)).
>>
>
>Note that the postgresql.org mail serve
Tom Lane wrote:
>Peter remarked that he wouldn't use a bug database unless it has some
>input filtering to remove all the non-bug issues that currently clutter
>the pgsql-bug archives. I tend to agree with him. A possible way to
>handle that is to set up bug-input like a closed mailing list: on
Tom Lane wrote:
>Given a threaded index, you aren't wading through "a few hundred posts".
>Agreed, a nice canned database entry might be easier to look at, but
>who's going to expend the time to maintain the database? Unless someone
>actively takes responsibility for keeping the DB up to date, i
Bruce Momjian wrote:
>How do you communicate that to people looking at the content? Do you
>put in big letters at the top, "This list is not complete." The fact an
>items is missing from the list (new bug) is just as important as an item
>appearing on the list.
>
How do you distinguish that fr
Bruce Momjian wrote:
>OK, what value does a bug database have over a TODO list?
>
history of a bug, entire discussion about that bug on the same page with
hyperlinked patches and other attachments.
ability of everyone to add to the bug documentation without submitting
it to the TODO maintainer
Serguei Mokhov wrote:
>Maybe a better solution for the short run would be
>return the page where it was, and but links to the pgsql-bugs and
>pgsql-hackers archives with some sort of exmplanatory saying that "this is
>a *complete* (it must be complete of course) list of bugs, which are
>being e
Bruce Momjian wrote:
>>>That is the real question. Do we want to rely more heavily on a bug
>>>database rather than the email lists? I haven't heard many say they
>>>want that.
>>>
I'd very much like a bugzilla because I can do research on bugs past or
present now as well as know the status o
I vote for pgsql bugzilla. If I have a bug to report I'll file it. I
file plenty of moz bugs and aid in resolving them.
-d
Bruce Momjian wrote:
>>There are over 400 in the database. If that's a small percentage then
>>so be it, but it's still over 400 bugs that appear to have been ignored.
Honestly I wasn't aware postgres had any bugs... tongue in cheek.
What I mean is PG works very nicely for me and I haven't had any
problems with it, so that means "no bugs". Yes there are bugs and
things to be solved, but from my perspective it is already a pretty darn
good piece of software
Tom Lane wrote:
>[...]
>
>BTW, I think #ifdef would be a totally unworkable way to attack the
>format-string problem. The code clutter of #ifdef'ing everyplace that
>presently uses %u would be a nightmare; the impact on
>internationalization files would be worse. And don't forget that %llu
>wou
What I mean is, do host lookups first in the text file, then if a
pg_hostaccess table (example) exists, check it for host entries. This
alleviates HUP or restart etc. to reload a config file.
David
Bruce Momjian wrote:
>>>
>>>I haven't heard of any more issues with pg_hba.conf so I will mark
>
>
>I haven't heard of any more issues with pg_hba.conf so I will mark the
>item as done. I did cleanup the comments in the file. I have also
>added a TODO item:
>
> * Read pg_hba.conf only on postmaster startup or SIGHUP
>
If you do this, can you add an access table for secondary lookup
How 'bout posting what version of pgsql you're running, and we'll start
back at square one :)
-d
Bruce Irvine wrote:
> Hi All,
>
>
>
> This is my first post, so I hope I'm in the right area and doing it
> correctly.
>
>
>
> We are having MAJOR & URGENT problems with Postresql occaisonly
39 matches
Mail list logo
