Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Looking at the send/receive functions for the text type, they
> communicate all data in the server encoding, so it seems reasonable to
> do this here as well.
Uh, no, I'm pretty sure there's a translation to the client encoding.
It's in a subroutine
Alvaro Herrera wrote:
Matthew T. O'Connor wrote:
Alvaro Herrera wrote:
pg_av_igroupmembers
groupid oid
month int
dom int
dow int
starttime timetz
endtime timetz
This seems to assume that the start and end time for an interval will be
on th
We need to decide on how to handle encoding information embedded in xml
data that is passed through the client/server encoding conversion.
Here is an example:
Client encoding is A, server encoding is B. Client sends an xml datum
that looks like this:
INSERT INTO table VALUES (xmlparse(documen
Alvaro Herrera wrote:
> Hmm, I can see having DROP DATABASE just stopping the autovacuum
> (since the work will be thrown away),
For that same reason DROP DATABASE could just cut all connections to the
database. Or at least queue up and wait until the session is over.
(The latter would corresp
On Thu, 2007-01-11 at 14:36 -0500, Neil Conway wrote:
> I don't think they need to be integrated any time soon, but if we were
> to design pg_dump and pg_dumpall from scratch, it seems more logical to
> use a single program
On thinking about this some more, it might be useful to factor much of
pg_
Tom Lane wrote:
> As near as I can tell, you're using CopyErrorData not because you
> need an actual copy but just because elog.c doesn't export any other
> API to let you see the current sqlerrorcode. Perhaps adding a
> function to return the top stack entry's sqlerrorcode would be a
> better API
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Possibly we could handle these by extending create/drop db to check
>> whether a process-connected-to-the-target-db is an autovac, and if so
>> send it a SIGINT and wait for the process to terminate, instead of
>> failing.
> Hmm, I ca
Tom Lane wrote:
> >> * contrib tests fail in their repeated drop/create database operations
> >> because autovac is connected to that database. (pl tests presumably
> >> have same issue.)
>
> The DROP is at risk, but CREATE is also at risk because autovac feels
> free to connect to template0. (
Matthew T. O'Connor wrote:
> Alvaro Herrera wrote:
> >I've been thinking how to improve autovacuum so that we can convince
> >more people that it can be enabled by default.
>
> I would like to see it enabled by default too, however the reason it
> isn't already enabled by default is that it ca
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Hmm, right. The mentioned problems are:
>> * manual ANALYZE issued by regression tests fails because autovac is
>> analyzing the same table concurrently.
This problem might have gone away since then --- I think we are now
taking a lock to ensure only
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.)
The referred to thread starts here:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I've been thinnking how to improve autovacuum so that we can convince
> more people that it can be enabled by default. Here are my thoughts.
> There are two areas of improvements:
> 1. scheduling, and
> 2. process handling, i.e., how to have multiple v
First, thanks for working on this. I hope to be helpful with the design
discussion and possibly some coding if I can find the time.
My initial reaction to this proposal is that it seems overly complex,
however I don't see a more elegant solution. I'm a bit concerned that
most users won't fig
[EMAIL PROTECTED] (Peter Eisentraut) writes:
> Log Message:
> ---
> Add support for xmlval IS DOCUMENT expression.
I don't think I trust your reverse-listing of IS DOCUMENT; you need
parens around the argument to be sure it is parsed the same way next
time, if it's not a trivial expression
Simon Riggs wrote:
On Fri, 2006-12-29 at 20:25 -0300, Alvaro Herrera wrote:
Christopher Browne wrote:
Seems to me that you could get ~80% of the way by having the simplest
"2 queue" implementation, where tables with size < some threshold get
thrown at the "little table" queue, and tables above
> 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 logged to a table or baring that the error_log. I'd like to be
> able to see what was done, and how long it took to do fo
On Sunday 14 January 2007 05:18, Alvaro Herrera wrote:
> I've been thinnking how to improve autovacuum so that we can convince
> more people that it can be enabled by default. Here are my thoughts.
> There are two areas of improvements:
>
> 1. scheduling, and
> 2. process handling, i.e., how to ha
I've been thinnking how to improve autovacuum so that we can convince
more people that it can be enabled by default. Here are my thoughts.
There are two areas of improvements:
1. scheduling, and
2. process handling, i.e., how to have multiple vacuum processes running
at any time.
I ripped out
18 matches
Mail list logo
