... 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.orgextra=pgsql-patches
.
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 list (pgsql-patches@postgresql.org)
To make
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 the back-patch
commits came through either
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@postgresql.org)
To make changes to your subscription:
http://mail.postgresql.org/mj/mj_wwwusr
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 (pgsql-patches@postgresql.org
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 there's
not enough information in the system catalogs
the target program?
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
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't forget to increase your
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
---(end of broadcast
to use it?
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
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
. 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)---
TIP 9: In versions below 8.0, the planner
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
---(end of broadcast
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?
regards, tom lane
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 at
this point, so keeping a pointer
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's OK in the built-in SRFs is disastrously
.
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 broadcast)---
TIP 1: if posting
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.
regards, tom lane
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 supported platform which
does not have
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 of a
compiled instance. How about if we get pg_config
)?
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
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.
regards, tom lane
---(end of broadcast
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
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)---
TIP 9: In versions below 8.0, the planner will ignore your
; 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
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
---(end of broadcast)---
TIP 1
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
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)---
TIP 9: In versions below 8.0, the planner
.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
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* on platforms without post-Y2038 calendar
support.
regards, tom lane
, tom lane
bin5xGxvAMBU7.bin
Description: toast-strategy.patch
---(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
check was at
least as good.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
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
(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
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
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 computing pd_upper - pd_lower as it had done in
every previous release
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
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
===
RCS file
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 in front of it.
It should be possible
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
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
===
RCS file
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
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
a showstopper problem.
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
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 the (ahem)
obfuscated way that it's
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: Have you checked our extensive FAQ
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 help support the PostgreSQL
to make that happen.
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
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.sgml
*** doc
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
---(end of broadcast
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
future? I want to be able
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 appropriate
subscribe-nomail command to [EMAIL
() and StatementCancelHandler(). Seems cleaner than
before.
regards, tom lane
Index: src/backend/port/posix_sema.c
===
RCS file: /cvsroot/pgsql/src/backend/port/posix_sema.c,v
retrieving revision 1.19
diff -c -r1.19
in psql; though I'm not
sure what to do to disambiguate the case with no arguments.
regards, tom lane
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http
).
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 something
regards, tom lane
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
...
regards, tom lane
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
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?
Other than that quibble, +1.
regards, tom lane
---(end
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
subscribe-nomail command to [EMAIL
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...
regards, tom lane
---(end
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.
regards, tom lane
---(end of broadcast)---
TIP 2
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 appropriate
: 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
---(end
, 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
---(end of broadcast
the lockfile (if any) look live.
Maybe we should go back to the plan of having the postmaster
wait for the archiver to exit.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Maybe we should go back to the plan of having the postmaster
wait for the archiver to exit.
Yeah, that seems the safest to me -- the problem is that it complicates
the shutdown sequence a fair bit, because postmaster must act
I wrote:
I'll respin my patch this way...
Third time's the charm?
regards, tom lane
binFKkWVCJKov.bin
Description: archiver-shutdown-3.patch
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ
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 broadcast)---
TIP 7: You can help support the PostgreSQL project
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 wouldn't be a bit
surprised if its data
, tom lane
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
or not. Comments?
regards, tom lane
binEUCN9e9ool.bin
Description: archiver-shutdown.patch
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
are gone.
The comment in line 2180 seems a bit bogus ...?
Yeah, that could use a bit more work I guess, since normal children
sounds like it would refer to more than just backends.
regards, tom lane
---(end of broadcast
...
regards, tom lane
binN52EbkMKOk.bin
Description: archiver-shutdown-2.patch
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
simple adjustment to my prior patch for 8.3,
which I will go ahead and make if there are no objections...
regards, tom lane
binleD9NAxImv.bin
Description: const-propagation-8.2.patch
---(end of broadcast)---
TIP 2: Don't 'kill
thing it's good for is this rather specialized optimization
rule.
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
backpatch that portion of the patch to back branches
if anyone feels strongly.
Not worth backpatching --- the plan node output support is only of
interest to hard-core hackers, who'd be working on current sources.
regards, tom lane
---(end
patch. It seems to fix my simplified
test case, but I'm not sure if there are any additional considerations
involved in your real queries.
This is against CVS HEAD but I think it will apply cleanly to beta4.
Haven't looked closely at how to fix 8.2, yet.
regards, tom
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
It seems we ought to forbid delimiter from matching CSV
quote or escape characters. I'll let you clean up that case though...
This should do the trick - I'll apply it tomorrow.
A couple thoughts:
* This test needs to appear further
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= [EMAIL PROTECTED] writes:
- individual data types is expected evolve in order to align the
+ individual data types is expected to evolve in order to align the
Applied, thanks.
regards, tom lane
---(end
.
Ideally I think it'd be a good idea if these types did allow zero
elements, but that would clearly be a feature extension more than a bug
fix, since the implications aren't entirely obvious. I concur with
disallowing the case for existing branches. Will go apply.
regards, tom
on reports from the field.
Applied patch attached.
regards, tom lane
Index: pgarch.c
===
RCS file: /cvsroot/pgsql/src/backend/postmaster/pgarch.c,v
retrieving revision 1.35
diff -c -r1.35 pgarch.c
*** pgarch.c
it is
a horrible idea.
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Guillaume Lelarge [EMAIL PROTECTED] writes:
Tom Lane a écrit :
The attached patch does this, and seems to resolve Guillaume Lelarge's
original complaint.
It does resolve it. I applied your patch on my CVS HEAD checkout and it
works just great.
Patch is applied to CVS
to just live with that, since it seems a relatively minor
deficiency, but I wonder if anyone has a better idea how to do it?
regards, tom lane
Index: src/bin/psql/describe.c
===
RCS file: /cvsroot/pgsql/src/bin/psql
situations...
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
switches,
I believe they are all equivalent to one or another GUC variable:
http://developer.postgresql.org/pgdocs/postgres/runtime-config-short.html
so the restrictions are the same as for the underlying variable.
regards, tom lane
---(end of broadcast
() --- it's the same
sort of animal as PGHOST or PGPORT. So those provide alternate paths
for getting at the same functionality, and any documentation patch
should be clear about this.
regards, tom lane
---(end of broadcast
?
regards, tom lane
Index: fe-connect.c
===
RCS file: /cvsroot/pgsql/src/interfaces/libpq/fe-connect.c,v
retrieving revision 1.354
diff -c -r1.354 fe-connect.c
*** fe-connect.c9 Dec 2007 19:01:40 -
Joshua D. Drake [EMAIL PROTECTED] writes:
Tom Lane wrote:
As of PG 8.3, libpq allows a conninfo string to be passed in via the
dbName parameter of PQsetdbLogin.
I didn't even know we could do that. I always use the shell variable
option instead. Does anyone actually use the facility?
Well
to show the best way of doing it if we're gonna
do it ...
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
for an ugly special case, instead.
regards, tom lane
Index: doc/src/sgml/libpq.sgml
===
RCS file: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v
retrieving revision 1.247
diff -c -r1.247 libpq.sgml
*** doc/src/sgml
/2007-12/msg00014.php
Anyway, I'd like to see a design discussion about what any libpq API
changes in this area ought to look like, rather than having it be
determined by who can submit the quickest-and-dirtiest patch.
regards, tom lane
---(end
affects the
estimated total cost (only).
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
, tom lane
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
equal to the sum of its
input startup costs (hence, zero in the cases of interest here).
regards, tom lane
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail
into the idea that libpq should know explicitly about each
and every backend datatype. The 100% lack of any documentation in the
patch isn't helping you sell it, BTW.
regards, tom lane
---(end of broadcast)---
TIP 1: if posting
?
regards, tom lane
Index: src/backend/optimizer/path/costsize.c
===
RCS file: /cvsroot/pgsql/src/backend/optimizer/path/costsize.c,v
retrieving revision 1.189
diff -c -r1.189 costsize.c
*** src/backend/optimizer/path/costsize.c
Hannes Eder [EMAIL PROTECTED] writes:
Don't try to install a missing file ;) Install.pm needs an update, see
attached .diff
Ooops :-(. Looks like Magnus got to this mere seconds before I did.
regards, tom lane
---(end of broadcast
,
the COPY operation will not be so straightforward.
Does my latest patch attached address this well enough?
Applied with revisions and extensions. (I take it you hadn't actually
tested the example :-()
regards, tom lane
---(end of broadcast
401 - 500 of 3477 matches
Mail list logo
