Otherwise we'd never consider
making it a userset config setting.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Gregory Stark <[EMAIL PROTECTED]> writes:
>>> Can we just disable const checking for MSVCC in general without using the
>>> #pragmas? It clearly doesn't understand how const works making
complain to ActiveState
so maybe they'll fix it sometime.
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
from other compilers.
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Magnus Hagander <[EMAIL PROTECTED]> writes:
> On Tue, Jul 24, 2007 at 09:55:57AM -0400, Tom Lane wrote:
>> If you insist you can apply that in some way that makes it Windows-only.
> Uh, it's already inside a win32-only block. So it'll only affect mingw.
Doh ... not e
s, but that
doesn't make the palloc'd area itself const. You're making the same
mistake msvc does.
I agree though that the #pragma solution is awfully ugly. What I'd
be inclined to do is
/* cast away indirect const to avoid warnings from broken compilers */
free
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Sure: the advantage is that the backends (ie, user query processing)
>> don't get blocked on fsync's. This is not really different from the
>> rationale for
rs every few pages worth of WAL output.
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
n some way that makes it Windows-only.
I object strongly to the patch in this form, because it will mask our
own mistakes as well as one particular Perl build's mistakes.
regards, tom lane
---(end of broadcast)---
T
eally doing the
majority of the wal-flushing work.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
current thinking BTW is that trying to make XLogBackgroundFlush serve
two purposes is counterproductive. It should be dedicated to use by the
walwriter only, and the checkpoint case should simply read the async
commit pointer and call regular XLogFlush with it.
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Mon, 2007-07-23 at 18:59 -0400, Tom Lane wrote:
>> The shutdown logic in particular seems all wrong; you can't have
>> a process connected to shared memory that is going to outlive the
>> postmaster.
&g
eems all wrong; you can't have
a process connected to shared memory that is going to outlive the
postmaster.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
text to work in. (We could
increase that figure if need be, but we need to know by how much.)
As a general style note, the patch seems to add and remove blank
lines in a most arbitrary and inconsistent way. Please try to
clean that up. pgindent would fix some of that, but it's not very
go
want to engage in purely cosmetic changes.
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
ending on your
platform, linking in thread support might incur some generalized
overhead costs even when it's not being used; for instance the malloc
functions might start using mutexes.
regards, tom lane
---(end of broadcast)---
lt name for the different auth
method. I think a platform-dependent default would seriously suck,
and changing the default behavior for existing configurations would
break things. So Stephen's suggestion seemed plausible to me.
regards, tom lane
--
been resolved by kicking the subprojects out again,
and so I don't really see that automake has much to offer us.
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It's too bad that gcc doesn't have a
>> -Wno-snarkiness-about-system-headers-thank-you switch.
> It does have a switch to *add* snarkiness about system headers, but does
> not do it by default
behavior than the previous one. The code is comparing
against
anltuples = tabentry->n_live_tuples + tabentry->n_dead_tuples -
tabentry->last_anl_tuples;
and deletions surely increase n_dead_tuples.
regards, tom lane
-
ven with the 64-bit explaination.
There are lots of platforms where the include files and the compiler are
not all that compatible, gcc + vendor include files being the prototype
case. It's too bad that gcc doesn't have a
-Wno-snarkiness-about-system-headers-thank-you switch.
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Well, this doesn't take a lot of numerical methods background: the
>> fundamental problem is that the existing code generates an *approximate*
>> answer, whereas pe
"Affan Salman" <[EMAIL PROTECTED]> writes:
> Thanks, Tom. We're also back-patching this, right?
Yeah, working on that now.
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Yeah. I was basically waiting to see if anyone could come up with a
>> faster solution. Since no one seems to have an idea how to do it
>> better, I'm inclined to
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Sun, 15 Jul 2007, Tom Lane wrote:
>> I don't think this is right. If the original tuple was inserted by a
>> subtransaction of our transaction, it will have been checked at
>> subtransaction subcommit, no?
&g
anyone else.
Yeah. I was basically waiting to see if anyone could come up with a
faster solution. Since no one seems to have an idea how to do it
better, I'm inclined to apply the patch for 8.3.
regards, tom lane
---(end of broadcast)-
and those are not the
semantics of TransactionIdIsCurrentTransactionId, unfortunately.
Stephan, have you looked at this bug report? What do you think?
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>>> A much simpler approach would be to try to acquire the vacuum lock, and
>>> compact the page the usual way, and fall back to a co
g for ways to make the patch simpler and less invasive.
+1 on that, for sure.
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> I'm worried that we leave garbage entries in the stats. As you suggested,
> don't we need to remove unreferenced entries from stats periodically?
VACUUM does that already.
regards, tom lane
Greg Smith <[EMAIL PROTECTED]> writes:
> On Mon, 9 Jul 2007, Tom Lane wrote:
>> The hardware is just a Dell x86_64 workstation with crappy IDE disk, so
>> maybe things would look better elsewhere, but it's all I have to work
>> with.
> Do you have write
Gregory Stark <[EMAIL PROTECTED]> writes:
> It's pretty serious what you're suggesting since it means that we'll
> basically never have a real cluster feature.
It seems entirely likely that this is not the way to go about "real
clustering".
modularity and
layering standpoint, I'm now inclined to reject it. AFAICT this test
case is showing the patch at its best possible advantage; under
real-world conditions the benefit would be less. It doesn't look to me
like the gain is worth the loss of system understandability a
acket contents.
To me this scenario is too far-fetched to justify sacrificing
convenience and backwards compatibility. It should be sufficient to add
some paragraphs about security considerations to the dblink docs.
regards, tom lane
-
aking it unusable is an overreaction.
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
ly best not to take the risk of dropping useful stats.
Call removed from 8.1.x and up.
regards, tom lane
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomai
ould be full
sentences (with initial cap and trailing period). Also possibly
"Target server's auth..." would read better. Also, I'd personally not
leave the "is" out of the errmsg, though that part is surely a judgment
call. Or maybe it should be just errmsg("
27;t seem to be anyone but you who feels any attraction to that
concept. These utilities have a wide enough difference in behavior and
intended usage that ISTM force-fitting them into a single binary would
just increase confusion and difficulty of use.
regar
lete hack anyway, and the reason
no one has bothered to improve it is that there is next to no use
for it anymore.
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
CTION dblink_connect_u (text) FROM public;
> REVOKE execute ON FUNCTION dblink_connect_u (text, text) FROM public;
I'd write that as REVOKE ALL just to be future-proof.
regards, tom lane
---(end of broadcast)---
TIP 4:
be superuser" and
keep it simple.
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
coverage of different sets of compile options (see notes at the bottom
of src/tools/pginclude/README).
Anybody feel like working on that?
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our exten
signatures of all the pg_stat_get_foo()
functions, which would break people's custom stats views.
What I'm inclined to propose is that we just remove the
pgstat_drop_relation() call from smgr_internal_unlink, and rely entirely
on VACUUM to clean out dead entries in the pgstats data.
makes sense for libpq to be able to execute within a C++ application.
As was already debated, it's not nearly as clear that it makes sense to
try to use C++ for backend modules.
In any case, you are not helping here. I asked for a technical solution
to a specific problem, and you are giving me poli
t convinced this is safe; in particular, ISTM that a PITR slave
following the WAL log is likely to be at risk if it tries to restart
from the checkpoint you've omitted some full-page-images after. There's
no guarantee it will have flushed pages at the same spots the master did.
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> Neil Conway wrote:
>> On Mon, 2007-02-07 at 23:13 -0400, Tom Lane wrote:
>>> Er, was this on the agenda for 8.3?
>>
>> Well, it seemed fairly harmless to me (no behavioral changes and very
>> little
eme. Carrying over info from the previous cycle
doesn't seem like it would help much; rather, the point is exactly
that we *don't* want a constant write speed during the checkpoint.
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
gt; Applied with some fixes. Thanks for the patch. ALTER VIEW ... SET SCHEMA
> might be another worthwhile thing to add, for consistency.
Er, was this on the agenda for 8.3?
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
"Jacob Rief" <[EMAIL PROTECTED]> writes:
>> Tom Lane writes:
>> Anyway, at this point my concern is not so much whether we could fix
>> it as what is the plan for keeping it fixed.
> A best practice statement, telling developers not use C++-keywords as
>
unction names. Those are not C++ keywords
to my knowledge; anyone have a theory?
Anyway, at this point my concern is not so much whether we could fix
it as what is the plan for keeping it fixed.
regards, tom lane
---(end of broadcast)-
either grant execute
access to appropriate people in the original suggestion, or wrap
dblink_connect in a SECURITY DEFINER function in my new suggestion.
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Robert Treat <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I like this approach better than removing public execute privileges
>> on the functions, for two reasons:
> I think this will break backwards compatability though.
Well, revoking public execute will break bac
ake the check before allowing any use of
the new PGconn object.
regards, tom lane
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> bool PQconnectionUsedPassword(const PGconn *conn);
> Maybe PQconnectionUsedAuthToken() to mean "data supplied by the client",
> including other potential future mechanisms?
Well, that'd not solve the
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Would it be sensible to change dblink so that unless invoked by a
>> superuser, it fails any connection attempt in which no password is
>> demanded? I am not sure that this is possible without change
ble without changes to libpq;
but ignoring implementation difficulties, is this a sane idea from
the standpoint of security and usability?
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
ething to back-patch, though, since
a back-patch will accomplish zero for existing installations.
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
se Alvaro is
about to commit something in postmaster.c (I suspect the double-shutdown
business is a bug in there). Don't want to cause merge problems for him
just for cosmetic message cleanup.
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Here's a reworked version Greg Smith's patch for logging checkpoints.
Applied with minor editorialization.
regards, tom lane
---(end of broadcast)---
TIP 4
adding a word to the message for each flag bit. No
more lines than you have.
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
t every other backend header? Once we buy into the
principle, you can bet that we'll get requests to sanitize every header
that's of any interest. So I'd want to see some estimate of how many
changes that entails, not just fixing the set of things that spi.h
depends on.
Patrick Welche <[EMAIL PROTECTED]> writes:
> On Thu, Jun 28, 2007 at 04:16:37PM -0400, Tom Lane wrote:
>> What exactly does xml2-config --libs produce on your machine?
> -Wl,-R/usr/local/lib -L/usr/local/lib -lxml2 -lz -lpthread -lm
> but because I added the -R - it
a second bug in the same
area: autoconf was stripping the []'s out of the sed regexp, causing
it to fail to do anything. Apparently passing a string like "3devel"
to awk's "%d" format gets you just "3", but I wonder how portable th
rom CFLAGS, and LDFLAGS from LIBS), then we could just use them as-is.
They don't, so we have to do some picking-apart.
What exactly does xml2-config --libs produce on your machine?
regards, tom lane
---(end of broadcast)-
ference, but we do. Likewise, I would not
expect that all of --libs output is really a good idea to put into
LDFLAGS.
Exactly what items are you hoping to transfer that aren't transferred
by the existing coding?
regards, tom lane
---
start_backup?
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
do more work as that it needs to be called
more often. Right now we only do it once per checkpoint.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Neil Conway <[EMAIL PROTECTED]> writes:
> On Thu, 2007-28-06 at 01:15 -0400, Tom Lane wrote:
>> The patch as given merely renames some random identifiers that happen to
>> be keywords in some non-C language ...
> The fact is, any user-written extensions that de
ased executable either.
I might be willing to accept this patch if I thought it were the end of
the story, but I know that it is only the camel's nose poking under the
tent.
regards, tom lane
---(end of broadcast)---
er does the work instead of a
foreground process. I'm hesitant to go much further than that, because
I don't want to bloat the minimum disk footprint for low-volume
installations, but the minimum footprint is really 2 xlog files anyway...
regards, tom lane
t any documentation changes to make?
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
handled by allowing
a bit more slop in the number of recycled-into-the-future xlog segments.
Come to think of it, shouldn't we be allowing some extra slop in the
number of future segments to account for xlog archiving delays, when
that's enabled?
regards, tom
see what happens, but I doubt that will
> change my mind on the above decisions.
When do you expect to have those results?
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
es, so it's not free to keep it.
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Who's "we"? AFAICS, CVS HEAD will treat a large copy the same as any
>> other large heapscan.
> Umm, I'm talking about populating a table with COPY *FROM*. That's not a
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> (Note that COPY per se will not trigger this behavior anyway, since it
>> will act in a limited number of buffers because of the recent buffer
>> access strategy patch.)
> Actually we dropped it fro
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> This argument supposes that the bgwriter will do nothing while the COPY
>> is proceeding.
> It will clean buffers ahead of the COPY, but it won't write the buffers
> COPY leaves behind since the
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> ... that's what the LRU scan is for.
> Yeah, except the LRU scan is not doing a very good job at that. It will
> ignore buffers with usage_count > 0, and it only scans
> bgwriter_lru_percent
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Hmm. But if we're going to do that, we might as well have a checkpoint
>> for our troubles, no? The reason for the current design is the
>> assumption that a bgwriter_all scan is less burdensome t
t; this may not be a problem at all.
> FWIW, we remove the second argument in textToQualifiedNameList() two
> years ago so i think this is just finishing what we already started,
True, we whack around APIs like this one in every release anyway ...
I don't have an objection to changi
[ back to this thread... ]
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The other question is why is execMain involved in this? That makes the
>> design nonfunctional for tuples inserted in any other way than through
>> the main executor --- C
hat sit idle a long time
and suddenly go nuts, but it seems to me that smoothing the write rate
across more than one checkpoint could help if the fluctuations occur
over a timescale of a few checkpoints.
regards, tom lane
---(end of broadcast)-
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>>> If you have a system with a very bursty transaction rate, it's possible
>>> that when it's time for a checkpoint, there ha
ility between sinval.c and
sinvaladt.c has never been real clean AFAICS ... so I think if you want
to touch this you should try to make that division better-specified.)
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
But that was for 7.4 which was awhile
ago. There's probably not a strong argument to keep it, but on the
other hand is there a strong argument to remove it?
regards, tom lane
---(end of broadcast)---
TIP 5: don't f
, you have to flush those dirty pages at that point. It
> would be better to trickle flush those dirty pages during the idle period.
But wouldn't the LRU-based scan accomplish that?
regards, tom lane
---(end of broadcast)--
tached.
We do not "patch" those files; the update technique is "download, untar,
commit", and there's really no point in doing it except when a release
is imminent. See src/timezone/README and src/tools/RELEASE_CHANGES.
regards, tom lane
-
very well. And if you
think that the current code had enormous amounts of testing before it
went in, I've got to disillusion you :-(
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner wil
a new xlog segment is created,
> the write to clear it out doesn't happen via direct I/O like the rest
> of the xlog writes do?
It's not supposed to matter, because that path isn't supposed to be
taken often.
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
we might as well expose the fraction instead. (Still don't
like the name "smoothing" though.) I agree with removing the non-LRU
part of the bgwriter's write logic though; that should simplify matters
a bit and cut down the overall I/O volume.
regards, tom
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Thu, 2007-06-21 at 16:05 -0400, Tom Lane wrote:
>> Can we fix it to be a read test instead of a write test, that is, if
>> we know WAL has been flushed through the target LSN, it's safe to set
>> the hint bi
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I still think you've not demonstrated a need to expose this parameter.
> Greg Smith wanted to explicitly control the I/O rate, and let the
> checkpoint duration vary. I personally think that fixing the
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> (BTW, the patch seems
>> a bit schizoid about whether checkpoint_rate is int or float.)
> Yeah, I've gone back and forth on the data type. I wanted it to be a
> float, but guc code doesn'
reasonable to back-patch into 8.2 too...
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> So the question is, why in the heck would anyone want the behavior that
>> "checkpoints take exactly X time"??
> Because it's easier to tune. You don't need to know how much checkpoint
bloats the patch
noticeably, and I don't entirely see the value of it.
There's some padding junk inserted in XLogCtlData, which as far as I
recall was never discussed, and is certainly not an integral part of the
delayed-commit feature. If you want that you sho
s hard. It looks to me like the
components of the decision are the same numbers in any case: you have to
estimate your progress towards checkpoint completion, your available
time till next checkpoint, and your write rate. Then you either delay
or not.
regard
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I tend to agree with whoever said upthread that the combination of GUC
>> variables proposed here is confusing and ugly. It'd make more sense to
>> have min and max checkpoint rates in KB/s, with
We might have
to resign ourselves to this much messiness, but I'd rather not...
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> I don't see how you arrive at that conclusion. The message is printed
>> by the backend that is waiting for (or just obtained) a lock, dependent
>> on its own lo
801 - 900 of 4175 matches
Mail list logo
