Jonah H. Harris wrote:
I'm willing to move soundex and metaphone into the backend.
Does anyone see a reason not to do so?
As a kinda strange reason, I like them in contrib because
they demonstrate a nice simple example of how one can write a
contrib extension.
This module has simple functions
Tom Lane wrote:
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.
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 ps
"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 registe
"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
-- 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
""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, bu
""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 co
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
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 backen
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 m
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 ... tha
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 t
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 dataty
> >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
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 c
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,
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 fu
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,
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
>
>
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.
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/: backend/utils/adt/dat
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
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
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 wo
"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 o
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 re
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=shark&dt=2005-05-26%2004:21:00
I'm getting the same regression failures shown in that link; he
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 wil
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 nobo
> >>(*) 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
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 th
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 soun
> 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 pip
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
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
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 i
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 tab
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
"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 data
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 n
41 matches
Mail list logo
