Dimitris Karampinas dkaram...@gmail.com writes:
Is there any way to retrieve the actual variable names (as were given
during Stored Procedure definition) for the corresponding var_ids in
pl/plpgsql/src/pl_exec.c ?
As of 9.0, you could dig through the namespace stack looking for a
match to
Alexander Korotkov aekorot...@gmail.com writes:
On Tue, May 31, 2011 at 12:06 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
The documentation should be fixed too.
Patch with documentation fix is attached.
Applied, thanks. I threw in an isnan() test too, just to be
On Wed, Jun 1, 2011 at 1:03 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Kreen mark...@gmail.com writes:
My suggestion would be to use getpeereid() everywhere.
And just have compat getpeereid() implementation on non-BSD
platforms. This would minimize ifdeffery in core core.
Hm, maybe. I'd
On Tue, May 31, 2011 at 1:07 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Ross J. Reedstrom's message of mar may 31 14:02:04 -0400 2011:
Follows from one of the practical maxims of databases: The data is
always dirty Being able to have the constraints enforced at least
On Tue, May 31, 2011 at 2:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Prevent problems by clamping negative penalty values to
zero. (Just to be really sure, I also made it force NaNs to zero.)
Do gistchoose et al expect the triangle function to obey the triangle
inequality? If so isn't it
Greg Stark gsst...@mit.edu writes:
On Tue, May 31, 2011 at 2:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Prevent problems by clamping negative penalty values to
zero. (Just to be really sure, I also made it force NaNs to zero.)
Do gistchoose et al expect the triangle function to obey the
On Tue, May 31, 2011 at 4:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Do gistchoose et al expect the triangle function to obey the triangle
inequality?
Don't think so.
I guess it was obvious but that was expect the *penalty* function to
obey the triangle inequality
--
greg
--
Sent via
Hi,
Pgpool currently acquires row locks on sequences to sync sequences
among PostgreSQL servers in replication mode.
Suppose you have a table t1(i int, j SERIAL) and two sessions are
trying to INSERT the table(initial value of t1_j_seq is 100 on
PostgreSQL server D1 and D2):
S1: INSERT INTO t1
On 31 May 2011 18:43, Alvaro Herrera alvhe...@commandprompt.com wrote:
Here it is -- as a context patch this time, as well.
--
Álvaro Herrera alvhe...@commandprompt.com
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
There
On 01/06/11 09:24, Cédric Villemain wrote:
Hello
here is a partial review of your patch, better than keeping it
sleeping in the commitfest queue I hope.
Submission review
* The patch is not in context diff format.
* The patch apply, but contains some extra
On 01/06/11 12:27, Mark Kirkwood wrote:
Re the code comments - I agree with most of them. However with respect
to the Guc units, I copied the setup for work_mem as that seemed the
most related.
Also - forget to mention - I *thought* you could specify the temp files
size GUC as KB, MB, GB
2011/5/31 Robert Haas robertmh...@gmail.com:
On Thu, May 26, 2011 at 8:33 AM, panam pa...@gmx.net wrote:
Any third party confirmation?
Yeah, it definitely looks like there is some kind of bug here. Or if
not a bug, then a very surprising feature. EXPLAIN ANALYZE outputs
from your proposed
On 01/06/11 12:32, Mark Kirkwood wrote:
On 01/06/11 12:27, Mark Kirkwood wrote:
Re the code comments - I agree with most of them. However with
respect to the Guc units, I copied the setup for work_mem as that
seemed the most related.
Also - forget to mention - I *thought* you could specify
On Tue, May 31, 2011 at 8:43 PM, Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
Yes, while here I noticed that the query was long to be killed.
I added a CHECK_FOR_INTERRUPT() in the for(;;) loop in nodeHashjoin.c.
It fixes the delay when trying to kill but I don't know about
On Tue, May 31, 2011 at 7:03 PM, Greg Stark gsst...@mit.edu wrote:
On Tue, May 31, 2011 at 1:07 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Ross J. Reedstrom's message of mar may 31 14:02:04 -0400 2011:
Follows from one of the practical maxims of databases: The data is
On 1/06/2011 1:28 AM, Rikard Pavelic wrote:
The following bug has been logged online:
Bug reference: 6046
Logged by: Rikard Pavelic
Email address: rikard.pave...@zg.htnet.hr
PostgreSQL version: 9.1 beta 1
Operating system: Windows 7 64bit
Description:select
On 1 June 2011 06:36, Peter Eisentraut pete...@gmx.net wrote:
It looks like the original DocBook distribution has a limit of 44, but
someone patched it to 256 on your installation.
But it seems like no one else has seen this problem yet, so it's quite
suspicious, since surely people have
2011/6/1 Robert Haas robertmh...@gmail.com:
On Tue, May 31, 2011 at 8:43 PM, Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
Yes, while here I noticed that the query was long to be killed.
I added a CHECK_FOR_INTERRUPT() in the for(;;) loop in nodeHashjoin.c.
It fixes the delay when
On 1/06/2011 9:01 AM, Craig Ringer wrote:
Is anyone aware of any changes between 9.0 and 9.1beta that messed with
time zone handling and loading?
By the way, it looks like using any of:
SELECT 'now'::timestamp;
SELECT 'now'::timestamptz;
SELECT current_time;
SELECT current_date;
Hi
Unfortunately, I found another way to produce invalid XML values.
template1=# SELECT (XPATH('/*', XMLELEMENT(NAME root, XMLATTRIBUTES('' as
xmlns[1];
xpath
---
root xmlns=/
Since a literal is not allowed in XML attributes, this XML value is not
Excerpts from Thom Brown's message of mar may 31 20:18:18 -0400 2011:
On 31 May 2011 18:43, Alvaro Herrera alvhe...@commandprompt.com wrote:
Here it is -- as a context patch this time, as well.
There is this scenario:
test=# CREATE DOMAIN things AS INT CHECK (VALUE 5);
CREATE DOMAIN
On Tue, May 31, 2011 at 12:04:07PM -0400, Alvaro Herrera wrote:
This patch allows you to initially declare a CHECK constraint as NOT
VALID, similar to what we already allow for foreign keys. That is, you
create the constraint without scanning the table and after it is
committed, it is
On Tue, May 31, 2011 at 8:08 PM, Tatsuo Ishii is...@postgresql.org wrote:
[snip]
In summary,
1) LOCK table foo cannot be used because of conflict with autovacuum
2) LOCK sequence just doesn't work
3) SELECT 1 FROM LOCK sequece fails after XID wraparound
If you have other idea to serialize
On Tue, May 31, 2011 at 8:08 PM, Tatsuo Ishii is...@postgresql.org wrote:
[snip]
In summary,
1) LOCK table foo cannot be used because of conflict with autovacuum
2) LOCK sequence just doesn't work
3) SELECT 1 FROM LOCK sequece fails after XID wraparound
If you have other idea to serialize
Craig Ringer cr...@postnewspapers.com.au writes:
On 1/06/2011 9:01 AM, Craig Ringer wrote:
Is anyone aware of any changes between 9.0 and 9.1beta that messed with
time zone handling and loading?
By the way, it looks like using any of:
SELECT 'now'::timestamp;
SELECT
Excerpts from David Fetter's message of mar may 31 21:42:08 -0400 2011:
A colleague brought up an interesting idea that I think is worth
exploring for all NOT VALID constraints, to wit, is there some way
(via SQL) to find which rows violate which constraints? I'm picturing
some kind of
On Tue, May 31, 2011 at 9:11 PM, Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
Oh damned, I am currently with an eeepc, I'll need 2 days to bench that :-D
I'll see tomorow.
LOL.
With respect to the root of the issue (why does the anti-join take so
long?), my first thought was that
On Sat, May 28, 2011 at 3:13 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Also, if the postmaster.pid file is not there at any point after we've
waited 5 seconds, assume the postmaster has failed and report that, rather
than almost-certainly-fruitlessly continuing to wait. The pidfile should
appear
Fujii Masao masao.fu...@gmail.com writes:
On Sat, May 28, 2011 at 3:13 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Also, if the postmaster.pid file is not there at any point after we've
waited 5 seconds, assume the postmaster has failed and report that, rather
than almost-certainly-fruitlessly
Tatsuo Ishii is...@postgresql.org writes:
Sorry, I'm not real familiar with pgpool, but have you thought about
using an advisory lock on the target table, instead of a real lock
(SELECT ... FOR UPDATE / LOCK table)?
Problem with the advisory lock is, it will not work if the target
table is
Robert Haas robertmh...@gmail.com writes:
With respect to the root of the issue (why does the anti-join take so
long?), my first thought was that perhaps the OP was very unlucky and
had a lot of values that hashed to the same bucket. But that doesn't
appear to be the case.
Well, yes it is.
On Wed, Jun 1, 2011 at 12:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
To address this corner
case, we should check whether postmaster is really running by sending
the signal 0 after we read postmater.pid file? Attached patch does that.
I find myself unimpressed by this approach, because it
On tis, 2011-05-31 at 11:49 +0300, Peter Eisentraut wrote:
On mån, 2011-05-30 at 01:30 -0400, Greg Smith wrote:
Greg Stark is right that Debbugs has a lot of interesting features
similar to the desired workflow here. It's not tied to just Debian
anymore; the GNU project is also using it
101 - 133 of 133 matches
Mail list logo
