this on the client side. I'm not sure
why it would be beneficial to do this as part of the PostgreSQL server.
Scott Lamb
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
in the name column).
Good luck.
Scott Lamb
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
. It's a pretty short list. Notably absent are
pthread_mutex_*() and malloc() (and anything that uses them).
Scott Lamb
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister
it more obvious.
Speaking of async signal-safe functions, pthread_getspecific() isn't
specified to be (and thus PQinSend() and thus
sigpipe_handler_ignore_send()). It's probably okay, but libpq is
technically using undefined behavior according to SUSv3.
Scott Lamb
---(end
Bruce Momjian wrote:
Scott Lamb wrote:
Speaking of async signal-safe functions, pthread_getspecific() isn't
specified to be (and thus PQinSend() and thus
sigpipe_handler_ignore_send()). It's probably okay, but libpq is
technically using undefined behavior according to SUSv3.
Yikes. I never
Scott Lamb wrote:
You could just do a pthread_sigmask() before and after the
pthread_setspecific() to guarantee that no SIGPIPE will arrive on that
thread in that time. I think it's pretty safe to assume that as long as
you're not doing a pthread_[gs]etspecific() on that same pthread_key_t
thread-directed signals are synchronous.
Here the signal is synchronous, so the signal is guaranteed to happen
at a safe point (during the read()), so there's no problem.
Thanks,
Scott Lamb
---(end of broadcast)---
TIP 3: if posting/reading through
Tom Lane wrote:
Seriously, I agree with Marc's opinion that issuing an RC1 is the best
way to flush out some more port reports. I do not know what else we can
do to get people off their duffs and onto last-minute testing.
If testing is the problem, I think publicizing the betas would help
Bruce Momjian wrote:
I am going to work on nested transactions for 7.4.
If you're going to do a lot of reworking of how transactions are
handled, maybe this is a good time to beg for cursors that stay open
across commits. It looks like the JDBC driver is moving to using cursors
with
Christopher Kings-Lynne wrote:
There isn't one!
Chris
No kidding. I propose changes to the following pages:
http://www14.us.postgresql.org/: Prominent mention of the latest
stable and unstable releases (just stable now, of course). But since
this seems to be kind of a repeat of the news
Lamar Owen wrote:
However, I seriously question the need in the long term for our sites to be as
fractured as they are. Good grief! We've got advocacy.postgresql.org,
techdocs.postgresql.org, odbc.postgresql.org, gborg.postgresql.org,
developer.postgresql.org, jdbc.postgresql.org, etc. Oh,
Marc G. Fournier wrote:
I'm just announcing here, since I'd like to see some ppl testing this out
and let us know if there are any problems ... DNS is going to take a
little while to propogate, so the old site may still come up in the
interium ... another reason not to announce it right away :)
into an array
(2) use each value's array index as its key
It reduces to the problem you're trying to use it to solve.
--
Scott Lamb http://www.slamb.org/
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
about anything.Interesting. If you abandon the idea that collisions should be impossible (they're not indexes) or extremely rare (they're not hashes), it's pretty easy to come up with a decent hint to avoid a lot of dereferences. --Scott Lamb http://www.slamb.org/
a guess. (Alternate moral: don't be like Microsoft.)
Thanks,
Scott Lamb
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
15 matches
Mail list logo
