> > I'm writing up the new GUCs, and noticed that max_prepared_transactions
> > defaults to 5. This is too many for most applications (which don't use
> > them
> > at all) and far too few for applications which use them regularly.
>
> I think the intention was to have enough so you could tes
D'Arcy J.M. Cain wrote:
> On Thu, 11 Oct 2007 16:34:14 -0400 (EDT)
> Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > Kevin Grittner wrote:
> > > > PostgreSQL. Many complex ideas that normally take years
> > > > to implement were added rapidly to this release by our development team.
> > >
> > > You
Hello
this function can help with array's iteration.
create function generate_iterator(anyarray)
returns setof integer
as $$
select i
from generate_series(array_lower($1,1),
array_upper($1,1)) g(i)
$$ language sql;
-- multidimensional
create function gene
Josh Berkus wrote:
> On Wednesday 17 October 2007 21:35, Tom Lane wrote:
> > Josh Berkus <[EMAIL PROTECTED]> writes:
> > > I'm writing up the new GUCs, and noticed that max_prepared_transactions
> > > defaults to 5. This is too many for most applications (which don't use
> > > them at all) and far
Josh Berkus <[EMAIL PROTECTED]> writes:
> Yeah, given the amount of memory per xact, I guess we can't actually set the
> default higher. I just hate to see a setting that is liable to bite someone
> on the tuchas so easily.
I seem to recall thinking about replacing the setting with a
"prepared_
On Wednesday 17 October 2007 21:35, Tom Lane wrote:
> Josh Berkus <[EMAIL PROTECTED]> writes:
> > I'm writing up the new GUCs, and noticed that max_prepared_transactions
> > defaults to 5. This is too many for most applications (which don't use
> > them at all) and far too few for applications whi
Josh Berkus <[EMAIL PROTECTED]> writes:
> I'm writing up the new GUCs, and noticed that max_prepared_transactions
> defaults to 5. This is too many for most applications (which don't use them
> at all) and far too few for applications which use them regularly.
I think the intention was to hav
Folks,
I'm writing up the new GUCs, and noticed that max_prepared_transactions
defaults to 5. This is too many for most applications (which don't use them
at all) and far too few for applications which use them regularly.
It seems like we should either set the value to 0, or to something hig
Hmm ... playing a bit more with the example I was just on about:
regression=# create table ts_subst(target tsquery, subst tsquery);
CREATE TABLE
regression=# insert into ts_subst values('a', 'foo|bar');
INSERT 0 1
regression=# insert into ts_subst values('bar', 'baz');
INSERT 0 1
regression=# sele
While working on the documentation it's finally sunk into me what
ts_rewrite is all about, and I'm not very happy. The simple
three-argument form is fine, it's basically a tsquery-specific
version of replace():
regression=# select ts_rewrite('a & b'::tsquery, 'a'::tsquery,
'foo|bar'::tsquery);
Tom,
That is great. I am looking forward to your patch. After the
issues that you needed to address, I think that it would be
reasonable to add a few more user settings for the hash index.
Fill-factor is too course a knob. The others that I have been
considering are:
maxtuples - Not really the ma
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> but I would
> #define ENVELOPE_FCE(name,dest) \
> Datum name (PG_FUNCTION_ARGS); \
> PG_FUNCTION_INFO_V1(name); \
> Datum \
> name (PG_FUNCTION_ARGS) \
> { \
> return (dest)(fceinfo); \
> }
That seems perfectly legitimate to me --- I'm pretty s
Josh Berkus <[EMAIL PROTECTED]> writes:
>> Barring objection I'll remove the current files, add the removets2.pl
>> script that was batted around yesterday, and fix the Makefile to install
>> just that script (and later any migration docs or other stuff we add).
> I forget, did we want Oleg to cre
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> BTW, why does the 'a':6 lexeme disappear? To the extent that I
>> understand how this should work, I'd have expected 'a' and 'a':6
>> to merge into 'a':6 not plain 'a'.
> 'a':1,6 perhaps?
No, it would be inappropriate to add a '1' t
Tom Lane wrote:
> BTW, why does the 'a':6 lexeme disappear? To the extent that I
> understand how this should work, I'd have expected 'a' and 'a':6
> to merge into 'a':6 not plain 'a'.
'a':1,6 perhaps?
--
Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J
We take ris
regression=# SELECT 'a very fat cat sat:4 on:5 a:6 mat:7'::tsvector;
tsvector
---
'a' 'on':5 'cat' 'fat' 'mat':7 'sat':4 'very'
(1 row)
regression=# SELECT 'a very fat cat sat:4 on:5 a:6 mat:7'::tsvector;
server cl
Magnus Hagander wrote:
> Got some help on IRC to dentify the charafters as ç and Ç.
>
Exact.
> I can confirm that both work perfectly fine with UTF-8 and locale
> Swedish_Sweden.1252. They sort correctly, and they work with both upper()
> and lower() correctly.
>
I didn't remember what locale
Tom,
> Barring objection I'll remove the current files, add the removets2.pl
> script that was batted around yesterday, and fix the Makefile to install
> just that script (and later any migration docs or other stuff we add).
I forget, did we want Oleg to create a Tsearch2 archive on pgfoundry?
-
2007/10/17, Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
> >> Surely this shouldn't be creating its own tsvector datatype?
>
> > I would to use only pg_catalog.tsvector. But dump contains CREATE TYPE
> > statement, and custom functions which prefere it, because path i
2007/10/17, Brendan Jurd <[EMAIL PROTECTED]>:
> On 10/17/07, Pavel Stehule <[EMAIL PROTECTED]> wrote:
> > New syntax:
> >
> > a) EXECUTE stringexpr
> > [INTO [STRICT] varlist
> > [USING exprlist]
> >
> > b) FOR varlist IN EXECUTE stringexpr USING exprlist LOOP
>
> Just chiming in w
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> Surely this shouldn't be creating its own tsvector datatype?
> I would to use only pg_catalog.tsvector. But dump contains CREATE TYPE
> statement, and custom functions which prefere it, because path is:
> public, pg_catalog :(. I didn't find any other
>
> Surely this shouldn't be creating its own tsvector datatype? Having
> both public.tsvector and pg_catalog.tsvector seems like a seriously
> bad idea, if only because of confusion. ISTM you should only be
> creating new public.foo objects for the functions whose names changed.
>
I would to us
I'm getting annoyed by glimpse hits on the old code when I'm looking
for bits of tsearch code... Is there any reason to keep the current
contents of contrib/tsearch2 any longer? It'll all still be obtainable
from CVS, of course, but it doesn't seem like it has any more purpose
in HEAD.
Barring o
Tom Lane wrote:
Anyway, the picture that's starting to emerge for me is that we
should repurpose contrib/tsearch2 as a repository for scripts
and documentation to help people migrate from previous use of
tsearch2 to use of the new core facilities; and for people who
want to try to *not* migrate,
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> I created new project on pgfoundry. It's wrapper of integrated
> fulltext and it's binary compatible with TSearch2 API.
> * it works, (I am able load 82 dump without changes)
> * it is ugly :( . I expected, so this wrapper can be more elegant, but
> no
I think we should go ahead and kill the old 'n'/' ' api for heaptuple.c. The
code duplication here is really annoying and it makes it confusing for
developers trying to read or write code where they have to keep straight which
interface they're using.
What I think we should do is just announce th
Simon Riggs wrote:
> On Wed, 2007-10-17 at 18:13 +0100, Heikki Linnakangas wrote:
>
>>> The test script you
>>> showed cheats six-ways-from-Sunday to cause an OID collision that would
>>> never happen in practice. The only case where it would really happen
>>> is if a table that has existed for a
On Wed, 2007-10-17 at 18:13 +0100, Heikki Linnakangas wrote:
> > The test script you
> > showed cheats six-ways-from-Sunday to cause an OID collision that would
> > never happen in practice. The only case where it would really happen
> > is if a table that has existed for a long time (~ 2^32 OID
Simon Riggs wrote:
> On Wed, 2007-10-17 at 17:36 +0100, Heikki Linnakangas wrote:
>> Simon Riggs wrote:
>>> On Wed, 2007-10-17 at 15:02 +0100, Heikki Linnakangas wrote:
Simon Riggs wrote:
> If you've got a better problem statement it would be good to get that
> right first before we di
On Wed, 2007-10-17 at 17:36 +0100, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Wed, 2007-10-17 at 15:02 +0100, Heikki Linnakangas wrote:
> >> Simon Riggs wrote:
> >>> If you've got a better problem statement it would be good to get that
> >>> right first before we discuss solutions.
> >>
Tom Lane wrote:
> Simon has a legitimate objection; not that there's no bug, but that the
> probability of getting bitten is exceedingly small.
Oh, if that's what he meant, he's right.
> The test script you
> showed cheats six-ways-from-Sunday to cause an OID collision that would
> never happen
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> I don't think you still quite understand what's happening. GetNewOid()
> is not interesting here, look at GetNewRelFileNode() instead. And
> neither are snapshots or MVCC visibility rules.
Simon has a legitimate objection; not that there's no bug, b
Magnus Hagander wrote:
> On Wed, Oct 17, 2007 at 05:09:25PM +0100, Dave Page wrote:
>> Stephen Frost wrote:
>>> * Tom Lane ([EMAIL PROTECTED]) wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> There's legitimate use for creating a role with NOLOGIN and a password.
If we think th
On Wed, Oct 17, 2007 at 11:27:10AM -0400, Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > There's legitimate use for creating a role with NOLOGIN and a password.
>
> If we think that, then we shouldn't have a message at all.
At least if we think it's more than a very narrow l
On Wed, Oct 17, 2007 at 05:09:25PM +0100, Dave Page wrote:
> Stephen Frost wrote:
> > * Tom Lane ([EMAIL PROTECTED]) wrote:
> >> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> >>> There's legitimate use for creating a role with NOLOGIN and a password.
> >> If we think that, then we shouldn't have
Simon Riggs wrote:
> On Wed, 2007-10-17 at 15:02 +0100, Heikki Linnakangas wrote:
>> Simon Riggs wrote:
>>> If you've got a better problem statement it would be good to get that
>>> right first before we discuss solutions.
>> Reusing a relfilenode of a deleted relation, before next checkpoint
>> fo
On Wed, 2007-10-17 at 15:02 +0100, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > If you've got a better problem statement it would be good to get that
> > right first before we discuss solutions.
>
> Reusing a relfilenode of a deleted relation, before next checkpoint
> following the commit of
Stephen Frost wrote:
> * Tom Lane ([EMAIL PROTECTED]) wrote:
>> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>>> There's legitimate use for creating a role with NOLOGIN and a password.
>> If we think that, then we shouldn't have a message at all.
>
> I'm not sure I agree with that. I don't agre
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > There's legitimate use for creating a role with NOLOGIN and a password.
>
> If we think that, then we shouldn't have a message at all.
I'm not sure I agree with that. I don't agree that there's really a
le
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> There's legitimate use for creating a role with NOLOGIN and a password.
If we think that, then we shouldn't have a message at all.
regards, tom lane
---(end of broadcast)---
T
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> could not determine encoding for locale "Czech_Czech Republic.1250": codeset
> is
> "CP1250"
Hm, we seem to have missed an entry for PG_WIN1250. Fixed.
regards, tom lane
---(end of broadcast)
Magnus Hagander wrote:
> On Sun, Oct 14, 2007 at 06:16:04PM -0400, Stephen Frost wrote:
>> * Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost <[EMAIL PROTECTED]> writes:
> I wonder if the OP was unhappy because he created a role w/ a pw and
> then couldn't figure out why the user coul
Hannes Eder worte:
We wrote a little contrib module, which we'd like to share. It can be
used to generate random datasets as they have been used in
[Borzsonyi2001] and related work.
[snip]
The module was moved to:
http://randdataset.projects.postgresql.org/
resp.
http://randdataset.projects.p
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
> I think that's a good idea. Attached is a patch that implements this (I
> think - haven't messed around in that area of the code before). Thoughts?
Cool, thanks!
My only comment is that you should probably stick to one 'zero'
convention- either '!can
I did some test, but without success,
Pavel
I have win2003 Server .. with czech locales support.
I:\PGSQL\BIN>initdb -D ../data -L i:\pgsql\share
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster wi
On Sun, Oct 14, 2007 at 06:16:04PM -0400, Stephen Frost wrote:
> * Tom Lane ([EMAIL PROTECTED]) wrote:
> > > Stephen Frost <[EMAIL PROTECTED]> writes:
> > >> I wonder if the OP was unhappy because he created a role w/ a pw and
> > >> then couldn't figure out why the user couldn't log in?
> >
> > >
Rodrigo Hjort wrote:
Is this the regular behavior on DBLink?
rot=> SELECT user, current_database();
current_user | current_database
--+--
sa_rot | rot
(1 registro)
rot=> SELECT *
rot-> FROM dblink('dbname=escola',
rot(> 'SELECT user, current_database()')
rot-
Florian G. Pflug wrote:
> Heikki Linnakangas wrote:
>> I wrote:
>>> Unfortunately I don't see any easy way to fix it. One approach would be
>>> to avoid reusing the relfilenodes until next checkpoint, but I don't see
>>> any nice place to keep track of OIDs that have been dropped since last
>>> che
Simon Riggs wrote:
> If you've got a better problem statement it would be good to get that
> right first before we discuss solutions.
Reusing a relfilenode of a deleted relation, before next checkpoint
following the commit of the deleting transaction, for an operation that
doesn't WAL log the cont
Simon Riggs wrote:
On Wed, 2007-10-17 at 12:11 +0100, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Wed, 2007-10-17 at 17:18 +0800, Jacky Leng wrote:
Second, suppose that no checkpoint has occured during the upper
series--authough not quite possible;
That part is irrelevant. It's forced out
>>> On Wed, Oct 17, 2007 at 1:40 AM, in message
<[EMAIL PROTECTED]>,
"Kuriakose, Cinu Cheriyamoozhiyil" <[EMAIL PROTECTED]> wrote:
>
> I am trying to configure CVS through Eclipse, infact i was able to do that
> but when I map the postgreSQL code into CVS through Eclipse, it is displaying
> th
On Wed, 2007-10-17 at 12:11 +0100, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Wed, 2007-10-17 at 17:18 +0800, Jacky Leng wrote:
> >> Second, suppose that no checkpoint has occured during the upper
> >> series--authough not quite possible;
> >
> > That part is irrelevant. It's forced o
Is this the regular behavior on DBLink?
rot=> SELECT user, current_database();
current_user | current_database
--+--
sa_rot | rot
(1 registro)
rot=> SELECT *
rot-> FROM dblink('dbname=escola',
rot(> 'SELECT user, current_database()')
rot-> AS (usr name, db name
Heikki Linnakangas wrote:
I wrote:
Unfortunately I don't see any easy way to fix it. One approach would be
to avoid reusing the relfilenodes until next checkpoint, but I don't see
any nice place to keep track of OIDs that have been dropped since last
checkpoint.
Ok, here's one idea:
Instead o
I wrote:
> Unfortunately I don't see any easy way to fix it. One approach would be
> to avoid reusing the relfilenodes until next checkpoint, but I don't see
> any nice place to keep track of OIDs that have been dropped since last
> checkpoint.
Ok, here's one idea:
Instead of deleting the file im
Forgot to attach the script I promised..
You need to set $PGDATA before running the script. And psql,pg_ctl and
pg_resetxlog need to be in $PATH. After running the script, restart
postmaster and run "SELECT * FROM t2". There should be one row in the
table, but it's empty.
Heikki Linnakangas wrote
> On Wed, 2007-10-17 at 17:18 +0800, Jacky Leng wrote:
>> Second, suppose that no checkpoint has occured during the upper
>> series--authough not quite possible;
>
> That part is irrelevant. It's forced out to disk and doesn't need
> recovery, with or without the checkpoint.
>
> There's no hole th
Simon Riggs wrote:
> On Wed, 2007-10-17 at 17:18 +0800, Jacky Leng wrote:
>> Second, suppose that no checkpoint has occured during the upper
>> series--authough not quite possible;
>
> That part is irrelevant. It's forced out to disk and doesn't need
> recovery, with or without the checkpoint.
>
On Wed, 2007-10-17 at 17:18 +0800, Jacky Leng wrote:
> Second, suppose that no checkpoint has occured during the upper
> series--authough not quite possible;
That part is irrelevant. It's forced out to disk and doesn't need
recovery, with or without the checkpoint.
There's no hole that I can se
Hi All,
The ls and rls commands are used to list files and directories in the
repository, but we should be logged in to the repository for getting the
listing of the same.
I use the command "cvs login" to connect to the repository but instead of
connecting to the local repository it is conne
> Jacky Leng wrote:
>> If I run the database under non-archiving mode, and execute the following
>> command:
>> alter table t set tablespace tblspc1;
>> Isn't it possible that the "new t" cann't be recovered?
>
> No. At the end of copy_relation_data we call smgrimmedsync, which fsyncs
> the ne
Hiroshi Saito wrote:
> Hi.
>
> From: "Magnus Hagander" <[EMAIL PROTECTED]>
>
>>> But, Please see.
>>> http://winpg.jp/~saito/pg83/pg83b1-err3.txt
>>> Japanese_Japan.65001 is error...
>>> Japanese_Japan is true.
>>
>> Yes, that is expected. If you explicitly ask for the .65001 locale it
>> will tr
Hello
I created new project on pgfoundry. It's wrapper of integrated
fulltext and it's binary compatible with TSearch2 API.
* it works, (I am able load 82 dump without changes)
* it is ugly :( . I expected, so this wrapper can be more elegant, but
not. I had to create full dual interface to fullt
63 matches
Mail list logo
