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 ba
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 se
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
setup,
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]
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 readin
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 mea
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
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:
Bruce Momjian 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 Windows.
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
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 ou
Andrew Dunstan wrote:
> Now, in src/include/port/win32.h we have this:
>
> /*
> * Supplement to .
> *
> * 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. */
> #defin
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
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 abl
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 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
> platform
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 erro
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" funct
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 thou
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 cu
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 doma
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 la
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, wh
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
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. Perh
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 fo
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 c
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,
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
unconditio
I see that also, What I am testing now, it downgrading gcc to the sarge
versions. If it works on testing then I know
it's a gcc issue.
Jim
-- Original Message ---
From: Kurt Roeckx <[EMAIL PROTECTED]>
To: Stefan Kaltenbrunner <[EMAIL PROTECTED]>
Cc: pgsql-hackers , [EMAIL PRO
On Mon, 2006-01-09 at 11:03 -0500, Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > AFAICT, perl doesn't keep any state about locale settings, it just
> > reacts to whatever the current settings are, I think, but I could be wrong.
>
> If that's the case, why would it be bothering
> > 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
On Mon, Jan 09, 2006 at 03:03:28PM +0100, Stefan Kaltenbrunner wrote:
> >
> >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.
>
>
> lionfish is a stock Debian/Sarge box (a cobalt cube) with gcc 3.3.5.
Martin is
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> AFAICT, perl doesn't keep any state about locale settings, it just
> reacts to whatever the current settings are, I think, but I could be wrong.
If that's the case, why would it be bothering to issue setlocale during
startup at all? If you look in loc
Ü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 timeou
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
by
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 unfortun
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
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
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,
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
Sent: Mon, 09 Jan 2
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
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 call
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., lengths
> 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.
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 benchma
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 t
47 matches
Mail list logo
