() be a constant-time operation seem like a win to me.
Anyway, we should build the code that way and then do profiling with and
without support for constant-cost length().
regards, tom lane
---(end of broadcast)---
TIP 7: don't forget
, and the changes are only needed at 8.1 and up.
I'm guessing, though, so I'll go dust off a copy of Tcl 8.0.x and try it.
Please. I'm willing to apply the patch, but this close to release
there's no room for error. Double-checking is good.
regards, tom lane
shared buffers --- I made that
change myself.
I had some concern about whether Andrew's rewrite had tracked all the
recent changes to the initdb shell-script sources. Are you both
confident that it is up to date?
regards, tom lane
---(end
that initdb itself hasn't
got.
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
the
more recent versions had at least rudimentary permissions.
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
why contort initdb's behavior for a very
transient implementation savings?
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
seems like a secondary consideration.)
regards, tom lane
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
it.
regards, tom lane
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
reaction was the same as Peter's, but after seeing the small
size of the patch I reconsidered. It seems to make sense that BEGIN
should be an exact synonym for START TRANSACTION.
regards, tom lane
---(end of broadcast)---
TIP 4
* lines of documentation to explain that the two
statements aren't alike than it would take lines of code to make them
work alike.
regards, tom lane
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send
Bruce Momjian [EMAIL PROTECTED] writes:
Is this to be applied to CVS HEAD?
It sounded like large portions were still at the request-for-comment
stage...
regards, tom lane
---(end of broadcast)---
TIP 8: explain analyze
.
regards, tom lane
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
is yes.
Any other opinions?
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Neil Conway [EMAIL PROTECTED] writes:
This patch makes some minor improvements to a few release note
entries.
Applied.
regards, tom lane
---(end of broadcast)---
TIP 7: don't forget to increase your free space map
swap space to cover your memory needs. If this is intended to
communicate anything meaningful, can someone rephrase it, please?
Seemed pretty content-free to me too.
regards, tom lane
---(end of broadcast)---
TIP 8: explain
is
that it eliminates the need for anything as messy as that.
regards, tom lane
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
One reason I like the idea of adopting a sync-when-you-write policy is
that it eliminates the need for anything as messy as that.
Yes, but can we do it without causing a performance degredation, and I
would hate to change something
Bruce Momjian [EMAIL PROTECTED] writes:
Is running the rest of the
application with SIGPIPE = SIG_IGN a problem?
That is NOT an acceptable thing for a library to do.
regards, tom lane
---(end of broadcast)---
TIP 1
settings that govern this instead of
1.
Okay, I revised that section yet again based on this info:
http://candle.pha.pa.us/main/writings/pgsql/sgml/kernel-resources.html#AEN17043
Thanks for the update.
regards, tom lane
---(end of broadcast
that are not currently needed where they are,
and would only be needed under their new names at some future time.
If the rename gets lost shortly after it's done, it can be redone.
regards, tom lane
---(end of broadcast)---
TIP 1
that though.
regards, tom lane
---(end of broadcast)---
TIP 8: explain analyze is your friend
. There could and should be a
lower-level notion of open relation that bgwriter and checkpoint
could use. See recent discussion with Neil, for example. Vadim had
always wanted to do that, IIRC.
regards, tom lane
---(end of broadcast
, which is what we can
assume is true on every platform...
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
that
planstate-ps_ResultTupleSlot = ExecInitExtraTupleSlot(estate);
is better than
planstate-ps_ResultTupleSlot = ExecAllocTableSlot(estate-es_tupleTable);
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our
recall if anyone had good ideas about how to describe the
expected output. If you search the archives you can probably find
the previous discussions --- it was a couple years ago.
regards, tom lane
---(end of broadcast)---
TIP
completely (perhaps CopyTupleDesc() ?) as a means of catching places
that aren't correctly updated. (I worry about add-on modules that might
not get recompiled between versions; they'd still link, but then crash,
if the routine name is the same.)
regards, tom lane
of call sites seems small enough that altering the API isn't
out of the question either, if you like that better.
regards, tom lane
---(end of broadcast)---
TIP 8: explain analyze is your friend
to clean up the current weird-hack implementation of SELECT INTO
until we can freeze the syntax somehow. The above looks at least as
reasonable as what we're currently recommending ...
regards, tom lane
---(end of broadcast
behavior of being able to set
PGHOST/PGPORT in the environment to control which postmaster make
installcheck will speak to. So, yeah, I think it's a bad idea.
regards, tom lane
---(end of broadcast)---
TIP 7: don't forget
Joe Conway [EMAIL PROTECTED] writes:
Tom Lane wrote:
(More generally, I wonder if AtEOXact_SPI oughtn't be fixed to emit
a WARNING if the SPI stack isn't empty, except in the error case.
Neglecting SPI_finish is analogous to a resource leak, and we have
code in place to warn about other sorts
),
since I'm about to get started on some related hash index work, for
which I'll submit a mega-patch containing everything.
regards, tom lane
---(end of broadcast)---
TIP 7: don't forget to increase your free space map
Bruce Momjian [EMAIL PROTECTED] writes:
I will try to apply it within the next 48 hours.
This one's applied already, no?
regards, tom lane
---(end of broadcast)---
TIP 8: explain analyze is your friend
to
it.
regards, tom lane
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
...
regards, tom lane
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
for
statement_timestamp, but a cleaner replacement for timeofday()
would be nice to have.
regards, tom lane
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
This is a nonstarter,
Oh, I forgot about that. Peter seems only to want statement_timestamp
and transaction_timestamp. Aren't those both stable if
statement_timestamp is set from exec_simple_query?
Hm. If you restricted the option
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
This is a nonstarter, as is the previous proposal to have a single
function with an explicit parameter that selects the behavior. The
reason is that any such function would have to be treated as completely
non-optimizable.
Why
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
There was just a discussion a few days ago about the page size for large
objects, for which the correct answer was BLCKSZ/4 IIRC. Whether
people actually *should* care about the page size of large objects I
dunno, but the fact
still have worked, because we'd never
have selected a key value wider than 32 bits anyway. What *exact*
misbehavior were you seeing?
regards, tom lane
---(end of broadcast)---
TIP 9: the planner will ignore your desire
Kurt Roeckx [EMAIL PROTECTED] writes:
On Mon, Dec 01, 2003 at 05:19:17PM -0500, Tom Lane wrote:
After reviewing the proposed patch, I find it hard to believe that the
patch would have fixed any such problem ---
It's not the key (key_t) that is the problem, but the size, which
used to be int
it.
regards, tom lane
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list
level
implementation dependency?
Because it sorts on tuple position, which is certainly about as low
level as you can get. More to the point, though, no evidence has been
provided that this is a good idea.
regards, tom lane
---(end of broadcast
Bruce Momjian [EMAIL PROTECTED] writes:
Also, I think we have to have a SET before every CREATE TABLE.
No, only when the value changes from last time. This is not rocket
science, it's the way pg_dump handles SETs already.
regards, tom lane
already running a postmaster that was eating all the available
semaphores. When it worked, it was because you'd stopped the other
postmaster, and not because of any code changes.
regards, tom lane
---(end of broadcast)---
TIP 1
a variable.
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
+ xref linkend=runtime-config-resource for information.
I think you could drop the middle four sentences (Each ... formatted page)
without losing much.
Otherwise it looks fine ...
regards, tom lane
---(end of broadcast
...
regards, tom lane
---(end of broadcast)---
TIP 8: explain analyze is your friend
Matthew T. O'Connor [EMAIL PROTECTED] writes:
Ok, one more pg_autovacuum patch (Thanks to Tom for fixing the long long
overflow problem).
Applied.
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all
Neil Conway [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
The others are already #ifdef'd out by default, which is more or
less what I was suggesting you do with the wal_debug code.
(FWIW, trace_notify is not #ifdef'd out.)
My mistake --- if you feel like making it so, go
about it and I think other people did too. It's a messy, ugly approach;
moreover we have no field experience that says it's reliable.
It may be the least messy, ugly approach available, but I concur with
Neil's wish to at least look for other answers.
regards, tom lane
Alvaro Herrera [EMAIL PROTECTED] writes:
On Sun, Dec 14, 2003 at 06:53:22PM -0500, Tom Lane wrote:
You can hardly claim that no one had issues with that.
Don't the FSM and the system catalog cache use a similar mechanism?
FSM uses a backing file to hold information over a database shutdown
files may actually be a cleaner solution than writing
shared memory, once we take these considerations into account. My gripe
about race conditions was I want to see how you solve this, and wasn't
intended to mean I don't think that is soluble.
regards, tom lane
Claudio do it this way ...
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
cases.
The pg_dump change looks okay for the 7.4 branch. It will not apply to
HEAD but I think you can just add
if (plang-lanpltrusted)
before the dumpACL call in that case.
regards, tom lane
---(end of broadcast
schemas from
the \dn display. That isn't what this patch does, however.
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister
if we ever add schemas that might
conflict.
Looking at the present output of \dn, I wonder whether we should not
suppress the pg_toast schema as well. That could be done (at the
moment) by bouncing all schemas 'pg_t*' ...
regards, tom lane
---(end
everything not in your search path ...
regards, tom lane
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
be simple.
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Why are you doing any of this? We had agreed to suppress all temp
schemas, period. The query should be simple.
I know some feel that showing any temporary schemas is wrong, but it
seems that the local temp schema has valuable
not like 'pg\\_temp%'
OR nspname = (current_schemas(true))[1]) ...
would probably work well enough.
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
David Fetter [EMAIL PROTECTED] writes:
On Mon, Dec 22, 2003 at 05:50:12PM -0500, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
+ Note that it is not possible to assign function arguments during
+ a literalDECLARE/ block.
Seems to me this is a bug that should be fixed
to test.
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
example, we have *no* evidence to suggest that that NOFIXADE stuff in
main.c is needed on platforms that don't define __alpha. I would tend
to take an if it ain't broke don't fix it approach, especially on
platforms we don't have handy
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
It seems risky to me to define macros that are in the
reserved-for-system-use namespace. Who knows what might break in the
system headers if we did that?
I see we already do this in solaris.h:
Mph. Well, at least that's restricted
that the precedence will work correctly if
processNamePattern plasters an AND phrase after this.
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister
Bruce Momjian [EMAIL PROTECTED] writes:
!n.nspname = (current_schemas(true))[1]\n, /*
temp schema is first */
One more thing: that needs to be pg_catalog.current_schemas to
be search-path-proof.
regards, tom lane
more-easily-accessible library.
regards, tom lane
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
in messages. I think it's actively
misleading.
A simpler but uglier solution would be to quote the schema and table
names separately:
Table public.foo
regards, tom lane
---(end of broadcast)---
TIP 6: Have you searched
can't, then the gcc IA64 code is wrong,
because it uses the default version of S_UNLOCK.)
+#define S_LOCK_FREE(lock) ( *(volatile slock_t*)(lock))
This is wrong too, unless you're not using the convention that zero
indicates a free lock.
regards, tom lane
Jan Wieck [EMAIL PROTECTED] writes:
Tom Lane wrote:
Not that hard ... just requires replacing some special-purpose code with
general-purpose code ...
Does that code cause the variables value to change from function call to
function call (what most users would expect if they give
from previous postgres will not give their old superusers
back their catalog privilege, unless they dump with 7.5's pg_dump.
Only if you make it default to NOCATALOG, which is highly debatable in
my mind, since it is non-backwards-compatible.
regards, tom lane
on an #ifdef.
If you want to change them both, let's first see the reason why it's
necessary.
regards, tom lane
---(end of broadcast)---
TIP 8: explain analyze is your friend
above and below depending
on #ifdefs.
regards, tom lane
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
is the place to be adding anything anyway.
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Manfred Spraul [EMAIL PROTECTED] writes:
Tom Lane wrote:
Don't you have to put it in a specific place in the loop to make that
work? If not, why not?
Rep;nop is just a short delay - that's all.
That view seems to me to be directly contradicted by this statement:
The PAUSE instruction
to PostgresMain didn't change.
I do not want to alter either of those decisions, however. What we need
is to provide an alternative exec-able interface that encapsulates the
processing that now occurs between these steps.
regards, tom lane
---(end of broadcast
that don't customarily use ... as
quotation marks.
regards, tom lane
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
, but by and large, yes: I want to run BackendFork
pretty much as-is. I see no strong reason to do differently, and I am
convinced that we will spend the next six months ferreting out startup
bugs if we make wholesale revisions in the order in which things are
done.
regards, tom
.
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
with the data payload string once we implement that.
I also fixed the underlying infinite-loop problem.
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs
why we'd abandon that technique in favor of using cpp again.
So I propose that we remove the cpp invocation and associated
infrastructure from genbki.sh. Any objections?
regards, tom lane
---(end of broadcast)---
TIP 6: Have
the present definition is badly designed and needs to be
replaced with a different API.
regards, tom lane
---(end of broadcast)---
TIP 8: explain analyze is your friend
(char). See the archives; we've had at least one bug of this ilk.
regards, tom lane
---(end of broadcast)---
TIP 8: explain analyze is your friend
to bother with FastList, so
if we don't get the List rewrite done, I'm gonna have to revisit some
things ...
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http
to pgsql-committers. But
for your situation I don't see the value in the extra message.
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs
is applied.) The references to default_with_oids have to be
postponed to analyze.c's processing. Compare the way that inhOpt has
an INH_DEFAULT setting --- you probably need the same kind of solution
for the WITH OIDS options.
regards, tom lane
---(end
about what's
involved?
regards, tom lane
---(end of broadcast)---
TIP 8: explain analyze is your friend
Korea PostgreSQL Users' Group [EMAIL PROTECTED] writes:
In 7.4.1, intarray module have a problme about equal operator (=).
select * from table where intarray_column = '{}';
above query make error.
Good catch. Patch applied --- thanks!
regards, tom lane
)));
proc_exit(status);
}
is responsible. May we have an explanation of the thought process,
if any?
regards, tom lane
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
IsUnderPostmaster true --- elog pays attention to the
value of that flag, and will do the wrong thing if called in a child
process that doesn't yet have it set.
regards, tom lane
---(end of broadcast)---
TIP 7: don't forget to increase your
to know the cancel key --- he can just
issue a SIGINT (or worse) directly to the target backend.
regards, tom lane
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining
up the postmaster, etc. But if it's a separate array then we
can just have the rule that no one but the postmaster gets to write in it.
I still think it's unnecessary to make a separate shmem segment for it,
though.
regards, tom lane
---(end
-postmasters would need to read the array, either to check an
incoming cancel request or to get the current-session key value to pass
back to the client. I don't think that PostgresMain or any subsidiary
routine would ever need to touch it.
regards, tom lane
, tom lane
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Claudio Natoli [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think the simplest way to make this work is to use an array that's
2*MaxBackend items long (corresponding to the max number of children the
postmaster will fork).
Actually, now that I think about it, is even that big enough
, it is unused
(see win/tclWinFile.c - TclpFindExecutable()). Just a
value != NULL is OK, so I used an empty string.
AFAICS this patch breaks all non-Windows platforms. Sorry, that
won't do ...
regards, tom lane
---(end of broadcast
.
regards, tom lane
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Neil Conway [EMAIL PROTECTED] writes:
Yeah, I had considered that, but hesitated for the same reason you
cite. Is it worth creating a parse_util.c, perhaps?
Okay with me, if you feel like taking the trouble.
regards, tom lane
---(end
numbers. People
who just want a list of the live columns can get it from the OLD or NEW
arrays.
regards, tom lane
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail
.
Hm. Perhaps we should tighten the test to reject only .tupno, rather
than any name starting with dot?
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
101 - 200 of 3477 matches
Mail list logo
