Currently PG win32 port mainly does the following to simulate signals:
(*) the process who kill the signal:
- put the signal in a named pipe, then it is done;
(*) the process who should receive the signal:
- a non-stop thread pg_signal_thread will read the signal from the pipe,
and start
I spent a little while looking into a performance issue with a large
UPDATE on a table with foreign keys. A few questions:
(1) When a PK table is updated, we skip firing the per-row UPDATE RI
triggers if none of the referenced columns in the PK table have been
modified. However, AFAICS we do
Jonah H. Harris [EMAIL PROTECTED] writes:
Hey everyone,
I've been working with a couple people who didn't know that soundex
and metaphone were included in the distribution as contrib modules.
While it's their fault that they didn't check contrib, soundex is
pretty common among database
At a minimum I think we should support soundex in the core. I'm willing
to move soundex and metaphone into the backend. Does anyone see a
reason not to do so?
Douglas McNaught wrote:
Jonah H. Harris [EMAIL PROTECTED] writes:
Hey everyone,
I've been working with a couple people who
On Thu, 26 May 2005, Neil Conway wrote:
I spent a little while looking into a performance issue with a large
UPDATE on a table with foreign keys. A few questions:
(1) When a PK table is updated, we skip firing the per-row UPDATE RI
triggers if none of the referenced columns in the PK table
Stephan Szabo wrote:
Are you sure? RI_FKey_Check seems to have a section on
TRIGGER_FIRED_BY_UPDATE which seems to check if the keys are equal if the
old row wasn't part of this transaction.
Well, regardless of how RI_FKey_Check() itself works, ISTM there is no
need to enqueue the RI trigger
On Thu, 26 May 2005, Stephan Szabo wrote:
On Thu, 26 May 2005, Neil Conway wrote:
(2) For per-row RI triggers of all kinds, we save the trigger under
CurTransactionContext and invoke it at the end of the current query.
There is not even overflow to disk (the report that prompted me to
Jonah H. Harris wrote:
At a minimum I think we should support soundex in the core. I'm
willing to move soundex and metaphone into the backend. Does anyone
see a reason not to do so?
Soundex is really only useful for English names with English
pronunciation. If we were to adapt a phonetic
Currently PG win32 port mainly does the following to simulate signals:
(*) the process who kill the signal:
- put the signal in a named pipe, then it is done;
(*) the process who should receive the signal:
- a non-stop thread pg_signal_thread will read the signal
from the pipe, and
Peter,
I don't disagree with you that a more generalized function would also be
good, just that soundex is common and would be helpful if it were built-in.
Peter Eisentraut wrote:
Jonah H. Harris wrote:
At a minimum I think we should support soundex in the core. I'm
willing to move
Magnus Hagander wrote:
(*) the process who kill the signal:
- put the signal in a *shared memory variable
pg_signal_queue* and
SetEvent(*shared_memory_event_variable*), then it is done;
(*) the process who should receive the signal:
- the main thread of this process could be awakened by
(*) the process who kill the signal:
- put the signal in a *shared memory variable
pg_signal_queue* and
SetEvent(*shared_memory_event_variable*), then it is done;
(*) the process who should receive the signal:
- the main thread of this process could be awakened by the
event from
Jonah H. Harris wrote:
At a minimum I think we should support soundex in the core. I'm
willing to move soundex and metaphone into the backend. Does anyone
see a reason not to do so?
I take it you mean apart from the fact that soundex is horribly limited
and out of data and probably
Stephan Szabo [EMAIL PROTECTED] writes:
Are you sure? RI_FKey_Check seems to have a section on
TRIGGER_FIRED_BY_UPDATE which seems to check if the keys are equal if the
old row wasn't part of this transaction. I'm not sure why it's doing the
transaction id check, but it looks like it will do
I'm getting time, timetz, and horology regression failures in HEAD
on Solaris 9 / gcc 3.4.2. So are other machines in the build farm,
such as this one:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=sharkdt=2005-05-26%2004:21:00
I'm getting the same regression failures shown in that link;
Hi Rod Taylor,
ajs at crankycanuck.ca wrote
On Thu, May 26, 2005 at 11:18:12AM +0630, Narasimha.Sridhar at cybernetsoft.com wrote:
Hi
Can anybody tell me whether Slony-I replication works with Postgres
v7.2.1. I dont
see any document specifying the minimum postgres version required by
Jonah H. Harris [EMAIL PROTECTED] writes:
At a minimum I think we should support soundex in the core. I'm willing
to move soundex and metaphone into the backend. Does anyone see a
reason not to do so?
Is it really ready for prime time? For one thing, a quick look shows no
evidence of
On Fri, 27 May 2005, Neil Conway wrote:
Stephan Szabo wrote:
Are you sure? RI_FKey_Check seems to have a section on
TRIGGER_FIRED_BY_UPDATE which seems to check if the keys are equal if the
old row wasn't part of this transaction.
Well, regardless of how RI_FKey_Check() itself works,
On Thu, 26 May 2005, Stephan Szabo wrote:
On Fri, 27 May 2005, Neil Conway wrote:
Stephan Szabo wrote:
Are you sure? RI_FKey_Check seems to have a section on
TRIGGER_FIRED_BY_UPDATE which seems to check if the keys are equal if the
old row wasn't part of this transaction.
Well,
Tom Lane wrote:
Jonah H. Harris [EMAIL PROTECTED] writes:
At a minimum I think we should support soundex in the core. I'm willing
to move soundex and metaphone into the backend. Does anyone see a
reason not to do so?
Is it really ready for prime time? For one thing, a quick
Michael Fuhr [EMAIL PROTECTED] writes:
I'm getting time, timetz, and horology regression failures in HEAD
on Solaris 9 / gcc 3.4.2. So are other machines in the build farm,
such as this one:
I'll bet a nickel this broke it:
2005-05-25 23:48 momjian
* src/:
Stephan Szabo [EMAIL PROTECTED] writes:
Okay, I can't think of cases even with triggers and the like where
removing the check on equal valued rows would give appreciably different
results, but I haven't thought too hard about it.
Err, except the case that Tom mentions in his message.
But the
Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
I'm getting time, timetz, and horology regression failures in HEAD
on Solaris 9 / gcc 3.4.2. So are other machines in the build farm,
such as this one:
I'll bet a nickel this broke it:
2005-05-25 23:48 momjian
* src/:
On Thu, 26 May 2005, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
Okay, I can't think of cases even with triggers and the like where
removing the check on equal valued rows would give appreciably different
results, but I haven't thought too hard about it.
Err, except the
On Thu, 26 May 2005, Tom Lane wrote:
The thoughts I've had about special-casing RI events to save memory
have to do with the idea of lossy storage. As you accumulate more
per-row events, at some point it becomes more efficient to forget
the individual rows and just reapply the original
Stephan Szabo [EMAIL PROTECTED] writes:
On Thu, 26 May 2005, Tom Lane wrote:
The thoughts I've had about special-casing RI events to save memory
have to do with the idea of lossy storage.
One problem with that is that it works for the constraint check but not
for referential actions,
True.
On Thu, 26 May 2005, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
On Thu, 26 May 2005, Tom Lane wrote:
The thoughts I've had about special-casing RI events to save memory
have to do with the idea of lossy storage.
One problem with that is that it works for the constraint
At the VERY LEAST, you'd best get off 7.2.1 to something later (i.e.
the last 7.2 release). ISTR some nasty bug or other in 7.2.1.
I heard for Andrew Sullivan that you managed to hack Slony-I to work
for postgre 7.2.
Can you tell me how you did as it would me helpful to me
I no longer
On 5/25/05, Jaime Casanova [EMAIL PROTECTED] wrote:
Also, defining the return type as ANYELEMENT will definitely NOT work,
since none of the input arguments are polymorphic.
mmm... This is a problem, there is a way to make a function that can
be used for returning different datatypes
Hi,
I reinstall postgresql 7.4.6 instead of 7.4.8 (still on Solaris 10)
and didn't include postgresql as services that is managed by SMF, and
it works fine so far. Also, I should mentioned that I configured
postgresql 7.4.6 with --enable-thread-safety option, don't know if
this will have anything
On Wed, 25 May 2005 18:19:19 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
but it keeps a list (hash table, file, whatever) of those blocks.
[...] Is it sufficient to
remember just the relation and the block number or do we need the
contents a well?
We don't *have* the contents ... that's exactly
Manfred Koizar [EMAIL PROTECTED] writes:
[...] Is it sufficient to
remember just the relation and the block number or do we need the
contents a well?
I meant the contents of the WAL record, not the original block
contents. Anyway, I think it's not needed.
Oh, I see. Yes, it might be
Hackers,
I'm seeing the following weirdness with the 2PC patch:
alvherre=# begin;
BEGIN
alvherre=# create table a (a int);
CREATE TABLE
alvherre=# insert into a values (1);
INSERT 0 1
alvherre=# prepare transaction 'foo';
PREPARE TRANSACTION
alvherre=# select * from a;
At this point, the
Alvaro Herrera [EMAIL PROTECTED] writes:
I'm wondering what should happen at prepare time so that my own cache
is correct.
Good point. As far as the local caches are concerned, we probably have
to make it look like the transaction rolled back. I think Heikki
already had code in there to send
Magnus Hagander [EMAIL PROTECTED] writes
Yeah, that should work. With one shared memory segment and one event for
each process, of course. The event can be the same one as is used now,
only it has to be named so it can be accessed externally.
Yes, the shared memory segment size could be
Magnus Hagander [EMAIL PROTECTED] writes
I assume that this will not break the use of pg_ctl to
deliver pseudo-signals. That would be a show-stopper.
It shouldn't, but there is one concern: it has to be created in the
global namespace. On older windows there is no different, but on modern
-- First part ---
In md.c/RememberFsyncRequest():
if (hash_search(pendingOpsTable, entry, HASH_ENTER, NULL) == NULL)
ereport(FATAL,
(errcode(ERRCODE_OUT_OF_MEMORY),
errmsg(out of memory)));
pendingOpsTable uses MdCxt to allocate memory. So if out of memory, we
actually have no
Qingqing Zhou [EMAIL PROTECTED] writes:
In md.c/RememberFsyncRequest():
if (hash_search(pendingOpsTable, entry, HASH_ENTER, NULL) == NULL)
ereport(FATAL,
(errcode(ERRCODE_OUT_OF_MEMORY),
errmsg(out of memory)));
pendingOpsTable uses MdCxt to allocate memory. So if out of
Tom Lane [EMAIL PROTECTED] writes
Qingqing Zhou [EMAIL PROTECTED] writes:
Unsafe is a bit of an overstatement, when you evidently haven't
analyzed the consequences of either choice of error level. That is,
why is this a bug?
Consider the senario like this:
Backends register some dirty
Tom Lane wrote:
But the check could incorporate the same transaction ID test already
in use. I think Neil is right that it'd be a win to apply the test
before enqueueing the trigger instead of after.
Speaking of which, does anyone see a reason why RI_FKey_keyequal_upd()
is implemented as a
40 matches
Mail list logo
