Hello PostgreSQL developers,
9.0beta5 seems to enable -Werror by default (which is a good thing,
thanks!). FORTIFY_SOURCE catches a few places where the result of
write() and fgets() is not checked, and thus the build fails with
gcc -g -O2 -g -Wall -O2 -fPIC -Wall -Wmissing-prototypes -Wpointer-a
On fre, 2010-04-30 at 12:55 +0200, Martin Pitt wrote:
> Hello PostgreSQL developers,
>
> 9.0beta5 seems to enable -Werror by default (which is a good thing,
> thanks!).
You probably mean alpha5, unless you come from the future. ;-) That was
actually a mistake in the packaging, which is why there
The following bug has been logged online:
Bug reference: 5443
Logged by: Claudio
Email address: clau...@livra.com
PostgreSQL version: 8.3.7
Operating system: CentOS
Description:Undetected deadlock situation
Details:
During a massive update of a table A, a single-row
The following bug has been logged online:
Bug reference: 5444
Logged by: Chaminda Jayawardana
Email address: wpgchami...@gmail.com
PostgreSQL version: 8.3
Operating system: Windows Server 2003
Description:Database Backup Restore - Out of memory problem
Details:
I ha
Peter Eisentraut [2010-04-30 14:56 +0300]:
> You probably mean alpha5, unless you come from the future. ;-)
FYI, those are next week's lottery numbers: 12, 19, ...
Right, of course I mean alpha-5, sorry.
> That was actually a mistake in the packaging
Oh, I see. Well, for a mistake the code is s
On Friday 30 April 2010 13:56:11 Peter Eisentraut wrote:
> On fre, 2010-04-30 at 12:55 +0200, Martin Pitt wrote:
> > Hello PostgreSQL developers,
> >
> > 9.0beta5 seems to enable -Werror by default (which is a good thing,
> > thanks!).
>
> You probably mean alpha5, unless you come from the future
On fre, 2010-04-30 at 14:43 +0200, Andres Freund wrote:
> On Friday 30 April 2010 13:56:11 Peter Eisentraut wrote:
> >
> > You probably mean alpha5, unless you come from the future. ;-) That was
> > actually a mistake in the packaging, which is why there is a -revised
> > tarball available.
> Isn
On fre, 2010-04-30 at 03:51 +, Claudio wrote:
> The following bug has been logged online:
>
> Bug reference: 5443
> Logged by: Claudio
> Email address: clau...@livra.com
> PostgreSQL version: 8.3.7
> Operating system: CentOS
> Description:Undetected deadlock situat
Peter Eisentraut wrote:
> This is not a deadlock.
Agreed.
> It's just two locks on the same table
Not as I read it.
> (and maybe a bit more readable formatting).
Eliminating null columns and mangling column headers for length, I
get this:
>> locktype| tranid | virtualx | pid
On Fri, Apr 30, 2010 at 9:14 AM, Peter Eisentraut wrote:
> On fre, 2010-04-30 at 14:43 +0200, Andres Freund wrote:
>> On Friday 30 April 2010 13:56:11 Peter Eisentraut wrote:
>> >
>> > You probably mean alpha5, unless you come from the future. ;-) That was
>> > actually a mistake in the packaging
On Fri, 2010-04-30 at 08:47 -0500, Kevin Grittner wrote:
> Peter Eisentraut wrote:
>
> > This is not a deadlock.
>
> Agreed.
>
> > It's just two locks on the same table
>
> Not as I read it.
>
> > (and maybe a bit more readable formatting).
>
> Eliminating null columns and mangling co
"Kevin Grittner" writes:
> Eliminating null columns and mangling column headers for length, I
> get this:
> locktype| tranid | virtualx | pid | mode | gr
> transactionid | 39773877 | 63/15761 | 11157 | ShareLock | f
> transactionid | 39773877 | 4/10902 | 6421 | ExclusiveLo
Claudio Freire wrote:
> I know it doesn't look like a deadlock from where you're standing,
> but it does so from where I am.
It's possible that you're filtering out the information which would
be most useful to diagnosing the problem. Next time it happens,
please send the entire output from p
"Kevin Grittner" writes:
> Claudio Freire wrote:
>> I know it doesn't look like a deadlock from where you're standing,
>> but it does so from where I am.
> It's possible that you're filtering out the information which would
> be most useful to diagnosing the problem. Next time it happens,
> pl
Robert Haas writes:
> Still, I think we should consider applying the portion of
> the proposed patch that avoid relying on the contents of the fgets()
> buffer after fgets() returns NULL,
I concur, those two changes look worthwhile. The proposed Assert()
additions are right out, though, as they
On Fri, 2010-04-30 at 11:50 -0400, Tom Lane wrote:
> "Kevin Grittner" writes:
> > Eliminating null columns and mangling column headers for length, I
> > get this:
>
> > locktype| tranid | virtualx | pid | mode | gr
> > transactionid | 39773877 | 63/15761 | 11157 | ShareLock
Andres Freund writes:
> plpython[u] leaks memory in PLy_spi_execute_fetch_result in the following
> snippet:
Yeah. There's a leak of the tuptable in the CATCH path, too. Will fix.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To m
Hi,
On Friday 30 April 2010 19:39:32 Tom Lane wrote:
> Andres Freund writes:
> > plpython[u] leaks memory in PLy_spi_execute_fetch_result in the following
>
> > snippet:
> Yeah. There's a leak of the tuptable in the CATCH path, too. Will fix.
Yes, theres even more than that (measured it) in th
On Fri, 2010-04-30 at 11:14 -0500, Kevin Grittner wrote:
> Claudio Freire wrote:
>
> > I know it doesn't look like a deadlock from where you're standing,
> > but it does so from where I am.
>
> It's possible that you're filtering out the information which would
> be most useful to diagnosing
On Fri, 2010-04-30 at 12:32 -0400, Tom Lane wrote:
> "Kevin Grittner" writes:
> > Claudio Freire wrote:
> >> I know it doesn't look like a deadlock from where you're standing,
> >> but it does so from where I am.
>
> > It's possible that you're filtering out the information which would
> > be
Andres Freund writes:
> On Friday 30 April 2010 19:39:32 Tom Lane wrote:
>> Yeah. There's a leak of the tuptable in the CATCH path, too. Will fix.
> Yes, theres even more than that (measured it) in the error case. Will have a
> look later today.
Here's the patch I'm planning to apply --- work
On Friday 30 April 2010 20:09:48 Tom Lane wrote:
> Andres Freund writes:
> > On Friday 30 April 2010 19:39:32 Tom Lane wrote:
> >> Yeah. There's a leak of the tuptable in the CATCH path, too. Will fix.
> >
> > Yes, theres even more than that (measured it) in the error case. Will
> > have a look
On Friday 30 April 2010 23:54:16 Andres Freund wrote:
> On Friday 30 April 2010 20:09:48 Tom Lane wrote:
> > Andres Freund writes:
> > > On Friday 30 April 2010 19:39:32 Tom Lane wrote:
> > >> Yeah. There's a leak of the tuptable in the CATCH path, too. Will
> > >> fix.
> > >
> > > Yes, theres
23 matches
Mail list logo
