Hi,
On Thu, Aug 13, 2009 at 2:24 AM, Magnus Hagandermag...@hagander.net wrote:
Not sure. Potentially pure luck. SIGINT has never *worked*, though, it
just hasn't crashed.
OK.
We could implement the same type of check in pg_standby, but it
requires something like CHECK_FOR_INTERRUPTS. And
Greg Stark wrote:
If you use binary encoding then you don't have to deal with that.
Though I seem to recall there is still a gotcha you have to worry
about if there are nul bytes in your datum. I don't recall exactly
what that meant you had to do though.
As far as I know, it only means that
When FindConversion() is called, it also checks current user's ACL_EXECUTE
privilege on the conproc of the fetched conversion.
Why this check is applied on FindConversion(), instead of
FindDefaultConversion()?
The FindConversion() returns the OID of conversion for the given name and
namespace,
Suspect that attaching large amounts of code is a breach of etiquette.
So apologies in advance.
Needed to write a contains(polygon,point) function that gave a level of
accuracy greater than the current 'poly@point' operator. The new
function works just fine. While at it, thought it would be
On Wed, Aug 19, 2009 at 08:38, Fujii Masaomasao.fu...@gmail.com wrote:
On Thu, Aug 13, 2009 at 2:24 AM, Magnus Hagandermag...@hagander.net wrote:
Not sure. Potentially pure luck. SIGINT has never *worked*, though, it
just hasn't crashed.
OK.
We could implement the same type of check in
Magnus Hagander wrote:
This would amount to fairly major surgery for pg_standby on Win32. Is
that something we'd want to backpatch, or do we want to backpatch just
the removal of the signal() calls which would amount to not supporting
signals in pg_standby on win32?
I think we should just
Alpha1 has been bundled and is available at
http://developer.postgresql.org/~petere/alpha/
Please check that it is sane.
Then, someone please move this to an appropriate place on the FTP server
and make an announcement.
See http://wiki.postgresql.org/wiki/Alpha_release_process for process
On Wed, Aug 19, 2009 at 03:58, Stef Walterstef-l...@memberwebs.com wrote:
Attached is a new patch, which I hope addresses all the concerns raised.
I think you forgot to actually attach the patch
(others have taken care of the question about login already I see)
--
Magnus Hagander
Me:
Magnus Hagander wrote:
On Wed, Aug 19, 2009 at 03:58, Stef Walterstef-l...@memberwebs.com wrote:
Attached is a new patch, which I hope addresses all the concerns raised.
I think you forgot to actually attach the patch
Whoops. Here it is.
Stef
diff --git a/configure.in b/configure.in
On Wed, Aug 19, 2009 at 3:53 AM, Tom Lanet...@sss.pgh.pa.us wrote:
* The expression might throw an error for some inputs, for instance
(1 / field) 0.5
which would fail on zero. We could recover by wrapping the whole
estimation process in a subtransaction, but that seems really
On Wed, Aug 19, 2009 at 3:16 PM, Greg Starkgsst...@mit.edu wrote:
On Wed, Aug 19, 2009 at 3:53 AM, Tom Lanet...@sss.pgh.pa.us wrote:
* The expression might throw an error for some inputs, for instance
(1 / field) 0.5
which would fail on zero. We could recover by wrapping the whole
Greg Stark gsst...@mit.edu writes:
We could add another flag in pg_proc for functions which cannot throw
an error. Perhaps all index operator class operators be required to
use such functions too?
It would be an extremely small set. For starters, anything that returns
a pass-by-reference data
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp writes:
Here is a WIP patch for a foreign data wrapper based dblink.
It integrates dblink module into core and adds a new functionality,
automatic transaction management.
I don't believe there is any consensus for integrating dblink into core,
2009/8/19 Tom Lane t...@sss.pgh.pa.us:
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp writes:
Here is a WIP patch for a foreign data wrapper based dblink.
It integrates dblink module into core and adds a new functionality,
automatic transaction management.
I don't believe there is any
Pavel Stehule pavel.steh...@gmail.com writes:
2009/8/19 Tom Lane t...@sss.pgh.pa.us:
I don't believe there is any consensus for integrating dblink into core,
and I for one will resist that strongly. Â Keep it in contrib.
if integration means, so I could to write query like
SELECT * FROM
Itagaki Takahiro wrote:
It integrates dblink module into core and adds a new functionality,
automatic transaction management.
Why does it need to be integrated to core? I'd prefer to keep dblink out
of core, unless there's a reason.
I want pretty much the automatic transaction management. It
2009/8/19 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2009/8/19 Tom Lane t...@sss.pgh.pa.us:
I don't believe there is any consensus for integrating dblink into core,
and I for one will resist that strongly. Keep it in contrib.
if integration means, so I could
Tom Lane wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
2009/8/19 Tom Lane t...@sss.pgh.pa.us:
I don't believe there is any consensus for integrating dblink into core,
and I for one will resist that strongly. Â Keep it in contrib.
if integration means, so I could to write query like
-- Forwarded message --
From: David Fetter da...@fetter.org
To: Andrew Dunstan and...@dunslane.net
Date: Tue, 18 Aug 2009 11:31:41 -0700
Subject: Re: REGRESS_OPTS versus MSVC build scripts
On Tue, Aug 18, 2009 at 02:15:48PM -0400, Andrew Dunstan wrote:
Andrew Dunstan
Are we going to publish an XML DTD for EXPLAIN, or have we already?
---
Andrew Dunstan wrote:
The attached tiny patch sets the explain root element for auto-explain
XML output, so it looks something like this:
Bruce Momjian wrote:
Are we going to publish an XML DTD for EXPLAIN, or have we already?
Not a DTD, but I am working on an XML Schema (DTDs are a bit yesterday).
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Andrew Dunstan wrote:
Bruce Momjian wrote:
Are we going to publish an XML DTD for EXPLAIN, or have we already?
Not a DTD, but I am working on an XML Schema (DTDs are a bit yesterday).
OK, either one would be good.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
On Tue, Aug 18, 2009 at 6:49 AM, Heikki
Linnakangasheikki.linnakan...@enterprisedb.com wrote:
Hmm, are you sure you the right version of libpq is being loaded at
runtime? What does ldd ./test-libpq say?
i have to rebuild with the patch on linux and windows and i'm not sure
i will have time
Andrew Dunstan and...@dunslane.net writes:
Bruce Momjian wrote:
Are we going to publish an XML DTD for EXPLAIN, or have we already?
Not a DTD, but I am working on an XML Schema (DTDs are a bit yesterday).
+1 ... I asked for a spec for the output format before, and this would
do fine.
Peter Eisentraut pete...@gmx.net wrote:
Alpha1 has been bundled and is available at
http://developer.postgresql.org/~petere/alpha/
Please check that it is sane.
I downloaded it and did a make and make check on a machine without all
the packages to build from a source checkout. All 121
In XLogInsert (src/backend/access/transam/xlog.c), the part that adds back-up
blocks into the rdata chain is described:
/*
* Make additional rdata chain entries for the backup blocks, so that we
* don't need to special-case them in the write loop. Note that we have
Kevin Grittner wrote:
Peter Eisentraut pete...@gmx.net wrote:
Alpha1 has been bundled and is available at
http://developer.postgresql.org/~petere/alpha/
Please check that it is sane.
I downloaded it and did a make and make check on a machine without all
the packages to build
Jeff Janes jeff.ja...@gmail.com writes:
If I read the code correctly, the only thing that is irrevocable is
that it writes into
rdt-next, and if it saved an old copy of rdt first, then it could
revoke the changes just
by doing rdt_old-next=NULL. If that were done, then I think this
code
Peter Eisentraut pete...@gmx.net writes:
Alpha1 has been bundled and is available at
http://developer.postgresql.org/~petere/alpha/
Please check that it is sane.
It looks like all the derived grammar files have been built with bison
2.4.1, which is not what's on svr1 (unless that's been
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Alpha1 has been bundled and is available at
http://developer.postgresql.org/~petere/alpha/
Please check that it is sane.
It looks like all the derived grammar files have been built with bison
2.4.1, which is not what's on svr1 (unless
... for the simple reason that nobody is maintaining it. Wheeler just
pointed out to me today that the OSX startup script hasn't been updated
since 7.4 and contains misinformation and dangerous scripting.
Other startup scripts there are equally dilapidated, and aren't used by
the linux distros
Greg Stark gsst...@mit.edu writes:
Another thought. In the above case it would actually be fine to catch
the error with PG_TRY() without a subtransaction. As long as no shared
database state has been modified when the error is thrown then the
subtransaction isn't needed to roll them back.
I
KaiGai Kohei kai...@ak.jp.nec.com writes:
When FindConversion() is called, it also checks current user's ACL_EXECUTE
privilege on the conproc of the fetched conversion.
Why this check is applied on FindConversion(), instead of
FindDefaultConversion()?
Does seem pretty inconsistent, doesn't
Josh Berkus wrote:
... for the simple reason that nobody is maintaining it. Wheeler just
pointed out to me today that the OSX startup script hasn't been updated
since 7.4 and contains misinformation and dangerous scripting.
Other startup scripts there are equally dilapidated, and aren't used
Chander Ganesan chan...@otg-nc.com writes:
Josh Berkus wrote:
... for the simple reason that nobody is maintaining it. Wheeler just
pointed out to me today that the OSX startup script hasn't been updated
since 7.4 and contains misinformation and dangerous scripting.
Other startup scripts
On Wed, Aug 19, 2009 at 7:22 PM, Tom Lanet...@sss.pgh.pa.us wrote:
It may be that a subtransaction will actually be acceptable overhead,
as long as we don't go overboard and invoke this mechanism for simple
WHERE clauses. Hard to tell without coding it up and testing it though.
Are you
Greg Stark gsst...@mit.edu writes:
On Wed, Aug 19, 2009 at 7:22 PM, Tom Lanet...@sss.pgh.pa.us wrote:
It may be that a subtransaction will actually be acceptable overhead,
as long as we don't go overboard and invoke this mechanism for simple
WHERE clauses. Hard to tell without coding it up
Josh Berkus wrote:
... for the simple reason that nobody is maintaining it. Wheeler just
pointed out to me today that the OSX startup script hasn't been updated
since 7.4 and contains misinformation and dangerous scripting.
Other startup scripts there are equally dilapidated, and aren't
Tom, Greg, Robert,
Here's my suggestion:
1. First, estimate the cost of the node with a very pessimistic (50%?)
selectivity for the calculation.
2. If the cost hits a certain threshold, then run the calculation
estimation on the histogram.
That way, we avoid the subtransaction and other
Tom Lane wrote:
(Personally, I use scripts based on start-scripts/osx/ for a number of
services on my own machines, so if there's something wrong with them
I'd definitely like to know what it is.)
What kind of based on? I mean, are there some changes of yours that
could be applied to the
Josh Berkus j...@agliodbs.com writes:
Tom,
(Personally, I use scripts based on start-scripts/osx/ for a number of
services on my own machines, so if there's something wrong with them
I'd definitely like to know what it is.)
I quote:
# What to use to start up the postmaster (we do NOT use
On Wed, Aug 19, 2009 at 3:00 PM, Josh Berkusj...@agliodbs.com wrote:
Tom, Greg, Robert,
Here's my suggestion:
1. First, estimate the cost of the node with a very pessimistic (50%?)
selectivity for the calculation.
There is no such thing as a pessimistic selectivity estimation. Right
now a
On Aug 19, 2009, at 11:48 AM, Tom Lane wrote:
(Personally, I use scripts based on start-scripts/osx/ for a number of
services on my own machines, so if there's something wrong with them
I'd definitely like to know what it is.)
+1. Please don't remove the start scripts. I use them on every
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
(Personally, I use scripts based on start-scripts/osx/ for a number of
services on my own machines, so if there's something wrong with them
I'd definitely like to know what it is.)
What kind of based on? I mean, are there
On Wed, Aug 19, 2009 at 11:45, Heikki
Linnakangasheikki.linnakan...@enterprisedb.com wrote:
Magnus Hagander wrote:
This would amount to fairly major surgery for pg_standby on Win32. Is
that something we'd want to backpatch, or do we want to backpatch just
the removal of the signal() calls
Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com writes:
we do NOT use pg_ctl for [postmaster start], as it adds no value
and can cause the postmaster to misrecognize a stale lock file
And? That statement was and remains perfectly correct.
Is this mentioned in the
Tom,
# What to use to start up the postmaster (we do NOT use pg_ctl for this,
# as it adds no value and can cause the postmaster to misrecognize a stale
# lock file)
DAEMON=$prefix/bin/postmaster
And? That statement was and remains perfectly correct. We don't use
pg_ctl to start the
Josh Berkus wrote:
Tom,
# What to use to start up the postmaster (we do NOT use pg_ctl for this,
# as it adds no value and can cause the postmaster to misrecognize a stale
# lock file)
DAEMON=$prefix/bin/postmaster
And? That statement was and remains perfectly correct. We don't
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
we do NOT use pg_ctl for [postmaster start], as it adds no value
and can cause the postmaster to misrecognize a stale lock file
And? That statement was and remains perfectly correct.
Is this mentioned
On Aug 19, 2009, at 2:03 PM, Tom Lane wrote:
These considerations don't apply to ordinary hand launching of the
postmaster, for the primary reason that the chance of a false PID
match
is several orders of magnitude smaller when you're talking about a
manual restart --- the likely postmaster
Should we add a comment to the startup scripts linking this email?
http://archives.postgresql.org/message-id/28922.1250715...@sss.pgh.pa.us
---
Tom Lane wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
David E. Wheeler da...@kineticode.com writes:
Nice summary, Tom. Do the distro packagers know this, though?
All the active ones I know of learned it the hard way, or were paying
attention when someone else did. Still, it wouldn't be a bad thing
for us to document it somewhere.
On Wed, Aug 19, 2009 at 07:29:43PM +1000, Paul Matthews wrote:
Suspect that attaching large amounts of code is a breach of
etiquette.
Code attachments aren't, but HTML messages are, so in future, please
send only text :)
Cheers,
David.
--
David Fetter da...@fetter.org http://fetter.org/
On Wed, Aug 19, 2009 at 10:03 PM, Tom Lanet...@sss.pgh.pa.us wrote:
What this all leads to is that it's safe to launch a postmaster from
an init script via something like
su - postgres sh -c postmaster ...
Surely you don't want -? If you run postgres's .profile etc. then
random user
Tom,
(Personally, I use scripts based on start-scripts/osx/ for a number of
services on my own machines, so if there's something wrong with them
I'd definitely like to know what it is.)
I quote:
# What to use to start up the postmaster (we do NOT use pg_ctl for this,
# as it adds no value
Tom Lane t...@sss.pgh.pa.us wrote:
The problem is that after a system crash and reboot, an old
postmaster.pid file might be left behind. The postmaster can only
safely remove this lock file if it is *certain* that it doesn't
represent another live postmaster process. Otherwise it is
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Right -- we did run into this in spades when our backup server,
running dozens of instances of PostgreSQL in warm standby to confirm
the integrity of the files received, crashed hard. I wasn't sure if
this was the problem being addressed.
Greg Stark gsst...@mit.edu writes:
On Wed, Aug 19, 2009 at 10:03 PM, Tom Lanet...@sss.pgh.pa.us wrote:
What this all leads to is that it's safe to launch a postmaster from
an init script via something like
su - postgres sh -c postmaster ...
Surely you don't want -? If you run
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Well, using a different user per instance is a good idea because
then the safety analysis I gave holds rigorously for each instance.
It doesn't get you out of the problem by itself, because the problem
I wrote:
Oh, right -- it does let PostgreSQL automatically deal with the file
left by a different instance, but could still fail on it's own file.
Er, it does let PostgreSQL automatically deal with a different
instance using the PID matching what this instance left in its file,
but could be
Tom Lane wrote:
KaiGai Kohei kai...@ak.jp.nec.com writes:
When FindConversion() is called, it also checks current user's ACL_EXECUTE
privilege on the conproc of the fetched conversion.
Why this check is applied on FindConversion(), instead of
FindDefaultConversion()?
Does seem pretty
I am getting a repeatable failure on the HEAD regression tests when
auto_explain's log_verbose is set. If auto_explain.log_verbose is turned
off the failure disappears. Data below.
cheers
andrew
config settings:
custom_variable_classes = 'auto_explain'
auto_explain.log_min_duration = 0
Here is a patch to fix a bug in handling default values in reloptions.
This fix should be applied to HEAD and 8.4.0.
I used 'magic number -1' to propagate not-specified information to
autovacuum process. It might look strange because the default value is
out of range of the reloption, but I
On Wed, Aug 19, 2009 at 7:57 PM, Andrew
Dunstanandrew.duns...@pgexperts.com wrot
I am getting a repeatable failure on the HEAD regression tests when
auto_explain's log_verbose is set. If auto_explain.log_verbose is turned off
the failure disappears. Data below.
cheers
andrew
config
Robert Haas wrote:
On Wed, Aug 19, 2009 at 7:57 PM, Andrew
Dunstanandrew.duns...@pgexperts.com wrot
I am getting a repeatable failure on the HEAD regression tests when
auto_explain's log_verbose is set. If auto_explain.log_verbose is turned off
the failure disappears. Data below.
cheers
On Wed, Aug 19, 2009 at 9:39 PM, Andrew Dunstanand...@dunslane.net wrote:
Robert Haas wrote:
On Wed, Aug 19, 2009 at 7:57 PM, Andrew
Dunstanandrew.duns...@pgexperts.com wrot
I am getting a repeatable failure on the HEAD regression tests when
auto_explain's log_verbose is set. If
On Wed, Aug 19, 2009 at 10:07 PM, Robert Haasrobertmh...@gmail.com wrote:
On Wed, Aug 19, 2009 at 9:39 PM, Andrew Dunstanand...@dunslane.net wrote:
Robert Haas wrote:
On Wed, Aug 19, 2009 at 7:57 PM, Andrew
Dunstanandrew.duns...@pgexperts.com wrot
I am getting a repeatable failure on the
Tom Lane t...@sss.pgh.pa.us wrote:
I don't believe there is any consensus for integrating dblink into core,
and I for one will resist that strongly. Keep it in contrib.
OK, our consensus is that dblink should be replaced with SQL/MED interface
and then we'll start to consider integrating
Robert Haas robertmh...@gmail.com wrote:
It looks like this is enough to reproduce the cache lookup failure:
The cache loopup failure part could be fixed by the attached patch.
It forbids explaining if the transaction is in error state.
I cannot reproduce unexpected refassgnexpr and
Robert Haas wrote:
On Mon, Aug 17, 2009 at 6:50 AM, Robert Haasrobertmh...@gmail.com wrote:
I think there's a race condition in the way LogCurrentRunningXacts() is
called at the end of checkpoint. This can happen in the master:
1. Checkpoint starts
2. Transaction 123 begins, and does some
70 matches
Mail list logo
