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 :-(
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 broadcast)--
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 s
> 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 r
(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
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
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
On Thu, 10 Mar 2005 19:21:41 -0500 (EST), Bruce Momjian
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
> > usable replacem
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 reco
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 broadcast)--
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
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 tru
Tom Lane wrote:
> Bruce Momjian 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 it in the patch
Bruce Momjian 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
-
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
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
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
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
> >>>
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
> >
> 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
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
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
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 reg
* 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
Here is my attempt at doing so: http://itc.musc.edu/wiki/PostGreSQL
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:
http://itc.musc.edu/wiki/Post
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 c
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian 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(.
Tom Lane wrote:
> Bruce Momjian 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
Bruce Momjian 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__)
> + #define snpr
> > > 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
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 thi
[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 macr
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 t
> 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
>> Windo
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...
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
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.u
Nicolai Tufar wrote:
> On Thu, 10 Mar 2005 16:26:47 -0500 (EST), Bruce Momjian
> 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 more to it beca
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 nee
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.
--
Br
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 whi
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 * from
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 onl
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 u
> >
> > 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.
---
>
> 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 le
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 without otherwise referencing or making use of those
tables. This may cause excessively poor performance of
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
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".
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 1=1;
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?
Laszlo
On Fri, 11 Mar 2005, Thomas Hallgren wrote:
> Laszlo Hornyak wrote:
>
> > IMHO this is why decoupling is good and n
52 matches
Mail list logo
