Tom Lane wrote:
Still in the think-about-it mode, personally ... my proposed fix is
certainly much too invasive to consider back-patching, so unless someone
comes up with a way-simpler idea, it's 8.3 material at best ...
I ran into a variant of this today - simply creating and
On Thursday 01 November 2007 00:44:16 Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Perhaps both these considerations dictate providing another command or a
special flavor of \l instead of just modifying it?
I've seen no argument made why \l should print this info at all.
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
So my current theory is:
In xmlelement(), we use ExecEvalExpr(), which in turn calls xml_parse.
xml_parse calls xmlCleanupParser(). But when we call ExecEvalExpr(),
we're in the middle of constructing an xml buffer, so calling
There is one more condition under which this becomes useful. Suppose you
have requirements for setting transaction isolation level as serializable
only for select statements, you can avoid setting the transaction isolation
level as serializable by making use of this feature. any expert comments?
Mark Kirkwood [EMAIL PROTECTED] writes:
The previous discussion centered around working on on locking in
dependency.c whilst dropping related objects - but does this apply when
there is just one? Anyway I tried to understand what was happening and
the attached rather hacky patch seems to
Heikki Linnakangas [EMAIL PROTECTED] writes:
Hmm. There's the check sizeof(char) == sizeof(xmlChar), which in fact should
be evaluated at compile time (should that actually be an #error?).
sizeof() isn't expanded by cpp (and cannot be due to cross-compilation) so it
can't be a #error. It
This email was sent to you by Xandria.com. To ensure delivery to your inbox
(not bulk or junk folders),
please add [EMAIL PROTECTED] to your safe senders list.
Over 200 Vibrators on Sale!
Greetings,
Regarding Magnus' patch for matching against the Kerberos realm- I'd
see it as much more useful as a multi-value configuration option.
Perhaps 'krb_alt_realms' or 'krb_realms'. This would look like:
Match against one, and only one, realm (does not have to be the realm
the
Hi.
I think that a calculation sheet will be made.
However, calculation does not suitable.:-(
It is this.(8.2.5 Default-FreeBSD)
--
max_locks_per_transaction 64
max_connections 40
max_prepared_transactions 5
shared_buffers 28MB
wal_buffers 64kB
max_fsm_relations 1000
max_fsm_pages 179200
inet%
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think that (1) we need a call to xml_init here, and hence also a
PG_TRY block;
xml_init doesn't actually do anything that would need to be free'd in
case of error. But yeah, it does seem like a good idea to free the text
[Camilo Porto]
Date: Tue, 30 Oct 2007 16:09:01 +
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [HACKERS] URGENT HELP about 'duration' stats
CC: pgsql-hackers@postgresql.org
2007/10/30, Camilo Porto [EMAIL PROTECTED]:
I am simulating only 1 client with the
Bruce Momjian wrote:
No, it isn't. Please add a TODO item about it:
* Prevent long-lived temp tables from causing frozen-Xid advancement
starvation
Can somebody explain this one to me? because of our auditing technique,
we have many LONG lived temp tables.(one per
Heikki Linnakangas wrote:
It still feels unsafe to call ExecEvalExpr while holding on to xml
structs. It means that it's not safe for external modules to use
libxml2 and call xmlMemSetup or xmlSetGenericErrorFunc themselves.
Well yeah, they shouldn't do that. I don't think we want to support
Tom Lane wrote:
No, your first theory is closer to the mark. What is happening is
that xmlelement neglects to call xml_init, therefore the various
stuff allocated by libxml is allocated using malloc(). Then
xml_parse is called, and it *does* do xml_init(), which calls
xmlMemSetup. Then
Tom Lane wrote:
Well, xml_init calls xmlInitParser() which needs to be cleaned up.
But since xmlelement doesn't need that, maybe we should factor it
out of xml_init.
That could help.
As for the try/catch blocks instead of relying on memory context
cleanup, I'm not entirely sure if that's
Hello
I would to initdb with UTF8 encoding. But after installation, I had
cp1250 encoding
lc_collate | Czech_Czech Republic.1250
he collation order locale.
lc_ctype| Czech_Czech Republic.1250
he character classification and case conversion locale.
Hiroshi Saito [EMAIL PROTECTED] writes:
inet% ipcs -b -m
Shared Memory:
T ID KEY MODEOWNERGROUP SEGSZ
m 917504 5432001 --rw---saitowheel 32571392
40*(400+270*64)= 707200
5*(600+270*64)= 89400
28MB= 29360128
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
The note
at line 27ff of xml.c implies that libxml keeps static pointers to
allocated things that it thinks will survive indefinitely, so we
may have to have these. I'm suspicious whether xmlelement doesn't
have a problem if the
Pavel Stehule [EMAIL PROTECTED] writes:
When I try manually rebuild cluster I had second problem:
C:\PostgreSQL\bininitdb -D ../data
The program postgres is needed by initdb but was not found in the
same directory as C:\PostgreSQL\bin/initdb.
Check your installation.
Do you have the same
On 01/11/2007, Tom Lane [EMAIL PROTECTED] wrote:
Pavel Stehule [EMAIL PROTECTED] writes:
When I try manually rebuild cluster I had second problem:
C:\PostgreSQL\bininitdb -D ../data
The program postgres is needed by initdb but was not found in the
same directory as
Gregory Stark wrote:
I think the change to the hash functions needs to be called out in the release
notes.
If anyone stored any results of hashintN, hashfloat8, etc in their database or
outside the database those results will have changed. It's fairly unlikely but
there could be someone
Andrew Dunstan wrote:
Tom Lane wrote:
OTOH we may be talking at cross-purposes --- on looking into gram.y
I see that this syntax is transformed to a call of convert_using(),
which may mean it has nothing to do with your changes.
No, I changed convert_using -
Bruce Momjian wrote:
Andrew Dunstan wrote:
Tom Lane wrote:
OTOH we may be talking at cross-purposes --- on looking into gram.y
I see that this syntax is transformed to a call of convert_using(),
which may mean it has nothing to do with your changes.
No, I changed
Andrew Dunstan wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:
Tom Lane wrote:
OTOH we may be talking at cross-purposes --- on looking into gram.y
I see that this syntax is transformed to a call of convert_using(),
which may mean it has nothing to do with your changes.
Bruce Momjian [EMAIL PROTECTED] writes:
Andrew Dunstan wrote:
No, we're long past this point. We've dropped 'convert ... using' entirely.
The question is whether re-adding it should be a TODO.
Not unless someone wants it and can explain the spec convincingly.
regards,
Bruce Momjian wrote:
Is this a TODO?
No, we're long past this point. We've dropped 'convert ... using' entirely.
The question is whether re-adding it should be a TODO.
One of the reasons we dropped it was that the spec didn't seem to make
sense. So if there's a
Hi.
From: Tom Lane [EMAIL PROTECTED]
Hiroshi Saito [EMAIL PROTECTED] writes:
inet% ipcs -b -m
Shared Memory:
T ID KEY MODEOWNERGROUP SEGSZ
m 917504 5432001 --rw---saitowheel 32571392
40*(400+270*64)= 707200
Hiroshi Saito [EMAIL PROTECTED] writes:
40*(1800+270*64)= 763200
5*(700+270*64)= 89900
28MB=29360128
64kB= 65536
1000*70= 7
179200*6= 1075200
700kB= 716800
Total :32140764
ipcs-m:32571392
-430628
I think it is a
Hi.
Thanks!
From: Tom Lane [EMAIL PROTECTED]
I think it is a permissible range. Thanks!
Most of the remaining discrepancy is because you did not account for the
per-shared-buffer management overhead. The table shows shared_buffers
as costing 8300 bytes each, not 8192.
Oops, I did the
29 matches
Mail list logo
