On Fri, 2006-01-06 at 16:13 -0500, Greg Stark wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
Before we start debating merits of proposals based on random reads, can
someone confirm that the sampling code actually does read randomly? I
looked at it yesterday; there is a comment that states
Simon Riggs wrote:
- yes, the random sampling is random - please read the code and comments
- yes, I would expect the results you get. If you sample 5% of rows and
each block has on average at least 20 rows, then we should expect the
majority of blocks to be hit.
and it seems from the
As per docs, if the databases are rarely updated it could take a long
time for the WAL segment to roll over.
Yes, therefore I want to copy the current WAL (as I said earlier).
When restoring, I also want to make sure that I restore exactely to the point
when I copied the current WA segment.
On Jan 8, 2006, at 12:12 , Larry Rosenman wrote:
I was thinking of handling the TODO for ISO8601 Interval output.
Just to be clear, you're talking about the ISO8601 duration syntax
(PnYnMnDTnHnMnS), correct? (The SQL standard made the unfortunate
choice to call durations, i.e.,
Greg Stark wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
The attached patch against cvs tip does seem to work. Instead of playing
with the environment, we simply allow perl to do its worst and then put
things back the way we wanted them.
How does that affect to the API calls
Michael Glaesemann wrote:
On Jan 8, 2006, at 12:12 , Larry Rosenman wrote:
I was thinking of handling the TODO for ISO8601 Interval output.
Just to be clear, you're talking about the ISO8601 duration syntax
(PnYnMnDTnHnMnS), correct? (The SQL standard made the unfortunate
choice to
Stefan,
well that is good news, can you tell me what version of linux you are using and
what gcc version also. I will let
Martin know.
Thanks
Jim
-- Original Message ---
From: Stefan Kaltenbrunner [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: pgsql-hackers
Jim Buttafuoco wrote:
Stefan,
first i would ask you to fix your mailserver setup because my last Mail
to you bounced with:
550 5.0.0 Sorry we don't accept mail from Austria
which makes it rather difficult for me to reply to your personal mail
well that is good news, can you tell me what
Stefan,
My mail admin has removed the Austria block, I guess we were getting spammed by
some one there. Can you send the output
of dpkg --list, so I can compare what packages you are using to what I have.
Thanks
Jim
-- Original Message ---
From: Stefan Kaltenbrunner [EMAIL
Simon Riggs [EMAIL PROTECTED] writes:
- yes, I would expect the results you get. If you sample 5% of rows and
each block has on average at least 20 rows, then we should expect the
majority of blocks to be hit.
These results are from my test program. 5% means 5% of 8k blocks from the test
Larry Rosenman wrote:
Michael Glaesemann wrote:
On Jan 8, 2006, at 12:12 , Larry Rosenman wrote:
I was thinking of handling the TODO for ISO8601 Interval output.
Just to be clear, you're talking about the ISO8601 duration syntax
(PnYnMnDTnHnMnS), correct? (The SQL standard made the
One more link...
this http://archives.postgresql.org/pgsql-patches/2003-12/msg00049.php
was the final draft of the patch I submitted, with docs patches, that
did not break backward computability (did not rip out the old syntax)
and supported both input and output of ISO-8601 compliant intervals
Ühel kenal päeval, P, 2006-01-08 kell 11:49, kirjutas Greg Stark:
Hannu Krosing [EMAIL PROTECTED] writes:
Interestingly I use pg_stat_activity view to watch for stuck backends,
stuck in the sense that they have not noticed when client want away
and are now waitin the TCP timeout to
These numbers don't make much sense to me. It seems like 5% is about as slow
as reading the whole file which is even worse than I expected. I thought I
was
being a bit pessimistic to think reading 5% would be as slow as reading 20%
of
the table.
I have a theory. My test program,
Andrew Dunstan [EMAIL PROTECTED] writes:
I don't know. Reading that code just makes my head spin ...
Yeah, too many ifdefs :-(. But I suppose that the initial
#ifdef LOCALE_ENVIRON_REQUIRED block is not compiled on sane
platforms, meaning that the first code in the routine is the
unconditional
On Sun, 2006-01-08 at 20:04 -0500, Tom Lane wrote:
On reflection I think that lookup_rowtype_tupdesc is simply misdesigned.
We can't have it handing back a pointer to a data structure of unspecified
lifetime. One possibility is to give it an API comparable to the
syscache lookup functions, ie
Neil Conway [EMAIL PROTECTED] writes:
On Sun, 2006-01-08 at 20:04 -0500, Tom Lane wrote:
On reflection I think that lookup_rowtype_tupdesc is simply misdesigned.
We can't have it handing back a pointer to a data structure of unspecified
lifetime. One possibility is to give it an API
On Sun, 8 Jan 2006, Tom Lane wrote:
Yeah, that's not very surprising. Running the forced-cache-resets
function will definitely expose that catcache bug pretty quickly.
You'd need to apply the patches I put in yesterday to have a system
that has any chance of withstanding that treatment for
Neil Conway [EMAIL PROTECTED] writes:
GetDomainConstraints() looks fairly expensive, so it would be nice to do
some caching. What would the best way to implement this be? I had
thought that perhaps the typcache would work, but there seems to be no
method to flush stale typcache data. Perhaps
Jeremy Drake [EMAIL PROTECTED] writes:
I ran without that function you made, and it got the error, but not a
crash. I stuck an Assert(false) right before the ereport for that
particular error, and I did end up with a core there, but I don't see
anything out of the ordinary (what little I know
Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
For #2, I'm not sure where the right place to check domain constraints
is. I was thinking about adding the check to the fmgr function call
logic[1], but the domain checking code needs an ExprContext in which to
evaluate the constraint,
Thomas Hallgren [EMAIL PROTECTED] writes:
Neil Conway [EMAIL PROTECTED] writes:
For #2, I'm not sure where the right place to check domain constraints
is.
Should I consider this as something to add to the PL/Java TODO list?
Yup, probably.
regards, tom lane
On Mon, 2006-01-09 at 20:23 +0100, Thomas Hallgren wrote:
Should I consider this as something to add to the PL/Java TODO list?
Probably, yes (if/when I fix the in-tree PLs I was planning to take a
look at all the externally-maintained ones, although you're welcome to
do it instead).
Before
On Mon, 9 Jan 2006, Tom Lane wrote:
Does your application drop these temp tables explicitly, or leave them
to be dropped automatically during commit? It might be interesting to
see whether changing that makes any difference.
I drop them explicitly at the end of the function.
I'm also
On Mon, 2006-01-09 at 12:57 -0500, Tom Lane wrote:
I have not been able to think of an efficient way to make it work while
still handing back a simple TupleDesc pointer --- seems like we'd have
to contort the API somehow so that the release function can find the
reference count. Any thoughts
Neil Conway [EMAIL PROTECTED] writes:
On Mon, 2006-01-09 at 12:57 -0500, Tom Lane wrote:
I have not been able to think of an efficient way to make it work while
still handing back a simple TupleDesc pointer --- seems like we'd have
to contort the API somehow so that the release function can
Tom,
My email to you was blocked.
Jim
-- Forwarded Message ---
From: Mail Delivery Subsystem [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sun, 8 Jan 2006 20:16:27 -0500
Subject: Returned mail: see transcript for details
- The following addresses had permanent fatal errors
On Mon, 2006-01-09 at 12:06 -0500, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I don't know. Reading that code just makes my head spin ...
Yeah, too many ifdefs :-(. But I suppose that the initial
#ifdef LOCALE_ENVIRON_REQUIRED block is not compiled on sane
platforms, meaning
Andrew Dunstan [EMAIL PROTECTED] writes:
On Mon, 2006-01-09 at 12:06 -0500, Tom Lane wrote:
We could just file a Perl bug report and wait for them to fix it.
What's the data risk?
Given that it took us this long to identify the problem, I'm guessing
that it doesn't affect too many people.
On Mon, 2006-01-09 at 14:51 -0500, Tom Lane wrote:
Nah, I don't think this works. The problem is that after an inval,
you may have to provide an updated TupleDesc to new callers while
old callers still have open reference counts to the old TupleDesc.
Good point.
However, you might be able
Neil Conway [EMAIL PROTECTED] writes:
Hmm, okay. There's the additional complication that we need to handle
record types (see RecordCacheArray in typcache.c). Since I don't think
we need reference counting for those,
Yeah, you do. See record_out for instance, and reflect on the fact that
it
Andrew Dunstan wrote:
Now, in src/include/port/win32.h we have this:
/*
* Supplement to sys/types.h.
*
* Perl already has conflicting defines for uid_t and gid_t.
*/
#ifndef PLPERL_HAVE_UID_GID
typedef int uid_t;
typedef int gid_t;
#else
/* These are redefined by perl. */
#define
Tom Lane wrote:
I'm just about out of ideas and right out of time to spend on this.
We could just file a Perl bug report and wait for them to fix it.
done
cheers
andrew
---(end of broadcast)---
TIP 4: Have you searched
Is there a TODO here, even if the Perl folks are supposed to fix it?
---
Andrew Dunstan wrote:
Tom Lane wrote:
I'm just about out of ideas and right out of time to spend on this.
We could just file a Perl
Bruce Momjian pgman@candle.pha.pa.us writes:
Is there a TODO here, even if the Perl folks are supposed to fix it?
When and if they fix it, it'd be useful for us to document the gotcha
someplace (not sure where, though). Maybe we should even go so far as
to refuse to work with older libperls on
It has probably been sufficiently mitigated on *nix. On Windows, the
choice seems to be between living with the risk and trying my put the
locales back where they were patch, which as Tom and Greg point out
might have other consequences. Take your pick.
cheers
andrew
Bruce Momjian wrote:
I can put it in the Win32 section of the TODO list. If we have
something not working on Win32, I would like to document it.
Is it:
plperl changes the locale in Win32?
---
Andrew Dunstan wrote:
It has probably
Bruce Momjian wrote:
I can put it in the Win32 section of the TODO list. If we have
something not working on Win32, I would like to document it.
Is it:
plperl changes the locale in Win32?
As long as the locale is consistent I think we're OK (is that right, Tom?)
Would that
Greg Stark [EMAIL PROTECTED] writes:
These numbers don't make much sense to me. It seems like 5% is about as
slow
as reading the whole file which is even worse than I expected. I thought
I was
being a bit pessimistic to think reading 5% would be as slow as reading
20% of
Martin,
I have installed the Sarge binutils on my testing/Etch system and all of the
Postgresql regression test pass. I
don't know where to go from here, any suggestions?
Jim
-- Original Message ---
From: Martin Pitt [EMAIL PROTECTED]
To: Jim Buttafuoco [EMAIL PROTECTED]
Bruce Momjian wrote:
Why do we need these defines at all? We don't use either of these types
anywhere in the plperl code.
Is the community perl different in what it does here from what the ActiveState
perl?
No idea, but if you don't need them, remove them so they work on your
Andrew Dunstan [EMAIL PROTECTED] writes:
As long as the locale is consistent I think we're OK (is that right, Tom?)
Right.
Would that mean not using any of initdb's locale settings?
Yeah, you'd want to not use the --locale switch for initdb, and also not
to change the system-wide locale
Greg Stark [EMAIL PROTECTED] writes:
Well my theory was sort of half right. It has nothing to do with fooling Linux
into thinking it's a sequential read. Apparently this filesystem was created
with 32k blocks. I don't remember if that was intentional or if ext2/3 did it
automatically based
43 matches
Mail list logo
