Howdy. I'm starting some work on our favorite LISTEN/NOTIFY subsystem
in the hopes of more advanced functionality. Right now I'm using a
bastardized (RAISE NOTICE + tailing error logs) + NOTIFY to get what
should just be built in to the LISTEN/NOTIFY interface. Here's the
syntax for the
Basically I want to introduce formal support for turning
PostgreSQL into a message bus. To start with, it won't be a
scalable message bus that can scale to thousands of
concurrent connections (that's something I'd like to do long
term(tm), but I digress). The problem is with the
On Mon, 27 Dec 2004 07:55:27 +0530 (IST), Ameya S. Sakhalkar
[EMAIL PROTECTED] wrote:
For my project (main memory DBMS), I have written a main memory filesystem.
Idea is, the primary copy of data will reside in main memory. (Workable
only for small size data, at most 2GB).
Now, I want to
Sean Chittenden [EMAIL PROTECTED] writes:
* Allow LISTEN to block until a value changes. LISTEN [BLOCK|WAIT]
'relname'
* Allow LISTEN to have a timeout
LISTEN name [BLOCK] [WITH] [TIMEOUT [=] ''::INTERVAL];
* Allow blocking LISTEN queries to update the status of the proc title
Sean Chittenden [EMAIL PROTECTED] writes:
The async interface is nice, but not really useful to me as it requires
polling, instead of unblocking when an event comes through, which would
create a vastly more real time interface that should be easier on the
database.
BTW, this is nonsense;
Tom Lane wrote:
Are you using one of the scripts that
does an auto initdb if it doesn't see a valid PGDATA? 11 seconds might
be about right for that.
One problem with this theory is how come you didn't get screwed during
*that* boot cycle. It seems to require assuming that the NFS mount came
Sean Chittenden wrote:
Option 1) Use sleep(3) for the given timeout and wake up on some
interruptible a signal (USR2?). This is the simplest solution, but
likely the least portable to win32. Given the new world order of 8.0
and it's portability headaches, it's something I'm aware of.
NOTIFY 'relname' a_expr;
This would be great to have...at least I think this is what you are
driving at: (adding a noiseword for readability)
LISTEN system_messages;
NOTIFY system_messages MESSAGE logoff;
NOTIFY request_unlock MESSAGE 12345; -- for use with user locks!
Hrm... the userlock module
The async interface is nice, but not really useful to me as it
requires
polling, instead of unblocking when an event comes through, which
would
create a vastly more real time interface that should be easier on the
database.
BTW, this is nonsense; the backend sends a message exactly when the
Greetings,
As was discussed on IRC a bit- In the TODO list already there's a
blip about adding support for group ownership. In addition to this I
think it'd be nice if you could create a schema (owned by a group) in
which any tables/etc created were also owned by a group automatically.
Greg Stark [EMAIL PROTECTED] writes:
I think you want to extend the SQL syntax to allow updating views, and
implement plan nodes and executor functionality to handle them. So things
like this works:
UPDATE (SELECT id,val FROM t) SET val=0 where id 100
Then the rules you create on the views
Hi,
there is way to display all the values (fields) in a
tree node like this? for debug purpouses.
Query *query;
regards,
Jaime Casanova
_
Do You Yahoo!?
Información de Estados Unidos y América Latina, en Yahoo! Noticias.
Jaime Casanova [EMAIL PROTECTED] writes:
there is way to display all the values (fields) in a
tree node like this? for debug purpouses.
Query*query;
Look at elog_node_display().
regards, tom lane
---(end of
Where can I obtain a spec for postgresql, so I can start looking at the
code?
Benjamin
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 8: explain analyze is your friend
--- Tom Lane [EMAIL PROTECTED] escribió:
Jaime Casanova [EMAIL PROTECTED] writes:
there is way to display all the values (fields) in
a
tree node like this? for debug purpouses.
Query *query;
Look at elog_node_display().
regards, tom lane
Ok.
Simon Riggs wrote:
On Wed, 2004-12-22 at 04:43, Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
So what are we doing for 8.0?
Well, it looks like RC2 has already crashed and burned --- I can't
imagine that Marc will let us release without an RC3 given what was
committed
What are the open issues before we can release an RC3? I don't know of
any except the btree problem OSDL found. Is that fixed? Are their
others?
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a
I ran some tests last week and can report results similar on Tom's test:
pgbench -i -s 10 bench
pgbench -c 10 -t 1 bench
The tests were on a machine with a single SCSI drive that doesn't lie
about fsync. I found 7.4.X got around 75tps while 8.0 got 100tps, very
similar
Greg Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Suppose that you run a checkpoint every 5 minutes, and with the knob
you slow down the checkpoint to extend over say 3 minutes on average,
rather than the normal blast-it-out-as-fast-as-possible. Then you'll
be keeping an average
19 matches
Mail list logo
