Hey Teodor,
How's this going?
I think you were looking at the same paper I was reading about GiST
indexes. I found the GiST source code somewhat over my head, however.
I hope you'll still working on it and haven't given up!
Chris
Teodor Sigaev wrote:
Hi!
I'll have time and wish to work on
(1) Re-write the "SELECT...FOR UPDATE" SQL code, to
return with an exception or error if it cannot immediately
secure the lock, OR:
You could use SET STATEMENT_TIMEOUT...
Chris
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, pleas
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> andrew=# create table ab$cd$ef (ef$cd$ab text);
> CREATE TABLE
> andrew=# \d ab$cd$ef
> Did not find any relation named "ab$cd$ef".
Hmph. I always thought that "$" was only special at the end of a regex,
but that doesn't seem to be how our implementati
Anthony Rich <[EMAIL PROTECTED]> writes:
> When one process has a "row lock" on one or more rows
> in a table, using "SELECT...FOR UPDATE" in default lock
> mode, another process has NO WAY of aborting from the
> same request, and reporting to the user that this record
> is already locked, reserved
On Tue, 10 Feb 2004, Anthony Rich wrote:
> In other words, by the time the second process has run the
> "SELECT...FOR UPDATE" statement, it's too late!! This
> second process is now locked "forever", waiting for the
Or until statement_timeout is reached if it's set to a non-zero value.
Another interesting thing abut psql that I noticed when using '$' in
identifiers is this effect:
andrew=# create table ab$cd$ef (ef$cd$ab text);
CREATE TABLE
andrew=# \d ab$cd$ef
Did not find any relation named "ab$cd$ef".
andrew=# \d ab\$cd\$ef
Table "public.ab$cd$ef"
Column | Type | Modifie
Anthony,
What you need is a "NO WAIT" option.
This is already on the TODO list.
This feature should be implemented as GUC (see TODO list).
I don't think that a timeout would be accepted by the core team (doesn't
make too much sense to me either). Telling PostgreSQL not to wait for
certain locks
Hi Guys,
I have a suggestion for fixing a long-term and painful
problem in PostgreSQL that is holding up many very
important commercial projects, including ours!
This problem has been reported numerous times:
When one process has a "row lock" on one or more rows
in a table, using "SELECT...FOR UP
On Mon, 2004-02-09 at 16:53, Josh Berkus wrote:
> Jenny,
>
> > For 19, we moved the common conditions out of the big ORs, for 20, we
> > added distinct. We can change the query back if the optimizer can
> > handle it now.
>
> Well, we want to test if it can.
Replace the file 19.sql under datage
On Sun, 8 Feb 2004, Jeroen T. Vermeulen wrote:
> On Wed, Feb 04, 2004 at 10:22:16PM +0200, Heikki Linnakangas wrote:
>
> > There is a system view pg_prepared_xacts that gives you all transactions
> > that are in prepared state waiting for COMMITPREPARED or ABORTPREPARED.
>
> Great to hear that you
We use postgresql 7.4 running on a modified redhat
linux system as our database to store network related
data. The tables have millions of rows and several
joins on these tables are typically done in response
to user queries. The database itself takes about 40Gb
of disk space. Our application uses
On Mon, 2004-02-09 at 11:39, [EMAIL PROTECTED] wrote:
> On 9 Feb, Josh Berkus wrote:
> > Mark,
> >
> >> Ok, I've found that the kit does capture "explain" results and I've
> >> added a "Query Plans" links under the query time charts on each of the
> >> pages. Um, but I did notice a couple of pro
Shridhar Daithankar wrote:
Just stumbled upon this. just an FYI,
http://www.microsoft.com/sql/yukon/productinfo/top30features.asp
Shridhar
From the page:
> A new Snapshot Isolation (SI) level will be provided at the
> database level. With SI, users will be able to access the
> last committed ro
Bruce Momjian writes:
>
> I will do it by vote, not because _I_ decide it is unintuitive. And I
> don't have to talk _you_ into it, just a majority of developers.
Well, here's my vote on the subject: I purposefully avoided changing
the existing behavior because (a) it would break something I
On Sun, 2004-02-15 at 01:34, Neil Conway wrote:
> [EMAIL PROTECTED] writes:
> > The capability to move objects to other schemas would be quite
> > useful.
>
> I agree. It's not utterly-trivial to implement (for one thing, you
> need to move any dependant objects like indexes to the new schema),
>
Anyone please help... I'm a newbie on creating functions in postgresql.
Here is an oracle package that I'm trying to port to postgresql:
CREATE OR REPLACE PACKAGE BODY NewsPkg.NewsTools
AS
PROCEDURE del_news (i_id IN VARCHAR2)
IS
BEGIN
DELETE FROM tbl_news_type
WH
I wrote:
> I see what is going on to make Q4 slow, too. It's this:
> where o_orderdate >= date '1995-04-01' and o_orderdate < date '1995-04-01' +
> interval '3 month'
> ...
> As of CVS tip the issue could be eliminated by introducing
> cross-data-type comparison operators between types date and
On Wednesday 11 February 2004 12:46, Jim C. Nasby wrote:
> On Sun, Feb 08, 2004 at 11:24:56PM -0800, Josh Berkus wrote:
> > The problem with this approach, of course, is that large application
> > developers generally like to make the database fairly "passive" and put
> > all business & security lo
Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> No, it won't. The problem is that it should, because the backend will
>> see that as '42' followed by a $foo$ quote start.
> Ok, I see what you are saying. This mismatch would only happen on
> invalid input, though. I believe that what I did will wor
On Fri, 13 Feb 2004, Stephan Szabo wrote:
>
> On Fri, 13 Feb 2004, Tom Lane wrote:
>
> > Stephan Szabo <[EMAIL PROTECTED]> writes:
> > > On Fri, 13 Feb 2004, Tom Lane wrote:
> > >> I was looking at that last night. It seems like we could add a LIMIT at
> > >> least in some contexts. In the case
Florian Weimer <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> You can only fsync one FD at a time (too bad ... if there were a
>> multi-file-fsync API it'd solve the overspecified-write-ordering issue).
> What about aio_fsync()?
(1) it's unportable; (2) it's not clear that it's any improvement
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
... But how about
42$foo$
This is a syntax error in 7.4, and we propose to redefine it as an
integer literal '42' followed by a dollar-quote start symbol.
The test should not succeed anywhere in the stri
Tom Lane wrote:
> You can only fsync one FD at a time (too bad ... if there were a
> multi-file-fsync API it'd solve the overspecified-write-ordering issue).
What about aio_fsync()?
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands
zohn_ming wu wrote:
swap_free: Bad swap file entry 0004
Do you use ECC memory, is ECC enabled in the BIOS [and does it work -
some vendors lie about ECC support]?
I would bet that it's a soft memory error: means not used. One
bit differs, and the kernel complains about the invalid
24 matches
Mail list logo
