Oh, so this is the later version. Fine. Let me know when it is ready.
---
Nigel J. Andrews wrote:
>
>
> Okay, I've looked again at spi_exec and I believe I can fix the bug I
> introduced and the memory leak. However, I
Patch applied. Thanks.
---
Nigel J. Andrews wrote:
>
> Ok, below is the original email I sent, which I can not remember seeing come
> across the patches list. Please do read the assumptions since they might throw
> up p
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > ... Now, we just have the GUC value which does
> > propogate like the global one did. Does the postmaster still pass -dX
> > down to the child like it used to?
>
> Evidently not; else Patrick wouldn't be complaining that it doesn't
Jan Wieck wrote:
> Bruce Momjian wrote:
> >
> > Because the new 7.3 SSL code doesn't work (per Peter), and the author is
> > not responding, I am about to yank out that code. Peter suggests
> > ripping out all the new code rather than try to pick around and remove
> > just the broken parts.
>
>
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, I am back. I think the most promising proposal was from you, Tom:
> > http://candle.pha.pa.us/mhonarc/todo.detail/return/msg00012.html
>
> But that wasn't a specific proposal --- it was more or less an
> enumeration of the po
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Joe Conway wrote:
>> I can't think of a reason to have sub-second values, but it's
>> probably not worth changing it at this point.
> Most queries are sub-second in duration so it seemed logical to keep it
> the same as deadlock_timeout.
And machines g
Bruce Momjian <[EMAIL PROTECTED]> writes:
> ... Now, we just have the GUC value which does
> propogate like the global one did. Does the postmaster still pass -dX
> down to the child like it used to?
Evidently not; else Patrick wouldn't be complaining that it doesn't
work like it used to.
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, I am back. I think the most promising proposal was from you, Tom:
> http://candle.pha.pa.us/mhonarc/todo.detail/return/msg00012.html
But that wasn't a specific proposal --- it was more or less an
enumeration of the possibilities. What are we
Joe Conway wrote:
> Bruce Momjian wrote:
> > Uh, I thought you were changing connection_timeout, which is libpq and
> > not a GUC parameter
>
> Yup, you're right -- I got myself confused. Sorry.
>
> > not statement_timeout. Do we want sub-second
> > timeout values? Not sure.
> >
>
> I found
Uh, yes, it is a little confusing and I am not sure that patch is right
anymore. I haven't applied it.
Another issue is that we used to have a global debug_level variable that was
propogated to the client. Now, we just have the GUC value which does
propogate like the global one did. Does the p
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> (Looks at code...) Ah. It looks like -d to the postmaster no longer
>> means anywhere near what it used to. Bruce --- compare the handling
>> of -d in the backend (postgres.c lines 1251ff) with its handling in
>> the postmaster (pos
Bruce Momjian wrote:
> Uh, I thought you were changing connection_timeout, which is libpq and
> not a GUC parameter
Yup, you're right -- I got myself confused. Sorry.
> not statement_timeout. Do we want sub-second
> timeout values? Not sure.
>
I found it surprising that the statement_timeout
"Michael Paesold" <[EMAIL PROTECTED]> writes:
> Only vacuum will reset the insert times to the lowest possible!
> What does the vacuum code do?? :-]
It removes dead tuples. Dead tuples can only arise from update or
delete operations ... so you have not been telling us the whole
truth. An insert
Joe Conway wrote:
> I was working with this approach, when I noticed on *unmodified* cvs tip
> (about a day old):
>
> test=# set statement_timeout=1;
> SET
> test=# \dt
> ERROR: Query was cancelled.
> test=#
>
> At:
>http://developer.postgresql.org/docs/postgres/runtime-config.html#LOGGING
Tom Lane wrote:
> Patrick Welche <[EMAIL PROTECTED]> writes:
> > ... I was running postmaster -d4, yet the only
> > query I saw was the last LOG one. I pretty sure that I would see all queries
> > with -d3 before..
>
> It looked to me like you were just running with the recently-added
> frill to
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I already have a TODO item:
> > * Return proper effected tuple count from complex commands [return]
> > I am unsure if it will be fixed in 7.3 or not. It is still on the open
> > items list, and I think we have a general plan to
The actual checking is done in INSERT/UPDATE/COPY. However, the
checking is currently very limited: every byte of a mutibyte character
must be greater than 0x7f.
> Tatsuo,
>
> do I understand correctly that there is no checking for
> convertion between local charset and unicode in insert
Okay, I've looked again at spi_exec and I believe I can fix the bug I
introduced and the memory leak. However, I have only looked quickly and not
made these most recent changes to the execp version nor to the plpython
code. Therefore I am not attaching a patch at the moment, just mentioning that
Tatsuo Ishii wrote:
>
> > You should have chosen a better foundation. pg_bench is notorious for
> > producing results that are (a) nonrepeatable and (b) not relevant to
> > a wide variety of situations. All it really tells you about is the
> > efficiency of a large number of updates to a small
> You should have chosen a better foundation. pg_bench is notorious for
> producing results that are (a) nonrepeatable and (b) not relevant to
> a wide variety of situations. All it really tells you about is the
> efficiency of a large number of updates to a small number of rows.
You might want
On 24 Sep 2002, Neil Conway wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > It occurs to me that opening web page on www.postgresql.org, asking the
> > user to select the mirror, is rather unprofessional.
>
> I agree; not only that, it has advertisements on it. What's the
> justification fo
On Wed, 25 Sep 2002, Jan Wieck wrote:
> With the number of screws our product has, there are so many
> possible combinations that don't work, why worry about one more
> or less?
That's just silly, so I won't even bother replying.
> Seriously, if you move around files, make symlinks or adjust
>
Tom Lane wrote:
> It might work to measure time since the start of the whole process, or
> until the timeout target, rather than accumulating adjustments to the
> "remains" count each time through. In other words something like
>
> at start: targettime = time() + specified-timeout
>
>
> Only vacuum will reset the insert times to the lowest possible!
> What does the vacuum code do?? :-]
Please see the manual and the extensive discussions on this point in the
archives. This behaviour is well known -- though undesirable. It is an
effect of the multi-version concurrency control sy
Update:
> vacuum full; vacuum analyze;
> select bench_invoice(1000); select bench_invoice(1000); ... (10 times)
>
> It seems performance is degrading with every insert!
> Here is the result (time in seconds in bench_invoice(), commit between
> selects just under a second)
>
> 13, 24, 36, 47, 58,
Tom Lane wrote:
> "Michael Paesold" <[EMAIL PROTECTED]> writes:
> > To insert another 10562 rows takes about 12 minutes now!!!
>
> > As I said I wrote a function to insert the rows (PL/pgSQL). All values
were
> > inserted inside a single function call; I always though that a function
call
> > wo
Patrick Welche <[EMAIL PROTECTED]> writes:
> ... I was running postmaster -d4, yet the only
> query I saw was the last LOG one. I pretty sure that I would see all queries
> with -d3 before..
It looked to me like you were just running with the recently-added
frill to log only queries that cause er
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I already have a TODO item:
> > * Return proper effected tuple count from complex commands [return]
> > I am unsure if it will be fixed in 7.3 or not. It is still on the open
> > items list, and I think we have a general plan to
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I already have a TODO item:
> * Return proper effected tuple count from complex commands [return]
> I am unsure if it will be fixed in 7.3 or not. It is still on the open
> items list, and I think we have a general plan to fix it.
I got distracte
Michael Paesold wrote:
> Tom Lane wrote:
>
> > "Michael Paesold" <[EMAIL PROTECTED]> writes:
> > > I have come across a problem (bug?) with PL/pgSQL GET DIAGNOSTICS.
> >
> > Hm. This seems to be SPI's version of the same definitional issue
> > we're contending with for status data returned from
Joe Conway <[EMAIL PROTECTED]> writes:
> ...it seems that the connection timeout can only be specified to the nearest
> second. Given that, is there any reason not to use time() instead of
> gettimeofday()?
As the code stands it's pretty necessary. Since we'll go around the
loop multiple times
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Bruce Momjian writes:
>> I am getting errors when doing a checkout, related to Marc's splitting
>> up the CVS tree into modules:
> This split should be reverted.
I'm for that ... even if we have to do *another* set of fresh CVS
checkouts :-(
"Michael Paesold" <[EMAIL PROTECTED]> writes:
> To insert another 10562 rows takes about 12 minutes now!!!
> As I said I wrote a function to insert the rows (PL/pgSQL). All values were
> inserted inside a single function call; I always though that a function call
> would be executed inside a tran
I'm trying to get the client utilities to compile under win32/VS.net per
http://developer.postgresql.org/docs/postgres/install-win32.html.
I was able to do this successfully using the 7.2.2 tarball, but using current
7.3devel there are a number of minor issues (missing defines, adjustments to
Bruce Momjian writes:
> I am getting errors when doing a checkout, related to Marc's splitting
> up the CVS tree into modules:
This split should be reverted. It was poorly thought out to begin with,
and since all the candidates have been moved to their own homes now it's
obsolete as well. It j
Tom Lane wrote:
> "Michael Paesold" <[EMAIL PROTECTED]> writes:
> > To insert another 10562 rows takes about 12 minutes now!!!
>
> See
> http://www.ca.postgresql.org/users-lounge/docs/7.2/postgres/populate.html
> particularly the point about not committing each INSERT as a separate
> transaction.
Tom Lane wrote:
> "Michael Paesold" <[EMAIL PROTECTED]> writes:
> > I have come across a problem (bug?) with PL/pgSQL GET DIAGNOSTICS.
>
> Hm. This seems to be SPI's version of the same definitional issue
> we're contending with for status data returned from an interactive
> query: SPI is curren
"Michael Paesold" <[EMAIL PROTECTED]> writes:
> I have come across a problem (bug?) with PL/pgSQL GET DIAGNOSTICS.
Hm. This seems to be SPI's version of the same definitional issue
we're contending with for status data returned from an interactive
query: SPI is currently set up to return the sta
Tom Lane wrote:
> I said:
> > The ordering of these shutdown hooks is the reverse of the ordering
> > of the startup initialization of the modules. It looks like we'll
> > need to rejigger the startup ordering ... and it also looks like that's
> > going to be a rather ticklish issue. (See commen
I said:
> The ordering of these shutdown hooks is the reverse of the ordering
> of the startup initialization of the modules. It looks like we'll
> need to rejigger the startup ordering ... and it also looks like that's
> going to be a rather ticklish issue. (See comments in BaseInit and
> InitP
"Michael Paesold" <[EMAIL PROTECTED]> writes:
> To insert another 10562 rows takes about 12 minutes now!!!
See
http://www.ca.postgresql.org/users-lounge/docs/7.2/postgres/populate.html
particularly the point about not committing each INSERT as a separate
transaction.
rega
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Can we wait for someone to be injured in a car accident before putting
> in heavy seat belts?
Not the analogy you wanted to make ... if you knew there was a serious
risk, that's called negligence in most American courts. Ask Ford about
the Pinto ...
Bruce Momjian wrote:
>
> scott.marlowe wrote:
> > On Wed, 25 Sep 2002, Jan Wieck wrote:
> > So, should we take out seatbelts from cars, safeties from guns, and have
> > everyone run about with sharp sticks too? :-) I know that the second we
> > make something more idiot proof, someone will make
Hi,
I am wondering about bad INSERT performance compared against the speed of
COPY. (I use 7.2.2 on RedHat 7.2)
I have a table with about 30 fields, some constraints, some indexes, some
foreign key constraints. I use COPY to import old data. Copying about
10562 rows takes about 19 seconds.
For
"scott.marlowe" wrote:
> [...]
> But, I have a few more questions about the signature file solution. Is
> the signature file going to be updated by date or something everytime the
> database is started up and shut down? If not, then it's quite possible
> that someone could copy the pg_xlog dir s
scott.marlowe wrote:
> On Wed, 25 Sep 2002, Jan Wieck wrote:
> So, should we take out seatbelts from cars, safeties from guns, and have
> everyone run about with sharp sticks too? :-) I know that the second we
> make something more idiot proof, someone will make a better idiot, but
> that does
On Wed, 25 Sep 2002, Jan Wieck wrote:
> "scott.marlowe" wrote:
>
> > Having a FILE called pg_xlog isn't the fix here, it's the result of the
> > fix, which is to take all the steps of moving the pg_xlog directory and
> > put them into one script file the user doesn't need to understand to do it
Jan Wieck wrote:
> Bruce Momjian wrote:
> >
> > Because the new 7.3 SSL code doesn't work (per Peter), and the author is
> > not responding, I am about to yank out that code. Peter suggests
> > ripping out all the new code rather than try to pick around and remove
> > just the broken parts.
>
>
Jan Wieck wrote:
> > It's almost like people *don't* want to put this in the config file
> > or something
>
> I want to have it it the config file. Just that that doesn't
> prevent anything. And if we have a "signature" file in the xlog
> and data directories, you can make it dummy-safe as yo
"scott.marlowe" wrote:
> Having a FILE called pg_xlog isn't the fix here, it's the result of the
> fix, which is to take all the steps of moving the pg_xlog directory and
> put them into one script file the user doesn't need to understand to do it
> right. I.e. idiot proof the system as much as
Curt Sampson wrote:
>
> On Tue, 24 Sep 2002, Jan Wieck wrote:
>
> > And AFAICS it is scary only because screwing that up will simply corrupt
> > your database. Thus, a simple random number (okay, and a timestamp of
> > initdb) in two files, one in $PGDATA and one in $PGXLOG would be a
> > totall
I am getting errors when doing a checkout, related to Marc's splitting
up the CVS tree into modules:
C pgsql/contrib/earthdistance/Makefile
cvs checkout: move away
pgsql/contrib/earthdistance/README.earthdistance; it is in the way
C pgsql/contrib/earthdista
Hi,
I have come across a problem (bug?) with PL/pgSQL GET DIAGNOSTICS.
In a PL/pgSQL function I want to insert into a table and get the OID back.
That usually works with
GET DIAGNOSTICS last_oid = RESULT_OID;
right after the insert statement.
But if the table that I insert to has a rule (or per
Neil Conway <[EMAIL PROTECTED]> writes:
> I think it's worthwhile implementing this, if possible.
I wasn't objecting (I work for Red Hat, remember ;-)). I was just
saying there's a limit to the messiness I think we should accept.
>> The SysV API provides a reliable interlock to prevent this sce
In 7.3, SHOW returns a query results that can be resturned to jdbc. We
are using beta1/2 now, so you can test that from ftp.postgresql.org.
---
[ ?GB2312?] wrote:
> thank you for your information.
> I want to use the imfor
thank you for your information.
I want to use the imformation of show or other utilities sql in jdbc
interface. generally resultset is empty when such sql is execute. I want
to get the information like psql. How can I do?
Thanks again.
You should ask this on general, and be mo
Es facil, pruébalo ...
¡Hola! Recibes este mensaje en nombre de Francisco, que está
disfrutando de las ventajas de ser un usuario de Es-Fácil!
A través de nuestro servicio, podrás recibir información en tu
buzón de correo, y además cobrar por ello. Además, te ofrecemos
otras vías para aumentar tu
Tom Lane <[EMAIL PROTECTED]> writes:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > I'd like to enable PostgreSQL to use large TLB pages, if the OS
> > and processor support them.
>
> Hmm ... it seems interesting, but I'm hesitant to do a lot of work
> to support something that's only available on
On Wed, 25 Sep 2002, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I don't see the gain of having a file called pg_xlog vs. using GUC.
>
> Well, the point is to have a safety interlock --- but I like Jan's
> idea of using matching identification files in both directories.
> Wit
Dear Momjian£¬
hello,
I want to make the show variable SQL to return message like
pgresult. how can I revise the source code? Any suggestion?
I really need you help.
Jinqiang Han
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I don't see the gain of having a file called pg_xlog vs. using GUC.
Well, the point is to have a safety interlock --- but I like Jan's
idea of using matching identification files in both directories.
With that, a GUC variable seems just fine.
Jan Wieck wrote:
> Bruce Momjian wrote:
> >
> > Because the new 7.3 SSL code doesn't work (per Peter), and the author is
> > not responding, I am about to yank out that code. Peter suggests
> > ripping out all the new code rather than try to pick around and remove
> > just the broken parts.
>
>
Bruce Momjian wrote:
>
> Because the new 7.3 SSL code doesn't work (per Peter), and the author is
> not responding, I am about to yank out that code. Peter suggests
> ripping out all the new code rather than try to pick around and remove
> just the broken parts.
Agreed. I allways wondered what
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, I reinstalled the proper earthdistance.out/sql files and it passes
> regession now. Sorry for the mistake.
Looks good here too. Thanks.
regards, tom lane
---(end of broadcast)--
Scott Shattuck <[EMAIL PROTECTED]> writes:
> Sorry I can't add any insight at this level...but I can say that it
> would be significant to my customer(s) and my ability to recommend PG to
> future "ex-Oracle users" ;) to see a fix make it into the 7.3 final.
Rest assured that it *will* be fixed i
On Wed, 2002-09-25 at 09:52, Tom Lane wrote:
> I've identified the reason for the occasional "can't wait without a PROC
> structure" failures we've seen reported. I had been thinking that this
> must occur during backend startup, before MyProc is initialized ...
> but I was mistaken. Actually, i
I've identified the reason for the occasional "can't wait without a PROC
structure" failures we've seen reported. I had been thinking that this
must occur during backend startup, before MyProc is initialized ...
but I was mistaken. Actually, it happens during backend shutdown,
and the reason is
I do.
The problem is that if you change the location of pg_xlog and do one thing
wrong, poof, your database is now corrupt. Like Tom said earlier, imagine
a command like switch called "please-dont-scram-my-database" and if you
ever forgot it then your data is gone.
Is it better to move such
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> build cleanly, just wanna make sure tha i haven't overlooked anything...
The tarball seems to match my local tree ...
regards, tom lane
---(end of broadcast)---
TIP 3: if pos
I don't see the gain of having a file called pg_xlog vs. using GUC.
---
scott.marlowe wrote:
> On Wed, 25 Sep 2002, Curt Sampson wrote:
>
> > On Tue, 24 Sep 2002, Jan Wieck wrote:
> >
> > > And AFAICS it is scary only bec
On Wed, 25 Sep 2002, Curt Sampson wrote:
> On Tue, 24 Sep 2002, Jan Wieck wrote:
>
> > And AFAICS it is scary only because screwing that up will simply corrupt
> > your database. Thus, a simple random number (okay, and a timestamp of
> > initdb) in two files, one in $PGDATA and one in $PGXLOG wo
build cleanly, just wanna make sure tha i haven't overlooked anything...
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Because the new 7.3 SSL code doesn't work (per Peter), and the author is
not responding, I am about to yank out that code. Peter suggests
ripping out all the new code rather than try to pick around and remove
just the broken parts.
--
Bruce Momjian| http://candle.pha.
OK, I reinstalled the proper earthdistance.out/sql files and it passes
regession now. Sorry for the mistake.
---
Bruno Wolff III wrote:
> > > AFAICT, earthdistance is nowhere near passing yet :-(. It looks to
> > > me lik
> > AFAICT, earthdistance is nowhere near passing yet :-(. It looks to
> > me like the regression test is depending on the cube-based features
> > that we decided to hold off for 7.4. Bruno, is that right?
>
> It shouldn't be. When I resubmitted the patch I intended to take out
> all of the cub
On Tue, Sep 24, 2002 at 23:57:29 -0400,
Tom Lane <[EMAIL PROTECTED]> wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > How do I run the regression tests for /contrib stuff?
>
> make
> make install
> make installcheck
>
> AFAICT, earthdistance is nowhere near passing yet :-(. It looks to
Just got this. :-)
Michael
- Forwarded message from Akim Demaille <[EMAIL PROTECTED]> -
To: Michael Meskes <[EMAIL PROTECTED]>
Subject: Re: bison 1.49 release
From: Akim Demaille <[EMAIL PROTECTED]>
Date: 25 Sep 2002 11:32:42 +0200
> "Michael" == Michael Meskes <[EMAIL PROTECTED]>
On Tue, Sep 24, 2002 at 09:53:10AM -0400, Tom Lane wrote:
> *Everyone* who checks out from our CVS needs to build the bison output
> files. There seem to be quite a few such people; they will all be
I though time stamping is done to make sure the .c file is newer than
the .y one.
> forced to up
Alvaro Herrera kirjutas K, 25.09.2002 kell 02:45:
> Hannu Krosing dijo:
>
> > For me it feels assymmetric (unless we will make attislocal also int
> > instead of boolean ;). This assymetric nature will manifest itself when
> > we will have ADD COLUMN which can put back the DROP ONLY COLUMN and i
79 matches
Mail list logo
