Right now max_locks_per_transactions defines the average number of locks
taken by a transaction. thus, shared memory is limited to
max_locks_per_transaction * (max_connections + max_prepared_transactions).
this is basically perfect. however, recently we have seen a couple of
people having
I have made these adjustments to the documentation. Do people want
the
error message strings also updated? It will probably make the
translation easier/clearer in the future, but it does involve some
error
message wording churn. CVS HEAD only, of course.
I think most translations will
On 2/1/07, Tom Lane [EMAIL PROTECTED] wrote:
imad [EMAIL PROTECTED] writes:
OK, so renaming does not work in the same block.
You can rename a vairable in a nested block and thats why it works for
OLD/NEW.
BTW, what is the purpose behind it? Declaring a variable in a block
and quickly
I dont think we solved this.. But I think the way to put -m64 should be same as in Linux and Solaris
and not different.
Thanks.
Regards,
Jignesh
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Mittwoch, 17. Januar 2007 17:12 schrieb Tom Lane:
Jignesh K. Shah [EMAIL PROTECTED]
AFAICS, the statistics information the number of dead tuples
(n_dead_tuples) has an estimation error.
VACUUM sends a message to stats collector process when it has swept a table.
The stats collector receives the message and sets n_dead_tuples of the table
to zero. However, we can update or delete
Hello,
std. use rename only for triggers and variables new and old. It has sense. I
don't see sense for rename in clasic plpgsql functions. There was one
reason, rename unnamed $params. But currently plpgsql support named params
and this reason is obsolete.
Regards
Pavel Stehule
On 2/1/07, Chris Dunlop wrote:
In maillist.postgres.dev, you wrote:
On Thu, 1 Feb 2007, Chris Dunlop wrote:
The main idea is that, there might be space utilisation and
performance advantages if postgres had hard read-only
tables, i.e. tables which were guaranteed (by postgres) to
never have
Bruce Momjian schrieb:
I have made these adjustments to the documentation. Do people want the
error message strings also updated? It will probably make the
translation easier/clearer in the future, but it does involve some error
message wording churn. CVS HEAD only, of course.
I still think
Still sitting on my TODO. I have a working solution for MSVC, but it
didn't run on MingW. Andreas had a working solution on his MingW, but it
didn't work on my MingW.
I need to merge them together for something that works on all three. I
hope to have this done for 8.3, and possibly a 8.2.x, but
On Thu, 2007-02-01 at 15:03 +1100, Chris Dunlop wrote:
A different approach discussed earlier involves greatly
restricting the way in which the table is used. This table
could only be written to if an exclusive lock is held; on
error or ABORT, the table is truncated.
You're talking
On Thu, 2007-02-01 at 09:15 +0100, Hans-Juergen Schoenig wrote:
Right now max_locks_per_transactions defines the average number of locks
taken by a transaction. thus, shared memory is limited to
max_locks_per_transaction * (max_connections + max_prepared_transactions).
this is basically
On 1/31/07, Tom Lane [EMAIL PROTECTED] wrote:
We can't change TOAST_MAX_CHUNK_SIZE without forcing an initdb, but I
think that it would be safe to remove the MAXALIGN'ing of the tuple
size in the tests in heapam.c, that is
That would mean that the tuple size in the heap may exceed
On Tue, 2007-01-30 at 17:34 -0500, Tom Lane wrote:
I think the NOT IN optimization that *would* be of use is to
automatically transform the NOT IN representation to an
outer-join-with-null-test type of operation, so as to give us a wider
choice of join methods. However, I'm not sure about
Ühel kenal päeval, N, 2007-02-01 kell 13:24, kirjutas Gavin Sherry:
A different approach discussed earlier involves greatly restricting the
way in which the table is used. This table could only be written to if an
exclusive lock is held; on error or ABORT, the table is truncated.
The
Ühel kenal päeval, N, 2007-02-01 kell 14:38, kirjutas Hannu Krosing:
Ühel kenal päeval, N, 2007-02-01 kell 13:24, kirjutas Gavin Sherry:
A different approach discussed earlier involves greatly restricting the
way in which the table is used. This table could only be written to if an
On Thu, 2007-02-01 at 14:38 +0200, Hannu Krosing wrote:
Ühel kenal päeval, N, 2007-02-01 kell 13:24, kirjutas Gavin Sherry:
A different approach discussed earlier involves greatly restricting the
way in which the table is used. This table could only be written to if an
exclusive lock is
Peter Eisentraut wrote:
Bruce Momjian wrote:
I have made these adjustments to the documentation. Do people want
the error message strings also updated?
I have no problem with that. They seem to be in pretty good shape
already, so the changes should be few.
Yea, I see only a few. I
Simon Riggs wrote:
On Thu, 2007-02-01 at 09:15 +0100, Hans-Juergen Schoenig wrote:
Right now max_locks_per_transactions defines the average number of locks
taken by a transaction. thus, shared memory is limited to
max_locks_per_transaction * (max_connections + max_prepared_transactions).
On 1/31/2007 12:41 PM, Tom Lane wrote:
Pavan Deolasee [EMAIL PROTECTED] writes:
On 1/31/07, Tom Lane [EMAIL PROTECTED] wrote:
The toast code takes pains to ensure that the tuples it creates won't be
subject to re-toasting. Else it'd be an infinite recursion.
I think I found it. The
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
I'm thinking to add the number of vacuumed tuples to the message from
vacuum. The stats collector will subtract the value from n_dead_tuples
instead of setting it to zero. This is also needed if we want to make
some kinds of partial vacuum methods.
Jan Wieck [EMAIL PROTECTED] writes:
On 1/31/2007 12:41 PM, Tom Lane wrote:
We can't change TOAST_MAX_CHUNK_SIZE without forcing an initdb, but I
think that it would be safe to remove the MAXALIGN'ing of the tuple
size in the tests in heapam.c, that is
Can't we maxalign the page header in the
Has anyone looked into $SUBJECT? I just today realized that the
ECPG-Check failures on that machine are not the run-of-the-mill
small difference in the expected results. Rather, most of the
tests are actually dumping core on the client side:
testing connect/test1.pgc ...
Tom Lane wrote:
[...]
BTW, this is a perfect example of why it's not a good idea to allow
minor regression failures to go unfixed --- people become desensitized.
I know I've been completely ignoring ECPG-Check buildfarm results
for awhile now.
I already reported that a while ago:
Hannu Krosing [EMAIL PROTECTED] writes:
A more radical variation of the restricted-use archive table approach
is storing all tuple visibility info in a separate file.
At first it seems to just add overhead, but for lots (most ? ) usecases
the separately stored visibility should be highly
Hans-Juergen Schoenig [EMAIL PROTECTED] writes:
i would suggest to replace the existing parameter but something else:
- a switch to define the global size of the lock pool (e.g. max_locks)
- a switch which defines the upper limit for the current backend /
transaction
The problem with
Hannu Krosing wrote:
...is storing all tuple visibility info in a separate file.
At first it seems to just add overhead, but for lots (most ? ) usecases
the separately stored visibility should be highly compressible, so for
example for bulk-loaded tables you could end up with one bit per
Thread URL added to TODO item:
o Add long file support for binary pg_dump output
---
Magnus Hagander wrote:
On Fri, Dec 15, 2006 at 12:57:50AM +0900, Hiroshi Saito wrote:
Win32 does not implement fseeko()
3606c3606
errmsg(aggregate function calls cannot be nested)));
---
errmsg(aggregate function calls may not be nested)));
I don't think that this is an improvement, or even correct English.
You have changed a message that states that an action is logically
Tom Lane wrote:
3606c3606
errmsg(aggregate function calls cannot be nested)));
---
errmsg(aggregate function calls may not be nested)));
I don't think that this is an improvement, or even correct English.
You have changed a message that states that
On Thu, 1 Feb 2007, Bruce Momjian wrote:
From: Bruce Momjian [EMAIL PROTECTED]
Tom Lane wrote:
3606c3606
errmsg(aggregate function calls cannot be nested)));
---
errmsg(aggregate function calls may not be nested)));
I don't think that this is
Richard Troy wrote:
On Thu, 1 Feb 2007, Bruce Momjian wrote:
From: Bruce Momjian [EMAIL PROTECTED]
Tom Lane wrote:
3606c3606
errmsg(aggregate function calls cannot be
nested)));
---
errmsg(aggregate function calls may not be
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
3606c3606
errmsg(aggregate function calls cannot be nested)));
---
errmsg(aggregate function calls may not be nested)));
I don't think that this is an improvement, or even correct English.
Uh,
I am wanting to write some new C functions which leverage postgresql's
existing regexp code in an extension module. I notice that the functions
RE_compile_and_cache and RE_compile_and_execute in
src/backend/util/regexp.c contain the code necessary to connect the regexp
code in src/backend/regex
Koichi Suzuki [EMAIL PROTECTED] writes:
Here's an idea and a patch for full page writes improvement.
Idea:
(1) keep full page writes for ordinary WAL, make them available during
the crash recovery, - recovery from inconsistent pages which can be
made at the crash,
(2) Remove them from the
Where are we on this patch? Does it have performance tests to show
where it is beneificial? Is it ready to be reviewed?
---
Heikki Linnakangas wrote:
I've been skimming through the bitmap index patch...
A scan needs
On Thu, 1 Feb 2007, Bruce Momjian wrote:
Where are we on this patch? Does it have performance tests to show
where it is beneificial? Is it ready to be reviewed?
I've got an updated patch which adds significant performance improvements
for worse case data distributions. It also contains a
Jeremy Drake [EMAIL PROTECTED] writes:
Is there some specific reason that these functions are static,
Yeah: not cluttering the global namespace. I'm not excited about
exporting everything that anybody could possibly want access to;
that just makes it harder to maintain the code. When you see a
Tom Lane wrote:
Koichi Suzuki [EMAIL PROTECTED] writes:
Here's an idea and a patch for full page writes improvement.
Idea:
(1) keep full page writes for ordinary WAL, make them available during
the crash recovery, - recovery from inconsistent pages which can be
made at the crash,
(2)
Koichi Suzuki [EMAIL PROTECTED] writes:
Tom Lane wrote:
Doesn't this break crash recovery on PITR slaves?
Compressed archive log contains the same data as full_page_writes off
case. So the influence to PITR slaves is the same as full_page_writes off.
Right. So what is the use-case for
On Thu, 1 Feb 2007, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
Is there some specific reason that these functions are static,
Yeah: not cluttering the global namespace.
Is there a reason for not putting your new code itself into regexp.c?
Not really, I just figured it would be
Hi all,
I found the need to determine the type of a datum at runtime. David
Fetter and Elein have already written about this:
http://www.varlena.com/varlena/GeneralBits/117.php
(My scenario is similar to the article there; I was writing a
procedure which unit-tests other procedures. It needs to
Joshua D. Drake wrote:
To cure the shortage of experienced Postgres folks there is only one
solution - err, more experience! So the need is for good training
courses (not necessarily certification and all the IMHO nonsense that
comes with that), and a willingness on the part of employers to
Ivo,
Iannsp wrote:
Hello,
I did like to know what you think about the postgresql certifications
provided for
PostgreSQL CE
http://www.sraoss.co.jp/postgresql-ce/news_en.html
CertFirst
http://www.certfirst.com/postgreSql.htm
My question is about the validate of this certification for the
Chander Ganesan wrote:
Ivo,
Iannsp wrote:
Hello,
I did like to know what you think about the postgresql certifications
provided for
PostgreSQL CE
http://www.sraoss.co.jp/postgresql-ce/news_en.html
CertFirst
http://www.certfirst.com/postgreSql.htm
My question is about the validate of this
Tom Lane wrote:
Koichi Suzuki [EMAIL PROTECTED] writes:
Tom Lane wrote:
Doesn't this break crash recovery on PITR slaves?
Compressed archive log contains the same data as full_page_writes off
case. So the influence to PITR slaves is the same as full_page_writes off.
Right. So what is
Tom Lane [EMAIL PROTECTED] wrote:
I'm thinking to add the number of vacuumed tuples to the message from
vacuum. The stats collector will subtract the value from n_dead_tuples
instead of setting it to zero.
This seems awfully dangerous to me, because then you are operating on
dead
On Thu, Feb 01, 2007 at 05:11:30PM -0800, Jeremy Drake wrote:
On Thu, 1 Feb 2007, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
Is there some specific reason that these functions are static,
Yeah: not cluttering the global namespace.
Is there a reason for not putting your
Added to TODO:
o Allow column display reordering by recording a display,
storage, and permanent id for every column?
http://archives.postgresql.org/pgsql-hackers/2006-12/msg00782.php
---
Jim C.
On Thu, 1 Feb 2007, David Fetter wrote:
On Thu, Feb 01, 2007 at 05:11:30PM -0800, Jeremy Drake wrote:
Anyway, the particular thing I was writing was a function like
substring(str FROM pattern) which instead of returning just the
first match group, would return an array of text containing
Hello,
you can identify type via operator OF.
like:
IF a IS OF INTEGER THEN
RAISE NOTICE 'Parametr a is numeric';
ELSIF a IS OF varchar THEN
RAISE NOTICE 'Parametr a is string';
END IF;
Regards
Pavel Stehule
_
Citite se
On Thu, Feb 01, 2007 at 10:16:54PM -0800, Jeremy Drake wrote:
On Thu, 1 Feb 2007, David Fetter wrote:
On Thu, Feb 01, 2007 at 05:11:30PM -0800, Jeremy Drake wrote:
Anyway, the particular thing I was writing was a function like
substring(str FROM pattern) which instead of returning just
Pavel Stehule [EMAIL PROTECTED] writes:
you can identify type via operator OF.
IF a IS OF INTEGER THEN
RAISE NOTICE 'Parametr a is numeric';
Yeah, that is the SQL-standard syntax, but I think our implementation
doesn't work the way Kate would like: if a is an ANYELEMENT function
On Fri, Feb/ 2/07 02:17:51AM -0500, Tom Lane wrote:
Pavel Stehule [EMAIL PROTECTED] writes:
you can identify type via operator OF.
IF a IS OF INTEGER THEN
RAISE NOTICE 'Parametr a is numeric';
Yeah, that is the SQL-standard syntax, but I think our implementation
doesn't work the
Kate F [EMAIL PROTECTED] writes:
... OF takes a list of types; it needs parentheses:
IF a IS OF (INTEGER) THEN
Oh, right, minor detail.
Meanwhile, I still think the function David proposed is a worthy
addition (and I still have a user-case for it!), as using just the OF
operator for
Hello,
I miss doc for this operator
Regards
Pavel Stehule
_
Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci.
http://messenger.msn.cz/
---(end of broadcast)---
TIP
On Fri, Feb/ 2/07 02:41:15AM -0500, Tom Lane wrote:
Meanwhile, I still think the function David proposed is a worthy
addition (and I still have a user-case for it!), as using just the OF
operator for something similar, one would have to explictly test
against every type required.
Um,
56 matches
Mail list logo
