ULL initialised before each fetch, or
only before the first one? How should the memory be freed?
Any pointers to useful documentation?
Thanks, Lee Kindness.
---(end of broadcast)---
TIP 6: Have you searched our list archives?
h
Marc G. Fournier writes:
> Myself, I wonder why Oracle went the route they went ... does anyone have
> access to a Sybase / Informix system, to confirm how they do it? Is
> Oracle the 'odd man out', or are we going to be that? *Adding* something
> (ie. DROP TABLE rollbacks) that nobody appea
d for some documentation on this
aspect.
Regards, Lee Kindness.
Christof Petig writes:
> Michael Meskes wrote:
> > On Thu, Apr 25, 2002 at 12:42:00PM +0100, Lee Kindness wrote:
> >>Should the input pointers be NULL initialised? How should the memory
> >>be freed
Thomas Lockhart writes:
> Right. IBM.
> > Most likely they have fixed it by now ...
> Nope, though I don't know for sure. Anyone here have a recent AIX
> machine to test?
Well on AIX 4.3.3 the output from Lamar's earlier test program is:
The system thinks 11/30/1969 is a timestamp of -1
a
RROR: parser: parse error at or near "a"
[29189]: raising sqlcode -400 in line 21, ''ERROR: parser: parse error at or near
"a"' in line 21.'.
Regards, Lee Kindness.
Bruce Momjian writes:
> Has this been addressed? Can you supply a reproducable
roblem on my machine:
>
> #$ ./a.out floattest
> col1: -0.06
> *!*!* Error -220: No such connection NULL in line 21.
>
> Wow, how did that "A" get into the query string:
>
> insert into tab1 ( col1 ) values ( -6.002122251e-
floattest@localhost:5433
Regards, Lee Kindness.
Bruce Momjian writes:
> I am now getting this error:
> #$ ./a.out floattest
> col1: -0.06
> *!*!* Error -220: No such connection NULL in line 21.
> I will wait for Michael to
Vince Vielhaber writes:
> [ 'user@' patch ]
> whim. Then again as long as 7.2.1 is stable enough for me there's
> no reason to upgrade 'cuze I damn sure ain't going back and changing
> all sorts of programs and scripts that have global users.
Having read bits and pieces of this thread, can t
I'd have thought that if a matching user couldn't be found in the
specified database then it would default to searching through the
global users? Would be more intuitive...
Lee.
Bruce Momjian writes:
> Sample run:
> $ psql -U postgres test
> psql: FATAL: user "postgres@test" does n
Tom, do you think there is millage in adding functions (at least to
contrib) to PostgreSQL to avoid some of the common tasks applications
look into pg_* for?
For example I recently audited our code here for pg_* access, and
managed to create two plpgsql functions to replace all
occurrences. They
, but would like to check first there's no
simple way already!
Regards, Lee Kindness.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Dave Page writes:
> Just because I'm curious, is *all* new stuff going to Gborg, and is the
> existing /contrib going to migrated there?
I'm curious too...
If that is to happen then the profile of gborg would need to be
massively increased. Currenly the only real link on the 'net to gborg
(by
er
for a purely grammatical reason!
A good few months ago I put formward an idea to change (well migrate
really) to "COPY TABLE" rather than "COPY" - this would allow a well
designed and thoughtout syntax for the new version while retaining old
compatibility.
egards, Lee Kindness.
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Marc,
Marc G. Fournier writes:
> if (ic_flag == 1) {
> /*only select those non-IC/Spyder nodes that has full update set*/
> EXEC SQL DECLARE full_dyn_node CURSOR FOR
> SELECT node_name FROM NODE
> WHERE dynamic_community = 'f' AND ic_f
with
Linux installed... Or settle for the existing, non-native, Windows
version.
By the way, just to open Office documents? Have you tried OpenOffice?
Regards, Lee Kindness.
Al Sutton writes:
> Is there a rough date for when they'll be available?
>
> I have a development te
See:
http://www.us.postgresql.org/users-lounge/docs/7.2/postgres/catalogs.html
for PostgreSQL 7.2.x, for 7.3 see:
http://developer.postgresql.org/docs/postgres/catalogs.html
Lee.
Steve Jackson writes:
> Hi
>
> Has anyone of you a good pointer to a description of where in the system
> t
Christopher Kings-Lynne writes:
> Just out of interest, if someone was going to pay you to hack on Postgres
> for 6 months, what would you like to code for 7.4?
Well judging by the hoards on Slashdot, it would appear that
replication is the hot enhancement...
Slashdot | PostgreSQL 7.3 Released
Tom/Hackers,
Going back a bit, but relevant with 7.3's release...
Tom Lane writes on 03 Sep 2002:
> Lee Kindness <[EMAIL PROTECTED]> writes:
> >
> > [ original post was regarding the mileage in adding utility
> > functions to PostgreSQL to cut-out common cat
on all my projects and change thousands of
> lines.
>
> And that's not all :(
> I have other applications like phprojekt that was not developed by me and
> became useless now as I cant insert.
>
> Was this step so necessary ?
>
> - Original Message --
e (''); ?
>
> Who knows how many application will suffer becouse of this.
>
> - Original Message -
> From: "Bruce Momjian" <[EMAIL PROTECTED]>
> To: "Lee Kindness" <[EMAIL PROTECTED]>
> Cc: "Ben-Nes Michael" <
Perhaps the .so name should have been updated for PostgreSQL 7.3? For
example in 7.2 libpq is:
/usr/lib/libpq.so -> libpq.so.2.2
/usr/lib/libpq.so.2 -> libpq.so.2.2
/usr/lib/libpq.so.2.0 -> libpq.so.2
/usr/lib/libpq.so.2.2
and PostgreSQL 7.3:
/usr/lib/libpq.so -> libpq.so.2.2
Tom Lane writes:
> Okay, so it seems -D_REENTRANT is the appropriate fix.
>
> We could either add that to the template/solaris file, or just add a
> note to FAQ_Solaris advising that it be added to the configure switches
> if people intend to use libpq in threaded programs. Is there any
> c
Bruce Momjian writes:
> Tom Lane wrote:
> > Lee Kindness <[EMAIL PROTECTED]> writes:
> > > Perhaps the .so name should have been updated for PostgreSQL 7.3?
> >
> > It should have been. If it wasn't, that was a serious oversight.
> > Not sure
Tom Lane writes:
> Lee Kindness <[EMAIL PROTECTED]> writes:
> > Tom Lane writes:
> >>> Okay, so it seems -D_REENTRANT is the appropriate fix.
> > However, _REENTRANT is not a Solarisism... On all (recent) UNIX
> > systems it toggles on correct handlin
Dan Langille writes:
> On 10 Dec 2002 at 9:34, Tom Lane wrote:
> > Anyone running cvsup would have a complete copy of the source CVS, I
> > believe. It would be more troubling to reconstruct the mailing list
> > archives; I'm not sure that those are mirrored anywhere
> Do you mean the reposit
Ian Barwick writes:
> On Tuesday 10 December 2002 00:47, Tom Lane wrote:
> > In the next protocol version update (hopefully 7.4) I would like to see
> > the basic version string (eg, "7.3.1" or "7.4devel") delivered to the
> > client automatically during connection startup and then available fr
Making something binary incompatible IS an API change! In the case in
question an externally visible structure definition was changed -
clearly a change of API...
Bruce Momjian writes:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > So if a recompile fixes it, increment mi
Guys, can I take this chance to summarise the thread and when the
major and minor versions should be updated, perhaps could be added to
the developers FAQ if everyone is in agreement?
Major Version
=
The major version number should be updated whenever the source of the
library changes
Guys,
Some further comments on bumbing the major version number which aren't
so cut-n-dry...
Lee Kindness writes:
> The major version number should be updated whenever the source of the
> library changes to make it binary incompatible. Such changes include,
> but limite
Jeroen T. Vermeulen writes:
> On Mon, Dec 16, 2002 at 05:41:06PM +0100, Jeroen T. Vermeulen wrote:
> > Speaking of which, what if user relies on sizeof(PGnotify::relname)?
> ^
> code
Yes, a change in the size of relname makes thi
Guys,
I've been asked by a colleague about methods to keep track of
'previous' contents of a table - i.e. changes made and a way of
getting back to a previous state. Now, I know INSERT/UPDATE/DELETE
triggers to maintain an accompanying table is a way to do this. But, I
have a nagging feeling that
Tom Lane writes:
> Lee Kindness <[EMAIL PROTECTED]> writes:
> > I have a nagging feeling that somebody has at one point put together
> > such a feature in a generic fashion... I thought there was a 'time
> > machine' module in contrib!
> contrib/spi
Guys, for your convenience i've put online a source RPM for Bison
1.875 along with binary RPMs for Redhat 7.2, 7.3 and 8.0. Hunting
around the net i didn't find any existing Bison >= 1.50 RPMs, so this
should be useful for those compiling PostgreSQL (ECPG in particular)
from the CVS source:
http:
On a slightly related note to the other threads thread [sic] going
on... Over the Christmas/New Year break i've been looking into making
the PostgreSQL client libraries (in particular libpq and ecpg)
thread-safe - that is they can safely be used by a program which
itself is using mutliple threads.
Tom Lane writes:
> Lee Kindness <[EMAIL PROTECTED]> writes:
> > On a slightly related note to the other threads thread [sic] going
> > on... Over the Christmas/New Year break i've been looking into making
> > the PostgreSQL client libraries (in particular
Tom Lane writes:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > We have definatly had requests for improved thread-safeness for libpq
> > and ecpg in the past, so whatever you can do would be a help. We say
> > libpq is thread-safe, but specifically mention the non-threadsafe calls
> > in th
Bruce Momjian writes:
> Lee Kindness wrote:
> > Right, so a reasonable angle for me to take is to go through the libpq
> > source looking for potential problem areas and use of "known bad"
> > functions. I can add autoconf checks for the replacement *_r()
> &
Tom,
Tom Lane writes:
> Lee Kindness <[EMAIL PROTECTED]> writes:
> > + #define _THREAD_SAFE
> > + #define _REENTRANT
> > + #define _POSIX_PTHREAD_SEMANTICS
> What is this stuff, and why isn't it wrapped in any sort of
> platform-specific test? If
t use in the configure stuff is
100% right...
Patches also at:
http://services.csl.co.uk/postgresql/diffs-20030109-configure.txt.gz
http://services.csl.co.uk/postgresql/diffs-20030109-libpq.txt.gz
Thanks, Lee.
Lee Kindness writes:
> Tom Lane writes:
> > Bruce Momjian <[EMAIL P
und acceptable?
Thanks, Lee.
Peter Eisentraut writes:
> Lee Kindness writes:
>
> > Patches attached to make libpq thread-safe, now uses strerror_r(),
> > gethostbyname_r(), getpwuid_r() and crypt_r() where available. Where
> > strtok() was previously used strchr() is
Michael,
Michael Meskes writes:
> On Thu, Jan 23, 2003 at 02:40:33PM +0530, Shridhar
>Daithankar<[EMAIL PROTECTED]> wrote:
> > I would like to use ECPG as it is relatively easy to code. However my
> > application is multithreaded and also uses connecion pools.
>
> I'm afraid it needs some
Michael Meskes writes:
> On Mon, Jan 27, 2003 at 11:52:18AM +0000, Lee Kindness wrote:
> > I've spent a bit of time on making ecpg thread safe over Christmas,
> > while it's not finished i'm sure the attached patch is at least useful
> > and a step in the
Shridhar Daithankar writes:
> On 27 Jan 2003 at 14:06, Lee Kindness wrote:
> > Michael Meskes writes:
> > > Thanks a lot. I have no experience in multithreaded software development
> > > so I cannot completely check your patch but it surely looks good. Shall
>
t? Would:
WITH ON_DUPLICATE = CONTINUE|TERMINATE (or similar)
need to be added to the COPY command (I hope not)?
Thanks,
--
Lee Kindness, Senior Software Engineer
Concept Systems Limited.
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Justin Clift writes:
> Lee Kindness wrote:
> > WITH ON_DUPLICATE = CONTINUE|TERMINATE (or similar)
> I would suggest :
> WITH ON_DUPLICATE = IGNORE|TERMINATE
> purely for easier understanding, given there is no present standard nor
> other databases' syntax to
Tom Lane writes:
> Lee Kindness <[EMAIL PROTECTED]> writes:
> > Would this seem a reasonable thing to do? Does anyone rely on COPY
> > FROM causing an ERROR on duplicate input?
> Yes. This change will not be acceptable unless it's made an optional
> (and n
Okay,
If I'm going to modify 'COPY INTO' to include 'ignore duplicates'
functionality it looks like I'll have to add to the COPY syntax. The
most obvious way is to add:
WITH IGNORE DUPLICATES
to the syntax. I'm going to need my hand held a bit for this! The
grammar for COPY will need updating
Lee Kindness writes:
> If I'm going to modify 'COPY INTO' to include 'ignore duplicates'
> functionality it looks like I'll have to add to the COPY syntax. The
> most obvious way is to add:
> WITH IGNORE DUPLICATES
Or does it make more sense to ad
Peter Eisentraut writes:
> However, it seems to me that COPY ignoring duplicates can easily be
> done by preprocessing the input file.
Or by post-processing, like (error checking cut):
void import_shots(char *impfile, int lineshoot_id)
{
char tab_name[128];
char tab_temp[128];
frig_fi
x27;.
I keep a similar patch to Denis's (without the wierd hi-ascii
characters in his) lying around for when i build a Solaris version.
Regards, Lee Kindness.
Peter Eisentraut writes:
> Denis A Ustimenko writes:
>
> [change -Wl,-R to -R and -Wl,-h to -h]
>
> I'm ha
See the pg_database table:
http://www.postgresql.org/idocs/index.php?catalog-pg-database.html
Regards, Lee.
Ron de Jong writes:
> All,
>
> How do I get a list of DB's or Tables with a postgres SQL statement?
> It needs to be an SQL statement otherwise perl/DBI/prepare won't parse it.
> I
Peter Eisentraut writes:
> Lee Kindness writes:
> > For your information I've attached the man page for the Sun C
> > compiler, which explicitly lists the -h and -R flags.
> I didn't read much farther than
> acc (SPARC only) is not intended to be used
Peter Eisentraut writes:
> Lee Kindness writes:
> > Touche, but the man page for the front-end (plain old cc) doesn't list
> > options and only refers to the acc man page ;)
> Well, I'm stumped. All the Solaris compilers I've ever seen did support
>
if (!skip_tuple)
{
Now I imagine 'duplicate index value' would be functionally similar to
_bt_check_unique but obviously higher level. Is there any existing
code with the functionality I desire? Can anyone point me in the right
way...
Thanks,
Lee Kindness.
Lee Kin
Tom Lane writes:
> Lee Kindness <[EMAIL PROTECTED]> writes:
> > The existing code in ecpg/preproc/preproc.y to handle the WITH option
> > simply throws an error and aborts the processing... The patch below
> > prevents the segfault and also passes on the WITH
Bruce Momjian writes:
> Lee Kindness writes:
> > In which case a number of other cases should be weeded out of
> > parser.y and passed onto the backend:
> > [ snip ]
> > Let me known if you want a patch for these cases too.
> Sure, send them on over.
Patch be
Tatsuo Ishii writes:
> I saw over 7 hours delay between postgresql.org and sever1.pgsql.org.
> Does anynone know what's happening here?
I've seen massive delays too:
Received: from mail.csl.co.uk by euphrates.csl.co.uk (8.9.3/ConceptI 2.4)
id EAA08864; Tue, 16 Oct 2001 04:24:41 +0100
eds to be changed to
reserved since it can no-longer be used as an unquoted column
identifier?
Perhaps the other time related identifiers too.
Regards, Lee Kindness.
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an ap
Bill Studenmund writes:
> I think this patch is wrong. Wouldn't it be better to make the line number
> in yylineno be correct? Also, there are users of the line number in pcg.l
> which you didn't change.
> Looking at it, I don't see why the line number is off. It is initialized
> to 1 at the
When adding an index to a (quite large, ~2 million rows) table
PostgreSQL continues to do sequential lookups until VACUUM ANALYZE is
run. Naturally performance is poor.
The CREATE INDEX statement takes considerable time.
Seen with 7.1.3 on Intel Linux (RedHat 7.0 & 7.1 and Solaris 2.6.
In the e
Tom Lane writes:
> Uh, isn't the correct fix
> ! $$ = cat_str(8, make_str("grant"), $2, make_str("on"), $4, $5,
> make_str("to"), $7, $8);
> ISTM your patch loses the opt_with_grant clause. (Of course the
> backend doesn't currently accept that clause anyway, but that's no
> reason for ecpg
ences
reset
right
select
session_user
setof
show
some
substring
table
then
time
timestamp
to
trailing
transaction
trim
true
union
unique
unknown
user
using
vacuum
varchar
verbose
when
where
Best Regards, Lee Kindness..
--
Okay guys, i've been a bit tight of time recently to move forward on
this, but I plan to do a small amount of work on the patches to clean
them up so they can be merged into the sources.
I'll also add a README to document what will need to be fudged in the
makefile to get it building. Hopefully th
Larry Rosenman writes:
> <[EMAIL PROTECTED]> wrote:
> > Bison is 1.28. Yacc (version 91.7.30) gives a similar error.
> you need Bison 1.50 or later...
Which you can get binary and src RPMs of from:
http://services.csl.co.uk/postgresql/
L:
---(end of broadcast)-
For those using Linux, the RPMs at:
http://services.csl.co.uk/postgresql/
are probably handy.
L.
Bruce Momjian writes:
> Sorry, I meant bison 1.875 is now required, not 1.85.
>
> --
> Bruce Momjian| http://candle.pha.pa.us
> [EMAIL PROTECTED] |
Philip,
You can find the "patch so far" at:
http://services.csl.co.uk/postgresql/
along with a libpq thread-safe patch.
The thread referenced by Bruce's email details some of the issues
still to be looked at. The main work is integration with the build
system (testing for and linking in POSIX
t; I can help with the UnixWare threads stuff. Also, Micheal Meskes now has
> > an account
> > on my UnixWare box.
> >
> > The threads are native on UW, but you need to invoke the cc -Kpthread
> > option.
> >
> > LER
> >
> > >
cases?
>
> ---
>
> Lee Kindness wrote:
> Content-Description: message body text
>
> > Patch attached, along with new libpq-reentrant.c and libpq-reentrant.h
> > files for src/interfaces/
Bruce Momjian writes:
> My point is why do we care whether it returns char * or nothing --- we
> should just return strerrbuf in all cases.
Ok, I see. Guess that is reasonable.
L.
---(end of broadcast)---
TIP 7: don't forget to increase your free
Guys, surely some one's done this before? I've tried using
PQescapeBytea too, but still get (slightly) different output. If I try
and insert "\x02\x01\x02\x03\x04hello\x05\x64\x99\x45" I get (int
values of chars printed):
INSERT: 2 1 2 3 4 104 101 108 108 111 5 100 -103 69
SELECT: 2 1
Guys, attached is a patch to fix two memory leaks on start-up. The
first is when freeaddrinfo has been used to free memory allocated by
getaddrinfo2 (so freeaddrinfo2 should be used). The second is 2 leaks
when creating the lock (PostgreSQL and socket) files.
The diff is against last night's CVS H
It was in libpq in my original patch, not port.
L.
Peter Eisentraut writes:
> I have a few problems with the file threads.c:
>
> 1. It doesn't contain any threads, so the name is slightly inappropriate.
>
> 2. It's not a porting module (since pqStrerror, etc. are not system
> functions),
Tom Lane writes:
> Lee Kindness <[EMAIL PROTECTED]> writes:
> > I'd have to disagree with regards to the memory leaks not being worth
> > a mention - any such leak can cause problems when the PostgreSQL
> > installation is either unattended, long-living and
isn't negligible in
this light.
Regards, Lee.
Tom Lane writes:
> Lee Kindness <[EMAIL PROTECTED]> writes:
> > Guys, attached is a patch to fix two memory leaks on start-up.
>
> I do not like the changes to miscinit.c. In the first place, it is not
> a "memo
Guys, take a look at what was done in libpq to make it
thread-safe... No locks! No overheaded - just using "proper" reentrant
functions...
If we have libpq_r then we're making a complete hash of it all - being
reentrant is good, even if you're not using threads!
Now, ecpg is another issue...
L.
Bruce Momjian writes:
> Lee Kindness wrote:
> > Guys, take a look at what was done in libpq to make it
> > thread-safe... No locks! No overheaded - just using "proper" reentrant
> > functions...
> > If we have libpq_r then we're making a complete has
Tom Lane writes:
> Lee Kindness <[EMAIL PROTECTED]> writes:
> > Bruce Momjian writes:
> >>> My guess is that if the OS has separate threaded libs, we have to mimic
> >>> that stuff.
> > But there are NO thread primitives/calls in libpq
> That
Tom Lane writes:
> If the OS supplies both libc and libc_r, it is unlikely to be a good
> idea to link a threaded libpq with libc, or a non-threaded libpq with
> libc_r.
What modern OS has libc_r? The majors (Linux, Soalris, HPUX, AIX)
certainly do not.
L.
---(end of b
Tom Lane writes:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Now I see what you are saying, that _REENTRANT just makes it reentrant,
> > and doesn't have a downside in terms of performance.
> That's at best an unsupported assertion. Why would the platform bother
> with supplying two copie
Bruce Momjian writes:
> However, notice the flags needed under Linux:
>
> THREAD_CFLAGS="-D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS"
>
> or are you saying libpq needs only the first one because libpq, itself,
> doesn't use threads --- interesting distinction, and perhaps a
Bruce Momjian writes:
> Peter Eisentraut wrote:
> > Bruce Momjian writes:
> > > THREAD_CFLAGS="-D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS"
> > Those flags are bogus. You don't need any flags under Linux.
> Is that true for all versions of Linux? Don't we need the first one so
>
Peter Eisentraut writes:
> Larry Rosenman writes:
> > I beg to differ. Explicitly, on UnixWare, the header,
> > reproduced below, under fair use, show an EXPLICIT difference in what
> > happens with _REENTRANT:
> Hmm, I was too optimistic. I guess we'll just have to handcraft a
> different
Guys, looking at ecpg from CVS HEAD's 7.4. The following code
fragement:
EXEC SQL INCLUDE sqlca;
EXEC SQL WHENEVER SQLERROR call sqlprint;
void lofsdb_GetMinMaxRxStations(int *from, int *to)
{
EXEC SQL BEGIN DECLARE SECTION;
int l_from = 0;
int l_to = 0;
EXEC SQL END DECLARE SECTION
Guys,
I've been testing 7.4 against an application today. Recompiled
everything against the new libraries. However the application includes
code which builds up a bulkload file in the documented 7.1 format. The
documentation for COPY goes on at length about the format being
forward compatible...
Tom,
Tom Lane writes:
> Lee Kindness <[EMAIL PROTECTED]> writes:
> > I've attached a patch which lets COPY read in the 7.1 format. However
> > i'm not convinced this is the right way to go - I think the format
> > which is output by 7.4 should be identi
Tom Lane writes:
> Lee Kindness <[EMAIL PROTECTED]> writes:
> > Well in that case the docs need attention. They describe the
> > "envelope" surrounding the tuples, but no mention is made of the
> > format they are in. It is reasonable to assume that t
Tom,
Tom Lane writes:
> Lee Kindness <[EMAIL PROTECTED]> writes:
> > However, is COPY BINARY meant/designed to be used as transfer or
> > backup mechanism?
>
> I think you're overlooking a key consideration: COPY BINARY is not
> an isolated feature anymor
Larry Rosenman writes:
> What the fr*** harm is it in passing -D_REENTRANT into the libpq build on
> UnixWare
> irregardless of the --with-threads* flag?
Indeed for every other sane system out there. Folk are messing around
with the thread stuff using here-say as knowledge. We want to compile
Bruce, the changes you made yesterday to configure for
--enable-thread-safety have broken the build, at least for Linux on
Redhat 9.
Also, I took the opportunity to look at port/threads.c. It is missing
important functionality compaired to the patch I originally
submitted. For getpwuid_r, gethostb
I've not been keeping up with the thread re who has what version of
getpwuid_r... But just to clarify things the "right" version is:
int getpwuid_r(uid_t uid, struct passwd *pwd, char *buffer,
size_t bufsize, struct passwd **result);
documented at:
http://www.opengroup.org/onl
Bruce, I know it's a bit picky but both below should be along the
lines of "Allow thread-safe library" since they are not "threaded" per
se.
L.
Bruce Momjian writes:
> Libpq
> Allow threaded with --enable-thread-safety (Lee Kindness, Bruce)
> Miscellaneous
hanks, Lee.
Lee Kindness writes:
> Tom Lane writes:
> > Lee Kindness <[EMAIL PROTECTED]> writes:
> > > Well in that case the docs need attention. They describe the
> > > "envelope" surrounding the tuples, but no mention is made of the
> > >
Larry, haven't managed to look at that patch... But stuffed for time
just now - just about to head off for the weekend. I'm hoping to spend
a bit of time on this on Tuesday! So, i'll see how things have
progressed then.
L.
Larry Rosenman writes:
> --On Friday, August 08, 2003
Bruce Momjian writes:
> Lee Kindness wrote:
> > Bruce, the changes you made yesterday to configure for
> > --enable-thread-safety have broken the build, at least for Linux on
> > Redhat 9.
> OK, how did I break things? Can you show me the failure.
After a:
./con
Bruce Momjian writes:
> Marc G. Fournier wrote:
> > On Sat, 30 Aug 2003, Bruce Momjian wrote:
> >
> > > Yes, and that is the complex part because _some_ non-*_r functions are
> > > thread-safe, and some are not. I have to determine if we have other
> > > such platforms before I figure out h
Probably because I worked on thread safety and produced a patch. If
someone done the same for PITR and produced a patch i'm sure it would
have generated much more interest. I couldn't have done PITR, so no
loss of resource there.
Was Bruce planning to do the PITR work? If so I guess a lot of his
t
Guys, too much thought is being spent on this...
1. For the _r functions we "need" we should ALWAYS use them if the
system we are building on has them - they WILL be thread-safe.
2. If the system is missing a _r function then we implement a wrapper
to call the normal non-_r version. However we do
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Lee Kindness <[EMAIL PROTECTED]> writes:
> > Guys, too much thought is being spent on this...
> > 1. For the _r functions we "need" we should ALWAYS use them if the
> > system we are building on has them
"Larry Rosenman" <[EMAIL PROTECTED]> writes:
> then how do we *PROVE* thread-safety on a particular platform?
You're not going to be able to prove it anyway!
L.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
htt
Tom Lane writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > On the other hand, things like, getpwnam, strtok, etc have non-thread-safe
> > APIs. They can never be made thread-safe. The *_r versions of these functions
> > are standardized and required. If they don't exist then the platform sim
1 - 100 of 113 matches
Mail list logo
