27;t changed materially (except for
additions of subtransaction and 2PC support) for a long time,
back-patching should be straightforward, but I haven't actually done
that yet.
Comments?
regards, tom lane
binH6LxqEvTWN.bin
Description: listen-race-fix.patch.gz
--
e local
malloc library as to how bad it is). I'd go with the same
double-it-each-time-needed approach we use elsewhere.
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
ility if we can skip the call, for the cost of an
> integer comparison.
> Following patch implements fastpath in TransactionIdIsInProgress() to
> utilise single item cache.
Applied with minor adjustments and some desultory comment-improvement.
regards, tom lane
completeness, the raw per-backend stats are attached.
Unsurprisingly, the wins come in bunches.
regards, tom lane
XidCache: xmin: 1, known: 0, myxact: 0, latest: 0, mainxid: 0, childxid: 0,
nooflo: 0, slow: 0
XidCache: xmin: 1, known: 0, myxact: 0, latest: 0, mainxid: 0,
e
TransactionIdIsCurrentTransactionId test, since as was just being
discussed that could have nontrivial execution time. (I'll go look at
Heikki's improvement on that next, but it'll still be not-free if
there's lots of subtransactions.)
regards, tom lan
have been mentioned.
Yeah, please just make up a ten-line C program that prints the numbers
you want, and post it on -hackers for people to try. If manual testing
says that it's printing useful numbers, then it would be time enough to
think about how to get it into the buildfarm.
ven the lack of field reports
of compressed-data problems, it seemed to me that the risk of breaking
something was larger than the chance of helping someone. We could
reconsider this after the code has been in HEAD awhile, perhaps.
regards, tom lane
--
Sent via pgsql-pat
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> I think current patch could stay in CVS and I will rip out non segment
> code path in a new patch.
Sure, I feel no need to revert what's applied. Have at it.
regards, tom lane
--
Sent via pgsql-patches ma
omplex
already. Simon's approach hides the issue somewhere else where there
aren't so many code paths to keep straight.
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
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Tom Lane napsal(a):
>> These examples suggest that maybe what we want is not so much a "no
>> segments ever" mode as a segment size larger than 1GB.
> PS: ZFS is happy with 2^64bit size and UFS has 1TB file size limit
uot;no
segments ever" mode as a segment size larger than 1GB.
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:
> Tom Lane wrote:
>> I think this needs to be treated as experimental until it's got a few
>> more than zero miles under its belt.
> OK, then maybe we should document that.
Agreed, but at this point we don't even kno
pproximately zero.
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:
> Tom Lane wrote:
>> Applied with minor corrections.
> Why is this not the default when supported?
Fear.
Maybe eventually, but right now I think it's too risky.
One point that I already found out the hard way is that siz
ode.
Applied with minor corrections.
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
ld be done somewhere outside the
dictionary, should I revert the applied 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
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> On Sun, 9 Mar 2008, Tom Lane wrote:
>> Would a similar parameter be useful for any of the other dictionary
>> types?
> There are many things desirable to do with dictionaries, for example,
> say dictionary to return an ori
t his patches to be applied?
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
ument 2
> has type 'long int'
> I was thinking the %td specifier wasn't well supported enough, so I simply
> used long.
Applied, thanks (and yes, %ld is what we generally use for this).
regards, tom lane
--
Sent via pgsql-patches mailing list (
er dictionary
types?
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
ITAGAKI Takahiro <[EMAIL PROTECTED]> wrote:
> I found XLogCtlData.XLogCacheByte is already unused in CVS HEAD.
> Should we remove the variable, or reserve it for future use?
Applied, thanks. We can always put it back if we need it again.
regards, tom lane
itten
to not use dedicated shared memory, as I hope will happen for 8.4.
But we can always revert it if that happens.
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
ered this way:
> return min + (int) (((max - min + 1) * (double) random()) / (MAX_RANDOM_VALUE
> + 1.0));
> eliminating the result of max + 1 in a corner case when random() equals to
> MAX_RANDOM_VALUE.
Yeah, that looks more correct. Applied.
regards, tom lane
ure if printtup is good place for it, because pg_detoast is
> called from many places. However, is can be solved in separate patch.
I'm still unconvinced that that's worth any added complexity or
slowdown.
regards, tom lane
--
Sent via pgsql-patches mailing list
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> * Adds an early-failure path to the compressor as suggested by Jan:
>> if it's been unable to find even one compressible substring in the
>> first 1KB (paramete
ow dictionaries to change the token that is passed on to later
dictionaries".
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:
> Tom Lane wrote:
>> I don't think that follows. A tsearch index is lossy anyway, so there's
> Uh, the index is lossy but I thought it was lossy in a way that just
> required additional heap accesses, not lossy in tha
ich surely guarantees that searches won't find
them. How can you possibly argue that that option is better?
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
ou from storing the document.
There is another precedent too, namely that tsearch already discards
individual words over so-many-bytes long. If it doesn't throw an error
for that case, why is it throwing an error for this one?
regards, tom lane
--
Sent via pgsql-patches
ivity
fixes to 8.1, so I don't have too much hesitation about doing the same
here.
Comments?
regards, tom lane
binResgmyMI0F.bin
Description: like_minimum_estimate.patch.gz
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your s
BTW, I notice that the code allows CSV escape and quote characters that
have the high bit set (in single-byte server encodings that is). Is
this a good idea? It seems like such are extremely unlikely to be the
same in two different encodings. Maybe we should restrict to the ASCII
range? Especi
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Weird, I haven't seen the commit message come through here.
> Yeah, that's strange -- the (2) commit message got to me, but this one
> hasn't.
Moderation filter got it for some reason? None of
#x27;t seen the commit message come through here.
Anyway: (1) this should probably be back-patched; (2) please clean up
the ugly double negative here:
! #if !defined(HAVE_DLOPEN)
#else
dlclose(handle);
#endif
regards, tom lane
--
Sent via pgsql-patches mailing lis
hy anyone would care ... what
benefit is there to using Sun's compiler on Linux?
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-patches
on. Having to have two extra hook functions for every variable
seems like a lot of notational overhead for not much gain. (In my
experience C compilers are pretty darn lax about enums anyway, and so
there's not that much "strong typing" benefit to be gained from
declaring the var
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> What I'd suggest is declaring the actual variable as int. You can still
>> use an enum typedef to declare the values, and just avert your eyes
>> when you have to cast the enum to i
edef to declare the values, and just avert your eyes
when you have to cast the enum to int or vice versa. (This is legal per
C spec, so you won't introduce any portability issues when you do it.)
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@
Bjorn Munch <[EMAIL PROTECTED]> writes:
> The fix is simply to add "-lgss" to the list, as the attached patch
> does. I'm pretty sure no other Makefiles are affected.
Applied, thanks.
regards, tom lane
--
Sent via pgsql-patches mailing list (p
"Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> On Wed, Feb 20, 2008 at 3:55 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Actually the bug is that ALTER TABLE allows you to do that. It should
>> not be possible to drop an inherited constraint, but right now the
d to hold still for letting poorly-designed tools
dictate our coding conventions.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
x on the macro names before
we start to use it?
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
s tool really so badly designed that it thinks it has
ownership of the *entire* namespace within the target program?
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
some kluge or other in the libpgtcl client.
AFAICT from the 7.x code, the client-side kluge was never enabled by
default anyway, so it seems unlikely anyone will miss it.
regards, tom lane
---(end of broadcast)---
TIP 5: don&
erated, which is the
> file we will use for #includes, and contains just that block.
Or just two files. Call probes_null something else, have it be included
where needed, have it include the autogenerated file when appropriate.
regards, tom lane
--
ons of this would be,
either from a performance or number-of-places-to-change standpoint.
But it seems worth a bit of investigation while we're touching the
code.
Other than that issue, the patch seems OK in a quick once-over.
regards, tom lane
r any of the commands (initdb, psql, etc).
I agree with Peter. There are a whole lot of include files that are
needed by way more than 3 .c files, and yet are not folded into
postgres.h. c.h is right out.
regards, tom lane
---(end of broadcast)-
Neil Conway <[EMAIL PROTECTED]> writes:
> On Wed, 2008-02-27 at 15:07 -0500, Tom Lane wrote:
>> Negative refcount does not prove that the SRF itself hasn't
>> still got a pointer to the tupdesc.
> That sounds quite bizarre. The SRF has already finished execution
patch into stable branches. Negative refcount does
not prove that the SRF itself hasn't still got a pointer to the tupdesc.
Can't we fix it so that the tupdesc is allocated in the new special
context (at least in the primary code paths), and then no explicit
free is needed?
well
as read concerns; or have two versions of it, one for writing and one
for reading. In any case the point being to encapsulate all these
random little options in a struct, which could also carry along
state that needs to be saved across a series of inserts, such as
the last pinned buffer.
system that works for different localizations.
But as Peter remarks nearby, this discussion is wasted anyway, because
there is only one correct answer: whatever Oracle does with these
cases is what to_char() should do.
regards, tom lane
---(end of b
Neil Conway <[EMAIL PROTECTED]> writes:
> On Mon, 2008-02-25 at 21:00 -0500, Tom Lane wrote:
>> I find this part of the patch to be a seriously bad idea.
> AFAICS this is not true of any of the SRFs in the backend, which always
> return expendable tupdescs.
"It
lem. If you were asking for tests that the buildfarm wouldn't make,
I might think differently ... but then you'd need to be giving some more
detailed directions than these.
regards, tom lane
---(end of broadcast)-
try to make the tupdesc be in the new
multi_call_ctx when it's being created by the funcapi.c code.
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
obably some fairly small number of years. My position is simply
that pgstattuple does not present a reason to make that decision today,
especially not when making it rely on int64 is at variance with the
coding method already in use in related parts of the core backend.
r the heck that means in zeroconf)?
regards, tom lane
---(end of broadcast)---
TIP 1: 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 cleanly
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>>> Is there any currently supported platform which
>>> does not have uint64?
>>
>> I don't know, and neither do you.
> Maybe we should look at some reasonable way of getting the info out
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Tom Lane napsal(a):
>> Most places where we've dealt with this before, we use double, which is
>> guaranteed to be available whereas uint64 is not ...
> Is this requirement still valid?
Yes.
> Is there any currently
onfigure.in:
if test "$PORTNAME" = "solaris"; then
AC_LIBOBJ(getopt)
AC_LIBOBJ(getopt_long)
fi
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
s an empty string.
Since that's also effectively the way GUC handles it, I'm inclined
to think we should print NULL as "" not "(NULL)". Otherwise,
will apply.
regards, tom lane
---(end of broadcast)--
bug is that we are using it rather than one that acts
the way we want.
regards, tom lane
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
int-max.
> ...
> I think that max_avail and free_space should be uint64.
Most places where we've dealt with this before, we use double, which is
guaranteed to be available whereas uint64 is not ...
regards, tom lane
---
s use " \f\n\r\t\v" ?
Not sure. One point is that vertical whitespace shouldn't necessarily
be treated the same as horizontal whitespace.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
es in the committed patch
specifically to make it obvious if you were using tz files that lacked
post-2038 support.
I can't imagine that fixing this isn't pretty darn high on the Solaris
to-do list, anyway. Financial apps doing, say, 30-year mortgage
projections are broken *today
his patch and see what the results are like?
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
ic test scenarios they'd like to try?
regards, tom lane
bin5xGxvAMBU7.bin
Description: toast-strategy.patch
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscr
t I thought replacing them with a cast-based overflow check was at
least as good.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
matches LC_CTYPE, or maybe even just alter the
presented values for other LC_foo variables to match.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
numerator
is undefined in C (or at least used to be --- did C99 tighten this up?).
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> On investigation the problem occurs because we changed vacuum.c's
>> PageGetFreeSpaceWithFillFactor() to use PageGetHeapFreeSpace()
>> instead of just computin
27;m not
too surprised that there are no cases in the regression tests that
notice. We should probably add some reaching out to 2100 or so.
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
cleanup phase
> shouldn't take long.
That's what it smells like to me too. Any chance that you still have
the WAL log for examination?
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Neil Conway <[EMAIL PROTECTED]> writes:
> On Tue, 2008-01-29 at 13:20 -0500, Tom Lane wrote:
>> The reason it was kept was to override the search path --- unqualified
>> NUMERIC will always be taken as pg_catalog.numeric even if you have some
>> other type "numeric&
blem.
I am thinking that the extra notup condition should be back-patched,
at least as far back as we have fillfactor support, and maybe all
the way back on general principles.
Comments?
regards, tom lane
Index: vacuum.c
===
so I'm starting to think more and more that that's really the
right definition.
regards, tom lane
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
t tack we could take is to adopt the position
that LIKE INCLUDING INDEXES shouldn't copy index tablespaces at all,
but I didn't hear anyone favoring that approach in the bug discussion.
regards, tom lane
Index: src/backend/commands/indexcmds.c
=
ave that behavior and NUMERIC not.
regards, tom lane
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
t valid in the new database encoding. We've just gone around
> closing doors like this.
Ah, right, I hadn't thought about that, but it would be a hazard.
regards, tom lane
---(end of broadcast)---
TIP 3: Hav
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> However, I definitely agree that a separate loadable PL is the way to go
>> for functionality of this sort. There is no way that a dependency on
>> pgcrypto is going to be accepted into core, not even in t
at doesn't
seem like a showstopper problem.
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
ality of this sort. There is no way that a dependency on
pgcrypto is going to be accepted into core, not even in the (ahem)
obfuscated way that it's presented here.
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Gregory Stark <[EMAIL PROTECTED]> writes:
> I liked the "synchronized_sequential_scans" idea myself.
The name is still open for discussion --- it's an easy
search-and-replace in the patch ...
regards, tom lane
le, I thought I'd better post it for comment anyway.
regards, tom lane
Index: doc/src/sgml/config.sgml
===
RCS file: /cvsroot/pgsql/doc/src/sgml/config.sgml,v
retrieving revision 1.162
diff -c -r1.162 config.sg
;s an incremental step along
a clearly defined path to full WITH support in 8.4. I'm less eager to
put it in if there's not a plan and a commitment to make that happen.
regards, tom lane
---(end of broadcast)--
mplementation.
I don't recall at the moment if Greg has a credible design sketch for
the remaining work, but it might be a good idea to review that before
deciding.
regards, tom lane
---(end of broadcast)---
TIP 7: You can
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Fri, 2008-01-25 at 19:02 -0500, Tom Lane wrote:
>> This seems large, complex, and untested (I note in particular a
>> guaranteed-to-fail Assert).
> Yes, its for discussion. How would you describe such a patch in the
> f
sgNum == segP->minMsgNum when they first respond to a
signal. Do you have any evidence for performance improvement?
regards, tom lane
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropria
ers ignored the result), ending up with exactly
parallel code in die() and StatementCancelHandler(). Seems cleaner than
before.
regards, tom lane
Index: src/backend/port/posix_sema.c
===
RCS file: /cvsroot/pgs
ption notice would remain as possible additions.)
We really shouldn't be designing this on -patches, though.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
n't like the "Help me" thing though).
I think you're headed in the same direction as Alvaro. A slight
extension on this would be
help
produces short blurb describing \h and \?
help something
produces same result as \h some
"\?" all provoke the
same response(s) in mysql. Perhaps a patch that had had more than two
seconds' design effort in it would do the same in psql; though I'm not
sure what to do to disambiguate the case with no arguments.
regards, tom lane
e scenario
would be someone blindly following the hint and blowing away their old
data ...
regards, tom lane
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
uot;you need to initdb" is appropriate.
I think it still is, at least as much as it is in other situations where
we say that. I didn't like the wording of the other part of the hint
though. Maybe "This could be a problem of mismatched byte ordering"?
odify the tmp cleanup script,
> the admin might as well create the symlink at the same time and have it
> recreate on boot.
No, that's not the same, because it doesn't provide protection against
the symlink getting deleted later on.
TW, is a symlink's atime changed by accessing it? We could imagine
adapting the existing postmaster code that keeps the socket atime fresh
so that it will work on a symlink, thus providing partial protection
against tmp-cleaners. Portability of this is uncertain...
y if the attacker didn't get there first. I think this idea is
nothing but a crude kluge anyway...
regards, tom lane
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
need to be documented,
except as a release-note item.
Comments?
regards, tom lane
binKlTSMUpwon.bin
Description: rename-index-constraints.patch
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an a
not?
Note: the patch removes most of the PG_TRY blocks in xml.c. For ease of
reading I did not reindent the contained code, but will do so before
applying, if we choose to apply.
regards, tom lane
binymlB0qnjYe.bin
Description: xml-mem-4.patch
st checking.
Yeah, the postmaster would complain at exit, but the pg_control state
is already SHUTDOWN at that point. There'd be a log entry showing
abnormal archiver exit if the panic had had any actual effect on it.
regards, tom lane
-
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane escribió:
>> One thing I was wondering about earlier today is whether libxml isn't
>> expecting NULL-return-on-failure from the malloc-substitute routine.
>> If we take control away from it unexpectedly, I would
() will get rid of
all staticly-allocated pointers and not crash, whereas right now we
are assuming a great deal of libxml stuff still works after an ereport
(which makes throwing ereport from xml_palloc even more risky).
regards, tom lane
---(end of b
401 - 500 of 4175 matches
Mail list logo
