"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'
"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 "help
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 i
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
> http://archives.postgre
Btw -"unfound"?? I think the English there might need to be improved :)
Chris
On 1/11/07, Richard Huxton 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 failed to resta
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
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 g
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 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 s
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 diff
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
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
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=yak&dt=2007-01-11%2020:32:11
> http://
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
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 output
> >
> >
> >
>
>
> 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
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 W
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
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
On Thu, 2007-01-11 at 12:37 -0500, Bruce Momjian wrote:
> The trace probe was incorrect
Yes, incomplete, no doubt. On that point you were 100% right to reject.
> and kind of at an odd place. I don't
> think we want to go down the road of throwing trace in everwhere, do we?
> I would like to se
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 as
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 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 s
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 replaced.
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
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
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 whe
"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 be happy with
random checkpoint failures, either.
If we
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 -
On Thu, Jan 11, 2007 at 03:14:37PM -0500, Tom Lane wrote:
> The downside of this is that a real EACCES problem wouldn't get noted at
> any level higher than LOG, and so you could theoretically lose data
> without much warning. But I'm not seeing anything else we could do
> about it --- AFAIK we ha
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 prett
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
> per
"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
On Thu, Jan 11, 2007 at 12:35:25PM -0500, Tom Lane wrote:
> I think the real criterion has to be "is this probe useful to
> developers?". I'm entirely uninterested in adding probes that are
> targeted towards DBAs, as this one would have been --- if we think
> there's a problem that a DBA would ha
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 PathKeys
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
.. 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=yak&dt=2007-01-11%2020:32:11
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=snake&dt=2007-01-11%2018:30:01
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
Tom Lane wrote:
> "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
"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 ques
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
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
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
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 numeri
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;
>
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 runn
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 t
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.
> >
> >
"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 after the stat()
> then you cannot use DTrace, exc
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 wo
[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
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);
> >
"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
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
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
"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
Tom,
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
Dave
On 11-Jan-07, at 10:09 AM, Tom Lane wrote:
Dave Cramer <[EMAIL PROTECTED]> writes:
However I just loaded up an 8.2.1 and the defau
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 re
"Tom Lane" <[EMAIL PROTECTED]> writes:
> 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
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
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
> It shuold be the same - 10061 is the win32 error code. 274D is just the
> hex version of the same one.
Okay, changed this. Please test if you have a MinGW setup.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: mic
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 tha
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
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 funct
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?
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
paramete
"Tom Lane" <[EMAIL PROTECTED]> writes:
> "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 de
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.
>
> A
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 tha
"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
i
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 rev
On 1/11/07, Martijn van Oosterhout 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 show me the wa
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
>
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 sp
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 (b
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 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 bl
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Has anyone bothered to measure the overhead added by having to mask to
fetch or store the natts value? This is not a zero-cost improvement.
Tom, how should this be tested? I assume some loop of the same query
over an
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 y
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:
Con
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 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 yo
83 matches
Mail list logo
