?
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
the allowed ranges of the settings should
be. The method of using a shell case to verify the setting validity
is kinda klugy, but I couldn't offhand think of a direct test for
is this a power of 2 at the shell level, so it seems we need to be
restrictive.
regards, tom lane
Hell, Robert [EMAIL PROTECTED] writes:
You're right - that's just a typo in the subject of the post.
It's called cursor_tuple_fraction in the submitted patch.
Ah, I hadn't actually read the patch yet ;-). As penance for the noise,
I will do so now.
regards, tom lane
point? I had it like this in configure.in:
RELSEG_SIZE=`expr '(' 1024 '*' ${segsize} / ${blocksize} ')' '*' 1024`
Also it looks like you missed adding segsize to the config.pl comments.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches
code works?
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
This doesn't look quite right; unless the arithmetic is being done in
floating point? I had it like this in configure.in:
RELSEG_SIZE=`expr '(' 1024 '*' ${segsize} / ${blocksize} ')' '*' 1024`
blocksize is one of (1,2,4,8,16,32) so
Pavel Stehule [EMAIL PROTECTED] writes:
This patch allows dynamic queries in RETURN QUERY statement.
http://archives.postgresql.org/pgsql-hackers/2008-02/msg01180.php
Applied, thanks.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches
that is correct for its own PG version, not that of the
server it's dumping from.
The tradeoffs are probably different for pgAdmin, but it is important to
realize that either way might be the best thing for a particular case.
regards, tom lane
--
Sent via pgsql-patches mailing list
...
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
an integer.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
none at all for
varying XLOG_BLCKSZ. Why do we need to make it easier than edit
pg_config_manual.h?
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
.
They're logically different things, and after I get done putting a parse
location field into A_Const, they'll still be physically different too.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane escribió:
They're logically different things, and after I get done putting a parse
location field into A_Const, they'll still be physically different too.
Aha. Are you working from Brendan's patch? I was going to commit it.
Sure, go ahead
that there would never again be more than one
field.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
helpful unless you still have the original query string laying about.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Albe Laurenz [EMAIL PROTECTED] writes:
Tom Lane wrote:
If you actually want the behavior you propose, then the only correct way
to implement it is to embed it into the state machine logic, ie, do the
CancelBackup inside PostmasterStateMachine in some state transition
taken after the last
Albe Laurenz [EMAIL PROTECTED] writes:
That should work, but isn't it better if backup_label is removed
only if we know we're going to shutdown cleanly?
Why? That seems like an entirely arbitrary specification.
regards, tom lane
--
Sent via pgsql-patches mailing list
any visible database access. As of 8.3 that won't
cause consumption of CIDs, but before it did. I suspect that in a
lot of real-world scenarios, CID consumption from triggers will be
down by an order of magnitude.
regards, tom lane
--
Sent via pgsql-patches mailing list
Albe Laurenz [EMAIL PROTECTED] writes:
Tom Lane wrote:
Lastly, the changes to pmdie's SIGINT handling seem quite bogus.
Don't you need to transition into WAIT_BACKUP rather than WAIT_BACKENDS
state in that case too? Shouldn't you do CancelBackup *before*
PostmasterStateMachine? The thing
holds?
Oh, yes, could not is better. My mistake.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Albe Laurenz [EMAIL PROTECTED] writes:
Tom Lane wrote:
Why not? It'll fall out of the state again immediately in
PostmasterStateMachine, no, if we do a CancelBackup here?
We cannot call CancelBackup there because that's exactly the state
in which a smart shutdown waits for a superuser
, at least till such
time as we see whether there are still any real field complaints about
this with 8.3.
In any case the patch is broken by --enable-float8-byval, and would
need some adjustments to play nice with that.
regards, tom lane
--
Sent via pgsql-patches mailing list
, and
shouldn't be back-patched (particularly in view of the fact that we
haven't tested the change all that much --- there might be other
places depending on the old behavior).
Will take care of this.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches
/NOT NULL in 8.0.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Bruce Momjian [EMAIL PROTECTED] writes:
So, is this a feature we want?
I have no objection to being able to use Sun Studio, but the submitted
patch seemed to need a lot of work yet ...
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches
of race conditions.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
not FLOAT8PASSBYVAL. Not clear how
useful that really is though.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
configurable. Included
in committed patch.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Guillaume Smet [EMAIL PROTECTED] writes:
On Mon, Apr 21, 2008 at 2:28 AM, Tom Lane [EMAIL PROTECTED] wrote:
Applied with revisions --- mostly, supporting configure-time control
over whether pass-by-value is used.
Do we need buildfarm coverage of these options?
Wouldn't hurt, I guess, though
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
Both --enable and --disable-float4-byval produced only this regression,
but it seems to be a tuple order difference.
That looks suspiciously locale-ish; what locale are you running PG in?
regards, tom lane
--
Sent via pgsql
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane wrote:
Specifically, I think what you missed is that on some platforms C
functions pass or return float values differently from similar-sized
integer or pointer values (typically, the float values get passed in
floating-point registers
consider applying the other part of the
patch.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
a variant expected file
with the hu_HU sort ordering. I'd be happy to do that if it were
affecting the main regression tests, but not sure it's worth it for
contrib/tsearch2 ... thoughts?
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org
Tom Lane [EMAIL PROTECTED] writes:
BTW, I trolled the contrib files for other v0 functions taking or
returning float4 or float8. I found seg_size (fixed it) and a whole
bunch of functions in earthdistance.
Hmm, actually most of the bunch are SQL functions, there's only one
that needs fixing
, where's the randomness coming from?
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
a compile-time choice of whether things could
remain pass-by-ref? I rather imagine that some people out there will
prefer to stay that way instead of fix their old v0 code.
In the meantime, converting contrib/seg to v1 might be the best
solution.
regards, tom lane
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Since they're v0, they'd have to explicitly know about the pass-by-ref
status of float4.
Well, the previous code was doing some pallocs, and the new code is not:
http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/contrib/seg/seg.c.diff?r1
Tom Lane [EMAIL PROTECTED] writes:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Since they're v0, they'd have to explicitly know about the pass-by-ref
status of float4.
Well, the previous code was doing some pallocs, and the new code is not:
http://anoncvs.postgresql.org
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane wrote:
Specifically, I think what you missed is that on some platforms C
functions pass or return float values differently from similar-sized
integer or pointer values (typically, the float values get passed in
floating-point registers).
Hum
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
I was wondering about that too, once it became obvious that (almost?)
everything was failing not just some platforms. However, this
afternoon's CVS HEAD *does* pass the seg regression test for me on HPPA,
and I presume it passed
to a file at all.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
. It's going to take one hell of a
strong argument to persuade me that determination of the horizontal
dimension should not work exactly the same way.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription
. I know there was previously some handwaving about representing
XML values in some more intelligent fashion than a plain text string,
but I have no idea if anyone is likely to do anything about it in the
foreseeable future.
regards, tom lane
--
Sent via pgsql-patches
as the main backend goes I think it's ready to apply.
Patch to all contrib modules:
http://www.sigaev.ru/misc/contrib.patch.gz
Ooops, we duplicated work :-(. Will compare with your version before
applying.
regards, tom lane
--
Sent via pgsql-patches mailing list
goes I think it's ready to apply.
regards, tom lane
binI2STY1wRy8.bin
Description: run-time-recheck-1.patch.gz
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
is missing: every callback
function needs a pass-through void * pointer so that it can get at
private state.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
this idea with the attached patch.
It was already explained to you why this is a bad idea.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
though that the cases
like this:
! PG_RETURN_TEXT_P(DatumGetPointer(result));
might as well just use PG_RETURN_DATUM instead of casting twice.
Was this just eyeball inspection or did you find a compiler that would
complain about this?
regards, tom lane
--
Sent via
it wider on 32-bitters?
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Gavin Sherry [EMAIL PROTECTED] writes:
might as well just use PG_RETURN_DATUM instead of casting twice.
Oh of course. Updated patch attached.
Applied, thanks.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes
parameters,
though.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
a null pointer? I think a crash in
such a case is what we *want*. Silently not locking is surely
not very safe.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
. And
bloating one line of code into five or more lines to defend against
can't-happen cases is a good way to end up with unreadable,
unmaintainable software.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your
in include/port.h, and put it in include/port/win32.h instead?
Seems cleaner that way, at least for things where there's just an
#ifdef WIN32 hunk and not two cases for Win and not-Win.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org
...
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
some complicated method, and the patch
will be rejected because it adds too much overhead. Anything we do here
has to be cheap enough that no one will object to having it turned on
all the time --- else it'll be useless exactly when they need it.
regards, tom lane
--
Sent
, that is put something like
#define stat(...) pgwin32_stat(...)
into the win32 port header file, so the calls don't have to be
nonstandard.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
Ick.
The reason not to do so was to avoid having to do the two filesystem
calls for *every* stat, instead just calling them both when we actually
need to use the st_size member.
I don't think that's worth (a) the code uglification
the parametrized version.
I don't follow ... there's no such redefinition in our code AFAICS.
Do you mean that the system header files declare it as a macro?
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription
, especially since he'd not have to abort and restart the long
query to find out if it's making progress. It'd help if pgstattuple
were smarter about dead vs uncommitted tuples, though.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org
. I seem to recall some discussion of
including a low-overhead progress counter of some kind in the
pg_stat_activity state exposed by a backend. The number of rows so far
processed by execMain.c in the current query might do for the
definition.
regards, tom lane
--
Sent
those same
threads in the fest queue next time, unless someone's done some actual
work in between.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
an entry being made in the pending-commit-fest list.)
I've surely got no objection to you hanging on to such threads in your
personal almost-TODO list, and prodding people when appropriate. But
the commit fest queue is not for that purpose.
regards, tom lane
--
Sent via
has made it pretty clear
that he doesn't want to put in any extra cycles here. So someone
else has to step up to the plate if this is going to work.
Any volunteers out there?
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make
that that isn't sufficient
you really need a pretty convincing example why not.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
places where the performance argument for adding
such clutter was compelling. We can do that some more, but you'll need
equally compelling arguments. Do not bother submitting patches to
create a very large number of inlines.
regards, tom lane
--
Sent via pgsql-patches
mixing code ...
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
be welcomed.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
need is for someone to go through all those
files and propose a clear layering of them. This will very likely
involve having to move some declarations around, when we realize
something got put in a poorly chosen place.
regards, tom lane
--
Sent via pgsql-patches mailing
bright enough. When the state of the headers gets bad enough
that we're willing to accept collateral damage, then it should be
run, but I don't think it's reliable enough to use routinely.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org
Nobuhiro Iwamatsu [EMAIL PROTECTED] writes:
+#if defined(__sh__) /* Renesas SuperH */
Do they have any longer form of that macro? This one seems dangerously
likely to trigger on unrelated systems.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches
at lines
89-107 of s_lock.h, both cosmetic and substantive. Why? Are you
entirely certain it's right, and not subject to optimization problems in
versions of gcc other than whatever you tested?
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches
Greg Smith [EMAIL PROTECTED] writes:
On Thu, 3 Apr 2008, Tom Lane wrote:
I'd much rather be spending our time and effort on understanding what
broke for you, and fixing the code so it doesn't happen again.
[ shit happens... ]
Completely fair, but I still don't see how this particular patch
Greg Smith [EMAIL PROTECTED] writes:
On Fri, 4 Apr 2008, Tom Lane wrote:
(And you still didn't tell me what the actual failure case was.)
Database stops checkpointing. WAL files pile up. In the middle of
backup, system finally dies, and when it starts recovery there's a bad
record
the development of.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
that looking at the interval is
helpful anyway.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
if we shouldn't go the other way, ie, use ++ everywhere.
OffsetNumberNext seems like just useless obscurantism ...
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
these dependencies around bufpage.h, bufmgr.h
What's the point here, again?
Bruce periodically runs a script that's supposed to catch this type
of problem. Maybe we are overdue for another run?
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches
supposed to catch this type
of problem. Maybe we are overdue for another run?
Yes, but This problem is there for long time and I think Bruce's script does
not
catch it.
Exactly what problem do you see that he didn't catch?
regards, tom lane
--
Sent via pgsql-patches
? This is supposed to be a standard,
so there is no reason to designate it as PG-specific. plpsm seems the
right name.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
rows. Actually rows are supposed to be limited
to ~1600 columns, anyway, because of HeapTupleHeader limitations.
Apparently you've found a path where that restriction isn't enforced
correctly, but I haven't seen the referenced message yet ...
regards, tom lane
--
Sent via
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
Actually rows are supposed to be limited
to ~1600 columns, anyway, because of HeapTupleHeader limitations.
The trick is that that limitation doesn't apply to the intermediate
virtual tuples we move around in the executor.
I'm
, start to *require* a space between command
and args). Are we ready to do that?
This discussion really needs to be moved to someplace more widely read
than -patches, btw.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
I still haven't seen the actual bug description come by here, and the
pgsql-bugs archive hasn't got it either.
(apparently some mails on that thread are missing ...)
That's what I meant. Heikki is quoting himself from a message
the entries actually needed in the query.
What I propose we do is throw error for the moment, and make a TODO
note to revisit the question after redesigning outer-join planning.
Which is something I do intend to do for 8.4.
regards, tom lane
--
Sent via pgsql-patches
a higher
quality standard for patches that are claimed to be ready to apply.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
the
very next time the bgwriter sends a stats message. I'm not sure what
a sane behavior would be, but it seems unlikely that that's it.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http
checkpoint_timeout *
checkpoint_completion_target, regardless of load factors. So unless
your settings are completely broken, measuring the actual time isn't
going to tell you much.
In short: Heikki's question is on point.
regards, tom lane
--
Sent via pgsql-patches mailing list
on top of that, at the SQL
level; but I don't see the point, and I definitely disagree that it
would be easier than trolling the logs.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http
provide tracking of the last N checkpoints; which might start to
approach the level of an interesting feature, except that it's still not
clear *why* those numbers are interesting, given the bgwriter's
propensity to try to hold the checkpoint duration constant.
regards, tom lane
Robert Treat [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote:
3. As of PG 8.3, the bgwriter tries very hard to make the elapsed time
of a checkpoint be just about checkpoint_timeout *
checkpoint_completion_target, regardless of load factors. So unless
your settings are completely
Theo Schlossnagle [EMAIL PROTECTED] writes:
On Apr 3, 2008, at 10:33 PM, Tom Lane wrote:
Theo claimed he had a reason for wanting to know the latest checkpoint
time, *without* any intention of time-extended tracking of that; but
he didn't say what it was.
We had a recent event where
, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Peter Eisentraut [EMAIL PROTECTED] writes:
The attached patch implements a few changes to how shared libraries and
dynamically loadable modules are built.
Looks like a good idea to me, though I've not read it in great detail
(I hate unidiffs).
regards, tom lane
Joshua D. Drake [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote:
The fundamental problem I've got with this patch is that it adds 400K
of new code (and that's just the code, not counting documentation or
regression tests) that we'll have to maintain, to obtain a feature
that so far
201 - 300 of 3477 matches
Mail list logo
