"Takayuki Tsunakawa" <[EMAIL PROTECTED]> writes:
> BTW, why does the bgwriter try to open and write the pages of already
> dropped relations?
It does not; the problem is with stale fsync requests.
> If the relation being dropeed has
> already been registered in the list of files to be fsynced, is
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>> Are we going to ensure that what we hand back to another client has
>> an appropriate encding decl? Or will we just remove it in all cases?
> We can't do the former, but the latter might be doable.
I think that in the case of
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 should then log exactly what the errorcode
was.
> Or are you seeing more places th
I'm becoming confused by the encoding conversion API, in particular by
the function
pg_do_encoding_conversion(unsigned char *src, int len, int src_encoding,
int dest_encoding);
Since the function in various circumstances passes back src directly,
you might get back a string that encompasses th
On Monday 15 January 2007 15:23, Joshua D. Drake wrote:
> 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
>
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, converting it back to the
serv
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 logged to a table or baring that the err
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 logged to a table or baring that the error_log. I'd
> > like to be
Andrew Dunstan wrote:
> We should error out on any explicit encoding that conflicts with the
> client encoding. I don't like the idea of just ignoring an explicit
> encoding decl.
That is an instance of the problem of figuring out which encoding names
are equivalent, which I believe we have settl
Peter Eisentraut wrote:
> Florian G. Pflug wrote:
>> Couldn't the server change the encoding declaration inside the xml to
>> the correct
>> one (the same as client_encoding) before returning the result?
>
> The data type output function doesn't know what the client encoding is
> or whether the dat
Florian G. Pflug wrote:
> Sorry, I don't get it - how does this work for text, then? It works
> there to dynamically recode the data from the database encoding to
> the client encoding before sending it off to the client, no?
Sure, but it doesn't change the text inside the datum.
--
Peter Eisentr
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Here it is.
>
> I'd drop the InitProcess API change, which touches many more places than
> you really need, and just have InitProcess check IsAutoVacuumProcess(),
> which should be valid by the time control gets to it. This is more
Peter Eisentraut wrote:
Florian G. Pflug wrote:
Couldn't the server change the encoding declaration inside the xml to
the correct
one (the same as client_encoding) before returning the result?
The data type output function doesn't know what the client encoding is
or whether the data will be s
Joachim Wieland wrote:
> On Thu, Jan 11, 2007 at 09:59:14PM +0100, Magnus Hagander wrote:
>> .. appears to have killed win32. It did kill my manual MSVC builds, but
>> it also seems to have killed win32 buildfarm members yak and snake:
>> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=yak&dt=200
On 1/12/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
> What do you think about setting up the buildfarm clients
> with the users they are willing to test patches for, as opposed to
> having the patch system track who is are trusted users? My thoughts
> are the former is
Neil Conway <[EMAIL PROTECTED]> writes:
> BTW, your proposal would still pushdown all qualifiers, right?
Yeah, I have no intention of readopting xfunc in the near future ...
especially seeing that it's possible for the user to force that
sort of thing if he really has to.
SELECT * FROM (S
Florian G. Pflug wrote:
> Couldn't the server change the encoding declaration inside the xml to
> the correct
> one (the same as client_encoding) before returning the result?
The data type output function doesn't know what the client encoding is
or whether the data will be shipped to the client a
Martijn van Oosterhout wrote:
> The only real alternative is to treat xml more like bytea than text
> (ie, treat the input as a stream of octets).
bytea isn't "treated" any different than other data types. You just
have to take care in the client that you escape every byte greater than
127. Th
On Mon, 2007-01-15 at 15:05 -0500, Tom Lane wrote:
> maybe we should just do the constant for starters and see how many
> people really want to write C-code estimators ...
+1
BTW, your proposal would still pushdown all qualifiers, right?
Hellerstein's xfunc work discusses situations in which it m
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 like as a user is
> some way to tell the planner "this fun
Neil Conway wrote:
On Mon, 2007-01-15 at 10:51 -0800, Richard Troy wrote:
I therefore propose that the engine evaluate -
benchmark, if you will - all functions as they are ingested, or
vacuum-like at some later date (when valid data for testing may exist),
and assign a cost relative to what
On Mon, 15 Jan 2007, Neil Conway wrote:
> On Mon, 2007-01-15 at 10:51 -0800, Richard Troy wrote:
> > I therefore propose that the engine evaluate -
> > benchmark, if you will - all functions as they are ingested, or
> > vacuum-like at some later date (when valid data for testing may exist),
> > an
On Mon, 2007-01-15 at 10:51 -0800, Richard Troy wrote:
> I therefore propose that the engine evaluate -
> benchmark, if you will - all functions as they are ingested, or
> vacuum-like at some later date (when valid data for testing may exist),
> and assign a cost relative to what it already knows -
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> DEBUG5 is going to be a bit voluminous, but let's try that if we can.
> Perhaps we should switch down the DEBUG level of it, at least until we
> know what happens?
That would have to wait on another update release, or at least someo
On Mon, 15 Jan 2007, Tom Lane wrote:
> So I've been working on the scheme I suggested a few days ago of
> representing "equivalence classes" of variables explicitly, and avoiding
> the current ad-hocery of generating and then removing redundant clauses
> in favor of generating only the ones we wan
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> 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 should then log exactly what the errorcode was.
>> Or are you
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Note that currently there's no way for a backend to know whether another
> backend is autovacuum or not. I thought about adding a flag to PGPROC,
> but eventually considered it ugly,
No, that was exactly the way I thought we'd do it. One thing to note
Magnus Hagander <[EMAIL PROTECTED]> writes:
> 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 should then log exactly what the errorcode was.
> Or are you seeing more places th
Tom Lane wrote:
> Also see Peter's nearby suggestion that we ought to wait instead of fail
> for *all* cases of somebody attached to the database. This would adapt
> readily enough to that.
>
> I was complaining elsewhere that I didn't want to use a sleep loop
> for fixing the fsync-synchronizat
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> pg_control is certainly not ever deleted or renamed, and in fact I
>>> believe there's an LWLock enforcing that only one PG process at a time
>>> is even touching it. So we need another theory to explain this one
Peter Eisentraut wrote:
Am Montag, 15. Januar 2007 17:33 schrieb Florian G. Pflug:
Would this mean that if the client_encoding is for example latin1, and I
retrieve an xml document uploaded by a client with client_encoding utf-8
(and thus having encoding="c" in the xml tag), that I would get a
d
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> If we go this route it seems like we'll need four more columns in
>> pg_proc (cost estimation function OID, rowcount estimation function OID,
>> fallback cost constant, fallback rowcount constant).
> What would the fallbacks be fo
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
A simple constant would probably be enough. If we want anything fancier
than that, it should be up to the author of the function to define the
cost model as well. I'm envisioning that you could attach a custom cost
function to a us
On Mon, Jan 15, 2007 at 05:47:37PM +0100, Peter Eisentraut wrote:
> Am Montag, 15. Januar 2007 17:33 schrieb Florian G. Pflug:
> > Would this mean that if the client_encoding is for example latin1, and I
> > retrieve an xml document uploaded by a client with client_encoding utf-8
> > (and thus havi
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Would a simple constant value be workable, or do we need some more
>> complex model (and if so what)?
> A simple constant would probably be enough. If we want anything fancier
> than that, it should be up to the author of the fun
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.
That sounds like a straightforward idea.
This example
would be fixed with even a
Am Montag, 15. Januar 2007 17:33 schrieb Florian G. Pflug:
> Would this mean that if the client_encoding is for example latin1, and I
> retrieve an xml document uploaded by a client with client_encoding utf-8
> (and thus having encoding="c" in the xml tag), that I would get a
> document with latin1
Peter Eisentraut wrote:
Am Montag, 15. Januar 2007 12:42 schrieb Nikolay Samokhvalov:
On 1/15/07, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
Client encoding is A, server encoding is B. Client sends an xml datum
that looks like this:
INSERT INTO table VALUES (xmlparse(document '...'));
Assum
So I've been working on the scheme I suggested a few days ago of
representing "equivalence classes" of variables explicitly, and avoiding
the current ad-hocery of generating and then removing redundant clauses
in favor of generating only the ones we want in the first place. Any
clause that looks l
Pavan Deolasee wrote:
> 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
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I'm cooking a patch for this which seems pretty reasonable, but I'm
> having a problem: what mechanism do we have for waiting until a process
> exits?
None, and I think you probably don't want to sit on the database lock
while waiting, either. I was en
Hi Jim,
The solution was to put " set search_path=new_path" in Connection Settings
in the ODBC configuration (on Page 2 of the dialog).
Carlo
-Original Message-
From: Jim Nasby [mailto:[EMAIL PROTECTED]
Sent: January 14, 2007 10:07 PM
To: Carlo Stonebanks
Cc: [EMAIL PROTECTED]; PGSQL Ha
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,
On Dec 19, 2006, at 12:06 PM, Carlo Stonebanks wrote:
I would like to create an ODBC DSN for a user to export files rom
Acccess to
a safe area. Right now, all tables are being dumped to public by
default.
In order to use the one-click export option for Access, I would
like to have
the con
Neil Conway wrote:
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 u
Tom Lane wrote:
> The DROP is at risk, but CREATE is also at risk because autovac feels
> free to connect to template0. (One of the reasons we invented template0
> was to prevent CREATE DATABASE failures due to someone-else-connected,
> but autovac has broken that idea.)
ALTER DATABASE RENAME al
Am Montag, 15. Januar 2007 12:42 schrieb Nikolay Samokhvalov:
> On 1/15/07, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> > Client encoding is A, server encoding is B. Client sends an xml datum
> > that looks like this:
> >
> > INSERT INTO table VALUES (xmlparse(document ' > encoding="C"?>...'));
On 1/15/07, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
Client encoding is A, server encoding is B. Client sends an xml datum
that looks like this:
INSERT INTO table VALUES (xmlparse(document '...'));
Assuming that A, B, and C are all distinct, this could fail at a number
of places.
I sugges
48 matches
Mail list logo
