c.pdf
On Fri, Jun 2, 2017 at 11:32 PM, Andres Freund wrote:
> Hi,
>
> On 2017-06-02 16:40:56 +0800, Hao Lee wrote:
> > Hi all,
> >There is a lot of "if statement" in system, and GCC provides a
> > feature,"__builtin_expect", which let co
Okay. Thanks
On Fri, Jun 2, 2017 at 7:27 PM, Julien Rouhaud
wrote:
> On 02/06/2017 12:50, Craig Ringer wrote:
> >
> >
> > On 2 Jun. 2017 16:42, "Hao Lee" > <mailto:mixt...@gmail.com>> wrote:
> >
> > Hi all,
> >
Hi all,
There is a lot of "if statement" in system, and GCC provides a
feature,"__builtin_expect", which let compilers know which branch is
mostly run. as we known, miss-prediction will lead the performance
lost(because the CPU will thrown away some instructions, and re-fetch some
new instr
need more cares when do modifying. So that i think that whether there are
some more smarter approaches to make it smarter or not.
On Wed, Nov 9, 2016 at 6:33 AM, Robert Haas wrote:
> On Mon, Nov 7, 2016 at 9:10 PM, Michael Paquier
> wrote:
> > On Tue, Nov 8, 2016 at 10:57 AM, Hao L
Hi guys,
Although, usually, we do not change the system catalog or modify the
catalog schema, or adding a new system catalog, but in these system catalog
head files, such as pg_xxx.h, i think we should use more meaningful
variables. As we known, in pg_xxx.h files, we insert some initial values
i
Hi all,
When we debugging or hacking the internal, the tedious things is to
debug step by step the code, so that make sure the PostgreSQL generates the
right raw syntax tree or query tree or the plans. Therefore, i think if we
have a uitility statment to show that, such as, we can using the exp
Hi all,
Today, I am do some works on adding some customized featues to PostgreSQL
9.6 beta1. But, when i do some output to psql using the fuction
"do_text_output_multiline" with the string just like mentioned in mail
tilte, such as "this is a\ntest for\nnew blank.". the PostgreSQL may lead
to corr
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Hello.
I installed centos 6.7 version on virtualbax, have cl
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, failed
Spec compliant: tested, failed
Documentation:tested, failed
Hello.
I installed centos 6.7 version on virtualbax, have cl
>> Since I've mentioned my use case, I might as well mention another issue I
>> stumbled across, which is that concurrent index creation cannot happen from
>> within trigger functions. I'm able to non-concurrently create indexes from
>> within trigger functions. Why is there this disparity?
>
s to be able to launch background concurrent
index creation via triggers.
--David
On Oct 28, 2012, at 2:35 PM, Kevin Grittner wrote:
> David Lee wrote:
>
>> It seems like right now when you want to create an index
>> concurrently, the index creation will get canceled if you
Thanks. Is this something viable as a feature request?
On Oct 28, 2012 7:48 AM, "David Johnston" wrote:
> On Oct 27, 2012, at 19:20, David Lee wrote:
>
> > Hey folks,
> >
> > It seems like right now when you want to create an index concurrently,
> the in
Hey folks,
It seems like right now when you want to create an index concurrently, the
index creation will get canceled if you cancel the statement (i.e. you must
keep your statement open).
Is there a way to "launch" an index creation in the background so that the
statement doesn't need to be k
Hi,
I was trying to create foreign key constraints on a sub-column of a
composite-type column, but couldn't find a way to do it. After asking around on
IRC, it seems like this isn't supported in PostgreSQL.
I wanted to do something like:
create type profile as (account_id integer);
end a
vector result from fastpath function call?
2011/5/9 Tom Lane
> lee Richard writes:
> > I still can not see how it return a single return value to the client,
> and
> > why it call FunctionCall1() again when it want to send the result.
>
> pq_endmessage is where the by
the client, and
why it call FunctionCall1() again when it want to send the result.
Regards
Clipper
2011/5/8 Merlin Moncure
> On Sun, May 8, 2011 at 8:01 AM, lee Richard
> wrote:
> > Hi,
> >
> > I am reading the source code of fastpath to understand the internal of
Hi,
I am reading the source code of fastpath to understand the internal of
fastpath. I can not understand how does it send result to the client, I hope
somebody can help me on this.
I see it call it invoke the function in
HandleFunctionRequest()
-> retval = FunctionCallInvoke(&fcinfo);
-> Se
an EXT3 partition? I see that photorec is supposed to be able to
recognize mysql database files.
Thanks,
Lee
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 6 mar, 22:44, and...@dunslane.net (Andrew Dunstan) wrote:
> Holger Hoffstaette wrote:
> > On Fri, 06 Mar 2009 14:32:25 -0600, Kenneth Marshall wrote:
> >> On Fri, Mar 06, 2009 at 02:58:30PM -0500, Andrew Dunstan wrote:
> >>> Yes, I discovered this a few weeks ago. [...]
>
> Maybe someone can tra
On 7 feb, 23:44, da...@fetter.org (David Fetter) wrote:
> On Sat, Feb 07, 2009 at 10:44:48PM -0500, David Lee Lambert wrote:
> > In the same spirit as the FreeBSD-native UUID generator that was
> > discussed here a couple months ago, I was able to link Postgres 8.4
> > again
, there isn't a link-conflict issue that requires this;
it's just Another Way To Do It.
--
David Lee Lambert ... Software Developer, member IEEE, ACM
Cell phone: +1 586-873-8813
GPG key at http://www.lmert.com/keyring.txt
IM: davidleelambert (Yahoo!) or lambe...@cse.msu.edu (MSN)
--
clauses in
the same query. In general, when one uses ORDER BY, they expect their
results ordered based on the data returned. Being able to explain the
reason for this inconsistency is nice, but it certainly doesn't
invalidate the problem.
-Lee
-Original Message-
From: Tom Lane [mailt
On Dec 17, 2:30 pm, Andrew Gierth wrote:
> Has anyone ever managed to get uuid generation working on FreeBSD? [...]
>
> ([...] The only solution I could come up with was to knock
> off a quick uuid-freebsd module that uses the base system uuid
> functions rather than the ossp ones. I could put thi
t;feel"
for data. That always builds the unrandomized relation and then sorts it. I
guess an alternate path for single-table queries would be to randomly choose
a block number and then a tuple number; but that would be biased toward long
rows (of which fewer can appear in a block).
--
that ended up not compiling.)
I still have not tried this with my own C++ code, but it seems to have less
impact on the build process than some might have feared.
--
David Lee Lambert ... Software Developer
Cell phone: +1 586-873-8813 ; alt. email <[EMAIL PROTECTED]> or
<[EMAIL PROTECT
me library.
Everything else is routine stuff that an experienced C++ developer would end
up catching while trying to get his build-system for a new project running;
but it could certainly scare away someone with less experience. Better to
deal with this way ahead of time and test it on a few pla
Thanks for the feedback Tom. An initial patch for this has been posted
to pgsql-patches.
Cheers,
T
Tom Lane wrote:
Thomas Lee <[EMAIL PROTECTED]> writes:
How does this sound:
* A new GUC variable -- "activity_message_size" -- will be introduced
Well, &
Hi,
I'm new to the postgresql source, thought I'd try my hand at
implementing the change suggested (i.e. the GUC-ification of the
PGBE_ACTIVITY_SIZE constant) to get my hands dirty with the code.
How does this sound:
* A new GUC variable -- "activity_message_size" -- will be introduced
* The
can change cost delay setting of
workers on-the-fly. This can be achieved by forcing VACUUM refers to the
cost delay setting in its worker’s share memory every vacuum_delay_point.
Any comments or suggestions?
Best Regards
Galy Lee
[EMAIL PROTECTED]
NTT Open Source Software Center
orithm needs to ensure
each worker can finish their tasks on time, this might resolve the
headache HOT table problem. But this is a further issue to be discussed
after 8.3.
Best Regards
Galy Lee
lee.galy _at_ oss.ntt.co.jp
NTT Open Source Software Center
-
d | relid | group
--+---+---+---
1001 | 2 | 20001 | 0
1002 | 3 | 30001 | 0
Best Regards
Galy Lee
lee.galy _at_ oss.ntt.co.jp
NTT Open Source Software Center
---(end of broadcast)---
TIP 6: explain analyze is your friend
lly sounds more reasonable. We can use
it to balance total I/O of workers in service time or maintenance time.
It is not so difficult to achieve this by leveraging the share memory of
autovacuum.
Best Regards
Galy Lee
---(end of broadcast)---
TIP 9:
Alvaro Herrera wrote:
> I don't have anything else as detailed as a "plan". If you have
> suggestions, I'm all ears.
Cool, thanks for the update. :) We also have some new ideas on the
improvement of autovacuum now. I will raise it up later.
> Now regarding your restartable vacuum work.
> Does
autovacuum improvement for 8.4?
Thanks,
Galy Lee
lee.galy _at_ ntt.oss.co.jp
NTT Open Source Software Center
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joini
for it now. But I hope the
*restartable VACUUM feature* can be accepted for 8.3.
Hope your comments and suggestions.
Best Regards
Galy Lee
NTT Open Source Software Center
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project b
Simon Riggs wrote:
> Galy, please hear that people like your idea and understand your use
> case, but just don't like all of the proposal, just the main thrust of
> it. The usual way is that
> (people that agree + amount of your exact idea remaining) = 100%
Thank you. I am glad to hear that. :)
cation for me. :)
Regards,
--
Galy Lee
lee.galy _at_ oss.ntt.co.jp
NTT Open Source Software Center
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
runcate_heap, it takes AccessExclusiveLock for a long time,
that is problematic. Except we change such kinds of mechanism to ensure
that there is no problem to run vacuum on the same table for several
days, we can not say we don’t need to stop in a half way.
Best Regards,
--
Galy Lee <[EMAIL PR
Tom Lane wrote:
> Saving the array is
> expensive both in runtime and code complexity, and I don't believe we
> can trust it later --- at least not without even more expensive-and-
> complex measures, such as WAL-logging every such save :-(
I don’t understand well the things you are worrying about
Tom Lane wrote:
>One problem with it is that a too-small target would result in vacuum
>proceeding to scan indexes after having accumulated only a few dead
>tuples, resulting in increases (potentially enormous ones) in the total
>work needed to vacuum the table completely.
Yeah. This is also my bi
Simon Riggs wrote:
>>old dead tuple list. If the system manages the dead tuple list we may
>>need to keep such files around for long periods, which doesn't sound
>>great either.
The system manages such files. The files are kept in location like
$PGDATA/pg_vacuum. They are removed when CLUSTER, DR
sorry this late proposal, but I hope it can go into 8.3.
Welcome your comments and ideas.
Best Regards
Galy Lee ([EMAIL PROTECTED])
NTT Open Source Software Center
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donat
also merge the free space information into FSM.
We are working on this feature now. I will propose it latter to discuss
with you.
Best Regards
Galy Lee
--
NTT Open Source Software Center
---(end of broadcast)---
TIP 7: You can help suppor
Jim C. Nasby wrote:
On Thu, Jan 25, 2007 at 12:52:02AM -0300, Alvaro Herrera wrote:
Jim C. Nasby wrote:
I'll generally start with a cost delay of 20ms and adjust based on IO
utilization.
I've been considering set a default autovacuum cost delay to 10ms; does
this sound reasonable?
The pro
e interval of two vacuums? It seems that there is not easy to tune the
delay time of vacuum correctly.
Best Regards
--
Galy Lee
NTT Open Source Software Center
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an a
ect on the producing system outside the maintenance window.
Any ideas or comments?
Best Regards,
--
Galy Lee
NTT Open Source Software Center
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
c
do it quickly. If anyone is interested in the system, pls contact me.
I have a question. Does the PostgreSQL project have any plan of adding data integration functionalities in the PostgreSQL system as other DBMS vendors did? Thanks.Yours sincerely,Lee Rubao
[EMAIL PROTECTED]2006-11-1
[local] id
le
root 20809 978 1 09:47:17 pts/ta0:00 grep postg
#
Thanks
Lee
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
System: Windows XP Pro SP2
Running Postgres 8.0.3 for several months with the embedded PgAdmin3
1.2.1 on the same machine with no problems. Postgres is configured to
start automatically as a service. I installed the PgAdmin3 1.2.2 which
requested a Windows reboot. I rebooted without stopping Postg
Is there any documentation out there regarding the process used by the
postgreSQL development team on how Autoconf is used to create template
files for configuration of different operating systems (e.g. MinGW on
Windows, Red Hat Linux, etc.) and/or different hardware systems (e.g.
Intel processor,
Hi, All.
Has anyone successfully built PostgreSQL from source using MinGW? Anyone have
step-by-step instructions on how to do this? I am willing to write the
documentation on this if I can just get it to work. :-)
I have done the following:
1. Install MinGW
a. Go to URL: http://www.mingw
checkpoint and previous checkpoint.
Some of the code is borrowed from Tom Lane xlogdump.c file.
Hope for your advice.
Best RegardsYuanjia Lee
__Do You Yahoo!?Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
test
__
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html
---(end of broadcast)---
TIP 6: explain analyze is your friend
will be lost. Altough we can let the user the select
the possible time line, but the implementation until
now is using the highest time line number.
--- Tom Lane <[EMAIL PROTECTED]> wrote:
> yuanjia lee <[EMAIL PROTECTED]> writes:
> > The algorithm of searching the WAL i
limitation. Although I can search from the prevoius segement file of last segement file, but the implementation now just using the last segement file.
Regards
Yuanjia Lee
Start your day with Yahoo! - make it your home page
To be honest this idea strikes me as overkill - over
engineering. While there is a clear need for proper CSV import
(i.e. just setting DELIMITER to ',' doesn't work due to ','s in
strings) I cannot see how this would prove useful, or who would use
it?
While i have done a lot of messing around read
From: "Bruce Momjian" <[EMAIL PROTECTED]>
> Lee Kindness wrote:
> > Perhaps a cleaner way is to use an existing thread package with
encompasses
> > the various platform APIs - i.e. APR or ACE, or... But that's a big
> > discussion, and not one
From: "Bruce Momjian" <[EMAIL PROTECTED]>
> Lee Kindness wrote:
> > I still think it's worthwhile investigating the use of GCC's __thread
> > storage class specifier to remove the use of pthread_*specific in this
> > case. This would also be a help
d also be a help to the WIN32 port since this specifier
maps well to similar constructs in Microsoft's and Borland's compilers
(see "thread" item in the TODO at developer.postgresql.org).
And I still can't see how you'll bind sqlca to the connection object,
but b
From: "Michael Meskes" <[EMAIL PROTECTED]>
> Why? What doesn't work? AFAIRC the AT statement does indeed allow a
> variable as connection_target.
Yeah, I was wrong there. I updated the thread test program in ecpg/test to
make use of this functionality - see patch in pgsql-patches yesterday.
L.
gt; application gets.
>
> And on the plus side we don't have to worry about platform specific
threading
> models either.
>
> Thoughts?
>
> Shridhar
>
> Bruce Momjian wrote:
>
> > Should I add this to the TODO list?
> >
>
> -
Sort of related, I was thinking about adding some more thread-related
code such that if a connection wasn't explicitely specified then the
last connection SET or CONNECTed to for the current thread is used,
rather than just the "last connection".
But yeah, specifying the connection by variable (be
Marc G. Fournier writes:
> I think at this late stage in the game (almost 10 years), changing could
> be a bit difficult and confusing, no? :) I'd go with something like
> pgsqld myself though, keeps it short ... or we could go even shorter with
> just pgd ...
>
> But, I'm not, in any stre
point out the current
proliferation of terms is not user friendly. Any plans/interest in
standardisation?
Thanks, Lee.
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
On Mon, 8 Dec 2003, Tom Lane wrote:
> Elliot Lee <[EMAIL PROTECTED]> writes:
> > http://archives.postgresql.org/pgsql-hackers/2000-07/msg00483.php
> > I'm having this same problem with postgresql 7.3.4.
>
> You aren't having the "same" probl
http://archives.postgresql.org/pgsql-hackers/2000-07/msg00483.php
I'm having this same problem with postgresql 7.3.4. Easy to reproduce by
running an 'INSERT' query. Here is some of the debugging info if I break
near the beginning of the pglz_decompress function:
(gdb) p dend
$1 = (unsigned cha
Hi, please apply patch below to correct the EXEC SQL CREATE SCHEMA
construct in ECPG. Currently (versions 7.3.x, 7.4) the preprocessor
emmits "create scheme" in error, rather than "create schema".
A workaround also exists for those who require it (but I guess no-one
apart from me does since it's w
s of research. All other data models have been found
to
be flawed and (nearly) discarded.
If you don't care for mathematical principles, there's always ad-hoc database models.
Check out Pick, OO and XML databases. They're interested in what works and ignore
elegance and math
Bruce Momjian writes:
> Lee Kindness wrote:
> > No, it's not. Using the _r functions on such systems is BETTER because
> > the API is clean and the function can be implmented in a reentrant and
> > thread-safe fashion wuithout the need for thread local storage or
>
Bruce Momjian writes:
> Right. We can't assume because a *_r function is missing that the
> normal function is thread-safe.
I recon i'll get blue in the face before long, and one of you guys
will fly over to Scotland to give me a good kicking!... But'll say it
again anyway...
That's not our co
Lee Kindness writes:
> 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
> &
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
"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" <[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
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
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
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
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
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
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
> > >
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
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
an API which removes unneeded locking
within the old function.
I've still got the latest (and earlier with some configure work)
patches I submitted up at:
http://services.csl.co.uk/postgresql/
Thanks, Lee.
---(end of broadcast)---
TIP 6: Have you s
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
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
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:
> > 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
ily rework the
patch to revert 7.4 to a version of the 7.1 format which results in
the same feature gain but without forfeiting backward
compatibility. Let me know.
Thanks. Lee.
Index: src/backend/commands/copy.c
===
RCS file: /proje
Obviously TO is an SQL keyword, but it's not being
used within an EXEC SQL definition, so shouldn't break things.
Regards, Lee.
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
sub
aving on holiday tonight until Monday so will not
be able to get the example done...
Regards, Lee.
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
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
>
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
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
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:
> 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
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
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.
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
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),
1 - 100 of 176 matches
Mail list logo
