On Mon, Apr 02, 2007 at 10:01:44PM -0400, Alvaro Herrera wrote:
Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list
at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers
reviews
Pavel Stehule wrote:
it's problem. You cannot do it now. One year ago I sent patch
http://archives.postgresql.org/pgsql-patches/2006-03/msg00196.php
The only comments to that were that no one knew what it was good for.
But now we know, so I think we should add your patch.
--
Peter
David Fetter [EMAIL PROTECTED] writes:
On Mon, Apr 02, 2007 at 10:01:44PM -0400, Alvaro Herrera wrote:
So, hum, what happened to the idea of creating the array types only
on demand?
Scotched, as far as I could tell,
More like you submitted a patch that entirely ignores multiple people's
Ühel kenal päeval, E, 2007-04-02 kell 19:36, kirjutas Joshua D. Drake:
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
Added to TODO:
* Add idle_timeout GUC so locks are not held for log periods of time
That should actually be transaction_idle_timeout.
Pavel Stehule wrote:
it's problem. You cannot do it now. One year ago I sent patch
http://archives.postgresql.org/pgsql-patches/2006-03/msg00196.php
The only comments to that were that no one knew what it was good for.
But now we know, so I think we should add your patch.
Tom Lane did it
On Mon, 2007-04-02 at 19:09 -0400, Bruce Momjian wrote:
Where is this patch?
see Hackers thread: Minor changes to Recovery related code, Mar 30
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
... should we revel
in configurability, and allow CREATE TABLE/ALTER TABLE behavior to
vary depending on the current threshold setting? We'd have to fix
the
toaster routines to not try to push stuff out-of-line when there is
no
out-of-line to push to ... but I think we probably had
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
What sort of wait for finish mechanism do you have in mind?
I was thinking of XactLockTableWait.
Ugh. I don't think the bgwriter can participate in heavyweight-lockmgr
operations, or should become able to.
Oh,
On 4/3/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Where are we on Python 2.5?
I'll look into it.
--
marko
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL
On Mon, 2007-04-02 at 16:14 -0700, Jeff Davis wrote:
The results are very positive and quite conclusive.
Can we show some summary results?
I'm happy that the scans stay together all the way around, even handling
the max- 0 blockid transition well. So definite winner for me.
However, the
Hi Magnus.
configure was changed the cvs head.
Is this what you intended it?_?
I think necessary to recover it.
*** configure.orig Tue Apr 3 17:51:06 2007
--- configure Tue Apr 3 17:52:21 2007
***
*** 16732,16739
# For each platform, we need to know about any special
On Tue, Apr 03, 2007 at 06:06:16PM +0900, Hiroshi Saito wrote:
Hi Magnus.
configure was changed the cvs head.
Is this what you intended it?_?
I think necessary to recover it.
*** configure.orig Tue Apr 3 17:51:06 2007
--- configure Tue Apr 3 17:52:21 2007
***
***
Hi.
Am I misunderstanding it?
That is intended. With the changes that was put in to ecpg, pthreads is no
longer required. We use the native threading on Windows instead.
Also, enable_thread_safety is now the default for windows :-)
Ooops, Isn't pthreadGC2 necessary?
Slony-I is still
Mark Dilger wrote:
In particular, in UTF8 land I'd have expected the argument of chr()
to be interpreted as a Unicode code point, not as actual UTF8 bytes
with a randomly-chosen endianness.
Not sure what to do in other multibyte encodings.
Not sure what to do in other multibyte encodings
Here's third revision of WAL archival optimization patch. GUC
parameter name was changed to wal_add_optimization_info.
Regards;
--
Koichi Suzuki
20070403_pg_lesslog.tar.gz
Description: application/gzip
---(end of broadcast)---
TIP 1: if
On 4/3/07, Marko Kreen [EMAIL PROTECTED] wrote:
On 4/3/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Where are we on Python 2.5?
I'll look into it.
Following patch converts plpython.c to use Python 2.5 types,
with compat ifdef for older version. This is recommended
method by PEP 353 to fix the
Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
Thank you very much for including. Attached is an update of the patch
according to Simon Riggs's comment about GUC name.
Regards;
--
Koichi
what can't be purchased and silenced, should be killed with rain of law suits.
Microsoft does it, novell does it, sco does it, and oracle too.
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
On Tue, Apr 03, 2007 at 06:16:26PM +0900, Hiroshi Saito wrote:
Hi.
Am I misunderstanding it?
That is intended. With the changes that was put in to ecpg, pthreads is no
longer required. We use the native threading on Windows instead.
Also, enable_thread_safety is now the default for
Magnus Hagander wrote:
On Tue, Apr 03, 2007 at 06:16:26PM +0900, Hiroshi Saito wrote:
Slony-I is still used...Ahh, I have not confirmed it yet.
Slony uses it, yes. It would probably be worthwhile to fix that one as
well, but I haven't looked at how much work that would be.
And to port the
From: Dave Page [EMAIL PROTECTED]
Magnus Hagander wrote:
On Tue, Apr 03, 2007 at 06:16:26PM +0900, Hiroshi Saito wrote:
Slony-I is still used...Ahh, I have not confirmed it yet.
Slony uses it, yes. It would probably be worthwhile to fix that one as
well, but I haven't looked at how much
Marko Kreen escribió:
On 4/3/07, Marko Kreen [EMAIL PROTECTED] wrote:
On 4/3/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Where are we on Python 2.5?
I'll look into it.
Following patch converts plpython.c to use Python 2.5 types,
with compat ifdef for older version. This is recommended
On Tue, Apr 03, 2007 at 02:30:07AM -0400, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
On Mon, Apr 02, 2007 at 10:01:44PM -0400, Alvaro Herrera wrote:
So, hum, what happened to the idea of creating the array types
only on demand?
Scotched, as far as I could tell,
More like
Great. Care to take on the Python boolean patch?
o Allow PL/PythonU to return boolean rather than 1/0
http://archives.postgresql.org/pgsql-patches/2007-01/msg00596.php
It requires only a few lines of code, but some testing, which you seem
to have available.
Patch applied. Thanks.
---
Marko Kreen wrote:
On 4/3/07, Marko Kreen [EMAIL PROTECTED] wrote:
On 4/3/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Where are we on Python 2.5?
I'll look into it.
Following patch
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
On 2007-04-03, Albe Laurenz [EMAIL PROTECTED] wrote:
According to RFC 2279, the Euro,
Unicode code point 0x20AC = 0010 1010 1100,
will be encoded to 1110 0010 1000 0010 1010 1100 = 0xE282AC.
IMHO this is the only good and intuitive way for CHR() and ASCII().
It is beyond ludicrous for
On 4/3/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Great. Care to take on the Python boolean patch?
o Allow PL/PythonU to return boolean rather than 1/0
http://archives.postgresql.org/pgsql-patches/2007-01/msg00596.php
It requires only a few lines of code, but some testing,
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
Nor will that work for prepared xacts --- you don't want to wait for the
eventual commit, only for PREPARE TRANSACTION to exit its critical
section.
PREPARE TRANSACTION wouldn't set the flag in MyProc; there's no clog
changes to
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
Nor will that work for prepared xacts --- you don't want to wait for the
eventual commit, only for PREPARE TRANSACTION to exit its critical
section.
PREPARE TRANSACTION wouldn't set the flag in MyProc; there's no
I noticed that the plan invalidation is not immediately effective.
Not sure whether it's worth fixing or has any other side-effects,
but thought would just post it.
I was testing the following scenario:
session1session2
CREATE TABLE test
(int a, int
Chris Browne [EMAIL PROTECTED] writes:
Here's a drafty patch that *tries* to do this using a GUC variable;
it passes some interactive testing.
BTW, it strikes me that a GUC variable is quite the wrong way to go
about this. The right way is a table storage parameter, a la FILLFACTOR,
so that it
Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
On Mon, Apr 02, 2007 at 10:01:44PM -0400, Alvaro Herrera wrote:
So, hum, what happened to the idea of creating the array types only
on demand?
Scotched, as far as I could tell,
More like you submitted a patch that entirely
Tom,
On 4/3/07 7:15 AM, Tom Lane [EMAIL PROTECTED] wrote:
BTW, it strikes me that a GUC variable is quite the wrong way to go
about this. The right way is a table storage parameter, a la FILLFACTOR,
so that it can be set on a per-table basis. That would also give us a
chance to fix my
On Tue, Apr 03, 2007 at 11:43:21AM +0200, Albe Laurenz wrote:
IMHO this is the only good and intuitive way for CHR() and ASCII().
Hardly. The comment earlier about mbtowc was much closer to the mark.
And wide characters are defined as Unicode points.
Basically, CHR() takes a unicode point and
Am Montag, 2. April 2007 18:41 schrieb Tom Lane:
Certainly they'd all be explicit-only. From a technical perspective
there's no need to do the two things at the same time; I'm just opining
that we could sell it easier if we did them together. If we just do
this part, what users will see is
Peter Eisentraut wrote:
Am Montag, 2. April 2007 18:41 schrieb Tom Lane:
Certainly they'd all be explicit-only. ?From a technical perspective
there's no need to do the two things at the same time; I'm just opining
that we could sell it easier if we did them together. ?If we just do
this
On 4/3/07, Marko Kreen [EMAIL PROTECTED] wrote:
On 4/3/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Great. Care to take on the Python boolean patch?
o Allow PL/PythonU to return boolean rather than 1/0
I think this should be also solved with backwards-compat ifdef.
Tested with python
While going through some log files, we noticed that some of the log entries
are garbled. For example:
2007-03-27 01:19:44.139 UTC [1761474] oxrsa aepp xx.xx.xx.xx LOG:
duratio2007-03-n: 3751.27 01:19801 ms :44.139 statemenUTC [421940]
oxrt: EXECUsor
g aTE unnaepp 10.4med [P0.136.10REPARE: 8
Hi,
The following things are TODOs:
iv) Auto generate rules using the checks mentioned for the partitions, to
handle INSERTs/DELETEs/UPDATEs to navigate them to the appropriate child.
Note that checks specified directly on the master table will get inherited
automatically.
Am planning to
Great, patch applied and TODO item removed.
---
Marko Kreen wrote:
On 4/3/07, Marko Kreen [EMAIL PROTECTED] wrote:
On 4/3/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Great. Care to take on the Python boolean patch?
Am Dienstag, 3. April 2007 17:17 schrieb Bruce Momjian:
I assumed the issue was that there might not be explicit casts for every
case were were now disallowing.
My proposal is to downgrade some casts from implicit to assignment. Tom's
proposal is to add more casts at the level of explicit,
Andrew wrote:
According to RFC 2279, the Euro,
Unicode code point 0x20AC = 0010 1010 1100,
will be encoded to 1110 0010 1000 0010 1010 1100 = 0xE282AC.
IMHO this is the only good and intuitive way for CHR() and ASCII().
It is beyond ludicrous for functions like chr() or ascii() to
Am Montag, 2. April 2007 18:41 schrieb Tom Lane:
The scheme that was in the back of my mind was to do this at the same
time as providing a general facility for casting *every* type to and
from text, by means of their I/O functions if no specialized cast is
provided in pg_cast.
On Mon, 2007-04-02 at 21:38 -0700, Luke Lonergan wrote:
Jeff,
Your conclusions sound great - can you perhaps put the timings in a column
in your table so we can confirm them?
I just threw the logs up, which contain the timings involved. I will try
to make graphs out of them, but the data
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
Tom Lane wrote:
Just to distinguish postmasters from standalone backends in the error
messages. I think that's still useful.
I'm not sure what you mean. It is used only in CreatePidFile function
and I think that if directory is locked
Martijn van Oosterhout wrote:
On Tue, Apr 03, 2007 at 11:43:21AM +0200, Albe Laurenz wrote:
IMHO this is the only good and intuitive way for CHR() and ASCII().
Hardly. The comment earlier about mbtowc was much closer to the mark.
And wide characters are defined as Unicode points.
Basically,
Peter,
Which precise implicit casts are we breaking? Can we provide an exact list in
the release notes?
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
Mark Dilger [EMAIL PROTECTED] writes:
Martijn van Oosterhout wrote:
Just about every multibyte encoding other than Unicode has the problem
of not distinguishing between the code point and the encoding of it.
Thanks for the feedback. Would you say that the way I implemented things in
the
Peter Eisentraut [EMAIL PROTECTED] writes:
FWIW, is the attached patch about what you had in mind? (It probably only
covers normal types at the moment.)
Hm, I hadn't realized that it would take as little work as that ...
I have an itchy feeling that you missed something but I'm not sure
what.
Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
Ühel kenal päeval, T, 2007-03-27 kell 07:11, kirjutas Andrew Dunstan:
Er, what listen table?
At least the list of which backends listen to which events should be
also in shared mem.
No, the intent is
On Tue, 2007-04-03 at 10:01 +0100, Simon Riggs wrote:
On Mon, 2007-04-02 at 16:14 -0700, Jeff Davis wrote:
The results are very positive and quite conclusive.
Can we show some summary results?
I should be able to make some graphs today.
I'm happy that the scans stay together all the way
Zdenek Kotala [EMAIL PROTECTED] writes:
Tom Lane wrote:
The start script does not typically have the intelligence to get this
right, particularly not the is-shmem-still-in-use part. If you check
the archives you will find many of us on record telling people who think
they should remove the
Andrew Dunstan [EMAIL PROTECTED] writes:
We'll also need to store the database id along with the event name and
message, since pg_listener is per db rather than per cluster.
Well, that's an artifact of the historical implementation ... does
anyone want to argue that LISTEN should be
Albe Laurenz wrote:
What I suggest (and what Oracle implements, and isn't CHR() and ASCII()
partly for Oracle compatibility?) is that CHR() and ASCII()
convert between a character (in database encoding) and
that database encoding in numeric form.
Looking at Oracle documentation, it appears
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
We'll also need to store the database id along with the event name and
message, since pg_listener is per db rather than per cluster.
Well, that's an artifact of the historical implementation ... does
anyone want to argue that LISTEN
Pavan Deolasee [EMAIL PROTECTED] writes:
I traced it a bit and it seems that the invalidation messages
are not accepted in session 2 because the locks are already held
on the relation.
Right, because of this coding in LockRelationOid():
/*
* Now that we have the lock, check for
On 4/3/07, Tom Lane [EMAIL PROTECTED] wrote:
I'm not particularly worried about missing a potential improvement
in the plan during the first command after a change is committed.
Me too. Just noticed it, so brought it up.
If the invalidation were something that *had* to be accounted for,
Pavan Deolasee [EMAIL PROTECTED] writes:
On 4/3/07, Tom Lane [EMAIL PROTECTED] wrote:
If the invalidation were something that *had* to be accounted for,
such as a dropped index, then there should be adequate locking for it;
plancache is not introducing any new bug that wasn't there before.
Tim Goodaire [EMAIL PROTECTED] writes:
While going through some log files, we noticed that some of the log entries
are garbled. For example:
2007-03-27 01:19:44.139 UTC [1761474] oxrsa aepp xx.xx.xx.xx LOG:
duratio2007-03-n: 3751.27 01:19801 ms :44.139 statemenUTC [421940]
oxrt: EXECUsor
Tom Lane wrote:
Note to hackers: would it make sense to use write() instead of
fprintf() in send_message_to_server_log to avoid any possibility
of stdio deciding to fragment the message? Possibly there'd be
some marginal efficiency gain too.
What about in write_syslogger_file_binary()?
On Tue, 2007-04-03 at 15:02 -0400, Tom Lane wrote:
Tim Goodaire [EMAIL PROTECTED] writes:
While going through some log files, we noticed that some of the log entries
are garbled. For example:
2007-03-27 01:19:44.139 UTC [1761474] oxrsa aepp xx.xx.xx.xx LOG:
duratio2007-03-n: 3751.27
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Note to hackers: would it make sense to use write() instead of
fprintf() in send_message_to_server_log to avoid any possibility
of stdio deciding to fragment the message? Possibly there'd be
some marginal efficiency gain too.
What
Josh,
On 3/31/07 11:01 AM, Joshua D. Drake [EMAIL PROTECTED] wrote:
The PostgreSQL project should not give any credence to these
announcements and should avoid all patent issues possible.
I think that's appropriate - the structure of the OIN looks like it's:
1) focused on Linux
2) designed to
Klint Gore [EMAIL PROTECTED] writes:
Is there any way to create operators to point like to ilike? There
doesn't seem to be a like or ilike in pg_operator (not in 7.4 anyway).
Actually it's the other way 'round: if you look into gram.y you'll see
that LIKE is expanded as the operator ~~ and
65 matches
Mail list logo
