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 m
"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
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
5*(60
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 proposal
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.
reg
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
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 c
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_usi
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 som
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\bin>initdb -D ../data
> > The program "postgres" is needed by initdb but was not found in the
> > same directory as "C:
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> When I try manually rebuild cluster I had second problem:
> C:\PostgreSQL\bin>initdb -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 ha
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 probl
"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=
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.
l
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'
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
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 suppor
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 pooled
[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
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 "te
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%
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 se
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!
http://www.xandria.com/promo-pages/toychest-sale.html?aid=SEL110107T&utm_source=Promo&utm_medium=email&utm_
"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.
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
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
x
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.
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?
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 dropping
29 matches
Mail list logo
