At 16:46 15/04/02 +0200, Mario Weilguni wrote:
And how about getting database internals via SQL-functions - e.g. getting
BLCSIZE, LOBBLCSIZE?
ISTM that there would be some merit in making a selection of compile-time
options available via SQL. Is this worth considering?
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
1 - All SETs are rolled back in aborted transaction
2 - SETs are ignored after transaction abort
3 - All SETs are honored in aborted transaction
? - Have SETs vary in behavior depending on variable
My
Curt Sampson wrote:
On Tue, 23 Apr 2002, mlw wrote:
On a system that has neither read-ahead nor sorting of I/O requests,
yes. Which systems are you using that provide neither of these
facilities?
This only happens if the OS can organize the I/O requests in such a manner. It
is
Hi!
I seem to have trouble returning large strings of text from stored procedures
(coded in C), It works fine for smaller data?
And elog prints out the result nicely; but when the result is returned it
makes the server disconnect I use the standard Datum methods (actually
I've tried any
Hiroshi Inoue wrote:
I'd be willing to consider making the behavior variable-specific
if anyone can identify particular variables that need to behave
differently. But overall I think it's better that the behavior
be consistent --- so you'll need a good argument to convince me
that
Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
...Based on that data, I'd vote against making any changes to NAMEDATALEN.
It looked to me like the cost for going to NAMEDATALEN = 64 would be
reasonable. Based on these numbers I'd have a problem with 128 or more.
But as you
OK, I have applied the following patch to fix these warnings. However,
I need Mario to confirm these are the right changes. Thanks.
---
Peter Eisentraut wrote:
This patch does not compile correctly:
Curt Sampson wrote:
At 12:41 PM 4/23/02 -0400, Bruce Momjian wrote:
This is an interesting point, that an index scan may fit in the cache
while a sequential scan may not.
If so, I would expect that the number of pages read is significantly
smaller than it was with a sequential scan. If
I wanted to correct the patch this evening after work, and will check your changes.
Thanks!
-Ursprüngliche Nachricht-
Von: Bruce Momjian [mailto:[EMAIL PROTECTED]]
Gesendet: Mittwoch, 24. April 2002 16:03
An: Peter Eisentraut
Cc: Mario Weilguni; [EMAIL PROTECTED]
Betreff: Re: [HACKERS]
Philip Warner [EMAIL PROTECTED] writes:
At 16:46 15/04/02 +0200, Mario Weilguni wrote:
And how about getting database internals via SQL-functions - e.g. getting
BLCSIZE, LOBBLCSIZE?
ISTM that there would be some merit in making a selection of compile-time
options available via SQL. Is
OK, would people please vote on how to handle SET in an aborted
transaction?
at the end, should 'x' equal:
1 - All SETs are rolled back in aborted transaction
2 - SETs are ignored after transaction abort
3 - All SETs are honored in aborted transaction
? -
[Please CC any replies, I'm subscribed nomail]
As promised I've given it a bit of polish and it's actually almost useful.
You can have a look at it http://svana.org/kleptog/pgsql/pgfsck.html
Just unpack the files into a directory. It's just a perl script with two
modules so no compiling
Thomas Lockhart [EMAIL PROTECTED] writes:
Let me give you some examples. We might someday have nested
transactions, or transactions which can be resumed from the point of
failure. We *might* want to be able to affect recovery behaviors, and we
*might* want to do so with something like
Steffen Nielsen [EMAIL PROTECTED] writes:
Any Ideas why? Are there restriction on the size of text a stored procedure
can return?
One gig ...
It's hard to guess what you're doing wrong when you haven't shown us
your code.
regards, tom lane
I was thinking in something independent from the executor, simply a variable
that recommends or not the use of a particular index, it could be obtained
from user, and so it could be improved(a factor lower than 1) on planner.
How about something like this?
- Original Message -
From:
Here's today's tidbit for those who like to argue about nitty little
details of behavior ...
Presently, the parser (in particular gram.y) has quite a few special
transformations for certain type and function names. For example,
You write You get
char(N)
Am Mittwoch, 24. April 2002 16:03 schrieb Bruce Momjian:
OK, I have applied the following patch to fix these warnings. However,
I need Mario to confirm these are the right changes. Thanks.
I've checked it and works fine, but the memcpy() prototype says it should be
void pointers. Will this
Thomas Lockhart writes:
Right. The two areas which come to mind are integer availability and the
timezone support (as you might know we support *three* different time
zone models). At the moment, none of the developers know the features
supported on the platforms we claim to support. Which
It depends. QNX4 may be used with GCC, in which case it does have long long.
I am not sure if that combination will play along with Postgres, but it
should not be assumed impossible.
- Original Message -
From: Peter Eisentraut [EMAIL PROTECTED]
To: Thomas Lockhart [EMAIL PROTECTED]
Cc:
Tom Lane writes:
This could usefully be combined with the nearby thread about recording
configuration options (started by Thomas). I'd be inclined to make it
a low-footprint affair where you do something like
select compilation_options();
and you get back a long textual list of
On Wed, 24 Apr 2002, Michael Loftis wrote:
Vote number 1 -- ROLL BACK
I agree.. Number 1 - ROLL BACK
Bruce Momjian wrote:
OK, would people please vote on how to handle SET in an aborted
transaction? This vote will allow us to resolve the issue and move
forward if needed.
In the
Tom Lane writes:
You write You get
char(N) pg_catalog.bpchar
pg_catalog.char pg_catalog.char (not bpchar)
real pg_catalog.float4
myschema.real myschema.real (not float4)
Igor Kovalenko writes:
It depends. QNX4 may be used with GCC, in which case it does have long long.
I am not sure if that combination will play along with Postgres, but it
should not be assumed impossible.
The point is, it should not be assumed possible.
--
Peter Eisentraut [EMAIL
Thanks Dave.
I will create the project at gborg.postgresql.org on
Friday :)
You might want to look at
http://gborg.postgresql.org.
Regards, Dave.
___
Yahoo! Empregos
O trabalho dos seus sonhos
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
select compilation_options();
This assumes that compilation options only matter in the server and that
only SQL users would be interested in them. In fact, compilation options
affect client and utility programs as well, and it's
We have had several threads about index usage, specifically when PostgreSQL has
the choice of using one or not.
There seems to be a few points of view:
(1) The planner and statistics need to improve, so that erroneously using an
index (or not) happens less frequently or not at all.
(2) Use
Bruce Momjian wrote:
OK, would people please vote on how to handle SET in an aborted
transaction? This vote will allow us to resolve the issue and move
forward if needed.
In the case of:
SET x=1;
BEGIN;
SET x=2;
query_that_aborts_transaction;
Tom Lane wrote:
Right offhand, I am not seeing anything here for which there's a
compelling case not to roll it back on error.
In fact, I have yet to hear *any* plausible example of a variable
that we would really seriously want not to roll back on error.
Honetsly I don't understand
OK, the votes are in:
#1
Lamar Owen
Jan Wieck
Tom Lane
Bruce Momjian
Joe Conway
Curt Sampson
Michael Loftis
Vince Vielhaber
Sander Steffann
#2
Bradley McLean
Hiroshi Inoue wrote:
Tom Lane wrote:
Right offhand, I am not seeing anything here for which there's a
compelling case not to roll it back on error.
In fact, I have yet to hear *any* plausible example of a variable
that we would really seriously want not to roll back on error.
Jan Wieck wrote:
Hiroshi Inoue wrote:
Tom Lane wrote:
Right offhand, I am not seeing anything here for which there's a
compelling case not to roll it back on error.
In fact, I have yet to hear *any* plausible example of a variable
that we would really seriously want not to
Hiroshi Inoue [EMAIL PROTECTED] writes:
Honetsly I don't understand what kind of example you
expect. How about the following ?
[The curren schema is schema1]
begin;
create schema foo;
set search_path = foo;
create table t1 ();
.
[error occurs]
Bruce Momjian wrote:
OK, the votes are in:
#1
Lamar Owen
Jan Wieck
Tom Lane
Bruce Momjian
Joe Conway
Curt Sampson
Michael Loftis
Vince Vielhaber
Sander Steffann
#2
Bradley McLean
Hiroshi Inoue wrote:
Bruce Momjian wrote:
OK, the votes are in:
#1
Lamar Owen
Jan Wieck
Tom Lane
Bruce Momjian
Joe Conway
Curt Sampson
Michael Loftis
Vince Vielhaber
Sander Steffann
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
OK, the votes are in:
#1
Lamar Owen
Jan Wieck
Tom Lane
Bruce Momjian
Joe Conway
Curt Sampson
Michael Loftis
Vince
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
OK, the votes are in:
#1
Lamar Owen
Jan Wieck
Tom Lane
Bruce Momjian
Joe Conway
Curt Sampson
Bruce Momjian wrote:
I voted not only ? but also 2 and 3.
And haven't I asked twice or so if it's a vote ?
Yes, it is a vote, and now that we see how everyone feels, we can
decide what to do.
Hiroshi, you can't vote for 2, 3, and ?.
Why ?
I don't think the items
Hiroshi Inoue wrote:
Bruce Momjian wrote:
I voted not only ? but also 2 and 3.
And haven't I asked twice or so if it's a vote ?
Yes, it is a vote, and now that we see how everyone feels, we can
decide what to do.
Hiroshi, you can't vote for 2, 3, and ?.
Hiroshi Inoue wrote:
What's wrong with it ? The insert command after *rollback*
would fail. It seems the right thing to me. Otherwise
the insert command would try to append the data of the
table t1 to itself. The insert command is for copying
schema1.t1 to foo.t1 in case the previous create
* mlw ([EMAIL PROTECTED]) [020424 18:51]:
(2) Use programmatic hints which allow coders specify which indexes are used
during a query. (ala Oracle)
We would certainly use this if it were available. Hopefully not to
shoot ourselves in the foot, but for the rather common case of having
a
On Wed, 24 Apr 2002, Bruce Momjian wrote:
We expect the file system to do re-aheads during a sequential scan.
This will not happen if someone else is also reading buffers from that
table in another place.
Right. The essential difficulties are, as I see it:
1. Not all systems do
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
I voted not only ? but also 2 and 3.
And haven't I asked twice or so if it's a vote ?
Yes, it is a vote, and now that we see how everyone feels, we can
decide
Michael Loftis wrote:
Hiroshi Inoue wrote:
What's wrong with it ? The insert command after *rollback*
would fail. It seems the right thing to me. Otherwise
the insert command would try to append the data of the
table t1 to itself. The insert command is for copying
schema1.t1 to foo.t1 in
Curt Sampson wrote:
On Wed, 24 Apr 2002, Bruce Momjian wrote:
We expect the file system to do re-aheads during a sequential scan.
This will not happen if someone else is also reading buffers from that
table in another place.
Right. The essential difficulties are, as I see it:
Hiroshi Inoue wrote:
Michael Loftis wrote:
Hiroshi Inoue wrote:
What's wrong with it ? The insert command after *rollback*
would fail. It seems the right thing to me. Otherwise
the insert command would try to append the data of the
table t1 to itself. The insert command is for
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
I voted not only ? but also 2 and 3.
And haven't I asked twice or so if it's a vote ?
Yes, it is a vote, and now that we see how
Hiroshi Inoue wrote:
Michael Loftis wrote:
Hiroshi Inoue wrote:
What's wrong with it ? The insert command after *rollback*
would fail. It seems the right thing to me. Otherwise
the insert command would try to append the data of the
table t1 to itself. The insert command is for copying
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Must I understand this from your previous posting
(2 says roll back only after transaction aborts,)
or original posting ? What I understood was 2 only
says that SET fails between a failure and the
subsequenct ROLLBACK call.
Yes, 2 says
Hiroshi Inoue wrote:
Sure should it! You gave an example for the need to roll
back, because
otherwise you would end up with an invalid
search path foo.
What's wrong with it ? The insert command after *rollback*
would fail. It seems the right thing to me.
It seems we can create a forein key using REFERENCES privilege but
cannot drop the table if its owner is not same as the referenced
table. Is this a feature or bug?
-- create a table as user foo
\c - foo
create table t1(i int primary key);
-- grant reference privilege to user bar
grant
Bruce Momjian wrote:
Hiroshi, we need a psql solution too. People are feeding query files
into psql all the time and we should have an appropriate behavior for
them.
I now understand your point that from a ODBC perspective, you may not
want SETs rolled back and you would rather ODBC handle
Michael Loftis wrote:
Hiroshi Inoue wrote:
Where's the restriction that all objects in a schema
must be created in an transaction ? Each user has his
reason and would need various kind of command call sequence.
What I've mainly insisted is what to do with errors is
users' responsibilty
Jan Wieck wrote:
Hiroshi Inoue wrote:
Sure should it! You gave an example for the need to roll
back, because
otherwise you would end up with an invalid
search path "foo".
What's wrong with it ? The insert command after *rollback*
would fail. It seems the
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Hiroshi, we need a psql solution too. People are feeding query files
into psql all the time and we should have an appropriate behavior for
them.
What are you expecting for psql e.g. the following
wrong(?) example ?
[The curren schema is
Michael Loftis wrote:
Bruce Momjian wrote:
Hiroshi, we need a psql solution too. People are feeding query files
into psql all the time and we should have an appropriate behavior for
them.
I now understand your point that from a ODBC perspective, you may not
want SETs rolled back and
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Hiroshi, we need a psql solution too. People are feeding query files
into psql all the time and we should have an appropriate behavior for
them.
What are you expecting for psql e.g. the following
wrong(?) example ?
Bruce Momjian wrote:
Hiroshi Inoue wrote:
What are you expecting for psql e.g. the following
wrong(?) example ?
[The curren schema is schema1]
begin;
create schema foo;
set search_path = foo;
create table t1 (); [error occurs]
Mario Weilguni wrote:
Am Mittwoch, 24. April 2002 16:03 schrieb Bruce Momjian:
OK, I have applied the following patch to fix these warnings. However,
I need Mario to confirm these are the right changes. Thanks.
I've checked it and works fine, but the memcpy() prototype says it should be
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Hiroshi Inoue wrote:
What are you expecting for psql e.g. the following
wrong(?) example ?
[The curren schema is schema1]
begin;
create schema foo;
set search_path = foo;
create table
Bruce Momjian wrote:
What are you expecting for psql e.g. the following
wrong(?) example ?
[The curren schema is schema1]
begin;
create schema foo;
set search_path = foo;
create table t1 (); [error occurs]
On Wed, 24 Apr 2002, Bruce Momjian wrote:
1. Not all systems do readahead.
If they don't, that isn't our problem. We expect it to be there, and if
it isn't, the vendor/kernel is at fault.
It is your problem when another database kicks Postgres' ass
performance-wise.
And at that
Curt Sampson [EMAIL PROTECTED] writes:
Grabbing bigger chunks is always optimal, AFICT, if they're not
*too* big and you use the data. A single 64K read takes very little
longer than a single 8K read.
Proof?
regards, tom lane
---(end of
Curt Sampson [EMAIL PROTECTED] writes:
Grabbing bigger chunks is always optimal, AFICT, if they're not
*too* big and you use the data. A single 64K read takes very little
longer than a single 8K read.
Proof?
Long time ago I tested with the 32k block size and got 1.5-2x speed up
Well, this is a very interesting email. Let me comment on some points.
---
Curt Sampson wrote:
On Wed, 24 Apr 2002, Bruce Momjian wrote:
1. Not all systems do readahead.
If they don't, that isn't our
On Wed, 24 Apr 2002, mlw wrote:
I am not arguing about whether or not they do it, I am saying it is
not always possible. I/O requests do not remain in queue waiting for
reordering indefinitely.
It doesn't matter. When they go out to the disk they go out in
order. On every Unix-based OS I
Hi all,
Why does the password_encryption GUC variable default to false?
AFAICT there shouldn't be any issues with client compatibility -- in
fact, I'd be inclined to rip out all support for storing cleartext
passwords...
Cheers,
Neil
--
Neil Conway [EMAIL PROTECTED]
PGP Key ID: DB3C29FC
Tom Lane wrote:
Curt Sampson [EMAIL PROTECTED] writes:
Grabbing bigger chunks is always optimal, AFICT, if they're not
*too* big and you use the data. A single 64K read takes very little
longer than a single 8K read.
Proof?
I contend this statement.
It's optimal to a point. I know that
Neil Conway wrote:
Hi all,
Why does the password_encryption GUC variable default to false?
AFAICT there shouldn't be any issues with client compatibility -- in
fact, I'd be inclined to rip out all support for storing cleartext
passwords...
It is false so passwords can be handled by
A Block-sized read will not be rboken up. But if you're reading ina
size bigger than the underlying systems block sizes then it can get
broken up.
So yes a sequential read will get broken up. A single read request for
a block may or may not get broken up. If you're freading with set block
On Wed, 24 Apr 2002, Michael Loftis wrote:
A Block-sized read will not be rboken up. But if you're reading ina
size bigger than the underlying systems block sizes then it can get
broken up.
In which operating systems, and under what circumstances?
I'll agree that some OSs may not coalesce
70 matches
Mail list logo
