Tom Lane wrote:
> I'm also not totally clear on whether we are happy with the Windows
> locale situation yet. Comments from the Win32 contingent?
I'm happy that UTF-8 support is now working again, but not happy that
initdb and pg_control will report (for example) "English_United
Kingdom.1252" des
On Mon, Oct 22, 2007 at 08:59:07AM +0100, Dave Page wrote:
> Tom Lane wrote:
> > I'm also not totally clear on whether we are happy with the Windows
> > locale situation yet. Comments from the Win32 contingent?
>
> I'm happy that UTF-8 support is now working again, but not happy that
> initdb and
Alvaro Herrera wrote:
> Tom Lane wrote:
>
>> ISTM that perhaps a more generally useful definition would be
>>
>> lwordOnly ASCII letters
>> nlword Entirely letters per iswalpha(), but not lword
>> word Entirely alphanumeric per iswalnum(), but not nlword
>>
> Alvaro Herrera wrote:
> > Tom Lane wrote:
> >
> >> ISTM that perhaps a more generally useful definition would be
> >>
> >> lword Only ASCII letters
> >> nlword Entirely letters per iswalpha(), but not lword
> >> word Entirely alphanumeric per iswalnum(), bu
On Mon, 22 Oct 2007, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
On Sunday, October 21, 2007 22:38:04 -0400 Tom Lane <[EMAIL PROTECTED]>
wrote:
I've posted notes over the past few days about half a dozen relatively-
minor-but-none-the-less-initdb-forcing issues in tsearch.
This change in pgbench.c:
revision 1.71
date: 2007-08-25 10:21:14 +0100; author: ishii; state: Exp; lines: +7 -2;
The upper limit for -c option of pgbench is now obtained from
(FD_SETSIZE - 10) rather than a hardwired number.
Turns out to be, perhaps, ill-advised on Windows where FD_S
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> Tom Lane wrote:
>>
>>> ISTM that perhaps a more generally useful definition would be
>>>
>>> lword Only ASCII letters
>>> nlword Entirely letters per iswalpha(), but not lword
>>> word
On Mon, Oct 22, 2007 at 11:11:47AM +0100, Gregory Stark wrote:
>
> This change in pgbench.c:
>
> revision 1.71
> date: 2007-08-25 10:21:14 +0100; author: ishii; state: Exp; lines: +7 -2;
> The upper limit for -c option of pgbench is now obtained from
> (FD_SETSIZE - 10) rather than a h
"Oleg Bartunov" <[EMAIL PROTECTED]> writes:
> ts_debug is a really debug function and could be changed. Btw, it doesn't
> supports thesaurus dictionaries, so it should be rewritten in C.
I would think things like ts_debug (and ts_stat?) which are handy support
modules but not fundamentally part o
2007/10/22, Gregory Stark <[EMAIL PROTECTED]>:
> "Oleg Bartunov" <[EMAIL PROTECTED]> writes:
>
> > ts_debug is a really debug function and could be changed. Btw, it doesn't
> > supports thesaurus dictionaries, so it should be rewritten in C.
>
> I would think things like ts_debug (and ts_stat?) whi
Hi all,
I'm working for a brazillian company developing and maintaining a ERP sw
that uses PostgreSQL as it main OLTP database system. We're just to start
the migration to IBM DB2 because of many performance issues.
I searched the solution for these performance problems, and can't find
anything
> 2) The constraint doesn't exist on the master, only the slave, so I don't
> beleive EXECUTE SCRIPT will work, no?
No, it does not work. I've tried.
// John
_
John Parnefjord
Samordnare UBIT Utveckling / Coordinator UBIT Development
Tiago J. Adami wrote:
> The issue topics:
> 1) As the database grows on our customers, lower performance occurs. After
> one week of use, the I/O on database is extremely high. It appears that
> VACUUM FULL and/or VACUUM ANALYZE doesn't work on this databases.
That sounds like a classic case of "y
On 10/21/07, Josh Berkus <[EMAIL PROTECTED]> wrote:
> Bruce Momjian wrote:
> > We have had very few beta1 issues. I am thinking we should release
> > beta2 next week and perhaps accelerate beta and consider a final release
> > in November rather than December. Because of the length of our feature
"Tiago J. Adami" <[EMAIL PROTECTED]> writes:
> The issue topics:
> 1) As the database grows on our customers, lower performance occurs. After
> one week of use, the I/O on database is extremely high. It appears that
> VACUUM FULL and/or VACUUM ANALYZE doesn't work on this databases.
VACUUM FULL i
Tiago J. Adami schreef:
Hi all, I'm working for a brazillian company developing and
maintaining a ERP sw that uses PostgreSQL as it main OLTP database
system. We're just to start the migration to IBM DB2 because of many
performance issues. I searched the solution for these performance
problems
On Sunday 21 October 2007 22:38, Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > Bruce Momjian wrote:
> >> Nothing motivates people to test more than moving toward RC1. ;-)
> >
> > Getting Beta2 out is vital to actually getting people to test there are
> > known issues and chan
Hello,
I've installed on a windows xp machine beta 1 of postgresql 8.3 and pgadmin III
1.8.
I've loaded a backup of a database from a 8.2.5 machine, for testing purpose,
and tried
the new functionality of plpgsql debug of functions.
But I was disappointed to see that does not work.
I try to deb
Roberto Icardi wrote:
> Hello,
>
> I've installed on a windows xp machine beta 1 of postgresql 8.3 and
> pgadmin III 1.8.
> I've loaded a backup of a database from a 8.2.5 machine, for testing
> purpose, and tried
> the new functionality of plpgsql debug of functions.
>
> But I was disappointed
Gregory Stark a écrit :
"Tiago J. Adami" <[EMAIL PROTECTED]> writes:
The issue topics:
1) As the database grows on our customers, lower performance occurs. After
one week of use, the I/O on database is extremely high. It appears that
VACUUM FULL and/or VACUUM ANALYZE doesn't work on this dat
On Mon, Oct 22, 2007 at 09:25:03AM -0400, Robert Treat wrote:
> On Sunday 21 October 2007 22:38, Tom Lane wrote:
> > "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > > Bruce Momjian wrote:
> > >> Nothing motivates people to test more than moving toward RC1. ;-)
> > >
> > > Getting Beta2 out is vi
Dave,
the problem isn't with a particular function. Debug does not work with every
function I try, even with the simplest one, always with the same behaviour I've
previously explained.
I repeat, my postgresql server is an 8.3 beta 1 installed on the same machine
where pgadmin III 1.8 is insta
The program below works with PostgreSQL 8.0.3, but not 8.1.10. The
error I receive is:
Runtime Error!
Program: C:\testSQL.exe
This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
This happ
Roberto Icardi wrote:
> Dave,
>
> the problem isn't with a particular function. Debug does not work with
> every function I try, even with the simplest one, always with the same
> behaviour I've previously explained.
> I repeat, my postgresql server is an 8.3 beta 1 installed on the same
> machin
Magnus Hagander <[EMAIL PROTECTED]> writes:
> On Mon, Oct 22, 2007 at 08:59:07AM +0100, Dave Page wrote:
>> From chatting with Magnus, I believe he'd support losing the .1252 or
>> leaving it as is, where I'd rather rewrite it to .65001 (which he does
>> not support).
> I'm not against stripping t
Yes, they are all there
I've also tried on a newly created database instead of testing on a restored
from 8.2. backup but with
the same behaviour :-(
- Original Message -
From: "Dave Page" <[EMAIL PROTECTED]>
To: "Roberto Icardi" <[EMAIL PROTECTED]>
Cc:
Sent: Monday, October 22,
Le lundi 22 octobre 2007, Robert Treat a écrit :
> There was talk that the txid contrib module could be folded into core
> should we do an initdb post beta; has that idea been revisted now that we
> have?
It very well seem to have been integrated into core:
http://repo.or.cz/w/PostgreSQL.git?a=co
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> On Mon, Oct 22, 2007 at 08:59:07AM +0100, Dave Page wrote:
>>> From chatting with Magnus, I believe he'd support losing the .1252 or
>>> leaving it as is, where I'd rather rewrite it to .65001 (which he does
>>> not support).
>
>> I'
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> lwordEntirely letters per iswalpha, with at least one ASCII
>> nlword Entirely letters per iswalpha
>> word Entirely alphanumeric per iswalnum, but not nlword
> I don't like this categ
Roberto Icardi wrote:
> Yes, they are all there
> I've also tried on a newly created database instead of testing on a
> restored from 8.2. backup but with
> the same behaviour :-(
Please post the definition of an affected function, along with the
output from the following queries:
select * fr
On Mon, Oct 22, 2007 at 03:18:38PM +0100, Dave Page wrote:
> Tom Lane wrote:
> > Magnus Hagander <[EMAIL PROTECTED]> writes:
> >> On Mon, Oct 22, 2007 at 08:59:07AM +0100, Dave Page wrote:
> >>> From chatting with Magnus, I believe he'd support losing the .1252 or
> >>> leaving it as is, where I'd
I've requested this before without response, but I'm asking again
because it just caused me pain again: could we get a TODO added to
have the planner recognize equivalent IN and EXISTS constructs and
have them compete on cost estimates? I know it's not a trivial
improvement, but if it's on the lis
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
>> I like the "aword" name more than "lword", BTW. If we change the meaning
>> of the classes, surely we can change the name as well, right?
> I'm not very familiar with the use case here. Is there a good
Please post the definition of an affected function, along with the
output from the following queries:
select * from pldbg_get_proxy_info();
select * from pldbg_get_target_info('16480', 'o');
(where 16480 is replaced with the oid of the affected function).
Thanks, Dave
CREATE OR REPLACE FUN
On 10/21/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> > I tried generating idle connections in an effort to reproduce
> > Laurent's problem, but I ran into a local limit instead: for each
> > backend, postmaster creates a thread and burns 4MB of its 2GB address
> > space. It fails around 490.
Magnus Hagander <[EMAIL PROTECTED]> writes:
> As I chatted with Dave about - wnat encoding? We pull that value cluster
> wide, but the encoding is per-database. You could have one UTF8 and one
> WIN1252 database...
Will chklocale.c actually allow that? Should it? We've spent a lot of
time zeroed
Joshua D. Drake wrote:
> Josh Berkus wrote:
> > Bruce Momjian wrote:
> >> Those who have been with the community from long ago might remember
> >> discussion about implementing a undo log. The big advantage of this is
> >> that it allows UPDATE to _replace_ rows and limits the amount of cleanup
>
On Mon, Oct 22, 2007 at 10:55:14AM -0400, Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > As I chatted with Dave about - wnat encoding? We pull that value cluster
> > wide, but the encoding is per-database. You could have one UTF8 and one
> > WIN1252 database...
>
> Will chklocal
Roberto Icardi wrote:
> CREATE OR REPLACE FUNCTION public.prova(provain character varying)
> RETURNS character varying AS
> $BODY$
> begin
> if (provain = 'A') then
>return 'INVALIDO';
> else
>return 'VALIDO';
> end if;
> end;
> $BODY$
> LANGUAGE 'plpgsql' VOLATILE
> COST 100;
> ALTER
On Mon, 22 Oct 2007 12:07:06 +0100
Gregory Stark <[EMAIL PROTECTED]> wrote:
> "Oleg Bartunov" <[EMAIL PROTECTED]> writes:
>
> > ts_debug is a really debug function and could be changed. Btw, it
> > doesn't supports thesaurus dictionaries, so it should be rewritten
> > in C.
>
> I would think thi
- Original Message -
From: "Roberto Icardi" <[EMAIL PROTECTED]>
To: "Dave Page" <[EMAIL PROTECTED]>
Sent: Monday, October 22, 2007 5:31 PM
Subject: Re: [HACKERS] pgadmin debug on windows
When you attempt to debug it, do you see the parameter dialogue before
it crashes, or does it go
Hello,
I have a problem. Because some changes I made in the implementation of the
creation of indexes at the time that I try to insert an index is the
following error:
"bogus pg_index tuple"
What can be happening?
Thank,
--
Pedro Belmino.
---
Pedro Belmino wrote:
> I have a problem. Because some changes I made in the implementation of the
> creation of indexes at the time that I try to insert an index is the
> following error:
> "bogus pg_index tuple"
> What can be happening?
Obviously you broke something with the changes. That error m
Hello,
Yes, I've searched though the archives and can't seem to find the answer I'm
looking for.
I would like to modify the PostgreSQL Setup Wizard to only display certain
options. Only provide the user with one option as oppose to a number. i.e.
Driver: ODBC.
Which directory are
Bruce,
We never actually considred undo, but high UPDATE activity was one of
the areas we historically handled poorly compared to undo systems, and
undo would have been one way to improve that area. I think with HOT we
have improved high UPDATE activity enough that the undo benefits are no
long
Kath,
Which directory are the files located in, after having successfully
installed PostgreSQL on my PC. How can I access the source code of these
files? Is it possible to extract the files from postgresql-8.2.exe
windows installer package?
You need to join the mailing list of the pgInstalle
On Mon, 2007-10-22 at 09:31 -0500, Kevin Grittner wrote:
> I've requested this before without response, but I'm asking again
> because it just caused me pain again: could we get a TODO added to
> have the planner recognize equivalent IN and EXISTS constructs and
> have them compete on cost estimate
For planning purposes, I think its always a good idea to lay down some
dates for the next lot of development milestones. These can be
provisional, until declared solid later.
So: When is the next Feature Freeze?
Is it March 31? If not, when?
I know the answer is "too early to tell for certain",
Florian Weimer wrote:
> * Magnus Hagander:
>
>> Oh, that's interesting. That's actually a sideeffect of us increasing
>> the stack size for the postgres.exe executable in order to work on other
>> things. By default, it burns 1MB/thread, but ours will do 4MB. Never
>> really thought of the problem
On Mon, 22 Oct 2007 19:43:28 +0100
Simon Riggs <[EMAIL PROTECTED]> wrote:
> For planning purposes, I think its always a good idea to lay down some
> dates for the next lot of development milestones. These can be
> provisional, until declared solid later.
We can't not realistically consider this u
Magnus Hagander wrote:
> On Wed, Oct 17, 2007 at 11:27:10AM -0400, Tom Lane wrote:
>> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>>> There's legitimate use for creating a role with NOLOGIN and a password.
>> If we think that, then we shouldn't have a message at all.
>
> At least if we think it
* Magnus Hagander:
> Oh, that's interesting. That's actually a sideeffect of us increasing
> the stack size for the postgres.exe executable in order to work on other
> things. By default, it burns 1MB/thread, but ours will do 4MB. Never
> really thought of the problem that it'll run out of address
On Thu, Sep 13, 2007 at 02:02:14PM -0700, Neil Conway wrote:
> On Fri, 2007-09-07 at 08:29 -0500, Kenneth Marshall wrote:
> > This is a great starting point. I would appreciate it if you have the
> > time and could make it apply cleanly to HEAD.
>
> Just to give you an update on this, I'll try to
On Mon, 2007-10-22 at 11:53 -0700, Joshua D. Drake wrote:
> On Mon, 22 Oct 2007 19:43:28 +0100
> Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> > For planning purposes, I think its always a good idea to lay down some
> > dates for the next lot of development milestones. These can be
> > provisional, u
Trevor Talbot wrote:
> On 10/21/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
>
>>> I tried generating idle connections in an effort to reproduce
>>> Laurent's problem, but I ran into a local limit instead: for each
>>> backend, postmaster creates a thread and burns 4MB of its 2GB address
>>> spa
Roberto Icardi wrote:
>> When you attempt to debug it, do you see the parameter dialogue before
>> it crashes, or does it go immediately?
>>
>
> if I try debug->debug it goes immediately
> if I try debug->set breakpoint I can see debugger window but is
> completely empty and inactive
>
>
>
>> A
Simon,
> We can issue a provisional date. We could also say "at least 6 months
> after release date of 8.3". I'm sure there's other options too.
I'm going to suggest 4 months after 8.3. 8.3 was supposed to be a *short*
release so that we could move our calendar around. HOT and some of the
oth
Josh Berkus wrote:
> In fact, I could see doing a "no-catalog-changes, no major patches we don't
> already know about, 6-month release". It would reset our cycle and get
> PL/proxy, DSM, clustered indexes, etc. out the door. It could mean
> turning away patches which look attractive, though,
Josh Berkus wrote:
So my thought is, shoot for a short release so that we can get away from
summer consolidations and December releases, and extend the cycle if
someone dumps another 50,000 lines of attractive patches on us.
Before we settle on any dates I think we should have some disc
On Mon, 22 Oct 2007 16:47:41 -0300
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Josh Berkus wrote:
>
> > In fact, I could see doing a "no-catalog-changes, no major patches
> > we don't already know about, 6-month release". It would reset our
> > cycle and get PL/proxy, DSM, clustered indexes, etc
On 10/22/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> Trevor Talbot wrote:
> > I'd probably take the approach of combining win32_waitpid() and
> > threads. You'd end up with 1 thread per 64 backends; when something
> > interesting happens the thread could push the info onto a queue, which
> >
Magnus Hagander <[EMAIL PROTECTED]> writes:
> I was planning to make it even easier and let Windows do the job for us,
> just using RegisterWaitForSingleObject(). Does the same - one thread per
> 64 backends, but we don't have to deal with the queueing ourselves.
> Should be rather trivial to do.
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Alvaro Herrera <[EMAIL PROTECTED]> wrote:
>> Ah, you mean like we planned for 8.0 and failed, then for 8.1 and
>> failed, then for 8.2 and failed, then for 8.3 and failed? I can
>> definitely support that idea.
>>
> As I recall 8.0 and 8.1 actually
On 10/22/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > I was planning to make it even easier and let Windows do the job for us,
> > just using RegisterWaitForSingleObject(). Does the same - one thread per
> > 64 backends, but we don't have to deal with th
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> I was planning to make it even easier and let Windows do the job for us,
>> just using RegisterWaitForSingleObject(). Does the same - one thread per
>> 64 backends, but we don't have to deal with the queueing ourselves.
>> Should be r
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>> At least if we think it's more than a very narrow legitimate use, compared
>> to the number of ppl making the mistake.
> Did we ever come to a conclusion on this or not? I've changed my patch
> per the
"Tom Lane" <[EMAIL PROTECTED]> writes:
> In point of fact, the big patches that aren't in 8.3 were rejected
> because they weren't ready. They won't get into 8.4, either, unless
> someone does a lot more work on them. So I don't follow this idea
> of how we have a pre-loaded queue of good stuff
Ühel kenal päeval, R, 2007-10-19 kell 15:42, kirjutas Joe Conway:
> Decibel! wrote:
> > On Oct 18, 2007, at 11:17 PM, Joe Conway wrote:
> >>
> >> Seriously though, I can change it for 8.3, but is it really worth
> >> back-patching?
> >
> > I think it'd be worth changing for 8.3. While C forces y
>>> On Mon, Oct 22, 2007 at 1:30 PM, in message
<[EMAIL PROTECTED]>, Simon Riggs <[EMAIL PROTECTED]>
wrote:
> On Mon, 2007-10-22 at 09:31 -0500, Kevin Grittner wrote:
>> I've requested this before without response, but I'm asking again
>> because it just caused me pain again: could we get a TODO
Magnus Hagander <[EMAIL PROTECTED]> writes:
> We're not talking about the backends, we're talking about the backend
> waiter threads whose sole purpose is to wait for a backend to die and
> then raise a signal when it does.
Oh, OK, I had not twigged to exactly what the threads were being used
for.
>>> On Mon, Oct 22, 2007 at 4:37 PM, in message
<[EMAIL PROTECTED]>, "Kevin Grittner"
<[EMAIL PROTECTED]> wrote:
> One more logically equivalent, PostgreSQL-specific form which
> costs out even better was suggested off-list:
Oops. That is not logically equivalent. We want to delete WHERE NOT
[EMAIL PROTECTED] (Josh Berkus) writes:
> Simon,
>
>> We can issue a provisional date. We could also say "at least 6 months
>> after release date of 8.3". I'm sure there's other options too.
>
> I'm going to suggest 4 months after 8.3. 8.3 was supposed to be a *short*
> release so that we could m
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Before we settle on any dates I think we should have some discussion
> about how we can shorten the period between feature freeze and beta,
> which was far too long this time. Perhaps we need to be more aggressive
> about what what makes the cut and w
Chris Browne <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Josh Berkus) writes:
>> In fact, I could see doing a "no-catalog-changes, no major patches we don't
>> already know about, 6-month release". It would reset our cycle and get
>> PL/proxy, DSM, clustered indexes, etc. out the door. It
Josh Berkus wrote:
> Bruce,
>
> > We never actually considred undo, but high UPDATE activity was one of
> > the areas we historically handled poorly compared to undo systems, and
> > undo would have been one way to improve that area. I think with HOT we
> > have improved high UPDATE activity enou
Bruce Momjian wrote:
Josh Berkus wrote:
Bruce,
We never actually considred undo, but high UPDATE activity was one of
the areas we historically handled poorly compared to undo systems, and
undo would have been one way to improve that area. I think with HOT we
have improved high UPDAT
On Mon, 22 Oct 2007, Tom Lane wrote:
If we want a short FF-to-beta period then the criterion will have to be
that patches are either committed or darn near ready to commit on the FF
date.
I think you're stuck with a certain amount of schedule delay regardless of
how mature code is at submiss
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Before we settle on any dates I think we should have some discussion
about how we can shorten the period between feature freeze and beta,
which was far too long this time. Perhaps we need to be more aggressive
about what what makes the
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Before we settle on any dates I think we should have some discussion
about how we can shorten the period between feature freeze and beta,
which was far too long this time. Perhaps we need to be more aggressive
about what what make
79 matches
Mail list logo