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 out of
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
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
On Mon, Apr 24, 2006 at 10:23:07AM +0800, Qingqing Zhou wrote:
Tom Lane [EMAIL PROTECTED] wrote
Martijn van Oosterhout kleptog@svana.org 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
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.
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:
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:
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 running
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 above was
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 cheesy,
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
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.
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:
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.
snip
What do you think
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 of
Martijn van Oosterhout kleptog@svana.org 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
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 give
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-error
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 to fixup
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 lobby the gcc
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 commit
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 out on
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
warnings
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:
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), \
(Datum)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 of code
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)? (*(isnull) = true) :
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, 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
+ If your
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
The
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
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 potentially cause
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: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 the
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 to
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
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 with
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 student
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 defaults
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 having
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/
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
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
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't get
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:
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. That
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 flexibility to
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 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. That would
50 matches
Mail list logo
