Hi all,
It seems to me that the latest french .po files in pgtranslation are not
used in the 8.2.1 release and I wonder why. How do you synchronize
between the pgtranslation project tree and the PostgreSQL CVS source
tree ? and how often is it done ?
Thanks.
Regards.
--
Guillaume.
-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Jan 16, 2007 at 11:23:36AM -0300, Alvaro Herrera wrote:
> Matthew T. O'Connor wrote:
>
[...]
> Now I'm starting to wonder what will happen between 23:59:59 of day X
> and 00:00:00 of day (X+1) ... Maybe what we should do is not specify
> an e
Neil Conway wrote:
> Log Message:
> ---
> Implement width_bucket() for the float8 data type.
this seems to require an alternative regression output file on windows:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=snake&dt=2007-01-17%2006:30:00
http://buildfarm.postgresql.org/cgi-bi
Takayuki Tsunakawa wrote:
> From: "Tom Lane" <[EMAIL PROTECTED]>
>> I wrote:
>>> I've committed a tentative patch along these lines to HEAD. Please
>>> test.
>> So I come home from dinner out, and find the buildfarm all red :-(
>>
>> I'm not sure why I didn't see this failure in my own testing, bu
I can see that there are two issues in the design of Dead Space Map
in the recent discussions:
1. information accuracy of dead spaces
2. memory management
I'll write up the discussion about the 1st for now.
We need to increase page-tracking status for effective vacuum. 1 bit per
block is
From: "Tom Lane" <[EMAIL PROTECTED]>
>I wrote:
>> I've committed a tentative patch along these lines to HEAD. Please
>> test.
>
> So I come home from dinner out, and find the buildfarm all red :-(
>
> I'm not sure why I didn't see this failure in my own testing, but in
> hindsight it's quite obvio
From: "Tom Lane" <[EMAIL PROTECTED]>
> "Takayuki Tsunakawa" <[EMAIL PROTECTED]> writes:
>> Still, I don't understand well why config files need to be placed
>> outside the data directory, except for daring conform to FHS.
>
> The killer argument for it is that most of what is in $PGDATA should
be
>
"Takayuki Tsunakawa" <[EMAIL PROTECTED]> writes:
> Still, I don't understand well why config files need to be placed
> outside the data directory, except for daring conform to FHS.
The killer argument for it is that most of what is in $PGDATA should be
excluded from your normal filesystem backup m
From: "Bruce Momjian" <[EMAIL PROTECTED]>
> Takayuki Tsunakawa wrote:
>> In section "17.1. Setting Parameters", include directive is
described.
>> Why was this directive prepared? What usage is assumed? Is it for
>> GUI tools, or for placing custom parameters in other files?
>>
>> In section "17.
Neil has added this to CVS.
---
Jeremy Drake wrote:
> I came across this when looking through the patches_hold queue link that
> Bruce sent out.
>
> http://momjian.us/mhonarc/patches_hold/msg00162.html
>
> There is no patc
Takayuki Tsunakawa wrote:
> Hello,
>
> Let me ask about the background of configuration files. I couldn't
> find the relevant information in the 8.2 documentation. I'm sorry to
> cause you trouble.
>
> In section "17.1. Setting Parameters", include directive is described.
> Why was this directi
I wrote:
> I've committed a tentative patch along these lines to HEAD. Please
> test.
So I come home from dinner out, and find the buildfarm all red :-(
I'm not sure why I didn't see this failure in my own testing, but in
hindsight it's quite obvious that if the bgwriter is to take a hard
line a
Hubert FONGARNAND wrote:
> Hi,
>
> Is there a way to temporary disable a constraint (without drop and
> recreating it) in postgresql?
Sure, try ALTER TABLE ... DISABLE TRIGGER for the constraint trigger
name.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
Hello,
Let me ask about the background of configuration files. I couldn't
find the relevant information in the 8.2 documentation. I'm sorry to
cause you trouble.
In section "17.1. Setting Parameters", include directive is described.
Why was this directive prepared? What usage is assumed? Is i
From: "Tom Lane" <[EMAIL PROTECTED]>
I suggested that here
> http://archives.postgresql.org/pgsql-hackers/2007-01/msg00642.php
> but have received no feedback about it ...
I'm sorry, I missed it.
From: "Tom Lane" <[EMAIL PROTECTED]>
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> So: maybe the solution is to add a step to the drop sequence, namely
>> revoking any pending fsync request, before unlink.
> Perhaps we could have the bgwrite check the queue *if* it gets the
> ENOENT/EACCESS error and then re-check
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Perhaps we could have the bgwrite check the queue *if* it gets the
> ENOENT/EACCESS error and then re-check the queue for drops on that file?
Hmm ... seems a bit ugly, but then again I've not been able to come up
with a nice way of making the backends
I've just come across what seems to be a bug in our current planner
code. The existing code understands about transitive propagation of
equalities: given
SELECT * FROM a, b WHERE a.x = b.y AND a.x = 10
it will deduce b.y = 10 and then remove the a.x = b.y condition as
redundant. In gene
Tom Lane wrote:
> I just had a thought about fixing those Windows "permission denied"
> problems. The case that we believe we understand is where the bgwriter
> is trying to execute a previously-logged fsync request against a table
> file that is pending delete --- that is, actually has been unlin
Alvaro Herrera wrote:
Matthew T. O'Connor wrote:
This still seems ambiguous to me, how would I handle a maintenance
window of Weekends from Friday at 8PM though Monday morning at 6AM? My
guess from what said is:
mon dom dow starttime endtime
null null6 20:00 null
null null
Alvaro Herrera wrote:
I'd like to hear other people's opinions on Darcy Buskermolen proposal
to have a log table, on which we'd register what did we run, at what
time, how long did it last, how many tuples did it clean, etc. I feel
having it on the regular text log is useful but it's not good en
On Tue, Jan 16, 2007 at 06:04:07PM +0100, Enrico wrote:
> Hi,
> I written an index to improve similarity search like images search, string
> search etc...
> My index code is written in C and it is not linked with any dmbs, and I would
> to connect it to postgresql.
You probably want to build a G
On Tue, Jan 16, 2007 at 06:41:56PM +0100, Florian G. Pflug wrote:
> If you do that, maybe it would be the easiest and least confusing thing
> to just _always_ represent an xml document in utf-8, ignoring the
> client_encoding
> entirely for xml.
You can't do that. The server needs to parse the i
Peter Eisentraut wrote:
I wrote:
We need to decide on how to handle encoding information embedded in
xml data that is passed through the client/server encoding
conversion.
Tangentially related, I'm currently experimenting with a setup that
stores all xml data in UTF-8 on the server, convertin
Hi,
I written an index to improve similarity search like images search, string
search etc...
My index code is written in C and it is not linked with any dmbs, and I would
to connect it to postgresql.
Any suggest to begin my work?
Thanks
Enrico
--
If Bill Gates had a penny for everytime Windo
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> I imagine you've thought of this already but just in case, the cost of the
>> function call has to be combined with the selectivity to get this right. If
>> you can do an expensive but very selective clause first
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
And actually, when I look at the API docs, our case now seems to be
documented. Or am I misreading our situation. I have:
"If you call CreateFile on a file that is pending deletion as a result
of a previous call to DeleteF
On Tue, Jan 16, 2007 at 11:11:59AM -0500, Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > And actually, when I look at the API docs, our case now seems to be
> > documented. Or am I misreading our situation. I have:
>
> > "If you call CreateFile on a file that is pending deletion
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> With that taken care of, do I dare propose enabling autovacuum by
> default, so that further changes will be picked up quickly by the
> buildfarm?
Sure, let's try it and see what else breaks ;-)
regards, tom lane
--
Gregory Stark <[EMAIL PROTECTED]> writes:
> I imagine you've thought of this already but just in case, the cost of the
> function call has to be combined with the selectivity to get this right. If
> you can do an expensive but very selective clause first and save 100 cheap
> calls that almost alway
Magnus Hagander <[EMAIL PROTECTED]> writes:
> And actually, when I look at the API docs, our case now seems to be
> documented. Or am I misreading our situation. I have:
> "If you call CreateFile on a file that is pending deletion as a result
> of a previous call to DeleteFile, the function fails.
On Monday 15 January 2007 15:13, Darcy Buskermolen wrote:
> On Sunday 14 January 2007 08:45, Joshua D. Drake wrote:
> > > While we are talking autovacuum improvements, I'd like to also see some
> > > better logging, something that is akin to the important information of
> > > vacuum verbose being l
On Tuesday 16 January 2007 06:29, Alvaro Herrera wrote:
> elein wrote:
> > Have you made any consideration of providing feedback on autovacuum to
> > users? Right now we don't even know what tables were vacuumed when and
> > what was reaped. This might actually be another topic.
>
> I'd like to he
Andrew Dunstan wrote:
> Alvaro Herrera wrote:
> >Tom Lane wrote:
> >
> >
> >>Actually the reason it's not enabled by default today has nothing to do
> >>with either of those; it's
> >>
> >>3. Unexpected side effects on foreground processes, such as surprising
> >>failures of DROP DATABASE command
elein wrote:
> Have you made any consideration of providing feedback on autovacuum to users?
> Right now we don't even know what tables were vacuumed when and what was
> reaped. This might actually be another topic.
I'd like to hear other people's opinions on Darcy Buskermolen proposal
to have a
Alvaro Herrera wrote:
Tom Lane wrote:
Actually the reason it's not enabled by default today has nothing to do
with either of those; it's
3. Unexpected side effects on foreground processes, such as surprising
failures of DROP DATABASE commands. (See archives for details.)
Until (3) is addr
Simon Riggs wrote:
> Perhaps we should focus on the issues that might result, so that we
> address those before we spend time on the details of the user interface.
> Can we deadlock or hang from running multiple autovacuums?
If you were to run multiple autovacuum processes the way they are today,
Matthew T. O'Connor wrote:
> This still seems ambiguous to me, how would I handle a maintenance
> window of Weekends from Friday at 8PM though Monday morning at 6AM? My
> guess from what said is:
> mon dom dow starttime endtime
> null null6 20:00 null
> null null1 null
Tom Lane wrote:
> Actually the reason it's not enabled by default today has nothing to do
> with either of those; it's
>
> 3. Unexpected side effects on foreground processes, such as surprising
> failures of DROP DATABASE commands. (See archives for details.)
>
> Until (3) is addressed I don't
> Tom Lane wrote:
> > Instead, I'm thinking it might be time to re-introduce some notion of
> > function execution cost into the system, and make use of that info to
> > sort WHERE clauses into a reasonable execution order.
I imagine you've thought of this already but just in case, the cost of th
Gregory Stark wrote:
How do we handle this situation?
We go to insert a record in the heap, find no free space, so we extend the
table and insert it into a new page. Then we insert an index entry pointing
to the new tuple. Then some other backend (or bgwriter) comes along and
decides the ind
How do we handle this situation?
We go to insert a record in the heap, find no free space, so we extend the
table and insert it into a new page. Then we insert an index entry pointing
to the new tuple. Then some other backend (or bgwriter) comes along and
decides the index page is a good cand
Hi,
Is there a way to temporary disable a constraint (without drop and
recreating it) in postgresql?
Thanks
___
Ce message et les éventuels documents joints peuvent contenir des informations
confidentielles.
Au cas où il ne vous serait pas destiné, nou
Hi,
Most likely a waste of development effort --- have you got any evidence
of a real effect here? With 200 max_connections the size of the arrays
is still less than 10% of the space occupied by the buffers themselves,
ergo there isn't going to be all that much cache-thrashing compared to
what
On Tue, Jan 16, 2007 at 10:20:04AM +0900, Takayuki Tsunakawa wrote:
> From: "Magnus Hagander" <[EMAIL PROTECTED]>
> > But yeah, that's probably a good idea. A quick look at the code says
> we
> > should at least ask people who have this problem to give it a run
> with
> > logging at DEBUG5 which sh
On Mon, 2007-01-15 at 15:05 -0500, Tom Lane wrote:
> Brian Hurt <[EMAIL PROTECTED]> writes:
> > Non-developer here, but we use a lot of plpgsql functions at work. And
> > the functions we use fall into two broad, ill-defined catagories-
> > "expensive" functions and "cheap" functions. What I'd
46 matches
Mail list logo
