Bruce Momjian wrote:
Neil Conway wrote:
On Sat, 2007-05-05 at 20:52 -0400, Bruce Momjian wrote:
What? We don't pass float as a binary to clients.
Sure we do, if the client is sending or receiving data in binary format.
But in those cases, we assume the client and server have the same
config
Hello, I have a system where there are mostly COPYs,
which insert data into a table. Ocasionally a COPY will fail (and thus,
dead rows appear), but as far as I can tell ROLLBACK is not reflected
anywhere in the pg_stats_user_tables. And since there are no rows
n_tup_upd or n_tup_del, therefore a
What we've basically got here is a complaint that the default
textual-representation-based method for transmitting PL function
parameters and results is awkward and inefficient for bytea.
So the first question is whether this is really localized to only
bytea, and if not which other types have got
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> ITAGAKI Takahiro wrote:
> > > I found that autovacuum launcher does not launch any workers in HEAD.
> >
> > The attached autovacuum-fix.patch could fix the problem. I changed
> > to use 'greater or equal' instead of 'greater' at the decision of
> > next
Jim Nasby wrote:
> If we really want to make the logfile the approved method for
> monitoring performance, then why do we have the stats infrastructure
> at all? It could all be replaced with logging output and pgfouine.
First we'd have to fix the usability problem of our redirect_stderr
stuf
Neil Conway <[EMAIL PROTECTED]> writes:
> On Thu, 2007-26-04 at 18:07 -0400, Neil Conway wrote:
>> (1) I believe the reasoning for Tom's earlier change was not to reduce
>> the I/O between the backend and the pgstat process [...]
> Tom, any comments on this? Your change introduced an undocumented
Jim Nasby <[EMAIL PROTECTED]> writes:
> Also, what would be the appropriate way to put this into initdb?
You seem to have missed a step here, which is to convince people that
these belong in core at all. So far I've not even seen an argument that
would justify putting them in contrib. If they
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> This ought to be a property of data type plus language, not a property
>> of a function.
> Why should it?
> And how would you do it in such a way that it didn't break legacy code?
> My GUC proposal would have made it langua
Peter Eisentraut wrote:
> Hiroshi Inoue wrote:
>> Hiroshi Inoue wrote:
>>> User Petere wrote:
Log Message:
---
Put Autotools-generated files into subdirectory config/; add macro
files used from PostgreSQL there so you don't need a PostgreSQL
source tree to bootstrap
On Sun, 2007-06-05 at 13:09 -0400, Bruce Momjian wrote:
> Also, are we sure we can load a dump that used the float format? What
> happens for a date out of int8 range?
AFAIK we should always be able to reload timestamp values that are in
the legal range for an int8-based timestamp. For values out
On Sun, May 06, 2007 at 01:33:47PM -0400, Andrew Dunstan wrote:
> However, there are still some oddities. For example, a change to or
> removal of the base type affects the array type, but the array type
> can be directly operated on (e.g. alter type _aa set schema foo ).
> I'm inclined to say we
I wrote:
OK, summarising what looks to me like a consensus position, ISTM the
plan could be:
. fix makeArrayTypeName() or similar to make it try harder to generate
a unique non-clashing name
. remove the existing "62 instead of 63" name length restrictions
. autogenerate array types for a
Jim Nasby wrote:
> On May 5, 2007, at 10:38 AM, Neil Conway wrote:
> > On Sat, 2007-05-05 at 11:03 -0400, Tom Lane wrote:
> >> I'm not necessarily opposed to changing the default configure
> >> selection,
> >> but I am opposed to removing the FP code entirely.
> >
> > I would be satisfied with ch
Hiroshi Inoue wrote:
> Hiroshi Inoue wrote:
> > User Petere wrote:
> >> Log Message:
> >> ---
> >> Put Autotools-generated files into subdirectory config/; add macro
> >> files used from PostgreSQL there so you don't need a PostgreSQL
> >> source tree to bootstrap the code.
> >
> >
> >
> >
Andrew Dunstan wrote:
> It's not. If we really want to tackle this root and branch without
> upsetting legacy code, I think we'd need to have a way of marking
> data items as binary in the grammar, e.g.
>
> create function myfunc(myarg binary bytea) returns binary bytea
> language plperl as $$ ..
Peter Eisentraut wrote:
Andrew Dunstan wrote:
It's not. If we really want to tackle this root and branch without
upsetting legacy code, I think we'd need to have a way of marking
data items as binary in the grammar, e.g.
create function myfunc(myarg binary bytea) returns binary bytea
lan
Jim Nasby <[EMAIL PROTECTED]> writes:
> There's several problems with that. First, trace_sort isn't
> documented (or at least it's not in postgresql.conf), so most folks
> don't know it exists. Second, in order to see it's output you have to
> drop log_min_messages to debug. That results in a
On May 5, 2007, at 10:38 AM, Neil Conway wrote:
On Sat, 2007-05-05 at 11:03 -0400, Tom Lane wrote:
I'm not necessarily opposed to changing the default configure
selection,
but I am opposed to removing the FP code entirely.
I would be satisfied with changing the default to integer and
depreca
Dave Page wrote:
Bruce Momjian wrote:
The idea of the patch number in the subject line works with that
streaming model because it merely marks streams so they can be grouped.
The defining event that marks the stream is a post to the patches list.
We already number posts to the bugs list, so in
On May 6, 2007, at 9:32 AM, Tom Lane wrote:
Jim Nasby <[EMAIL PROTECTED]> writes:
There's several problems with that. First, trace_sort isn't
documented (or at least it's not in postgresql.conf), so most folks
don't know it exists. Second, in order to see it's output you have to
drop log_min_mes
On May 5, 2007, at 11:40 AM, Dave Page wrote:
Barring a few trivial details, that sounds almost identical to
what I
proposed.
Well, Andrew says everyone he talks to doesn't want it. They want a
more comprehensive solution that goes from bug to patch.
I don't recall him saying that, tho
Bruce Momjian wrote:
The idea of the patch number in the subject line works with that
streaming model because it merely marks streams so they can be grouped.
The defining event that marks the stream is a post to the patches list.
We already number posts to the bugs list, so in a way we could impr
22 matches
Mail list logo
