Mayuresh Nirhali [EMAIL PROTECTED] writes:
Sun Studio does not like array declarations with null as dimenstion.
So, In pipe.c we have,
typedef struct
{
LWLockId shmem_lock;
pipe *pipes;
alert_event *events;
alert_lock *locks;
size_t size;
pg_dump restore times can be high when they include many ALTER TABLE ADD
FORIEGN KEY statements, since each statement checks the data to see if
it is fully valid in all cases.
I've been asked why we run that at all?, since if we dumped the tables
together, we already know they match.
If we had a
Tom Lane wrote:
Most C compilers don't like that either. The standard locution is
something like
char data[1]; /* VARIABLE LENGTH ARRAY */
Yes, I tried this already and forgot to mention earlier that with such
patch, I do not see any other errors.
So, this is
On Thu, Jun 5, 2008 at 2:18 AM, Mayuresh Nirhali
[EMAIL PROTECTED] wrote:
Most C compilers don't like that either. The standard locution is
something like
char data[1]; /* VARIABLE LENGTH ARRAY */
So, this is the only issue with Sun Studio compilation of orafce.
Tom Lane wrote:
* How much overhead disk space are you willing to let Postgres use?
... The third one is a bit weird but
I don't see any other good way to set the checkpoint parameters.
The way I think about the checkpoint settings is:
1. Set checkpoint_timeout to the max. time you're
Guys,
A configuration wizard would be nice, but it would be a good start to
add a section to the manual on how to do the basic tuning. AFAICS we
don't have one. Clear instructions on how to set the few most important
settings like shared_buffers and checkpoint_timeout/segments would
probably
Simon Riggs wrote:
I'm guessing that the WITHOUT CHECK option would not be acceptable as an
unprotected trap for our lazy and wicked users. :-)
Yes, that sounds scary.
Instead, I'd suggest finding ways to speed up the ALTER TABLE ADD
FOREIGN KEY. Or speeding up COPY into a table with foreign
On Thu, 2008-06-05 at 10:19 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
I'm guessing that the WITHOUT CHECK option would not be acceptable as an
unprotected trap for our lazy and wicked users. :-)
Yes, that sounds scary.
Instead, I'd suggest finding ways to speed up the ALTER
On Thu, 5 Jun 2008, Heikki Linnakangas wrote:
A configuration wizard would be nice, but it would be a good start to add a
section to the manual on how to do the basic tuning. AFAICS we don't have
one. Clear instructions on how to set the few most important settings like
shared_buffers and
Simon Riggs wrote:
If we had a way of pg_dump passing on the information that the test
already passes, we would be able to skip the checks.
Proposal:
* Introduce a new mode for ALTER TABLE ADD FOREIGN KEY [WITHOUT CHECK];
* Have pg_dump write the new syntax into its dumps, when both the
Jeff Davis [EMAIL PROTECTED] writes:
On Wed, 2008-06-04 at 14:17 +0300, Heikki Linnakangas wrote:
Would that also cover possible differences in page size, 32bit OS vs.
64bit OS, different timestamp flavour, etc. issues ? AFAIR, all these
things can have an influence on how the data is
Simon Riggs wrote:
pg_dump restore times can be high when they include many ALTER TABLE ADD
FORIEGN KEY statements, since each statement checks the data to see if
it is fully valid in all cases.
I've been asked why we run that at all?, since if we dumped the tables
together, we already know
Simon Riggs wrote:
Are you saying you don't like the rest of the proposal, or just don't
like the idea of having that added as an unprotected option, but find
the proposal acceptable?
I don't like the idea of having an unprotected option. If we were going
to have one, I wouldn't bother with
On Thu, 2008-06-05 at 07:57 -0400, Andrew Dunstan wrote:
Simon Riggs wrote:
pg_dump restore times can be high when they include many ALTER TABLE ADD
FORIEGN KEY statements, since each statement checks the data to see if
it is fully valid in all cases.
I've been asked why we run that
Simon Riggs wrote:
On Thu, 2008-06-05 at 10:19 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
I'm guessing that the WITHOUT CHECK option would not be acceptable as an
unprotected trap for our lazy and wicked users. :-)
Yes, that sounds scary.
Instead, I'd suggest finding ways to speed
On Thu, 2008-06-05 at 16:01 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Thu, 2008-06-05 at 10:19 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
I'm guessing that the WITHOUT CHECK option would not be acceptable as an
unprotected trap for our lazy and wicked users. :-)
Simon Riggs wrote:
On Thu, 2008-06-05 at 16:01 +0300, Heikki Linnakangas wrote:
Well, one idea would be to allow adding multiple foreign keys in one
command, and checking them all at once with one SQL query instead of one
per foreign key. Right now we need one seq scan over the table per
Hi,
Consider this simple case:
postgres=# TRUNCATE foo, foo;
ERROR: cannot TRUNCATE foo because it is being used by active queries in
this session
The above occurs because the ExecuteTruncate() function invokes
truncate_check_rel() in a loop. Since the same table name appears twice, the
On Thu, Jun 05, 2008 at 01:23:53AM +0200, Rainer Bauer wrote:
I think it would be an enourmous help for beginners if they had a simple
tuning tool which would tell them which values where altered (and possibly
why) from Postgres' default settings based on some basic information.
Like:
-
I can add index support and support for arbitrary distance between
lexeme.
It appears to me that supporting arbitrary boolean expression will be
complicated. Can we pull out something from TSQuery?
I don't very like an idea to have separated interface for phrase search. Your
patch may be a
Heikki Linnakangas [EMAIL PROTECTED] writes:
A configuration wizard would be nice, but it would be a good start to
add a section to the manual on how to do the basic tuning.
+1. If we can't write an explanation of what to do, we certainly aren't
going to be able to implement it in a wizard.
A couple of caveats:
1. ts_headline testing was done with current cvs head where as
headline_with_fragments was done with postgres 8.3.1.
2. For headline_with_fragments, TSVector for the document was obtained
by joining with another table.
Are these differences understandable?
That is
Greg Smith wrote:
Where Josh got hung up, where I got hung up, where Lance Campbell stopped
at with his Dummies tool, and what some unknown number of other people
have been twarted by, is that taking that knowledge and turning it into a
tool useful to users is surprisingly difficult. The
On Wed, 2008-06-04 at 06:35 +0200, Martijn van Oosterhout wrote:
Check the archives for details on how it works precisely, but it's far
nicer than merely adding an typmod, since that would cause you to throw
errors at runtime if there's a problem.
Ok, that makes sense. I agree that any type
Alvaro Herrera wrote:
Greg Smith wrote:
Where Josh got hung up, where I got hung up, where Lance Campbell stopped
at with his Dummies tool, and what some unknown number of other people
have been twarted by, is that taking that knowledge and turning it into a
tool useful to users is
Heikki Linnakangas wrote:
Alvaro Herrera wrote:
What I think this says is that we should be pushing Magnus more to
continue work on the configuration API thing he was designing.
There's some magic in pgAdmin to parse and write the file. You could
take a look a that.
That's what they want
Heikki Linnakangas wrote:
Alvaro Herrera wrote:
Greg Smith wrote:
Where Josh got hung up, where I got hung up, where Lance Campbell
stopped at with his Dummies tool, and what some unknown number of
other people have been twarted by, is that taking that knowledge and
turning it into a tool
On Thu, 5 Jun 2008, Magnus Hagander wrote:
We really need a proper API for it, and the stuff in pgAdmin isn't
even enough to base one on.
I would be curious to hear your opinion on whether the GUC overhaul
discussed in this thread is a useful precursor to building such a proper
API.
--
*
Greg Smith wrote:
On Thu, 5 Jun 2008, Magnus Hagander wrote:
We really need a proper API for it, and the stuff in pgAdmin isn't
even enough to base one on.
I would be curious to hear your opinion on whether the GUC overhaul
discussed in this thread is a useful precursor to building such a
Greg Smith wrote:
On Thu, 5 Jun 2008, Magnus Hagander wrote:
We really need a proper API for it, and the stuff in pgAdmin isn't
even enough to base one on.
I would be curious to hear your opinion on whether the GUC overhaul
discussed in this thread is a useful precursor to building such
Steve Atkins wrote:
I'd be interested in putting together a framework+GUI client to do this
cleanly in a cross-platform (Windows, Linux, Solaris, OS X as a bare
minimum) sort of way, if no-one else already has such a thing.
This is a great idea, and I was thinking along the same line. The
Howdy,
I'm working on a custom data type based on TEXT that does case-
insensitive, locale-aware comparisons, essentially by calling LOWER()
to compare values. I'll have more to ask about this later, when I want
to get feedback on the implementation. But right now I'm just writing
tests
On Thu, Jun 05, 2008 at 11:18:26AM -0700, David E. Wheeler wrote:
I'm working on a custom data type based on TEXT that does case-
insensitive, locale-aware comparisons, essentially by calling LOWER()
to compare values.
What makes this different from the citext project?
However, thanks to
On Jun 5, 2008, at 11:28, Martijn van Oosterhout wrote:
On Thu, Jun 05, 2008 at 11:18:26AM -0700, David E. Wheeler wrote:
I'm working on a custom data type based on TEXT that does case-
insensitive, locale-aware comparisons, essentially by calling LOWER()
to compare values.
What makes this
Tom Lane wrote:
This is even assuming that the tool needs to edit the file itself,
rather than just give advice. The advice is the hard part, folks;
could we stop obsessing about trivia?
+1. IMHO, the tool doesn't need to worry about generating a prettied
version of postgresql.conf. It should
David E. Wheeler [EMAIL PROTECTED] writes:
On Jun 5, 2008, at 11:28, Martijn van Oosterhout wrote:
What would you want postgresql to choose in this case.
I was thinking that the ::text should be cast to ::lctext, as that's
how `'a'::lctext = 'a'` works, but I keep going back and forth in my
On Jun 5, 2008, at 11:51, Tom Lane wrote:
I was thinking that the ::text should be cast to ::lctext, as that's
how `'a'::lctext = 'a'` works, but I keep going back and forth in my
mind. Maybe 'a'::lctext should not equal 'A'::text.
It seems to me that lctext is sort of like a more-constrained
On Thu, 5 Jun 2008, Alvaro Herrera wrote:
I must say that I am confused by this thread. What's the discussed GUC
overhaul?
http://wiki.postgresql.org/wiki/GUCS_Overhaul
I drop that URL in every other message in hopes that people might start
commenting on it directly if they see it enough;
Tom Lane wrote:
If those aren't enough questions, what else must we ask? Or maybe they
aren't the right questions at all --- maybe we should ask is this a
dedicated machine or not and try to extrapolate everything else from
what we (hopefully) can find out about the hardware.
I think
Tom Lane wrote:
How far could we get with the answers to just three questions:
* How many concurrent queries do you expect to have?
* How much RAM space are you willing to let Postgres use?
* How much overhead disk space are you willing to let Postgres use?
+1 to this approach - these are the
Steve Atkins wrote:
... cross-platform (Windows, Linux, Solaris, OS X as a bare
minimum)
I wonder how cross-platform the tuning algorithm itself is.
I could also imagine that decisions like do I let the OS page
cache, or postgres's buffer cache get most of the memory are
extremely OS
On Thu, Jun 05, 2008 at 11:37:28AM -0700, David E. Wheeler wrote:
Whichever way
you want it, make that direction implicit and the other direction
assignment.
I'm sure I'm missing something simple here. How do I make it assignment?
# \h create cast
Command: CREATE CAST
Description:
* Greg Smith [EMAIL PROTECTED] [080605 15:17]:
On Thu, 5 Jun 2008, Alvaro Herrera wrote:
I must say that I am confused by this thread. What's the discussed GUC
overhaul?
http://wiki.postgresql.org/wiki/GUCS_Overhaul
I drop that URL in every other message in hopes that people might
On Thu, 5 Jun 2008, Aidan Van Dyk wrote:
People like me don't want to have postgresql.conf be *only* a
machine-generated file, which I am not allowed to edit anymore because
next DBA doing a SET PERSISTANT type of command is going to cause
postgres to write out something else, over-writing my
Currently, if you do DROP something RESTRICT where there are multiple
levels of dependencies on the something, you get reports that might
look about like this:
NOTICE: x depends on something
NOTICE: y depends on x
NOTICE: z depends on y
that is, you can trace the chain of reasoning for each
Tom Lane wrote:
So what I'd like to do about it is just use the CASCADE style all the
time. Thoughts?
It is loss of functionality, but I very much doubt anyone is depending
on it -- it's way too elaborate. +1 on doing the simpler report if it's
too expensive to build the full report.
BTW,
Tom Lane [EMAIL PROTECTED] writes:
Currently, if you do DROP something RESTRICT where there are multiple
levels of dependencies on the something, you get reports that might
look about like this:
NOTICE: x depends on something
...
So what I'd like to do about it is just use the CASCADE
Gregory Stark [EMAIL PROTECTED] writes:
On the other hand the fact that we don't actually provide an
exhaustive set of data for that purpose and a) nobody's complained and
b) it's for basically the same reason that you're suggesting this
change, ie, that it isn't convenient and isn't important
On Jun 5, 2008, at 14:07, Martijn van Oosterhout wrote:
I'm sure I'm missing something simple here. How do I make it
assignment?
# \h create cast
Command: CREATE CAST
Description: define a new cast
Syntax:
snip
CREATE CAST (sourcetype AS targettype)
WITHOUT FUNCTION
[ AS ASSIGNMENT
On Jun 5, 2008, at 14:47, Greg Smith wrote:
This is why there's the emphasis on preserving comments as they pass
into the GUC structure and back to an output file. This is one of
the implementation details I haven't fully made up my mind on: how
to clearly label user comments in the
David E. Wheeler wrote:
How about a simple rule, such as that machine-generated comments start
with ##, while user comments start with just #? I think that I've
seen such a rule used before. At any rate, I think that, unless you have
some sort of line marker for machine-generated
On Thu, 5 Jun 2008, Alvaro Herrera wrote:
FWIW smb.conf uses ; for one purpose and # for the other.
They're actually combining the way UNIX files use # with how Windows INI
files use ; in a config file context, which I personally find a little
weird.
I was already considering keeping user
On Jun 5, 2008, at 17:53, Greg Smith wrote:
I was already considering keeping user comments as # while making
all system-inserted ones #! ; many people are already used to #!
having a special system-related meaning from its use in UNIX shell
scripting which makes it easier to remember.
Hello
2008/6/5 Mayuresh Nirhali [EMAIL PROTECTED]:
Hello hackers,
During the Oracle migration tutorial by peter at PGCon, I took an action
item for myself to try orafce on Solaris/OpenSolaris.
As pg binaries are bundled with Solaris now (using Sun Studio compiler), I
decided to try out
54 matches
Mail list logo
