On Mon, Apr 19, 2010 at 10:52 AM, Robert Haas wrote:
> On Thu, Feb 18, 2010 at 8:41 PM, Bruce Momjian wrote:
>> Peter Eisentraut wrote:
>>> On ons, 2009-12-30 at 12:55 -0500, Greg Smith wrote:
>>> > Basically, configure failed on their OpenBSD system because thread
>>> > safety is on but the libx
On Thu, Feb 18, 2010 at 8:41 PM, Bruce Momjian wrote:
> Peter Eisentraut wrote:
>> On ons, 2009-12-30 at 12:55 -0500, Greg Smith wrote:
>> > Basically, configure failed on their OpenBSD system because thread
>> > safety is on but the libxml2 wasn't compiled with threaded support:
>> > http://xmlso
Peter Eisentraut wrote:
> On ons, 2009-12-30 at 12:55 -0500, Greg Smith wrote:
> > Basically, configure failed on their OpenBSD system because thread
> > safety is on but the libxml2 wasn't compiled with threaded support:
> > http://xmlsoft.org/threads.html
> >
> > Disabling either feature (no
On ons, 2009-12-30 at 12:55 -0500, Greg Smith wrote:
> Basically, configure failed on their OpenBSD system because thread
> safety is on but the libxml2 wasn't compiled with threaded support:
> http://xmlsoft.org/threads.html
>
> Disabling either feature (no --with-libxml or --disable-thread-sa
Tom Lane wrote:
> But my recollection of the parallel psql patch discussion is that it was
> rejected because nobody felt comfortable with the API design. Do we
> have any better ideas in that department yet?
It wasn't rejected AFAICT. A finalized API with which there was
(almost?) no dissent w
Greg Stark writes:
> On Fri, Dec 11, 2009 at 6:08 PM, Tom Lane wrote:
>> I'll commit a fix for that shortly, but this reminds me once again that
>> the EvalPlanQual logic is desperately under-tested in our normal
>> regression testing. We really need some kind of testing infrastructure
>> that w
On Fri, Dec 11, 2009 at 6:08 PM, Tom Lane wrote:
> I wrote:
> I'll commit a fix for that shortly, but this reminds me once again that
> the EvalPlanQual logic is desperately under-tested in our normal
> regression testing. We really need some kind of testing infrastructure
> that would let us exe
I wrote:
> ... What I would have expected is crashes on the very
> similar updates to pgbench_branches, which is designed to be
> high-contention. It might be that there is some other effect going on
> here that explains why that wasn't happening. Need to go back and look
> more closely.
... and
Greg Smith writes:
> It sounds like random pgbench run for a while would certainly expose the
> same thing you're concerned about eventually.
Yeah. Actually the odd thing about it is that the crash seemed to
invariably be on conflicting pgbench_accounts updates, which is a fairly
low-contention
Tom Lane wrote:
Also, the reason why Bruce's mistake exposed this is interesting.
Omitting the #define for ENABLE_THREAD_SAFETY does not actually break
"pgbench -j" at all -- it has a fallback strategy that uses multiple
subprocesses instead of multiple threads. However, it has only one
srandom(
I wrote:
> The crash is real --- I've replicated it here. Still trying to figure
> out what is the real cause.
Okay, I've sussed it. The crash itself is due to a memory management
mistake in the recently-rewritten EvalPlanQual code (pfree'ing a tuple
that we still have live Datum references to).
On 12/11/09, Tom Lane wrote:
> Alvaro Herrera writes:
> > Yes, but what if you test with the broken pgbench? As Tom says, it
> > should not be able to crash the backend no matter what it does.
>
>
> The crash is real --- I've replicated it here. Still trying to figure
> out what is the real
Alvaro Herrera writes:
> Yes, but what if you test with the broken pgbench? As Tom says, it
> should not be able to crash the backend no matter what it does.
The crash is real --- I've replicated it here. Still trying to figure
out what is the real cause.
regards, tom l
Jaime Casanova wrote:
> On Thu, Dec 10, 2009 at 11:33 PM, Jaime Casanova
> wrote:
> > On Thu, Dec 10, 2009 at 11:22 PM, Tom Lane wrote:
> >>
> >> My bet is that the real problem was a build inconsistency in
> >> the backend. Does "make distclean" and rebuild make it go away?
> >>
> >
> > actuall
On Thu, Dec 10, 2009 at 11:33 PM, Jaime Casanova
wrote:
> On Thu, Dec 10, 2009 at 11:22 PM, Tom Lane wrote:
>>
>> My bet is that the real problem was a build inconsistency in
>> the backend. Does "make distclean" and rebuild make it go away?
>>
>
> actually it was a clean build just after a cvs
On Thu, Dec 10, 2009 at 11:22 PM, Tom Lane wrote:
>
> My bet is that the real problem was a build inconsistency in
> the backend. Does "make distclean" and rebuild make it go away?
>
actually it was a clean build just after a cvs co (not an updated
tree), i build the binaries and installed it in
Greg Smith writes:
> The "-j" option is the recent addition to pgbench that causes it to
> launch multiple client threads when enabled, each handling a subset of
> the transactions. There's blocks of codes in pgbench.c now that depend
> on having sane values for thread safety in libpq. That i
Bruce Momjian wrote:
> Greg Smith wrote:
> > Bruce Momjian wrote:
> > > Peter Eisentraut wrote:
> > >
> > >>> if i remove the -j option then it runs without a problem
> > >>>
> > >> Possibly related to the incomplete removal of the enable-thread-safety
> > >> option that I just posted abo
Greg Smith wrote:
> Bruce Momjian wrote:
> > Peter Eisentraut wrote:
> >
> >>> if i remove the -j option then it runs without a problem
> >>>
> >> Possibly related to the incomplete removal of the enable-thread-safety
> >> option that I just posted about.
> >>
> >
> > I thought about
Bruce Momjian wrote:
Peter Eisentraut wrote:
if i remove the -j option then it runs without a problem
Possibly related to the incomplete removal of the enable-thread-safety
option that I just posted about.
I thought about that but I can't figure out how that would affect
pgbenc
Peter Eisentraut wrote:
> > starting vacuum...end.
> > TRAP: FailedAssertion("!((data - start) == data_size)", File:
> > "heaptuple.c", Line: 255)
> > Client 0 aborted in state 8. Probably the backend died while processing.
> > LOG: server process (PID 30713) was terminated by signal 6: Aborted
>
On ons, 2009-12-09 at 14:02 -0500, Jaime Casanova wrote:
> Hi,
>
> I compiled current HEAD and trying to use pgbench, i initialized a
> test database this way:
> bin/pgbench -i -F80 -s100 test
>
> and then run with this options:
> bin/pgbench -c 50 -j 5 -l -t 20 test
>
> and get this crash:
> ""
Andrew Chernow napsal(a):
It would probably be useful to nail down the supported platforms, have a
list somewhere of the oldest ones: oldest solaris, hpux, irix, aix, sco,
etc...
I ran into a few --enable-thread-safety problems, Magnus fixed the
cygwin build already. hpux 10.20 and solari
Magnus Hagander wrote:
On 27 nov 2008, at 13.00, Alvaro Herrera <[EMAIL PROTECTED]>
wrote:
Peter Eisentraut wrote:
Magnus Hagander wrote:
Can someone remind me why we have --enable-thread-safety? As opposed to
it being default and having --disable-thread-safety.
I don't have any numbers or
On 27 nov 2008, at 13.00, Alvaro Herrera <[EMAIL PROTECTED]>
wrote:
Peter Eisentraut wrote:
Magnus Hagander wrote:
Can someone remind me why we have --enable-thread-safety? As
opposed to
it being default and having --disable-thread-safety.
I don't have any numbers or a roster to support
Peter Eisentraut wrote:
> Magnus Hagander wrote:
>> Can someone remind me why we have --enable-thread-safety? As opposed to
>> it being default and having --disable-thread-safety.
>
> I don't have any numbers or a roster to support this, but I suppose that
> thread-safety is not supported on som
Magnus Hagander wrote:
Can someone remind me why we have --enable-thread-safety? As opposed to
it being default and having --disable-thread-safety.
I don't have any numbers or a roster to support this, but I suppose that
thread-safety is not supported on some platforms. So either we'd have
t
Jan Wieck wrote:
> On 6/10/2004 2:11 AM, Tom Lane wrote:
>
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> Are people OK with requiring PGUSER, $USER, $LOGNAME, or the username to
> >> be supplied by the connection string in libpq on platforms that want
> >> threads and don't have getpwuid_r()
Jan Wieck wrote:
> > I looked over the code and the only place getpwuid_r (through
> > pqGetpwuid) is used is in libpq to look up the default username based on
> > the euid for the connection to the backend. Unfortunately, I can't find
> > any other way to do such a lookup in a thread-safe manner
On 6/10/2004 8:49 AM, Bruce Momjian wrote:
Jan Wieck wrote:
Make it so that --enable-thread-safety bombs out, but make another
--enable-thread-safey-anyway work the way Tom descibed it.
Sure, we can do that by just not running the thread_test program. In
fact a cross-compile already skips running
Jan Wieck wrote:
> On 6/10/2004 2:11 AM, Tom Lane wrote:
>
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> Are people OK with requiring PGUSER, $USER, $LOGNAME, or the username to
> >> be supplied by the connection string in libpq on platforms that want
> >> threads and don't have getpwuid_r()
On 6/10/2004 2:11 AM, Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Are people OK with requiring PGUSER, $USER, $LOGNAME, or the username to
be supplied by the connection string in libpq on platforms that want
threads and don't have getpwuid_r() (Solaris, FreeBSD, etc.)?
AFAICS that was
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Are people OK with requiring PGUSER, $USER, $LOGNAME, or the username to
> be supplied by the connection string in libpq on platforms that want
> threads and don't have getpwuid_r() (Solaris, FreeBSD, etc.)?
AFAICS that was not what Jan was suggesting at
Are people OK with requiring PGUSER, $USER, $LOGNAME, or the username to
be supplied by the connection string in libpq on platforms that want
threads and don't have getpwuid_r() (Solaris, FreeBSD, etc.)?
If so, I can easily create a patch and apply it.
---
Jan Wieck wrote:
> On 6/9/2004 1:44 PM, Bruce Momjian wrote:
>
> > Jan Wieck wrote:
> >> On 6/9/2004 1:04 PM, Bruce Momjian wrote:
> >>
> >> > What we really need is a way to do the uid->username mapping in a
> >> > thread-safe way. Could we check the environment for $USER or $LOGNAME?
> >> > Co
On 6/9/2004 1:44 PM, Bruce Momjian wrote:
Jan Wieck wrote:
On 6/9/2004 1:04 PM, Bruce Momjian wrote:
> What we really need is a way to do the uid->username mapping in a
> thread-safe way. Could we check the environment for $USER or $LOGNAME?
> Could we require them to be set for thread builds on O
Jan Wieck wrote:
> On 6/9/2004 1:04 PM, Bruce Momjian wrote:
>
> > What we really need is a way to do the uid->username mapping in a
> > thread-safe way. Could we check the environment for $USER or $LOGNAME?
> > Could we require them to be set for thread builds on OS's without
> > getpwuid_r and
On 6/9/2004 1:04 PM, Bruce Momjian wrote:
What we really need is a way to do the uid->username mapping in a
thread-safe way. Could we check the environment for $USER or $LOGNAME?
Could we require them to be set for thread builds on OS's without
getpwuid_r and in cases where the username is not spe
Well, looks like you are missing getpwuid_r():
Your system uses getpwuid() which is not thread-safe. **
and we don't have any workaround for this.
---
Jan Wieck wrote:
> On 6/9/2004 11:16 AM, Bruce Momjian wrote:
>
Jan Wieck wrote:
> On 6/9/2004 11:45 AM, Bruce Momjian wrote:
>
> > Jan Wieck wrote:
> >> The problem is that if your thread-safety tests fail, there is no way to
> >> build libpq with -pthread and -DREENTRANT or whatever is required on
> >> that platform. On Solaris this results in errno being
Jan Wieck wrote:
> On 6/9/2004 9:36 AM, Bruce Momjian wrote:
> >
> >> Also, I would suggest that we allow to build the libpq with thread
> >> specific compiler options, even if it is not entirely thread safe. It
> >> would require that a really multithreaded application has to have
> >> mutexes
On 6/9/2004 11:16 AM, Bruce Momjian wrote:
Jan Wieck wrote:
On 6/9/2004 9:36 AM, Bruce Momjian wrote:
> Jan Wieck wrote:
>> I am wondering why thread_test.c is checking for mktemp()? That function
>> is nowhere used in the libpq.
>
> Uh, it isn't checking for mktemp, it is using it, and it is usi
On 6/9/2004 11:45 AM, Bruce Momjian wrote:
Jan Wieck wrote:
The problem is that if your thread-safety tests fail, there is no way to
build libpq with -pthread and -DREENTRANT or whatever is required on
that platform. On Solaris this results in errno being defined as
extern int errno;
as sup
On 6/9/2004 9:36 AM, Bruce Momjian wrote:
Jan Wieck wrote:
I am wondering why thread_test.c is checking for mktemp()? That function
is nowhere used in the libpq.
Uh, it isn't checking for mktemp, it is using it, and it is using it
because someone didn't like hard-coded paths I was using in the pas
Jan Wieck wrote:
> On 6/9/2004 9:36 AM, Bruce Momjian wrote:
>
> > Jan Wieck wrote:
> >> I am wondering why thread_test.c is checking for mktemp()? That function
> >> is nowhere used in the libpq.
> >
> > Uh, it isn't checking for mktemp, it is using it, and it is using it
> > because someone di
On 6/9/2004 9:36 AM, Bruce Momjian wrote:
Also, I would suggest that we allow to build the libpq with thread
specific compiler options, even if it is not entirely thread safe. It
would require that a really multithreaded application has to have
mutexes around certain operations, but being entir
Jan Wieck wrote:
> I am wondering why thread_test.c is checking for mktemp()? That function
> is nowhere used in the libpq.
Uh, it isn't checking for mktemp, it is using it, and it is using it
because someone didn't like hard-coded paths I was using in the past.
Is there something wrong with usi
[ CC to advocacy.]
Mendola Gaetano wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> wrote:
> > The thing that slows me down the most --- trips like FOSDEM. I am doing
> > one every month or every other month. That takes 1/4 of each month.
> > The threading discussion took 1/1000 of a month, but I
"Bruce Momjian" <[EMAIL PROTECTED]> wrote:
> The thing that slows me down the most --- trips like FOSDEM. I am doing
> one every month or every other month. That takes 1/4 of each month.
> The threading discussion took 1/1000 of a month, but I do several
> hundred of those, so it fills up a mont
On Tue, 2 Sep 2003 03:06 am, Mendola Gaetano wrote:
> May be I'm wrong but I'd like know why thread safety was so
> necessary.
It bugged Lee enough that he went and wrote a patch for it. It bugged me
enough that I couldn't use it on our choice of platform (older Linux) that I
did some little fix
Mendola Gaetano wrote:
> I seen on this list a lot of energy ( also little flames involving SCO
> & Co. ) spent on thread safety;
> was really necessary spent so much energy in this direction?
> I was at Fosdem in Bruxelles ( I spoke there about the use
> of postgres in my project ) and I seen al
Mendola Gaetano wrote:
> I seen on this list a lot of energy ( also little flames involving SCO
> & Co. ) spent on thread safety;
> was really necessary spent so much energy in this direction?
> I was at Fosdem in Bruxelles ( I spoke there about the use
> of postgres in my project ) and I seen al
On Mon, Sep 01, 2003 at 18:16:25 +0100,
Lee Kindness <[EMAIL PROTECTED]> wrote:
>
> Was Bruce planning to do the PITR work? If so I guess a lot of his
> time's been spent on integrating patches and the like - leaving less
> time for other developments.
Bruce was working on the WIN32 port. That
53 matches
Mail list logo
