raf r...@raf.org writes:
the sentence:
This is an facility independent of the collector process.
should be:
This is a facility independent of the collector process.
Seems to be fixed already in the 9.1 docs, but thanks for the report!
regards, tom lane
--
Sent
is in
8.4.5, which makes me doubt the OP's report of his server version.
http://git.postgresql.org/gitweb/?p=postgresql.gita=commitdiffh=dc9cc887b74bfa0d40829c4df66dead509fdd8f6
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
in
the timezone abbrevation configurations on the two machines.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
wrong to me.
Yeah, I see it too. It seems to be evaluating the placeholder for the
COALESCE expression at the wrong join level. Not sure why, yet.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
, not ON or WHERE). Patch committed, thanks for the report!
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
quotes}
(1 row)
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
mean
entirely different things in SQL commands.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
shows this is
still the case in Fedora 15. So I'm not convinced that nearly every
is anywhere near true.
How about 896?
But having said that, I could go with 896 (or perhaps 900, which seems
a shade less weird).
regards, tom lane
--
Sent via pgsql-bugs mailing list
Noah Misch n...@2ndquadrant.com writes:
On Fri, Aug 05, 2011 at 06:46:21PM -0400, Tom Lane wrote:
But having said that, I could go with 896 (or perhaps 900, which seems
a shade less weird).
That works for me.
OK, applied to HEAD and 9.1.
regards, tom lane
--
Sent
shared_preload_libraries here.
Yeah, I think you're right. Will fix.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
. 9.1 will be a bit cleaner in this regard, see
http://git.postgresql.org/gitweb/?p=postgresql.gita=commitdiffh=1453cd8f8
http://git.postgresql.org/gitweb/?p=postgresql.gita=commitdiffh=2594cf0e8
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
of that much information, I'd bet on
accidental invocation of a postmaster startup script that thinks it
should remove the postmaster.pid file before trying to launch a new
postmaster. I've seen a lot of those, and every one of them is
dangerously broken.
regards, tom lane
a self-contained
example? Also, 8.4 is by no means an adequate identification of the
PG version.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
whatever the
real problem is.
I've applied a patch along those lines. Thanks for the report!
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
that pg_restore produces
by default seems to be valid, so you could pipe that into psql.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
send you an extra
copy, I believe, but I don't know the incantation offhand.
Tom Lane wrote:
Not sure about a simple fix,
and I rather wonder if we shouldn't try to remove that code entirely
instead of fix it.
What would removing that code entirely mean?
I was wondering why it's necessary
or
(recently) free'd
Can't reproduce this on my own Red Hat machines ...
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
libpthread.so when
starting postgresql.
Linking pthreads into the backend is likely to cause more problems than
it solves, especially if you're proposing that we do that everywhere.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes
is that it
affects the size of the hash table that the HashAggregate step uses.
That's not tremendously relevant to fixing the problem, but just in
case you were wondering.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
-Index-relations))!
This isn't a bug, it just indicates no ANALYZE has happened yet.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
on the client end of it?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Greg Johnson greg.john...@interprose.com writes:
On Thu, Jul 21, 2011 at 11:44 AM, Tom Lane t...@sss.pgh.pa.us wrote:
This looks like pg_restore is terminating unexpectedly. What do you see
on the client end of it?
pg_restore: [custom archiver] could not read from input file: end of file
the data loaded. Let me know if there is any other info I get
you.
Parallel restore? You didn't mention using parallel restore before.
Were the failed pg_restore runs using parallelism?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
. Selectively quoting from your function does not
provide anything anyone could investigate. Please see
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
work through that you'll see that indeed these values should
produce a false result: we have S2 S1, S2 = T1, T2 = T1.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
of the DELETE
to be obsoleted, so heap_delete finds it has nothing to do. I'm
disinclined to mess with that logic.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
The update causes the already-selected target row version of the
DELETE to be obsoleted, so heap_delete finds it has nothing to do.
I'm disinclined to mess with that logic.
It's pretty astonishing behavior
on building an explicit
partitioning mechanism to handle the common cases more simply and
efficiently, instead of continuing to add frammishes to the inheritance
mechanism.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes
on the current behavior.
We could possibly address Aleksey's complaint without changing the
behavior otherwise, but I'm not sure it's worth the trouble. So I
vote for document-and-move-on.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
is OFF. As of 9.1 it's ON by default.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
within aggregates. Perhaps also omit those only used
within volatile sort expressions, though I think that would just be an
efficiency issue not a correctness issue, and it may be unreasonably
expensive to determine that.
regards, tom lane
--
Sent via pgsql-bugs mailing list
row. That seems pretty
useless, so I'm thinking it's not worth back-patching a fix for.
Comments?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
://wiki.postgresql.org/wiki/Guide_to_reporting_problems
We'd also need to know what locale (lc_collate, lc_ctype) and encoding
you are using, because that could easily affect the behavior of ILIKE.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
Jeff Davis pg...@j-davis.com writes:
On Tue, 2011-07-12 at 11:20 -0400, Tom Lane wrote:
So far as I can see, the failure only
occurs if we have a plain (non-grouping) Agg node, which implies that
the user is trying to use windowing functions on a result set that's
guaranteed to contain
to see a more complete test example.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
: unrecognized configuration parameter something.location
Nonetheless, it's clearly not the desired behavior :-(. Will look.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
Maxim Boguk maxim.bo...@gmail.com writes:
Description:Server crash when enabling custom_variable_classes
Fixed, thanks for the report.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
: INSERT INTO wage (id. pay)
^
This *is* valid syntax, if id is a composite-type column.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
Jeff Davis pg...@j-davis.com writes:
On Tue, 2011-07-05 at 13:56 -0400, Tom Lane wrote:
Yeah, I had been thinking along the same lines. It will require
duplicating the search loop, which is a bit annoying, but perhaps that
could be factored out as a subroutine.
Patch attached. The logic
Jeff Davis pg...@j-davis.com writes:
On Wed, 2011-07-06 at 13:25 -0400, Tom Lane wrote:
Actually, I'd just been working on this myself. I think the cleanest
solution will be to get rid of the duplicative logic by making
predtest.c use get_op_btree_interpretation(). That will require
Jeff Frost j...@pgexperts.com writes:
On 07/05/11 17:06, Tom Lane wrote:
Jeff Frost j...@pgexperts.com writes:
Ran into a situation with a customer who is using the btree_gist contrib
module to allow combined index of some tsearch data and two other columns.
One of these other columns
we still support for backwards compatibility with versions 7.3. We
can fix the immediate problem with something like the attached.
(a) Should we do that?
That seems like a horrid crock ...
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
of the
double-quote workaround, I feel little need to have a back-patchable
fix.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Robert Haas robertmh...@gmail.com writes:
On Sun, Jul 3, 2011 at 12:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The code that recognizes a default expression as being just constant
NULL doesn't think this is a constant NULL. In principle it could
recognize that, since the cast function
out as a subroutine.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
by the planner unless you specifically cast the bare
number to a bigint.
If memory serves, the btree_gist opclasses don't include any cross-type
operators, so int8 = int4 doesn't work here.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
. However, I'm unsure
whether to apply it to released branches ... does anyone think this
might break somebody's application?
regards, tom lane
diff --git a/src/bin/psql/copy.c b/src/bin/psql/copy.c
index 5e69d29b6cbeab56aa0c85e85c3edce46d06efac
Chris Bandy bandy.ch...@gmail.com writes:
On Fri, Jul 1, 2011 at 10:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
But AFAICS there is room for implementation dependency in other cases.
In the particular cases you show here, PG recognizes some of them as
being equivalent to not having a default
use seem negligible, and not at all adequate to
warrant adding extra cycles into mainstream code paths. It's not too
late to rip that out of 9.1, and that's what I think we should do.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
worrying about interrupt
response latency is worthwhile.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Jon Nelson jnelson+pg...@jamponi.net writes:
On Fri, Jul 1, 2011 at 3:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
FWIW, I can't reproduce such a failure with current 8.4 branch (nor any
other).
Try adding:
set enable_mergejoin = false;
Thanks, that did it. I've repaired the symptom exposed
on those to work (or rather, not work).
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
to this issue. I don't recall that
anyone liked his hack though ...
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
bound to make every
such case work like that, though.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Maksym Boguk maxim.bo...@gmail.com writes:
But I found I can not stop
COPY bill.changes (id, cdate, mdate, status, table_name, pk_id, old_row,
new_row) TO stdout;
with pg_terminate_backend(procpid) or kill (procpid).
Works for me ...
regards, tom lane
--
Sent via
the function
strict in pg_proc.h.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Jeff Davis pg...@j-davis.com writes:
http://archives.postgresql.org/pgsql-bugs/2011-06/msg00167.php
It's on my to-look-at list. Your patch looked to me like it would add
extra syscache fetches in typical cases, and I was hoping to find a way
that didn't.
regards, tom
) is used.
You did not provide any evidence of that. Please show a *complete*
self-contained test case.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
(I must
force with * to do that).
i can confirm this
This is allegedly a feature, not a bug, and it's been that way for a
couple releases now: \df with no argument prints only user-defined
functions. I will let those who advocated that behavior defend it.
regards, tom
is a different situation (because of some files being provided rather
than built on-the-fly) and it doesn't get tested regularly. Anyway,
I've applied fixes and verified that a build works now.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
/sysconfig/pgsql/ if you need to change 'em. It's
intentional that those settings win out over postgresql.conf.
I'm not entirely sure that the OP is using the RHEL RPMs, though,
because the fragment he quoted didn't quite match this.
regards, tom lane
--
Sent via pgsql
, all right, but I don't see that happening here.
At least I don't see any indication of it in
pg_stat_all_tables.last_autoanalyze. Are you looking at that, or some
other evidence? Do you have any nondefault settings?
regards, tom lane
--
Sent via pgsql-bugs mailing list
different about those two tables: they have no
analyzeable columns. I thinko'd what to do in that situation. Will
fix.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
,
and in general I doubt that we ever will, since in most cases the
behavior wouldn't be very well-defined. It might be worth a TODO
to provide a better error message than syntax error, though.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
various
other theories about PG portability problems.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
speculation at this point.
(BTW, is it really sane to be using ident auth over a high latency
connection? That would certainly suggest to me that you could be
getting connections from untrustworthy machines ...)
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql
.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
the rest.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
the pager.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
pg_basebackup.c.DIST pg_basebackup.c
BTW, plain diffs are just about useless, since patch can't apply them
safely if the code has changed at all. Please send -c or -u format
diffs in future.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
to do so. So data loads
that go through that particular API would miss incrementing the space
counter.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
-04/msg00127.php
Aside from pestering Apple to fix it, there's not much you can do except
install GNU libreadline and link against that instead.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Denis de Bernardy ddeberna...@yahoo.com writes:
Wrapping apparently doesn't want to work in expanded mode...
No, it's not supposed to.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
analysis is correct, we really ought to try to fix this in time
for beta2, since there's no way to fix it without a forced initdb.
Comments?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
Greg Stark gsst...@gmail.com writes:
On Jun 3, 2011 4:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm inclined to write this off as so don't do that. There's nothing
that pg_dump can do to make this work: it has to use the USING syntax
for the join, and that doesn't offer any way to qualify
want to be testing this in the
parser. It has to be done at plan or execute time.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
the fact that USING
is fragile *by definition*. Complain to the standards committee
about that.
(Question: would you also have us try to work around the fact that
USING stops working if you rename one of the join columns?)
regards, tom lane
--
Sent via pgsql-bugs mailing
put it in ExecOpenScanRelation instead, so that it covers both seqscan
and indexscan accesses.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
on unlogged tables, rather than rejiggering pieces of
the planner to sort-of not fail on an unlogged table.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
have gone down any ...
I had in mind for pg_dump to decide to use the non-standard syntax iff
it was necessary at dump time.
Maybe. I'm concerned about the cost of determining whether it's
necessary (cost meaning both runtime and code complexity).
regards, tom lane
Robert Haas robertmh...@gmail.com writes:
On Tue, Jun 7, 2011 at 3:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It might be that it'd be best just to have both the planner and executor
throwing errors on unlogged tables, rather than rejiggering pieces of
the planner to sort-of not fail
like RFC says it should.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
David Fetter da...@fetter.org writes:
On Sat, Jun 04, 2011 at 05:24:22PM -0400, Tom Lane wrote:
We could paste a copy of the original's cteList into the rule action,
but there are still issues:
* If there's more than one rule action, we could end up executing
multiple copies of the same CTE
Dylan Adams dad...@bybaxter.com writes:
If you create a view based on a VALUES statement with an ORDER BY clause,
the SQL produced by pg_dump can't be loaded back into the database.
I've applied a patch for this. Thanks for the report!
regards, tom lane
--
Sent via
rule action without risking a
conflict. Ideas anybody?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Robert Haas robertmh...@gmail.com writes:
On Fri, Jun 3, 2011 at 10:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Personally my advice is to avoid USING: it wasn't one of the SQL
committee's better ideas.
I don't understand why we can't just translate the USING into some
equivalent construct
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Personally my advice is to avoid USING: it wasn't one of the SQL
committee's better ideas.
There's no query you can write with USING that you can't write in a
longer form with ON; but a query of moderate
Robert Haas robertmh...@gmail.com writes:
On Fri, Jun 3, 2011 at 1:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Now, if the query doesn't involve any explicit reference to joinalias.*,
we could probably fake it with some ugly thing involving
COALESCE(leftcol, rightcol) ... but I don't think
() is not a builtin function, we can't change it to select
today()::timestamp;
You can get that by using date_trunc on the result of now(); or there's
current_date, which is actually SQL-standard unlike these other things.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql
in the version the OP is running.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
. Use CREATE EXTENSION.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
...)
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
around of the backend
cmsgmem declaration was documented as fixing problems on NetBSD and then
OpenBSD. If it's true as per the libpq comment that only FreeBSD needs
the client-side cmsgmem buffer, this might not have gotten retested.
regards, tom lane
--
Sent via pgsql-bugs
, and not the
next. Here's what I now get on 8.4, 9.0, and 9.1:
$ pgbench btest1 -n
setrandom: invalid maximum number 0
That's not valid syntax. Some versions of getopt() take it upon
themselves to rearrange the switch order, some do not ...
regards, tom lane
--
Sent via pgsql
.
AFAIK there isn't any way to exercise the receive functions via psql.
You need a client that will send data as binary parameters. But it's
obvious by inspection of the code that it's broken. Will fix, thanks
for the report!
regards, tom lane
--
Sent via pgsql-bugs mailing
much pain.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
901 - 1000 of 6572 matches
Mail list logo
