On Thu, Jan 11, 2007 at 08:41:24AM +0100, Michael Meskes wrote:
While I'm whining ... we really need some support in the ecpg regression
tests for platform-specific diffs, so that the consistent ECPG-check
failures in buildfarm can go away.
Hmm, I thought there was. Joachim, could you
Possibly, to merge the two programs. I'm intending to put some time into
the append and seperating globals items, but I don't think I have the
time to merge the apps given Tom's concerns and some further investigation.
Regards, Dave.
Bruce Momjian wrote:
Is there a TODO here?
On Thu, Jan 11, 2007 at 09:51:11AM +0100, Joachim Wieland wrote:
There are, see for example
ecpg/test/expected/compat_informix-dec_test-MinGW32.stdout
AFAIK there were no other platforms except for MinGW that need special
treatment.
Talking about MinGW, do all MinGW systems return:
Hi Johnny,
I must say, I was really fascinated by this. This is almost a
multi-master replication, although with a lot of grey areas. I had re
On 12/21/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Couldnt find a replication system that worked and did what I wanted, so I
made one.
If
On Thu, Jan 11, 2007 at 12:58:01AM -0500, Jaime Casanova wrote:
Hi,
i'm trying to share some info between backends but i cannot figure how
to do it...
i was reading bgwriter.c and autovacuum.c hoping there is something
that can show me the way to go...
Well, there's a shared memory block,
On 12/21/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
If you would like to give my humble creation a try...
http://spar.orgfree.com/index.html
Hi Johnny,
I must say, I was really fascinated by the idea. This is almost a
multi-master replication, although with a lot of grey areas. I
On Thu, Jan 11, 2007 at 10:49:59AM +0100, Michael Meskes wrote:
On Thu, Jan 11, 2007 at 09:51:11AM +0100, Joachim Wieland wrote:
There are, see for example
ecpg/test/expected/compat_informix-dec_test-MinGW32.stdout
AFAIK there were no other platforms except for MinGW that need special
On 1/11/07, Martijn van Oosterhout kleptog@svana.org wrote:
On Thu, Jan 11, 2007 at 12:58:01AM -0500, Jaime Casanova wrote:
Hi,
i'm trying to share some info between backends but i cannot figure how
to do it...
i was reading bgwriter.c and autovacuum.c hoping there is something
that can
Jaime Casanova wrote:
i'm trying to fix a problem related to the patch Albert sent in
october (Tablespace for temporary objects and sort files)
http://archives.postgresql.org/pgsql-patches/2006-10/msg00141.php
http://archives.postgresql.org/pgsql-patches/2007-01/msg00063.php
after reviewing
Assuming a working xml type, what do you think the future of the
contrib/xml2 module should be?
At the moment, I'd imagine that we add duplicate versions of most
functions, where appropriate, that use the xml type instead of the text
type. Perhaps we should supply two sets of SQL files, so
Currently says
Number of disk-page buffers allocated in shared memory for WAL data.
The default is 8. The setting need only be large enough to hold the
amount of WAL data generated by one typical transaction, since the
data is written out to disk at every transaction commit. This
Duplicate versions of functions (e.g., there would be XMLPATH() as the main
XPath function for XML type, producing arrays of values of XML type in
general case -- non-standard, but generalized).
In addition to two SQL files for registration of module functions in
database, I would move XSLT
Dave Cramer [EMAIL PROTECTED] writes:
However I just loaded up an 8.2.1 and the default is 32m
Then you changed it in postgresql.conf. I get
$ psql
Welcome to psql 8.2.1, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
On 1/11/07, Nikolay Samokhvalov [EMAIL PROTECTED] wrote:
Duplicate versions of functions (e.g., there would be XMLPATH() as the
main XPath function for XML type, producing arrays of values of XML type in
general case -- non-standard, but generalized).
Sorry :-) I wanted to say I suppose that
On Sat, Jan 06, 2007 at 01:37:03PM +0100, Joachim Wieland wrote:
Attached is a patch that adds a --regression option to ecpg. I replaced the
manual checking for long options (--version and --help) by a call to
...
Applied. I also changed the regression handling in other places. Guys,
please
Joachim Wieland [EMAIL PROTECTED] writes:
On guppy the ecpg checks trigger the OpenBSD bug that Michael and Stefan
identfied here:
http://archives.postgresql.org/pgsql-hackers/2006-09/msg00593.php
Not sure what to do about it, we could diff it away to get it green but it
would not solve the
On 1/4/07, Andrew Dunstan [EMAIL PROTECTED] wrote:
Gavin Sherry wrote:
On Thu, 4 Jan 2007 [EMAIL PROTECTED] wrote:
1. Pull source directly from repositories (cvs, git, etc.) PLM
doesn't really track actually scm repositories. It requires
directories of source code to be traversed, which
[EMAIL PROTECTED] wrote:
I am not clear about what is being proposed. Currently buildfarm syncs
against (or pulls a fresh copy from, depending on configuration) either
the main anoncvs repo or a mirror (which you can get using cvsup or
rsync,
among other mechanisms). I can imagine a mechanism
Dave Page wrote:
Possibly, to merge the two programs. I'm intending to put some time into
the append and seperating globals items, but I don't think I have the
time to merge the apps given Tom's concerns and some further investigation.
Yes, I was just wondering if an append mode for Win32
Dave Cramer [EMAIL PROTECTED] writes:
the point is that the documentation suggests that the default is 8
not 8MB, but 8, when in fact the defaults are now given in memory
units not pages
Oh, I thought you were complaining that the value was numerically wrong.
Perhaps we should convert the
No, I've not tried yet. Inaam-san told me that Linux had a few I/O
schedulers but I'm not familiar with them. I'll find information
about them (how to change the scheduler settings) and try the same
test.
I am sorry, your response just slipped by me. The docs for RHEL (I believe
you are
Tom Lane wrote:
I notice that the latest pgindent run has decided that comments attached
to else should be moved onto the next line, as in this example in
src/bin/psql/mbprint.c:
{
linewidth += 4;
On 11-Jan-07, at 12:49 PM, Tom Lane wrote:
Dave Cramer [EMAIL PROTECTED] writes:
the point is that the documentation suggests that the default is 8
not 8MB, but 8, when in fact the defaults are now given in memory
units not pages
Oh, I thought you were complaining that the value was
On Fri, 2007-01-05 at 17:52 -0500, Tom Lane wrote:
I think this will be an exercise in time-wasting, and very possibly
destabilize *both* tools. pg_dump has never been designed to reconnect
to a different database; for instance there isn't any code for resetting
all the internal state that it
Patrick Earl [EMAIL PROTECTED] writes:
In any case, the unit tests remove all contents and schema within the
database before starting, and they remove the tables they create as
they proceed. Certainly there are many things have been recently
deleted.
Yeah, I think then there's no question
I've been looking at improving the planner so that it can handle things
like backwards-order mergejoins, and I'm starting to realize that the
old assumption that mergejoinable operators had only one associated sort
ordering is wired into even more places than I thought. In particular,
the
Magnus Hagander [EMAIL PROTECTED] writes:
I find it very unlikely that you would during normal operations end up
in a situation where you would first have permissions to create files in
a directory, and then lose them.
What could be is that you have a directory where you never had
permissions
I'm seeing the following on cuckoo:
gcc -pipe -no-cpp-precomp -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Winline -Wdeclaration-after-statement -Wendif-labels
-fno-strict-aliasing -g -dynamiclib -install_name
/Users/buildfarm/buildfarm/HEAD/inst/lib/libecpg.5.dylib
-compatibility_version 5
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
I find it very unlikely that you would during normal operations end up
in a situation where you would first have permissions to create files in
a directory, and then lose them.
What could be is that you have a directory where you never
On Thu, Jan 11, 2007 at 04:32:42PM -0500, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
Given that this could result in data loss, if this was to be done I'd
very much want to see a way to disable it in a production environment.
Production environments are the same ones that won't
On Thu, 11 Jan 2007, Tom Lane wrote:
...snip...
(You know, of course, that my opinion is that no sane person would run a
production database on Windows in the first place. So the data-loss
risk to me seems less of a problem than the unexpected-failures problem.
It's not like there aren't a
Hello all,
I have a feature request as I think it is not possible with the actual version:
I want to load huge amount of data and I know that COPY is much faster than
doing inserts.
But in my case I have an already filled table and rows (not all, only partly)
from this table
should be
On Thu, Jan 11, 2007 at 04:03:55PM -0500, Tom Lane wrote:
I've been looking at improving the planner so that it can handle things
like backwards-order mergejoins, and I'm starting to realize that the
old assumption that mergejoinable operators had only one associated sort
ordering is wired
I caught this thread about O_DIRECT on kerneltrap.org:
http://kerneltrap.org/node/7563
It sounds like there is much to be gained here in terms of reducing
the number of user/kernel space copies in the operating system. I got
the impression that posix_fadvise in the Linux kernel isn't as good
Richard Troy wrote:
On Thu, 11 Jan 2007, Tom Lane wrote:
...snip...
(You know, of course, that my opinion is that no sane person would run a
production database on Windows in the first place. So the data-loss
risk to me seems less of a problem than the unexpected-failures problem.
It's not
Please don't. At least not on the PostgreSQL web site nor in the docs.
And no, I don't run my production servers on Windows either.
It does seem like it might be a good idea to have FAQs based on each OS,
yes? There are various things that effect each OS differently. The most
On Thu, Jan 11, 2007 at 09:59:14PM +0100, Magnus Hagander wrote:
.. appears to have killed win32. It did kill my manual MSVC builds, but
it also seems to have killed win32 buildfarm members yak and snake:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=yakdt=2007-01-11%2020:32:11
On Thu, Jan 11, 2007 at 03:12:07PM -0800, Joshua D. Drake wrote:
It does seem like it might be a good idea to have FAQs based on each OS,
yes? There are various things that effect each OS differently. The most
obvious to me being shared memory and wal_sync_method.
If could be a good idea to
On Thu, Jan 11, 2007 at 01:15:56PM +0100, Magnus Hagander wrote:
Can't comment on that one, since I just noticed it existed. How similar
was this one to the standard regression tests? Those were moved into a
C executable so they'd run on a Windows system without a shell, could
the same be done
On Wed, 2007-01-10 at 23:32 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
On Fri, 2007-01-05 at 22:57 -0500, Tom Lane wrote:
Jim Nasby [EMAIL PROTECTED] writes:
On Jan 5, 2007, at 6:30 AM, Zeugswetter Andreas ADI SD wrote:
Ok, so when you need CRC's on a replicate (but not on the
Simon Riggs [EMAIL PROTECTED] writes:
COPY XLogInsert() #1 on oprofile results at 17% CPU
(full_page_writes = on)
But what portion of that is actually CRC-related? XLogInsert does quite
a lot.
Anyway, I can't see degrading the reliability of the system for a gain
in the
On Thu, 2007-01-11 at 09:01 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
COPYXLogInsert() #1 on oprofile results at 17% CPU
(full_page_writes = on)
But what portion of that is actually CRC-related? XLogInsert does quite
a lot.
Anyway, I
Gregory Stark [EMAIL PROTECTED] writes:
What did you think about protecting against torn writes using id numbers every
512 bytes.
Pretty much not happening; or are you volunteering to fix every part of
the system to tolerate injections of inserted data anywhere in a stored
datum?
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Pretty much not happening; or are you volunteering to fix every part of
the system to tolerate injections of inserted data anywhere in a stored
datum?
I was thinking to do it at a low level as the xlog records are
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Pretty much not happening; or are you volunteering to fix every part of
the system to tolerate injections of inserted data anywhere in a stored
datum?
I was thinking to do it at a
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
You understand wrong ... a tuple sitting on disk is normally read
directly from the shared buffer, and I don't think we want to pay for
copying it.
xlog records
Oh, sorry, had the wrong context in mind. I'm still
Tom Lane [EMAIL PROTECTED] writes:
Oh, sorry, had the wrong context in mind. I'm still not very impressed
with the idea --- a CRC check will catch many kinds of problems, whereas
this approach catches exactly one kind of problem.
Well in fairness I tossed in a throwaway comment at the end
On Tue, 2007-01-09 at 17:16 -0500, Bruce Momjian wrote:
Tom Lane wrote:
/* reset flag so that die() interrupt won't cause
problems */
vfdP-fdstate = ~FD_TEMPORARY;
+ PG_TRACE1(temp__file__cleanup, vfdP-fileName);
+
Simon Riggs wrote:
Also, I dunno much about DTrace, but I had the idea that you can't
simply throw a PG_TRACE macro into the source and think you are done
--- isn't there a file of probe declarations to add to? Not to mention
the documentation of what probes exist.
I didn't like
On Thu, 2007-01-11 at 12:35 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Tom Lane wrote:
The TRACE is in the wrong place no? I thought it was going to be after
the stat() operation so it could pass the file size.
We had that discussion already. If you only pass it
On Thu, 2007-01-11 at 17:06 +, Gregory Stark wrote:
Having a CRC in WAL but not in the heap seems kind of pointless.
Yes...
If your
hardware is unreliable the corruption could anywhere.
Agreed.
Other DBMS have one setting for the whole server; I've never seen
separate settings for WAL
On Wed, 2007-01-10 at 16:00 -0500, Steven Flatt wrote:
On 1/9/07, Simon Riggs [EMAIL PROTECTED] wrote:
If you are doing date range partitioning it should be fairly
simple to
load data into the latest table directly. That was the way I
originally
Kim [EMAIL PROTECTED] writes:
We were running on 8.1.1 previous to upgrading to 8.2, and yes, we
definitely have a heafty pg_class. The inheritance model is heavily used
in our schema (the results of the group by you wanted to see are down
below). However, no significant problems were seen
Tom Lane wrote:
What I think we need to do about this is
(1) fix pgstat_vacuum_tabstats to have non-O(N^2) behavior; I'm thinking
of using a hash table for the OIDs instead of a linear list. Should be
a pretty small change; I'll work on it today.
(2) Reconsider whether last-vacuum-time
On Thu, 2007-01-11 at 14:45 -0500, Tom Lane wrote:
Kim [EMAIL PROTECTED] writes:
We were running on 8.1.1 previous to upgrading to 8.2, and yes, we
definitely have a heafty pg_class. The inheritance model is heavily used
in our schema (the results of the group by you wanted to see are
On Thu, Jan 11, 2007 at 12:15:50PM +, Simon Riggs wrote:
On Wed, 2007-01-10 at 16:00 -0500, Steven Flatt wrote:
On 1/9/07, Simon Riggs [EMAIL PROTECTED] wrote:
If you are doing date range partitioning it should be fairly
simple to
load data into the latest
Simon Riggs [EMAIL PROTECTED] writes:
It's not clear to me how this fix will alter the INSERT issue Kim
mentions.
I didn't say that it would; we have no information on the INSERT issue,
so I'm just concentrating on the problem that he did provide info on.
(BTW, I suppose the slow-\d issue is
On Thu, Jan 11, 2007 at 04:49:28PM -0300, Alvaro Herrera wrote:
Tom Lane wrote:
What I think we need to do about this is
(1) fix pgstat_vacuum_tabstats to have non-O(N^2) behavior; I'm thinking
of using a hash table for the OIDs instead of a linear list. Should be
a pretty small
I wrote:
(2) Reconsider whether last-vacuum-time should be sent to the collector
unconditionally.
Actually, now that I look, the collector already contains this logic:
/*
* Don't create either the database or table entry if it doesn't already
* exist. This avoids bloating the
Our pgstats.stat file is 40M for 8.2, on 8.1 it was 33M. Our schema size
hasn't grown *that* much in the two weeks since we upgraded
I'm not sure if this sheds any more light on the situation, but in
scanning down through the process output from truss, it looks like the
first section of
On Thu, 2007-01-11 at 16:11 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
It's not clear to me how this fix will alter the INSERT issue Kim
mentions.
I didn't say that it would; we have no information on the INSERT issue,
so I'm just concentrating on the problem that he did
Joshua D. Drake wrote:
Please don't. At least not on the PostgreSQL web site nor in the docs.
And no, I don't run my production servers on Windows either.
It does seem like it might be a good idea to have FAQs based on each OS,
yes? There are various things that effect each OS
On Thu, Jan 11, 2007 at 09:42:38PM -0300, Alvaro Herrera wrote:
But we have per-platform FAQs. If there is information missing, the
reason is that nobody has submitted an appropriate patch, nothing more.
where are these FAQs, and why were they not easily found when the original
poster sent
On Thu, 2007-01-11 at 21:42 -0300, Alvaro Herrera wrote:
Joshua D. Drake wrote:
Please don't. At least not on the PostgreSQL web site nor in the docs.
And no, I don't run my production servers on Windows either.
It does seem like it might be a good idea to have FAQs based on each
postgres=# select 'NaN'::numeric = 'NaN'::numeric,
'NaN'::float8 = 'NaN'::float8;
?column? | ?column?
--+--
t| t
(1 row)
This behavior is inconsistent with most people's notion of NaN -- in
particular, it is inconsistent with IEEE754. I can understand
Btw -unfound?? I think the English there might need to be improved :)
Chris
On 1/11/07, Richard Huxton dev@archonet.com wrote:
Warren Guy wrote:
Hi everyone
Was running a VACUUM on a database on a partition which was running out
of disk space. During VACUUM the server process died and
On 1/11/07, Andrew Dunstan [EMAIL PROTECTED] wrote:
Jaime Casanova wrote:
i'm trying to fix a problem related to the patch Albert sent in
october (Tablespace for temporary objects and sort files)
http://archives.postgresql.org/pgsql-patches/2006-10/msg00141.php
Jim C. Nasby [EMAIL PROTECTED] writes:
I'm seeing the following on cuckoo:
-L/opt/local/lib -lpgtypes -lpq -lm -o libecpg.5.3.dylib
ld: Undefined symbols:
_ecpg_internal_regression_mode
/usr/bin/libtool: internal link edit command failed
It looks like Joachim's last patch thinks it's OK for
Jim C. Nasby [EMAIL PROTECTED] writes:
On Thu, Jan 11, 2007 at 03:14:37PM -0500, Tom Lane wrote:
... And anyway there should never
*be* a real permissions problem; if there is then the user's been poking
under the hood sufficient to void the warranty anyway ;-)
Or some other helpful process
Simon Riggs wrote:
Temp relations still make pg_class entried don't they? Is that on the
TODO list to change?
Yeah, and pg_attribute entries as well, which may be more problematic
because they are a lot. Did we get rid of pg_attribute entries for
system attributes already?
Can we actually
Alvaro Herrera [EMAIL PROTECTED] writes:
Can we actually get rid of pg_class entries for temp tables. Maybe
creating a temp pg_class which would be local to each session? Heck,
it doesn't even have to be an actual table -- it just needs to be
somewhere from where we can load entries into the
71 matches
Mail list logo
