Itagaki Takahiro wrote:
> However, automatic transaction management needs help by core. Is it
> acceptable to have two-phase callbacks?
Probably, but it's far too early to decide what the interface should
look like.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent v
Robert Haas wrote:
> On Mon, Aug 17, 2009 at 6:50 AM, Robert Haas 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 updates
Robert Haas 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 "unexpected FieldStore"
er
Tom Lane 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 into core.
However,
On Wed, Aug 19, 2009 at 10:07 PM, Robert Haas wrote:
> On Wed, Aug 19, 2009 at 9:39 PM, Andrew Dunstan wrote:
>> Robert Haas wrote:
>>>
>>> On Wed, Aug 19, 2009 at 7:57 PM, Andrew
>>> Dunstan wrot>
>>>
I am getting a repeatable failure on the HEAD regression tests when
auto_explain'
On Wed, Aug 19, 2009 at 9:39 PM, Andrew Dunstan wrote:
> Robert Haas wrote:
>>
>> On Wed, Aug 19, 2009 at 7:57 PM, Andrew
>> Dunstan 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
>>>
Robert Haas wrote:
On Wed, Aug 19, 2009 at 7:57 PM, Andrew
Dunstan 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 settings:
cus
On Wed, Aug 19, 2009 at 7:57 PM, Andrew
Dunstan 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 settings:
>
> custom_var
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 thi
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
au
Tom Lane wrote:
> KaiGai Kohei 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 inconsisten
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 b
Tom Lane wrote:
> "Kevin Grittner" 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
> as described can happen with just one in
Greg Stark writes:
> On Wed, Aug 19, 2009 at 10:03 PM, Tom Lane 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
"Kevin Grittner" 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. One obvious solution,
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
On Wed, Aug 19, 2009 at 10:03 PM, Tom Lane 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 customization f
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 http://fetter.org/
Phone: +1 415 235 37
Tom Lane 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 honor-
> bound to co
"David E. Wheeler" 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.
regards, t
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" writes:
> > Tom Lane wrote:
> >>>
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 P
"Kevin Grittner" writes:
> Tom Lane 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 in the documentation somewhere tha
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
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
Tom Lane wrote:
> Josh Berkus 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 documentation somewhere that I've m
On Wed, Aug 19, 2009 at 11:45, Heikki
Linnakangas 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 which would amount to not support
Alvaro Herrera 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 some changes of your
On Wed, Aug 19, 2009 at 3:00 PM, Josh Berkus 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 lot of thing
Josh Berkus 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 pg_ctl fo
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
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 overhea
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 are
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 syst
Greg Stark writes:
> On Wed, Aug 19, 2009 at 7:22 PM, Tom Lane 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.
> A
On Wed, Aug 19, 2009 at 7:22 PM, Tom Lane 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 looking for volunt
Chander Ganesan 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 there are
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 by
KaiGai Kohei 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 it?
The original
Greg Stark 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 think catchin
... 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 r
Tom Lane wrote:
Peter Eisentraut 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 updat
Peter Eisentraut 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 updated
recently).
Jeff Janes 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 could be
> moved
Kevin Grittner wrote:
> Peter Eisentraut 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 fr
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
Peter Eisentraut 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 tests passe
Andrew Dunstan 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.
On Tue, Aug 18, 2009 at 6:49 AM, Heikki
Linnakangas 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 until friday...
once said that,
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 http://momjian.us
EnterpriseDB
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:
http://
Are we going to publish an XML DTD for EXPLAIN, or have we already?
---
Andrew Dunstan wrote:
>
> The attached tiny patch sets the root element for auto-explain
> XML output, so it looks something like this:
>
> http
> -- Forwarded message --
> From: David Fetter
> To: Andrew Dunstan
> 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 wrote:
>>>
>>
>> Here's an un
Tom Lane wrote:
> Pavel Stehule writes:
>> 2009/8/19 Tom Lane :
>>> 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 otherdatabase.
2009/8/19 Tom Lane :
> Pavel Stehule writes:
>> 2009/8/19 Tom Lane :
>>> 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 otherdataba
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. I
Pavel Stehule writes:
> 2009/8/19 Tom Lane :
>> 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 otherdatabase.schema.table
> UPDAT
2009/8/19 Tom Lane :
> Itagaki Takahiro 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,
>
Itagaki Takahiro 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,
and I for one will resist that
Greg Stark 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 type would b
On Wed, Aug 19, 2009 at 3:16 PM, Greg Stark wrote:
> On Wed, Aug 19, 2009 at 3:53 AM, Tom Lane 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 su
On Wed, Aug 19, 2009 at 3:53 AM, Tom Lane 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 expensive.
> I though
Magnus Hagander wrote:
> On Wed, Aug 19, 2009 at 03:58, Stef Walter 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
index 505644a..bc37b1b
On Wed, Aug 19, 2009 at 03:58, Stef Walter 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: http://www.hagander.net/
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
detai
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
On Wed, Aug 19, 2009 at 08:38, Fujii Masao wrote:
> On Thu, Aug 13, 2009 at 2:24 AM, Magnus Hagander 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 some
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 n
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, o
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 tha
70 matches
Mail list logo
