On 4/25/06 1:01 AM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
>> Where do you want me to send it to?
>
> pgsql-bugs would be appropriate.
It's not that small that I would want to post it to a list. Also, I think
I've sanitized the data, but I wouldn't want to post it on a public list.
Or are you j
Maybe you can develop a graphic interface just like Fedora Core setup interface
which can choose packages installing, then the user can choose config file and
then have a little change in parameters.
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Jonah H. Harris" <[EMAI
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> On 4/25/06, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>> Personally I would much rather see a tuning advisor tool in more general
>> use than just provide small/medium/large config setting files.
> True dat.
One thing that has to be figured out befo
Jim C. Nasby wrote:
On Mon, Apr 24, 2006 at 11:05:18PM -0400, Tom Lane wrote:
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
While the student could do some benchmarking on relatively new
hardware and make suggestions, I agree with Tom. Having to keep
support for older platforms doesn'
Wes <[EMAIL PROTECTED]> writes:
> Where do you want me to send it to?
pgsql-bugs would be appropriate.
> Of course, since your hardware is different, it may not show up since it
> appears to be a timing thing.. I'm on a PB G4 1Ghz.
My G4 is in the shop at the moment, but Apple promised it back
On 4/24/06 11:02 PM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> [ shrug... ] Worksforme.
>
> There is a short interval at the end of the first CREATE INDEX on the
> table where the problem would happen if another CREATE INDEX tries to
> modify the pg_class row before the first one's committed. Tha
On 4/25/06, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> We have already done some initdb tuning improvements for 8.2
Cool, I hadn't looked at this.
> I would have liked to increase max_connections too, but that would have
> caused problems on OSX, apparently. See previous discussion.
Yeah, their
On Mon, Apr 24, 2006 at 11:05:18PM -0400, Tom Lane wrote:
> "Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> > While the student could do some benchmarking on relatively new
> > hardware and make suggestions, I agree with Tom. Having to keep
> > support for older platforms doesn't leave much flexib
Wes <[EMAIL PROTECTED]> writes:
> I can duplicate the error at will.
[ shrug... ] Worksforme.
There is a short interval at the end of the first CREATE INDEX on the
table where the problem would happen if another CREATE INDEX tries to
modify the pg_class row before the first one's committed. Tha
>> Long ago. I just tested it again, and AFAICS you can create indexes
>> concurrently so long as the underlying table isn't changing (ie,
>> neither reltuples nor relpages changes).
>
> Hrm, the OP seemed to find a case that was having problems:
> http://archives.postgresql.org/pgsql-general/200
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Gevik Babakhani wrote:
>> If one is going to revoke the last ACL_CONNECT, a warning is going to
>> issued then that part of the REVOKE gets canceled.
> Humm, no, the WARNING is issued but the REVOKE is executed anyway.
Why are we debating this? It won
On 4/24/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> We've talked more than once about offering multiple alternative
> starting-point postgresql.conf files to give people an idea of what to
> do for small/medium/large installations. MySQL have done that for years
> and it doesn't seem that users are
Are we OK with the Coverity reports now?
---
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> On Fri, Apr 21, 2006 at 09:12:51AM +0800, Christopher Kings-Lynne wrote:
> > >I havn't been able to find any more s
Gevik Babakhani wrote:
> If one is going to revoke the last ACL_CONNECT, a warning is going to
> issued then that part of the REVOKE gets canceled.
Humm, no, the WARNING is issued but the REVOKE is executed anyway.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
P
On 4/24/06 7:54 PM, "Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
>> Long ago. I just tested it again, and AFAICS you can create indexes
>> concurrently so long as the underlying table isn't changing (ie,
>> neither reltuples nor relpages changes).
>
> Hrm, the OP seemed to find a case that was havi
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> While the student could do some benchmarking on relatively new
> hardware and make suggestions, I agree with Tom. Having to keep
> support for older platforms doesn't leave much flexibility to change
> the defaults.
Another point here is that the de
On 4/24/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> I doubt this is SoC material, simply because the issues have little to
> do with coding and a lot to do with persuading people to drop default
> support for old platforms. Which is not something a student is likely
> to succeed at.
While the stude
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Where do we stand with getting much more reasonable default values in
> postgresql.conf? Maybe that should be a SoC project, or is it too small?
Define "much more reasonable".
I doubt this is SoC material, simply because the issues have little to
do wi
""Jim C. Nasby"" <[EMAIL PROTECTED]> wrote
>
> There a patched build available for testing? (I'd rather not have to
> figure out how to get windows builds working, unless there's some kind
> of instructions somewhere...)
> --
Not yet - the patch is still pending.
Regards,
Qingqing
--
Hi,
The following is also added to a new patch.
> > At this moment the owner of the database CAN REVOKE himself form the
> > ACL_OBJECT_DATABASE. If the implementation above is acceptable then I
> > can work on this one :)
>
> Hmm, what do you want to do about it? ISTM the owner should be able
On Mon, Apr 24, 2006 at 08:42:41PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > Was the code ever changed so that it won't update relpages if the number
> > is the same?
>
> Long ago. I just tested it again, and AFAICS you can create indexes
> concurrently so long as th
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Was the code ever changed so that it won't update relpages if the number
> is the same?
Long ago. I just tested it again, and AFAICS you can create indexes
concurrently so long as the underlying table isn't changing (ie,
neither reltuples nor relpages
On Mon, Apr 24, 2006 at 08:14:33PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > Since this seems to only be an issue due to trying to update pg_class
> > for the table, perhaps CREATE INDEX can just ignore errors there?
>
> Lessee, where would ignoring an error potential
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Since this seems to only be an issue due to trying to update pg_class
> for the table, perhaps CREATE INDEX can just ignore errors there?
Lessee, where would ignoring an error potentially cause the greatest
damage? I can hardly think of a less critical
moving to -hackers
On Sun, Apr 23, 2006 at 09:06:59AM -0500, Wes wrote:
> Postgres: 8.1.3
> OS: Mac OS X 10.4.6
>
> I've run into another concurrency issue - parallel building of indexes.
> When I try to build multiple indexes at a time, I randomly get:
>
> ERROR: tuple concurrently updated
>
Kris Jurka wrote:
>
>
> On Mon, 24 Apr 2006, Bruce Momjian wrote:
>
> > Great, fix attached and applied.
> >
>
> You also need to change lines 48 and 64 of heapam.h to use the same
> coding.
Done.
--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDBhttp://www.enterprisedb.com
On Mon, 24 Apr 2006, Bruce Momjian wrote:
Great, fix attached and applied.
You also need to change lines 48 and 64 of heapam.h to use the same
coding.
Kris Jurka
---(end of broadcast)---
TIP 5: don't forget to increase your free space map
Kris Jurka wrote:
>
>
> On Mon, 24 Apr 2006, Martijn van Oosterhout wrote:
>
> > Perhaps someone could check if changing the test explicitly check
> > against NULL:
> >
> >> ((attnum) > (int) (tup)->t_data->t_natts) ? \
> >> ( \
> >> (((isnull) != NULL)? (
On Mon, Apr 24, 2006 at 05:39:30PM -0400, Tom Lane wrote:
> > Yes, this coding removes the warning.
>
> Oh, good, that seems like a reasonable change to make (it's arguably
> more clear than the original anyway).
>
> Is this the only place where the warning shows up? ISTM there's quite
> a lot o
Kris Jurka <[EMAIL PROTECTED]> writes:
> On Mon, 24 Apr 2006, Martijn van Oosterhout wrote:
>> Perhaps someone could check if changing the test explicitly check
>> against NULL:
>>
>> ((attnum) > (int) (tup)->t_data->t_natts) ? \
>> ( \
>> (((isnull) != NULL)? (*(isnull) = true) : (dummyret)NULL),
Confirmed to work on Win32 Visual C++.
With this patch, Win32 VisualC++ now passes all regression tests.
Thanks, Tom!
//Magnus
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
> Sent: Monday, April 24, 2006 10:37 PM
> To: pgsql-committer
On Mon, 24 Apr 2006, Martijn van Oosterhout wrote:
Perhaps someone could check if changing the test explicitly check
against NULL:
((attnum) > (int) (tup)->t_data->t_natts) ? \
( \
(((isnull) != NULL)? (*(isnull) = true) : (dummyret)NULL), \
On Mon, Apr 24, 2006 at 01:16:04PM -0500, Kris Jurka wrote:
>
>
> On Mon, 24 Apr 2006, Gevik Babakhani wrote:
>
> >I noticed the following compile warnings. Perhaps someone is interested
> >to know about them.
>
> Also I was testing a gcc 4.2 snapshot (20060419) and it has a whole lot of
> war
> > That totally didn't work on visual c++ at least. It fixes those two
> > ones, but it breaks the other lines in the same test:
>
> It's a couple bricks shy of a load (doesn't handle zero or
> negative input correctly) but easily fixed. I'm just about
> to commit it.
Great. I'll check it ou
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> That totally didn't work on visual c++ at least. It fixes those two
> ones, but it breaks the other lines in the same test:
It's a couple bricks shy of a load (doesn't handle zero or negative
input correctly) but easily fixed. I'm just about to comm
Tom Lane wrote:
> Kris Jurka <[EMAIL PROTECTED]> writes:
> > Also I was testing a gcc 4.2 snapshot (20060419) and it has a whole lot of
> > warnings stemming from heap_getattr's isnull check:
> > aclchk.c:791: warning: the address of 'isNull', will always evaluate as
> > 'true'
>
> We need to lo
> > What do you think is best - try to adapt that version, or
> update our
> > regression tests outputs to accept the output from our current code?
>
> Given that our output gets very very close, perhaps we should
> take a hint from the end of the MinGW version, do a single
> Newton iteration
Gevik Babakhani wrote:
> I noticed the following compile warnings. Perhaps someone is interested
> to know about them.
>
> /usr/bin/flex -o'pgc.c' pgc.l
> gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
> -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g
> -Wno-erro
Kris Jurka <[EMAIL PROTECTED]> writes:
> Also I was testing a gcc 4.2 snapshot (20060419) and it has a whole lot of
> warnings stemming from heap_getattr's isnull check:
> aclchk.c:791: warning: the address of 'isNull', will always evaluate as
> 'true'
We need to lobby the gcc maintainers to not
Martijn van Oosterhout writes:
> Given that our output gets very very close, perhaps we should take a
> hint from the end of the MinGW version, do a single Newton iteration to
> fixup those last few digits.
That seems like a plan to me.
regards, tom lane
> Ok, good. This is what people was aiming for initially, I hope. What
> do people think, particularly those who wanted to manage pg_hba.conf via
> SQL commands?
I guess for this one more people have to play with the new
functionality.
> Without looking at the surrounding code, I'm a bit wary
On Mon, Apr 24, 2006 at 03:01:51PM +0200, Magnus Hagander wrote:
> If I undefine HAVE_CBRT on Linux, I get the exact same failure! So it
> seems our own version of cbrt() is broken wrt our own regression tests
> :-( Must be that nobody else (at least on i386) uses that code.
> What do you think
On Mon, 24 Apr 2006, Gevik Babakhani wrote:
I noticed the following compile warnings. Perhaps someone is interested
to know about them.
Also I was testing a gcc 4.2 snapshot (20060419) and it has a whole lot of
warnings stemming from heap_getattr's isnull check:
aclchk.c:791: warning: the
Dhanaraj M <[EMAIL PROTECTED]> writes:
> Pl. look at the following code, which is taken from alter_table.sql
> (regression test)
The regression test is designed to check for the current behavior.
If we were to change the behavior, then of course we'd need to change
the regression test as well.
P
Tom Lane wrote:
Simon Riggs <[EMAIL PROTECTED]> writes:
On Fri, 2006-04-21 at 13:01 -0400, Tom Lane wrote:
I've been looking into Gavin Hamill's recent report of poor performance
with PG 8.1 on an 8-way IBM PPC64 box.
Keep in mind that Gavin's 8-way turns back into a pumpkin on Monday :-(
> > I'm getting the following regression errors with a backend
> built using
> > Visual C++:
>
> Is HAVE_CBRT getting defined? Either their cbrt() routine or
> our default one seems to be generating slightly-off answers.
> The default one (at the bottom of float.c) certainly looks a
> bit c
Hi
> I don't understand. The code should look like this:
>
> if (acl in pg_database == NULL)
> acl = acldefault
> else
> acl = acl in pg_database
> if (has_permission(acl, user, ACL_CONNECT))
> can connect
> else
> can't connect
>
To my surprise the code you described a
On Fri, 21 Apr 2006 17:38:01 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> I believe the particular test case being looked at here is read-only
> (Gavin, is that correct?)
Yes - I made sure the devels made it readonly so I could farm search
requests out to Slony-replicated machines (ended up runnin
Martijn, thanks for finfing those leaks. I haven't been around last
week, so it took until today to commit the fixes. But they are in now.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL
Where do we stand with getting much more reasonable default values in
postgresql.conf? Maybe that should be a SoC project, or is it too small?
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nas
I noticed the following compile warnings. Perhaps someone is interested
to know about them.
/usr/bin/flex -o'pgc.c' pgc.l
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g
-Wno-error -I./../include -I. -I../../../../s
On Mon, Apr 24, 2006 at 10:23:07AM +0800, Qingqing Zhou wrote:
>
> "Tom Lane" <[EMAIL PROTECTED]> wrote
> > Martijn van Oosterhout writes:
> > > On Thu, Apr 20, 2006 at 12:17:07PM -0500, Jim C. Nasby wrote:
> > >> Here's one to add to the list: running pgbench with a moderately heavy
> > >> load
Gevik Babakhani wrote:
> To my surprise the code you described above was already there :)
> function aclchk.c:pg_database_aclmask:1696
Sure, that sort of was my point :-)
> If the above is okay and correct. Then I guess for simple systems one
> could only enter the line below in pg_hba.conf
>
Bug- raised:
=
BUG #2073: Can't drop sequence when created via SERIAL column
Answered:
Right. We have this TODO item:
* %Disallow changing default expression of a SERIAL column?
which would prevent you from changing the default expression for a
SERIAL column. So the
"Tom Lane" <[EMAIL PROTECTED]> wrote
>
> The thing that's nagging at me at the moment is the realization that a
> partitioned hashtable will eat more shared memory than a single
> hashtable. It wasn't that long ago that we had to do some hacking to
> ensure that the buffer hashtable couldn't run
55 matches
Mail list logo
