Greg Sabino Mullane wrote:
> I was looking over the "FIXME" marks within the
> information_schema.sql, and the last ones left (after my previous
> patch) are for interval_type and interval_precision. It looks to me
> as if the standard is differentiating between datetime_precision and
> interval_pr
On 8/25/06, Tom Lane <[EMAIL PROTECTED]> wrote:
I coulda sworn there was a specific mention in the docs that you'd
better allow for autovac when choosing superuser_reserved_connections,
but a quick grep doesn't find it.
There is a mention in autovacuum doc:
http://www.postgresql.org/docs/8.1/in
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> Autovacuum uses connections in superuser mode. If all connections are used,
> autovacuum cannot start and the following message is written in server log.
> | FATAL: sorry, too many clients already
> Is this a feature?
Yes.
I coulda sworn there was
Hi hackers,
Autovacuum uses connections in superuser mode. If all connections are used,
autovacuum cannot start and the following message is written in server log.
| FATAL: sorry, too many clients already
Is this a feature?
The default value of 'superuser_reserved_connections' is 2, so maybe
fe
Greg Stark <[EMAIL PROTECTED]> writes:
> Updated patch. Fixed a few minor things, added documentation and regression
> tests. Unfortunately I can't test the regression tests because I get a
> segmentation fault earlier in the same file due to a GIN index build. So I
> haven't updated the "expected"
On Thu, Aug 24, 2006 at 01:48:50PM -0400, Alvaro Herrera wrote:
> Tom Lane wrote:
> > "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > > On Thu, Aug 24, 2006 at 09:58:10AM -0400, Tom Lane wrote:
> > >> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > >>> I think there is a reasonable case for saying th
Hello again,This is an usable version of my EAN13/UPC/ISBN module. It handles EAN13, ISBN13, ISBN, ISMN, ISSN, UPC and the non standard ISMN13 and ISSN13.
It validates check digits and can be used to auto generate valid numbers with correct check digits too.
It seems the the file I attached w
I wrote:
> I'm trying to work out whether we can fix this by taking an MVCC
> snapshot before we scan the index, and then inserting all tuples we find
> in the heap that are live according to the snap but are not present in
> the indexscan data. There are still race conditions in this but I think
On 8/24/06, Tom Lane <[EMAIL PROTECTED]> wrote:
This reminds me of a consideration I had been intending to bring up on
the mailing lists: what exactly do we want to do with the SPI API for
RETURNING queries? The current behavior is that it still returns
SPI_OK_INSERT and so on, but also creates
Tom Lane wrote:
Another issue I noted in that same area is that spi.c does not set
SPI_processed for a utility statement, even if the utility statement
returns tuples. Is this a bug, or should we leave it alone?
Bug or not, it's at least a limitation we could do without, I think.
cheers
--On Donnerstag, August 24, 2006 11:02:43 -0500 Jaime Casanova
<[EMAIL PROTECTED]> wrote:
Actually the code delete implicit rules based on a field added to
pg_rewrite but that catalog has a unique index on ev_class, rulename:
"pg_rewrite_rel_rulename_index" UNIQUE, btree (ev_class, rulename)
i
David Fetter <[EMAIL PROTECTED]> writes:
>> I've found a little lacuna in the RETURNING feature, that being in
>> PL/Perl's spi_prepare()/spi_execute_prepared() as illustrated in the
>> attached file on CVS TIP.
It looks like plperl_spi_execute_fetch_result only expects to find
tuples returned if
Zoltan Boszormenyi írta:
Zoltan Boszormenyi írta:
The option parsing and error checking is now common.
I also changed it to use transformStmt() in analyze.c.
However, both the UNION and sunselect cases give me
something like this:
ERROR: could not open relation 1663/16384/16723: No such file
David Fetter wrote:
On Thu, Aug 24, 2006 at 11:31:02AM -0700, David Fetter wrote:
Folks,
I've found a little lacuna in the RETURNING feature, that being in
PL/Perl's spi_prepare()/spi_execute_prepared() as illustrated in the
attached file on CVS TIP.
I think that fixing this is a matter of
--On Donnerstag, August 24, 2006 11:00:45 -0400 Tom Lane
<[EMAIL PROTECTED]> wrote:
If the code is dependent on recognizing names to know what it's doing,
then I'd say you have a fundamentally broken approach. Consider adding
a flag column to pg_rewrite to distinguish these rules, instead.
T
Is there actually evidence that there's a lot of problems with bad join
orders? ISTM that's one of the areas where the planner actually does a
pretty good job.
I put together a quick demonstration using AxBxC where AxB is empty but AxC is
not. Sure enough, postgres chooses AxC first, then xB,
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>>> Can some other people try this? We need to get a handle on which
>>> machines show the problem.
>>
>> I am trying on current copy of HEAD.. however:
Looks like Teodor already solved the problem, so no need for a fire
drill anymore.
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> Fixed in 8.1 and HEAD. Thank you
This appears to have created a regression test failure:
*** ./expected/tsearch2.out Sun Jun 18 12:55:28 2006
--- ./results/tsearch2.out Thu Aug 24 14:30:02 2006
***
*** 2496,2503
f|
On Thu, Aug 24, 2006 at 11:31:02AM -0700, David Fetter wrote:
> Folks,
>
> I've found a little lacuna in the RETURNING feature, that being in
> PL/Perl's spi_prepare()/spi_execute_prepared() as illustrated in the
> attached file on CVS TIP.
>
> I think that fixing this is a matter of post-RETURNI
On Thu, 2006-08-24 at 11:18 +0200, Markus Schiltknecht wrote:
> Hi,
>
> Jeff Davis wrote:
> > I disagree about high-availability. In fact, I would say that sync
> > replication is trading availability and performance for synchronization
> > (which is a valid tradeoff, but costly).
>
> In a way, r
Folks,
I've found a little lacuna in the RETURNING feature, that being in
PL/Perl's spi_prepare()/spi_execute_prepared() as illustrated in the
attached file on CVS TIP.
I think that fixing this is a matter of post-RETURNING-patch cleanup.
What else might not know about RETURNING that needs to?
C
Can some other people try this? We need to get a handle on which
machines show the problem.
I am trying on current copy of HEAD.. however:
Ignore the below... This is an error with my linker/ld.so.conf
Joshua D. Drake
[EMAIL PROTECTED]:~/pgsqldev$ bin/psql -U postgres postgres <
share/
Can some other people try this? We need to get a handle on which
machines show the problem.
[EMAIL PROTECTED]:~/pgsqldev$ /usr/local/pgsql/bin/psql -U postgres postgres
Welcome to psql 8.1.3, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help wit
Tom Lane wrote:
"Andrew J. Kopciuch" <[EMAIL PROTECTED]> writes:
On Thursday 24 August 2006 10:34, Stefan Kaltenbrunner wrote:
devel=# select 'blah foo bar'::tsvector = 'blah foo bar'::tsvector;
?column?
--
f
(1 row)
This could be an endianess issue?
Apparently not, it works for me
Stefan said he reproduced on OpenBSD/i386 so it is unlikely to be an
endianness issue. Anyway, here's the comparison code- I guess it doesn't
use strcmp to avoid encoding silliness. (?)
I suppose that ordering for tsvector type is some strange and it hasn't any
matter. For me, it's a secret wh
Jim C. Nasby wrote:
On Wed, Aug 23, 2006 at 10:49:05AM +0200, Martijn van Oosterhout wrote:
8) WAL/XLOG
Question: Should be deleted?
I imagine you should probably force a checkpoint and then wipe the wal
records. The WAL isn't going to be able to cover some of the stuff done
during the upgr
Teodor Sigaev wrote:
>> devel=# select 'blah foo bar'::tsvector = 'blah foo bar'::tsvector;
>> ?column?
>> --
>> f
>> (1 row)
>
> Fixed in 8.1 and HEAD. Thank you
thanks for the fast response - would it maybe be worthwhile to add
regression tests for this kind of thing though ?
Stefan
Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > On Thu, Aug 24, 2006 at 09:58:10AM -0400, Tom Lane wrote:
> >> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> >>> I think there is a reasonable case for saying that a manual vacuum could
> >>> hint pgstat to create the entry instead.
>
"Andrew J. Kopciuch" <[EMAIL PROTECTED]> writes:
> On Thursday 24 August 2006 10:34, Stefan Kaltenbrunner wrote:
>> devel=# select 'blah foo bar'::tsvector = 'blah foo bar'::tsvector;
>> ?column?
>> --
>> f
>> (1 row)
> This could be an endianess issue?
Apparently not, it works for me on
On Aug 24, 2006, at 12:58 , Andrew J. Kopciuch wrote:
On Thursday 24 August 2006 10:34, Stefan Kaltenbrunner wrote:
We just had a complaint on IRC that:
devel=# select 'blah foo bar'::tsvector = 'blah foo bar'::tsvector;
?column?
--
f
(1 row)
This could be an endianess issue?
T
devel=# select 'blah foo bar'::tsvector = 'blah foo bar'::tsvector;
?column?
--
f
(1 row)
Fixed in 8.1 and HEAD. Thank you
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
On Thursday 24 August 2006 10:34, Stefan Kaltenbrunner wrote:
> We just had a complaint on IRC that:
>
> devel=# select 'blah foo bar'::tsvector = 'blah foo bar'::tsvector;
> ?column?
> --
> f
> (1 row)
>
This could be an endianess issue?
This was probably the same person who posted th
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Thu, Aug 24, 2006 at 09:58:10AM -0400, Tom Lane wrote:
>> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>>> I think there is a reasonable case for saying that a manual vacuum could
>>> hint pgstat to create the entry instead.
>>
>> The problem with that
Gregory Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> Unless someone's got a brilliant idea, my recommendation at this point
>> is that we restrict the patch to building only non-unique indexes.
> I assume you'll add the check?
Yeah, I'll take care of it.
At the mom
Jim C. Nasby wrote:
> On Sun, Aug 20, 2006 at 10:56:12PM -0700, Neil Conway wrote:
> > On Mon, 2006-08-21 at 07:31 +0200, Hans-Juergen Schoenig wrote:
> > > CREATE OR REPLACE FUNCTION xy() RETURNS SETOF record AS $$
> > >SELECT relname::text, relpages::int4
> > >FROM pg_clas
We just had a complaint on IRC that:
devel=# select 'blah foo bar'::tsvector = 'blah foo bar'::tsvector;
?column?
--
f
(1 row)
and that searches for certain values would not return all matches under
some circumstances.
a little bit of testing shows the following:
postgres=# create tab
On 8/24/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Bernd Helmle <[EMAIL PROTECTED]> writes:
> While working on Alvaro's suggestions to fix the code i got the opinion
> that we need to reject any attempts to name a user defined rule
> as
> "_INSERT"
> "_NOTHING_INSERT"
> "_DELETE"
> "_NOTHING_DELETE
On Wed, Aug 23, 2006 at 10:49:05AM +0200, Martijn van Oosterhout wrote:
> > 8) WAL/XLOG
> > Question: Should be deleted?
>
> I imagine you should probably force a checkpoint and then wipe the wal
> records. The WAL isn't going to be able to cover some of the stuff done
> during the upgrade, so
On Sun, Aug 20, 2006 at 10:56:12PM -0700, Neil Conway wrote:
> On Mon, 2006-08-21 at 07:31 +0200, Hans-Juergen Schoenig wrote:
> > CREATE OR REPLACE FUNCTION xy() RETURNS SETOF record AS $$
> >SELECT relname::text, relpages::int4
> >FROM pg_class;
> > $$ LANGUAGE SQL IMMUTAB
On Thu, Aug 24, 2006 at 09:58:10AM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I think there is a reasonable case for saying that a manual vacuum could
> > hint pgstat to create the entry instead.
>
> The problem with that is that a simple "VACUUM;" would force pgstat t
[EMAIL PROTECTED] (Jeff Davis) writes:
> On Wed, 2006-08-23 at 13:36 +0200, Markus Schiltknecht wrote:
>> Hannu Krosing wrote:
>> > But if you have very few writes, then there seems no reason to do sync
>> > anyway.
>>
>> I think there is one: high-availability. A standby-server which can
>> cont
Bernd Helmle <[EMAIL PROTECTED]> writes:
> While working on Alvaro's suggestions to fix the code i got the opinion
> that we need to reject any attempts to name a user defined rule
> as
> "_INSERT"
> "_NOTHING_INSERT"
> "_DELETE"
> "_NOTHING_DELETE"
> "_UPDATE"
> "_NOTHING_UPDATE"
If the code is
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I think there is a reasonable case for saying that a manual vacuum could
> hint pgstat to create the entry instead.
The problem with that is that a simple "VACUUM;" would force pgstat to
populate its entire hashtable. Which more or less defeats the ide
Larry Rosenman wrote:
> Jim C. Nasby wrote:
> > On Tue, Aug 22, 2006 at 11:08:49AM -0400, Tom Lane wrote:
> >> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> >>> If there's a bunch of activity on a table but stats are reset
> >>> before a vacuum is run on it and then a vacuum is run, the user
> >>> w
Jim C. Nasby wrote:
> On Tue, Aug 22, 2006 at 11:08:49AM -0400, Tom Lane wrote:
>> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>>> If there's a bunch of activity on a table but stats are reset
>>> before a vacuum is run on it and then a vacuum is run, the user
>>> will still be left thinking that th
Tom Lane <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> I was also considering going ahead and implementing Hannu's ALTER INDEX SET
>> UNIQUE too.
>
> Don't waste your time, when we don't have an algorithm that would make
> it work. It's too late for 8.2 anyway...
Oh,
Gregory Stark <[EMAIL PROTECTED]> writes:
> I was also considering going ahead and implementing Hannu's ALTER INDEX SET
> UNIQUE too.
Don't waste your time, when we don't have an algorithm that would make
it work. It's too late for 8.2 anyway...
regards, tom lane
---
> If this will be used interactively, it would be nice to have both. That
> way if you're running a bunch of cursor fetches, you can just do one
> \set, but if you only want to run one or a few you can use \gc and not
> mess around with \set. But I don't know how common interactive usage
> will be.
Zoltan Boszormenyi írta:
The option parsing and error checking is now common.
I also changed it to use transformStmt() in analyze.c.
However, both the UNION and sunselect cases give me
something like this:
ERROR: could not open relation 1663/16384/16723: No such file or
directory
What else
Tom Lane írta:
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
How about the callback solution for the SELECT case
that was copied from the original? Should I consider
open-coding in copy.c what ExecutorRun() does
to avoid the callback?
Adding a DestReceiver type is a good solution ...
Tom Lane <[EMAIL PROTECTED]> writes:
> I wrote:
>> The problem case is that we take a tuple and try to insert it into the index.
>> Meanwhile someone else updates the tuple, and they're faster than us so
>> they get the new version into the index first. Now our aminsert sees a
>> conflicting ind
On Fri, Aug 18, 2006 at 10:16:12AM -0400, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > A \set variable would make sense to me.
>
> So Peter and Bruce like a \set variable, Chris and I like a different
> command. Seems like a tie ... more votes out there anywhere?
If this wi
Hi,
Jeff Davis wrote:
I disagree about high-availability. In fact, I would say that sync
replication is trading availability and performance for synchronization
(which is a valid tradeoff, but costly).
In a way, replication is for databases systems what RAID1 is for hard
drives. Having multip
On Thu, Aug 17, 2006 at 10:39:14PM -0400, Alvaro Herrera wrote:
> Another question. The patch does a lot of scanning of the range table
> searching for specific aliases for things -- usually for *NEW* or *OLD*,
> but also to get the entry for the view we are modifying, etc. This
> seems pretty fr
On Wed, Aug 23, 2006 at 08:42:10AM -0700, Mark Dilger wrote:
> Jim C. Nasby wrote:
> >On Tue, Aug 22, 2006 at 11:56:17AM -0700, Mark Dilger wrote:
> >>I proposed something like this quite a bit up-thread. I was hoping we
> >>could have a mode in which the system would run the second, third,
> >>
55 matches
Mail list logo
