Robert Treat <[EMAIL PROTECTED]> writes:
> Tom, just curious as to what your resistance is to this feature? ISTM
> that making this admin modifiable doesn't hurt anyone and could be
> helpful to some people.
Admin modifiable at what level? I don't believe that the "feature" is
valuable enough to
On Fri, 2003-08-29 at 12:09, Tom Lane wrote:
> Bruce Badger <[EMAIL PROTECTED]> writes:
> > Unfortunately, I am not in a position to initiate a change in the StORE
> > schema. StORE is also used with other RDBMSs, and the users of those
> > have no incentive to bless a change in the schema just to
On Friday 29 August 2003 15:37, Bruce Badger wrote:
> On Fri, 2003-08-29 at 23:35, Tom Lane wrote:
> > Rod Taylor <[EMAIL PROTECTED]> writes:
> > >> So, being able to stop connections trying to use old protocol versions
> > >> would be very helpful in this case.
> > >
> > > Wouldn't it be better to
On Fri, Aug 29, 2003 at 12:06:59AM -0300, Marc G. Fournier wrote:
> The thing is ... there has been presented a strong, valid reason for
> moving to 16k (at least under FreeBSD) ... and there has been a valid
It sounds to me, actually, like there is a strong reason for telling
people running Free
Bruce Badger <[EMAIL PROTECTED]> writes:
> Unfortunately, I am not in a position to initiate a change in the StORE
> schema. StORE is also used with other RDBMSs, and the users of those
> have no incentive to bless a change in the schema just to help out the
> PostgreSQL users.
Hm, I must have mi
Jon Jensen wrote:
On Thu, 28 Aug 2003, Andrew Dunstan wrote:
What is the state of things regarding having to use massive strings of
quotes like this (taken from the 7.3 docs)?:
a_output := a_output || '' if v_'' ||
referrer_keys.kind || '' like ''
|| referrer_keys.key_strin
On Thu, 28 Aug 2003, Andrew Dunstan wrote:
> What is the state of things regarding having to use massive strings of
> quotes like this (taken from the 7.3 docs)?:
>
> a_output := a_output || '' if v_'' ||
> referrer_keys.kind || '' like ''
> || referrer_keys.key_string || '''
Thomas Schoebel-Theuer <[EMAIL PROTECTED]> writes:
> Do you have any clue whether it really could happen that really
> NEVER any blocking occurs when running the DBT3 benachmark with 8
> or 16 parallel backend processes???
I haven't looked at dbt3 at all ... what does it do?
We do make a point of
On Fri, 2003-08-29 at 23:23, Rod Taylor wrote:
> > So, being able to stop connections trying to use old protocol versions
> > would be very helpful in this case.
>
> Wouldn't it be better to have StORE run a select version() after
> connecting? Even better would be to call PQprotocolVersion() as
On Fri, 2003-08-29 at 23:35, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> >> So, being able to stop connections trying to use old protocol versions
> >> would be very helpful in this case.
>
> > Wouldn't it be better to have StORE run a select version() after
> > connecting?
>
> Wel
http://developer.postgresql.org/ftpsite/binary/v7.3.4/RPMS/
Robert Treat
On Thu, 2003-08-28 at 11:18, Marie G. Tuite wrote:
> Same issue - are there rpms anywhere for 7.3.4?
>
> Thanks.
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Tom Lane
>
Giuseppe Tanzilli - CSF <[EMAIL PROTECTED]> writes:
> create table test2 (i integer, t timestamp default 'now()');
Use "DEFAULT now()". I'm surprised you didn't get a syntax error from
the above.
> It is a known change or a bug ?
It's an intentional change, yes.
regards
Tom,
I just realized that I probably could have misinterpreted the locktag
information. This could have caused the conflicts in my postprocessing.
Apologies if that was the reason. I'm running further checks to
resolve that problem.
However, what remains strange is that the lockmanager is never b
Greg Stark <[EMAIL PROTECTED]> writes:
> [On that note, one of my pet peeves is that the default names for constraints
> are of the form $1 which requires quoting, but that \d doesn't quote them so
> that you can almost but not quite copy the \d output into an sql statement
> recreating the const
Rod Taylor <[EMAIL PROTECTED]> writes:
>> So, being able to stop connections trying to use old protocol versions
>> would be very helpful in this case.
> Wouldn't it be better to have StORE run a select version() after
> connecting?
Well, his point is that old versions of his client code wouldn't
> So, being able to stop connections trying to use old protocol versions
> would be very helpful in this case.
Wouldn't it be better to have StORE run a select version() after
connecting? Even better would be to call PQprotocolVersion() as it is a
protocol issue.
signature.asc
Description: This
On Thu, 2003-08-28 at 23:22, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > I've been fiddling away on ALTER TABLE and have a few questions about a
> > possible datatype change. Just alter portions.
>
> > I presume I'll need to do a table rewrite. What is the best way to
> > change a
Thomas Schoebel-Theuer <[EMAIL PROTECTED]> writes:
> the problem persists, even when starting from scratch. I did the following:
> + printf("lock\n"); fflush(stdout);
> +
> $ grep lock run/dbt3_logfile | wc -l
I'd bet that your logfile is not accumulating postmaster stdout, but
only stderr
On Fri, 2003-08-29 at 04:22, Hannu Krosing wrote:
> Rod Taylor kirjutas R, 29.08.2003 kell 03:31:
> > I've been fiddling away on ALTER TABLE and have a few questions about a
> > possible datatype change. Just alter portions.
> >
> > I presume I'll need to do a table rewrite. What is the best way t
On Thu, 2003-08-28 at 22:06, Christopher Kings-Lynne wrote:
> Do you have this working:
>
> ALTER TABLE / ADD COLUMN .. DEFAULT nextval('asdf')...
>
> (eg. a default that needs to be re-evaluated for each row)
>
> Also, did you remember about checking domain constraints, etc.?
Yes, and all nece
Hi Tom,
the problem persists, even when starting from scratch. I did the following:
# wget
ftp://ftp.de.postgresql.org/mirror/postgresql/source/v7.3.4/postgresql-7.3.4.tar.gz
# tar xzf postgresql-7.3.4.tar.gz
# cd postgresql-7.3.4/
# cat ../mypatch
--- src/backend/storage/lmgr/lock.c~2002-11
Hi,
I see it work without quotes around function,
but I got it from a 7.2 dump with quotes around it.
Maybe it require a note for people dumping from 7.2,
I don't have 7.3 around to try, sorry
bye
Giuseppe Tanzilli - CSF wrote:
Hi,
just testing beta2 I got strange things on default values with f
Hi,
just testing beta2 I got strange things on default values with functions:
create table test2 (i integer, t timestamp default 'now()');
test1=# \d test2
Table "public.test2"
Column |Type |
Modifiers
-
Christopher Kings-Lynne wrote:
I have changed psql to use pg_get_viewdef(oid, true). I agree with Tom for
not using it in dumps just yet though.
While there still might be a pg_dump option to do this.
Is there a function for getting nice constraint defs?
Of course there is, use pg_get_constrain
Rod Taylor kirjutas R, 29.08.2003 kell 03:31:
> I've been fiddling away on ALTER TABLE and have a few questions about a
> possible datatype change. Just alter portions.
>
> I presume I'll need to do a table rewrite. What is the best way to
> change a single datum? heap_modify() takes a single rel
I am not 100% sure that 16K blocksize is the best size, for instance :
Using FreebSD 5.1 - I got the best read and write performance using a
blocksize of 32K with 4K fragments - [ reading and writing 8K blocks,
ufs1 and ufs2 fs ].
I dont have the results in front of me, but I think I tried fs
On Fri, 29 Aug 2003, Tom Lane wrote:
> "scott.marlowe" <[EMAIL PROTECTED]> writes:
> > On Thu, 28 Aug 2003, Neil Conway wrote:
> >> On Thu, Aug 28, 2003 at 05:37:39PM -0400, Tom Lane wrote:
> >>> Who's to say? We've found bugs in the btree logic recently,
> >>> too.
> >>
> >> I'd rather print a
"scott.marlowe" <[EMAIL PROTECTED]> writes:
> On Thu, 28 Aug 2003, Neil Conway wrote:
>> On Thu, Aug 28, 2003 at 05:37:39PM -0400, Tom Lane wrote:
>>> Who's to say? We've found bugs in the btree logic recently,
>>> too.
>>
>> I'd rather print a loud warning when a hash index is created, but keep
On Thu, 28 Aug 2003, Neil Conway wrote:
> On Thu, Aug 28, 2003 at 05:37:39PM -0400, Tom Lane wrote:
> > > If so, then how many other bugs are lurking in the hash index code
> > > waiting to bite?
> >
> > Who's to say? We've found bugs in the btree logic recently,
> > too.
>
> I'd rather print
On Fri, 2003-08-29 at 13:23, Tom Lane wrote:
> Bruce Badger <[EMAIL PROTECTED]> writes:
> > Will it be possible to tell a PostgreSQL back end to use *only* the new
> > version of the FE/BE protocol?
> > That is, will it be possible to set up a database that will reject
> > connection attempts that
On Thu, 28 Aug 2003, David Schultz wrote:
> (2) Make BLCKSZ a runtime constant, stored as part of the database.
Now this I really like. It would make benchmarking 8K vs. 16K blocksizes
much easer, as well as of course avoiding the "initdb required after
rebuilding" problem.
BTW, pretty much ever
On Fri, Aug 29, 2003 at 12:06:59AM -0300, Marc G. Fournier wrote:
> "tuning documents" is *not* a valid reason for not doing this ... that's
> like saying "we can make it faster on some operating systems, but because
> we're going to have to modify the tuning documents, we're not going to do
> it"
Bruce Badger <[EMAIL PROTECTED]> writes:
> Will it be possible to tell a PostgreSQL back end to use *only* the new
> version of the FE/BE protocol?
> That is, will it be possible to set up a database that will reject
> connection attempts that do not use the new protocol version?
I cannot imagine
Rod Taylor <[EMAIL PROTECTED]> writes:
> I've been fiddling away on ALTER TABLE and have a few questions about a
> possible datatype change. Just alter portions.
> I presume I'll need to do a table rewrite. What is the best way to
> change a single datum? heap_modify() takes a single relation typ
On Thu, 28 Aug 2003, Neil Conway wrote:
> On Thu, Aug 28, 2003 at 01:00:44PM -0700, Sean Chittenden wrote:
> > Other than you feeling uneasy about the possibility of uncovering bugs
> > because this hasn't been widely done like this before, do you have any
> > other concerns, or do you think the
On Wed, 27 Aug 2003, Sean Chittenden wrote:
> FreeBSD uses 16K blocks for its FS...
Actually, FreeBSD can use 8K blocks as well. The reason for using 16K
blocks is not speeed, but to reduce filesystem overhead and, more
importantly, to allow larger cylinder groups. But for a database with
a lot o
On Thu, Aug 28, 2003 at 01:00:44PM -0700, Sean Chittenden wrote:
> Other than you feeling uneasy about the possibility of uncovering bugs
> because this hasn't been widely done like this before, do you have any
> other concerns, or do you think the possibility of finding bugs very
> likely?
In cas
On Thu, Aug 28, 2003 at 08:06:05PM +0200, Mendola Gaetano wrote:
> is not usefull have a mailing list in where people can
> partecipate in a sort of "code revision" about the
> actual code ?
I think pgsql-patches is used for that purpose by some people.
If you're implementing a major change, its
On Thu, Aug 28, 2003 at 05:22:36PM +0530, Shridhar Daithankar wrote:
> BTW, what is the sway of switching disk IO scheduler in 2.6? Could not find
> any references to sysctl switching. Andrew Morton's TODO list still list it
> as TODO.
Sorry, I was mistaken: you can switch I/O schedulers by spec
On Thu, Aug 28, 2003 at 05:37:39PM -0400, Tom Lane wrote:
> > If so, then how many other bugs are lurking in the hash index code
> > waiting to bite?
>
> Who's to say? We've found bugs in the btree logic recently,
> too.
I'd rather print a loud warning when a hash index is created, but keep
the
Do you have this working:
ALTER TABLE / ADD COLUMN .. DEFAULT nextval('asdf')...
(eg. a default that needs to be re-evaluated for each row)
Also, did you remember about checking domain constraints, etc.?
Chris
- Original Message -
From: "Rod Taylor" <[EMAIL PROTECTED]>
To: "PostgreSQL
> Obviously psql uses either use pg_constraint.consrc or
> pg_get_expr(conbin, conrelid) which both will give this lot of
> parentheses, so it's not a bug, but a feature
> For easier reengineering, I invented several pg_get_xxx functions with a
> pretty-print option, which omits this messy parenthe
> > > Early performance tests on my laptop suggest it's about 8%
> > > faster for writing when both the FS and PostgreSQL use 16K
> > > blocks.
> >
> > BTW, I don't really believe that one set of tests, conducted on
> > one single machine, are anywhere near enough justification for
> > changing thi
what sort of hardware was this run on?
On Thu, 28 Aug 2003, Sean Chittenden wrote:
> 'nother test in support of 16K blocks for FreeBSD, this time it was
> 25% faster to import. -sc
>
> --
> Sean Chittenden
>
---(end of broadcast)---
TIP 1: subscr
Will it be possible to tell a PostgreSQL back end to use *only* the new
version of the FE/BE protocol?
That is, will it be possible to set up a database that will reject
connection attempts that do not use the new protocol version?
Thanks,
Bruce
signature.asc
Description: This is a di
On Thu, Aug 28, 2003, Tom Lane wrote:
> Sean Chittenden <[EMAIL PROTECTED]> writes:
> > Are there any objections
> > to me increasing the block size for FreeBSD installations to 16K for
> > the upcoming 7.4 release?
>
> I'm a little uncomfortable with introducing a cross-platform variation
> in th
On Thu, Aug 28, 2003, scott.marlowe wrote:
> On Thu, 28 Aug 2003, Marc G. Fournier wrote:
> > On Thu, 28 Aug 2003, Thomas Swan wrote:
> >
> > > Has anyone looked at changing the default block size across the board
> > > and what the performance improvements/penalties might be? Hardware has
> > >
'nother test in support of 16K blocks for FreeBSD, this time it was
25% faster to import. -sc
--
Sean Chittenden
--- Begin Message ---
Hi.
I'm implementing postgresql 7.3.4 on FreeBSD 5.1, and
decided to place the pgsql-folder on it's own
partition so it was easier to test which blocksize to
go
Will it be possible to tell a PostgreSQL back end to use *only* the new
version of the FE/BE protocol?
That is, will it be possible to set up a database that will reject
connection attempts that do not use the new protocol version?
Thanks,
Bruce
---(end of bro
I've been fiddling away on ALTER TABLE and have a few questions about a
possible datatype change. Just alter portions.
I presume I'll need to do a table rewrite. What is the best way to
change a single datum? heap_modify() takes a single relation type where
I will need to deal with different type
Sean, can we get a copy of your test set? And any scripts that you have
for running the tests?
On Thu, 28 Aug 2003, Tom Lane wrote:
> Sean Chittenden <[EMAIL PROTECTED]> writes:
> > Early performance tests on my laptop suggest it's about 8% faster for
> > writing when both the FS and PostgreSQ
51 matches
Mail list logo
