On Thu, 10 Mar 2005, Tom Lane wrote:
Would those of you with access to other DBMSes try this:
create table tab (col integer);
select 1 from tab having 1=0;
select 1 from tab having 1=1;
insert into tab values(1);
insert into tab values(2);
select 1 from tab having 1=0;
select 1 from tab having
Laszlo Hornyak wrote:
The default should be the default used by PostgreSQL, and the extra ones
should be commented out under it.
Not the most user friendly solution, but can we do anything else?
Yes, we can do as I suggested and select mapping depending on the GUC
variable integer_datetimes. I
On Tue, 2005-03-01 at 13:53 -0800, Mark Wong wrote:
On Thu, Feb 03, 2005 at 07:25:55PM +0900, ITAGAKI Takahiro wrote:
Hello everyone.
I fixed two bugs in the patch that I sent before.
Check and test new one, please.
Ok, finally got back into the office and was able to run 1 set of
Greg Stark wrote:
Kevin Brown [EMAIL PROTECTED] writes:
Hence, it makes sense to go ahead and run the query, but issue a
warning at the very beginning, e.g. WARNING: query JOINs tables list
of tables without otherwise referencing or making use of those
tables. This may cause excessively poor
varchar means 'character varying'. What varies is the length. So a
varchar(1000) with 'foo' in it only takes a few bytes ('foo' plus length
info) instead of 1000 bytes.
Yes i know it, but i have vorgotten to inform you that all the values of
this attribute have really 1000 characthers
Is there any compression or what?
Yes, there is:
http://www.postgresql.org/docs/8.0/interactive/storage-toast.html
thanks, is there any way to increase the limit, upper wich toast strategy
is selected? By defaullt is Block_size/4 = about 2000 Bytes.
---(end of
Hi, i found this form of output of explain analyze, watching some old
mails in lists.
test4=# explain analyze select * from patients;
LOG: query: explain analyze select * from patients;
LOG: duration: 0.603887 sec
LOG: QUERY STATISTICS
! system usage stats:
! 0.624269 elapsed 0.458985
On Thu, Mar 10, 2005 at 09:01:21 -0800,
Hemapriya [EMAIL PROTECTED] wrote:
Hi,
Can anybody know how the following statement work.
Grant ALL on SCHEMA test to user 'user1';
will the user be able to have all the privileges on
all the objects/tables on schema test? Or he can only
create
See your postgresql.conf for
log_planner_stats = true #false
log_executor_stats = true #false
#log_statement_stats = false
Oleg
On Fri, 11 Mar 2005, Ioannis Theoharis wrote:
Hi, i found this form of output of explain analyze, watching some old
mails in lists.
test4=# explain analyze select *
Neil Conway wrote:
Bruce Momjian wrote:
The attached patch should remove the warnings but I am not applying it
because a non-static/extern global variable should be fine in C code.
What's the harm in applying it? Variables and functions not used outside
the compilation unit in which they
BVikram Kalsi wrote:
I was ignoring the warnings anyway.
I didn't look into that much but after upgrading to RHEL AS4, I am
able to compile successfully with --enable-thread-safety
OK, so there was some problem with AS3 and its use of the thread
library. Glad it is working now.
--
Bruce
Tom Lane wrote:
[EMAIL PROTECTED] writes:
Please see my posting about using a macro for snprintf.
Wasn't the issue about odd behavior of the Win32 linker choosing the wrong
vnsprintf?
You're right, the point about the macro was to avoid linker weirdness on
Windows. We need to do that
Nicolai Tufar wrote:
On Thu, 10 Mar 2005 16:26:47 -0500 (EST), Bruce Momjian
pgman@candle.pha.pa.us wrote:
Please see my posting about using a macro for snprintf. If the current
implementation of snprintf is enough for our existing translation users
we probably don't need to add anything
Chris Mair wrote:
Hello,
I'd like to start working on the following TODO item:
Referential Integrity / Support triggers on columns
Is somebody else already working on this?
No one, I think.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us
Adrian Nida wrote:
All,
I visited #postgresql @ FreeNode and asked about how to make pg use pam
about a week ago (specifically I wanted to auth against LDAP). I was
told to figure it out and write a doc...
Here is my attempt at doing so: http://itc.musc.edu/wiki/PostGreSQL
On Fri, Mar 11, 2005 at 11:42:53AM -0500, Bruce Momjian wrote:
Adrian Nida wrote:
All,
I visited #postgresql @ FreeNode and asked about how to make pg use pam
about a week ago (specifically I wanted to auth against LDAP). I was
told to figure it out and write a doc...
Here
Tom Lane wrote:
[EMAIL PROTECTED] writes:
Please see my posting about using a macro for snprintf.
Wasn't the issue about odd behavior of the Win32 linker choosing the
wrong
vnsprintf?
You're right, the point about the macro was to avoid linker weirdness on
Windows. We need to do that
On Fri, Mar 11, 2005 at 11:32:04AM -0500, Bruce Momjian wrote:
Chris Mair wrote:
Hello,
I'd like to start working on the following TODO item:
Referential Integrity / Support triggers on columns
Is somebody else already working on this?
No one, I think.
Isn't this the REFERENCING
[EMAIL PROTECTED] wrote:
Tom Lane wrote:
[EMAIL PROTECTED] writes:
Please see my posting about using a macro for snprintf.
Wasn't the issue about odd behavior of the Win32 linker choosing the
wrong
vnsprintf?
You're right, the point about the macro was to avoid linker
Alvaro Herrera wrote:
On Fri, Mar 11, 2005 at 11:32:04AM -0500, Bruce Momjian wrote:
Chris Mair wrote:
Hello,
I'd like to start working on the following TODO item:
Referential Integrity / Support triggers on columns
Is somebody else already working on this?
No one, I
I'd like to start working on the following TODO item:
Referential Integrity / Support triggers on columns
Is somebody else already working on this?
No one, I think.
Isn't this the REFERENCING clause? I think there was a partial patch
submitted already for this.
Those are
Bruce Momjian pgman@candle.pha.pa.us writes:
I'm not sure that macros can have variable number of arguments on all
supported platforms. I've been burnt by this before.
The actual patch is:
+ #ifdef __GNUC__
+ #define vsnprintf(...)pg_vsnprintf(__VA_ARGS__)
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
I'm not sure that macros can have variable number of arguments on all
supported platforms. I've been burnt by this before.
The actual patch is:
+ #ifdef __GNUC__
+ #define vsnprintf(...)
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
I'm not sure that macros can have variable number of arguments on all
supported platforms. I've been burnt by this before.
The actual patch is:
+ #ifdef __GNUC__
+ #define
Are we still bumping the libpq major version number for 8.0.2? I think
it is a bad idea because we will require too many client apps to be
recompiled, and we have had few problem reports.
We do need to bump the major version number for 8.1 and I am doing that
now.
One new problem I see is that
Snip/
Here is my attempt at doing so: http://itc.musc.edu/wiki/PostGreSQL
Snip/
I get a not exists error on that URL.
Sorry, I renamed the URL after someone pointed out the correct spelling.
This was a link to the old one. I apologize for the confusion, the
right URL is:
* Bruce Momjian (pgman@candle.pha.pa.us) wrote:
Are we still bumping the libpq major version number for 8.0.2? I think
it is a bad idea because we will require too many client apps to be
recompiled, and we have had few problem reports.
We do need to bump the major version number for 8.1 and
On Sat, Feb 19, 2005 at 04:49:03PM -0500, [EMAIL PROTECTED] wrote:
PostgreSQL is such an awesome project. The only thing it seems to suffer
from is a disregard for its users.
Gee. And all this time I thought that free support from the guy who
wrote the code and gave it to you was better regard
Kurt Roeckx wrote:
On Fri, Mar 11, 2005 at 12:58:28PM -0500, Bruce Momjian wrote:
Are we still bumping the libpq major version number for 8.0.2? I think
it is a bad idea because we will require too many client apps to be
recompiled, and we have had few problem reports.
We do need to
One of the things I was thinking about was whether we could use up those
cycles more effectively. If we were to include a compression routine
before we calculated the CRC that would
- reduce the size of the blocks to be written, hence reduce size of xlog
- reduce the following CRC calculation
I
Hi Evgen,
How's the syncing with HEAD going?
Cheers,
Chris
I'm working on it.
Regards, Evgen.
---(end of broadcast)---
TIP 8: explain analyze is your friend
Kurt Roeckx wrote:
On Fri, Mar 11, 2005 at 01:29:46PM -0500, Bruce Momjian wrote:
Kurt Roeckx wrote:
Does initdb call pg_snprintf directly? Or does it call some
libpq function that calls it?
With the current CVS, initdb calls pg_snprintf() on my platform which
doesn't support
I would like to apply this patch, and I think it is important enough
that it should be backpatched in to 8.0.X. Any objections?
---
Magnus Hagander wrote:
There is special code in the send_message_to_server_log
Bruce Momjian wrote:
Are we still bumping the libpq major version number for 8.0.2?
Yes.
I
think it is a bad idea because we will require too many client apps
to be recompiled,
That is not true, as previously discussed.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
I have reviewed this patch, and I already added these changes myself in
CVS.
Thanks.
---
Nicolai Tufar wrote:
On Mon, Feb 21, 2005 at 10:53:08PM -0500, Bruce Momjian wrote:
Applied.
Thanks a lot. The patch
Peter Eisentraut wrote:
Bruce Momjian wrote:
Are we still bumping the libpq major version number for 8.0.2?
Yes.
I
think it is a bad idea because we will require too many client apps
to be recompiled,
That is not true, as previously discussed.
It is not true only if the old
pgman wrote:
Peter Eisentraut wrote:
Bruce Momjian wrote:
Are we still bumping the libpq major version number for 8.0.2?
Yes.
I
think it is a bad idea because we will require too many client apps
to be recompiled,
That is not true, as previously discussed.
It is not
Bruce Momjian pgman@candle.pha.pa.us writes:
I would like to apply this patch, and I think it is important enough
that it should be backpatched in to 8.0.X. Any objections?
I wanted to review the patch before it went in. Will try to get to it
soon.
regards, tom lane
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
I would like to apply this patch, and I think it is important enough
that it should be backpatched in to 8.0.X. Any objections?
I wanted to review the patch before it went in. Will try to get to it
soon.
OK, I will just keep
On Fri, 11 Mar 2005, Bruce Momjian wrote:
Peter Eisentraut wrote:
Bruce Momjian wrote:
Are we still bumping the libpq major version number for 8.0.2?
Yes.
I
think it is a bad idea because we will require too many client apps
to be recompiled,
That is not true, as previously discussed.
It is not
Bruce Momjian wrote:
In fact, based on the few complaints we have heard about the current
situation, I am sure we are going to get many more complaints if we
bump up the major version in 8.0.2.
The lack of complaints is because the packagers that have recognized the
problem are refusing the
Bruce Momjian wrote:
It is not true only if the old libpq stays around, which isn't always
the case.
I think that would clearly be a Don't-do-that-then situation.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of
Peter Eisentraut wrote:
Bruce Momjian wrote:
In fact, based on the few complaints we have heard about the current
situation, I am sure we are going to get many more complaints if we
bump up the major version in 8.0.2.
The lack of complaints is because the packagers that have recognized
On Thu, 10 Mar 2005 19:21:41 -0500 (EST), Bruce Momjian
pgman@candle.pha.pa.us wrote:
The CVS-tip implementation is fundamentally broken and won't work even
for our internal uses. I've not wasted time complaining about it
because I thought we were going to replace it. If we can't find a
Hi all,
(B
(BI'm thinking about "partial (or range) vacuum" feature.
(B
(BAs you know, vacuum process scans and re-organizes a whole table,
(Bso huge cpu load will be generated when vacuuming a large table,
(Band it will take long time (in some cases, it may take 10 minutes
(Bor more).
(B
Satoshi Nagayasu [EMAIL PROTECTED] writes:
Attached patch extends vacuum syntax and lazy_scan_heap() function.
Backend can process the partial vacuum command as below:
psql$ vacuum table1 (0, 100);
In the above command, 0 means start block number,
and 100 means end block number of the
(BTom Lane wrote:
(B I think the major problem with this is the (untenable) assumption that
(B the user is keeping track of the table size accurately. It'd be very
(B likely that portions of the table get missed if someone tries to
(B maintain a table using only partial vacuums specified in
Have you looked at the vacuum cost delay features present in 8.0?
On the whole that seems like a better solution for reducing the impact
of routine vacuuming than trying to manage partial vacuuming with an
approach like this.
IMO vacuum cost delay seems not to be a solution. To keep long
Is there any compression or what?
Yes, there is:
http://www.postgresql.org/docs/8.0/interactive/storage-toast.html
thanks, is there any way to increase the limit, upper wich toast strategy
is selected? By defaullt is Block_size/4 = about 2000 Bytes.
Dunno, but you can alter the column and go 'set
The PostgreSQL docs suggest that ftp.postgresql.org holds binary builds
of CVSup:
http://developer.postgresql.org/docs/postgres/cvsup.html
Is this still the case? (I couldn't see any cvsup binaries, but perhaps
they are well-hidden).
-Neil
---(end of
Neil Conway [EMAIL PROTECTED] writes:
The PostgreSQL docs suggest that ftp.postgresql.org holds binary builds
of CVSup:
Is this still the case? (I couldn't see any cvsup binaries, but perhaps
they are well-hidden).
If they are still there, they're probably exceedingly out of date :-(
51 matches
Mail list logo
