On Jun 17, 2005, at 12:33 PM, Tom Lane wrote:
Bruce Momjian writes:
OK, the current patch warns about two things, \' with one message,
and
any backslash in a non-E string with a different message.
Those are two very different things. \' is easy to get around and
there's no very good re
Gavin,
For the record, I don't consider myself a PostgreSQL newbie, nor do I
manage any 2 TB databases (much less tables), but I do have an
unusual production use case: thousands (> 10,000) of tables, many of
them inherited, and many of them with hundreds of thousands (a few
with millions
Tom Lane wrote:
> Bruce Momjian writes:
> > OK, the current patch warns about two things, \' with one message, and
> > any backslash in a non-E string with a different message.
>
> Those are two very different things. \' is easy to get around and
> there's no very good reason not to send '' inst
Bruce Momjian writes:
> OK, the current patch warns about two things, \' with one message, and
> any backslash in a non-E string with a different message.
Those are two very different things. \' is easy to get around and
there's no very good reason not to send '' instead. But avoiding all
use o
Gavin Sherry wrote:
> In January I was in Toronto with Jan, Tom and others and some ideas about
> vacuum were being discussed. The basic idea is that when we dirty pages we
> need we set a bit in a bitmap to say that the page has been dirty. A
> convenient place to do this is when we are writing di
"Tom Lane" <[EMAIL PROTECTED]> writes:
>
> Yeah --- a libpq-based solution is not what I think of as integrated at
> all, because it cannot do anything that couldn't be done by the existing
> external autovacuum process. About all you can buy there is having the
> postmaster spawn the autovacuum
Andrew Dunstan wrote:
> Bruce Momjian said:
>
> > OK, the current patch warns about two things, \' with one message, and
> > any backslash in a non-E string with a different message. The \'
> > message can easily be avoided in clients even in 8.0 by using '', but
> > for E'', there is no way to p
Bruce Momjian said:
> OK, the current patch warns about two things, \' with one message, and
> any backslash in a non-E string with a different message. The \'
> message can easily be avoided in clients even in 8.0 by using '', but
> for E'', there is no way to prepare an application before upgra
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > All true. Conversely, there does need to be a path for us to get to
> > standard behaviour.
>
> Yes --- but the important word there is "path". I think we have to do
> this in stages over a number of releases, to give people time t
Josh Berkus wrote:
Alvaro,
coffee-with-cream vacuums.
I tried this and now my Hoover makes this horrible noise and smokes. ;-)
Probably related to the quality of American coffee ;).
All:
Seriously, all: when I said that "users" were asking for Autovac in the
backend (AVitB), I wasn't
Hey, Folks,
I need to find someone who's really interesed in working with DTrace. Sun
has offered to help put DTrace probes into PostgreSQL for advanced
profiling, but need to know where to probe. Anyone?
I'm afraid that I won't get around to this quickly enough.
--
--Josh
Josh Berkus
Agl
Title: MemoryContextAlloc: invalid request size
Our customer is reporting a database problem after they ran into a
disk quota/filesystem full situation.
This is Postgres 7.2.x on Solaris.
The database server starts without any obvious errors, but the app. Server
cannot establish connection
Andrew Dunstan wrote:
Andreas Pflug wrote:
We're having a growing zoo of daemons that can be regarded as tightly
integrated server add-on processes (slony, autovac, pgAgent), and it
would be really nice (say: win32 users are used to it, thus requiring
it) to have a single point of contro
On Thu, 16 Jun 2005, Alvaro Herrera wrote:
> On Thu, Jun 16, 2005 at 04:20:34PM +1000, Gavin Sherry wrote:
>
> > 2) By no fault of its own, autovacuum's level of granularity is the table
> > level. For people dealing with non-trivial amounts of data (and we're not
> > talking gigabytes or terabyte
Andreas Pflug wrote:
We're having a growing zoo of daemons that can be regarded as tightly
integrated server add-on processes (slony, autovac, pgAgent), and it
would be really nice (say: win32 users are used to it, thus requiring
it) to have a single point of control.
Maybe a super daemo
Hackers,
SpikeSource is now doing automated testing of the PostgreSQL code in their
stack testing platform. This includes:
* SpikeSource has incorporated the testing of PostgreSQL into
the company's 22,000 nightly automated test runs. SpikeSource includes
the code coverage of PostgreSQL, a
Josh Berkus wrote:
Dave,
In previous discussions on -hackers when ppl raised the idea of
something like pgAgent being built into the backend, istm that the
majority of people were against the idea.
Well, you're up against the minimalist approach to core PostgreSQL there. It
would pretty m
> -Original Message-
> From: Josh Berkus [mailto:[EMAIL PROTECTED]
> Sent: 16 June 2005 17:29
> To: Dave Page
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Autovacuum in the backend
>
> Dave,
>
> > In previous discussions on -hackers when ppl raised the idea of
> > somet
>
> Well, yes, but I don't think we should break compatibility
> arbitrarilly. I guess it could be argued that this is a missing feature
> in PL/SQL and its Ada parent - implementing GOTO just to handle this
> case seems unnecessary.
Yes. I din't use goto 5 years :-). Continue stmt is more
On Thu, 16 Jun 2005, Tom Lane wrote:
> Pavel Stehule <[EMAIL PROTECTED]> writes:
> > BEGIN
> > CONTINUE WHEN i = 10;
> > RAISE NOTICE '---1---';
> > END;
>
> I find that really ugly and confusing. If we add a CONTINUE it's only
> sensible to allow it inside a loop --- otherwise it's
On Thu, 16 Jun 2005, Josh Berkus wrote:
> Pavel,
>
> > Statement CONTINUE isn't in PL/SQL too, I know it, but Oracle PL/SQL
> > has statement GOTO. I don't need GOTO statement, but 'continue' can be
> > very usefull for me. I have to do some ugly trick now. With little change,
> > we can enhan
On Thu, 16 Jun 2005, Josh Berkus wrote:
> Pavel,
>
> > o User can specify SQLSTATE only from class 'U1'
> > o Default values for SQLSTATE usr excpt are from class 'U0'
> > o Every exception's variable has unique SQLSTATE
> > o User's exception or system's exception can be raised only with
> >
As a near-daily PL/pgSQL developer, I similarly agree.
-Jonah
Andrew Dunstan wrote:
Pavel Stehule wrote:
What do you think about it? It's broke PL/SQL compatibility, I know,
but via last discussion I have opinion so Oracle compatibility isn't
main objective PL/pgSQL. There is some less/
On N, 2005-06-16 at 11:42 -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
...
> > Some people say "keep it simple and have one process per cluster." I
> > think they don't realize it's actually more complex, not the other way
> > around.
>
> Agreed. If you aren't connected t
Pavel Stehule wrote:
What do you think about it? It's broke PL/SQL compatibility, I know, but
via last discussion I have opinion so Oracle compatibility isn't main
objective PL/pgSQL. There is some less/bigger diferencess: SQLSTATE,
EXCEPTION from my last proposal, atd.
Well, yes,
Tom Lane wrote:
"Matthew T. O'Connor" writes:
I don't think you can use a dump to determine who should be connected to
next since you don't really know what happened since the last time you
exited. What was a priority 5 or 10 minutes ago might not be a priority
now.
Well, the info
Pavel Stehule <[EMAIL PROTECTED]> writes:
> BEGIN
> CONTINUE WHEN i = 10;
> RAISE NOTICE '---1---';
> END;
I find that really ugly and confusing. If we add a CONTINUE it's only
sensible to allow it inside a loop --- otherwise it's just a nonstandard
spelling of EXIT.
"Matthew T. O'Connor" writes:
> I don't think you can use a dump to determine who should be connected to
> next since you don't really know what happened since the last time you
> exited. What was a priority 5 or 10 minutes ago might not be a priority
> now.
Well, the information necessary to
On Thu, Jun 16, 2005 at 09:40:16 -0700,
Josh Berkus wrote:
> Pavel,
>
> > Statement CONTINUE isn't in PL/SQL too, I know it, but Oracle PL/SQL
> > has statement GOTO. I don't need GOTO statement, but 'continue' can be
> > very usefull for me. I have to do some ugly trick now. With little cha
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Now, I'm hearing people don't like using libpq.
Yeah --- a libpq-based solution is not what I think of as integrated at
all, because it cannot do anything that couldn't be done by the existing
external autovacuum process. Abo
Pavel,
> Statement CONTINUE isn't in PL/SQL too, I know it, but Oracle PL/SQL
> has statement GOTO. I don't need GOTO statement, but 'continue' can be
> very usefull for me. I have to do some ugly trick now. With little change,
> we can enhance stmt EXIT for behavior continue.
Can you explain
Josh Berkus writes:
> Seriously, all: when I said that "users" were asking for Autovac in the
> backend (AVitB), I wasn't talking just the newbies on #postgresql. I'm also
> talking companies like Hyperic, and whole groups like the postgresql.org.br.
>
> This is a feature that people wan
Hello
Statement CONTINUE isn't in PL/SQL too, I know it, but Oracle PL/SQL
has statement GOTO. I don't need GOTO statement, but 'continue' can be
very usefull for me. I have to do some ugly trick now. With little change,
we can enhance stmt EXIT for behavior continue.
After some work I can
Dave,
> In previous discussions on -hackers when ppl raised the idea of
> something like pgAgent being built into the backend, istm that the
> majority of people were against the idea.
Well, you're up against the minimalist approach to core PostgreSQL there. It
would pretty much *have* to be an
People,
> AVitB has been on the TODO list for 2 versions. There's been 2 years to
> question its position there. Now people are bringing up objections when
> there's no time for discussion left? This stinks.
Hmmm ... to be specific, I'm referring to the objections to the *idea* of
AVitB, no
Alvaro,
> coffee-with-cream vacuums.
I tried this and now my Hoover makes this horrible noise and smokes. ;-)
All:
Seriously, all: when I said that "users" were asking for Autovac in the
backend (AVitB), I wasn't talking just the newbies on #postgresql. I'm also
talking companies like Hyp
Pavel,
> o User can specify SQLSTATE only from class 'U1'
> o Default values for SQLSTATE usr excpt are from class 'U0'
> o Every exception's variable has unique SQLSTATE
> o User's exception or system's exception can be raised only with
> level EXCEPTION
>
> Any comments, notes?
Looks gre
> -Original Message-
> From: Andreas Pflug [mailto:[EMAIL PROTECTED]
> Sent: 16 June 2005 15:14
> To: Dave Page
> Cc: Matthew T. O'Connor; Andrew Dunstan;
> [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; pgman@candle.pha.pa.us;
> pgsql-hackers@postgresql.org
> Subject: Re
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> All true. Conversely, there does need to be a path for us to get to
> standard behaviour.
Yes --- but the important word there is "path". I think we have to do
this in stages over a number of releases, to give people time to
migrate.
Assuming that th
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Now, I'm hearing people don't like using libpq.
Yeah --- a libpq-based solution is not what I think of as integrated at
all, because it cannot do anything that couldn't be done by the existing
external autovacuum process. About all you can buy there is
Alvaro Herrera wrote:
On Thu, Jun 16, 2005 at 04:20:34PM +1000, Gavin Sherry wrote:
2) By no fault of its own, autovacuum's level of granularity is the table
level. For people dealing with non-trivial amounts of data (and we're not
talking gigabytes or terabytes here), this is a serious drawba
[switched to -hackers]
Tom Lane wrote:
Rod Taylor <[EMAIL PROTECTED]> writes:
It probably won't be any worse than when '' was rejected for an integer
0.
That analogy is *SO* far off the mark that I have to object.
Fooling with quoting rules will not simply cause clean failures, whi
On Thu, Jun 16, 2005 at 04:20:34PM +1000, Gavin Sherry wrote:
> 2) By no fault of its own, autovacuum's level of granularity is the table
> level. For people dealing with non-trivial amounts of data (and we're not
> talking gigabytes or terabytes here), this is a serious drawback. Vacuum
> at peak
On Thu, Jun 16, 2005 at 01:32:16AM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > A question for interested parties. I'm thinking in handling the
> > user/password issue by reading the flat files (the copies of pg_shadow,
> > pg_database, etc).
>
> Er, what "user/password
Matthew T. O'Connor wrote:
Right, I think if VACUUM is improved than the semantics of AV in the
backend might change, but I think there will always be a need for some
maintenance, and a daemon that monitors the maintenance needs of your
database and fires off appropriate maintenance commands
On Wed, Jun 15, 2005 at 09:07:30PM -0700, Josh Berkus wrote:
> Josh,
>
> > Just my own two cents. First I am not knocking the work that has been on
> > autovacuum. I am sure that it was a leap on its own to get it to work.
> > However I will say that I just don't see the reason for it.
>
> I've p
Hans-Jürgen Schönig wrote:
I completly agree with Gavin - integrating this kind of thing into the
backend writer or integrate it with FSM would be the ideal solution.
Yes AV should look at FSM data, and it will eventually. I'm not sure
how you would integrate AV with the backend writer, but
Gavin Sherry wrote:
On Thu, 16 Jun 2005, Matthew T. O'Connor wrote:
Would you mind expounding on why you think autovacuum isn't suitable for
the general public? I know it's not a silver bullet, but I think in
general, it will be helpful for most people.
As I said, this is largely the
Andrew Dunstan wrote:
Gavin Sherry said:
I think this gets away from my point a little. People with 2 TB tables
can take care of themselves, as can people who've taken the time to
partition their tables to speed up vacuum. I'm more concerned about the
majority of people who fall in the middl
Simon Riggs <[EMAIL PROTECTED]> writes:
> Your suggested fix to the 2000+ inherited relation problem seemed like
> it would apply to an area that most people would never use, yet would
> have an effect on anybody using LockAcquire.
Just FYI, the proposed fix is already in, and I think it's a net w
Gavin Sherry said:
> On Thu, 16 Jun 2005, [ISO-8859-1] Hans-Jürgen Schönig wrote:
>
>> > 2) By no fault of its own, autovacuum's level of granularity is the
>> > table level. For people dealing with non-trivial amounts of data
>> > (and we're not talking gigabytes or terabytes here), this is a
>> >
> -Original Message-
> From: Magnus Hagander [mailto:[EMAIL PROTECTED]
> Sent: 16 June 2005 10:15
> To: Josh Berkus; Gavin Sherry
> Cc: Bruce Momjian; pgsql-hackers@postgresql.org; Dave Page
> Subject: RE: [HACKERS] Autovacuum in the backend
>
> > If we do integrated AV, it should only
On Thu, 2005-06-16 at 00:55 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Looks bad... but how does it look for 1000 inherited relations? My
> > feeling is that we should not be optimizing the case above 1000
> > relations. That many partitions is very unwieldy.
>
> Well, it
Gavin Sherry wrote:
On Thu, 16 Jun 2005, [ISO-8859-1] Hans-J�rgen Sch�nig wrote:
2) By no fault of its own, autovacuum's level of granularity is the table
level. For people dealing with non-trivial amounts of data (and we're not
talking gigabytes or terabytes here), this is a serious drawback.
On Thu, 16 Jun 2005, [ISO-8859-1] Hans-Jürgen Schönig wrote:
> > 2) By no fault of its own, autovacuum's level of granularity is the table
> > level. For people dealing with non-trivial amounts of data (and we're not
> > talking gigabytes or terabytes here), this is a serious drawback. Vacuum
> >
> If we do integrated AV, it should only be turned on by
> default at a relatively low level. And wasn't there an issue
> on Windows with AV not working?
AFAIK, it works.
But the fact that you need to provide it with a userid/password combo
makes it a lot harder to install as a service. And it'
2) By no fault of its own, autovacuum's level of granularity is the table
level. For people dealing with non-trivial amounts of data (and we're not
talking gigabytes or terabytes here), this is a serious drawback. Vacuum
at peak times can cause very intense IO bursts -- even with the
enhancements
Hello
I did some work on implementation of user's exception.
Generally:
o add pseudotype EXCEPTION
DECLARE excpt EXCEPTION [= 'SQLSTATE']
o change RAISE stmt
RAISE error_level [excpt_var|sys_excpt_name] errmsg, ...
o change EXCEPTION
EXCEPTION WHEN excpt_var|sys_excpt_name
On Thu, 2005-06-16 at 12:59 +0800, Christopher Kings-Lynne wrote:
> > Well, it's not so much that I care about queries with 1000+ relations,
> > as that this is a good way to stress-test the code and find out where
> > the performance issues are. There are many thousand lines of code that
> > can
59 matches
Mail list logo
