On Fri, Jun 4, 2010 at 9:55 PM, Joseph Adams wrote:
> If I had to choose between => and := for parameter naming, I'd go with
> := because it seems more SQLish to me.
On second thought, => might actually be a very intuitive syntax for
defining dictionary types like hstore and json, since it matche
On Sat, Jun 5, 2010 at 2:20 AM, Robert Haas wrote:
>> I've tried to keep this as similar as possible to the existing message while
>> making it less ambiguous about cause and effect.
>>
>> "If this has occurred more than once corrupt data might be the cause and you
>> might need to choose an ear
On Wed, May 26, 2010 at 9:28 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, May 26, 2010 at 8:21 PM, Tom Lane wrote:
>>> If we go with the spec's syntax I think we'd have no realistic choice
>>> except to forbid => altogether as an operator name. (And no, I'm not
>>> for that.)
>
>> I sup
On Fri, Jun 4, 2010 at 8:21 PM, Florian Pflug wrote:
> On Jun 3, 2010, at 5:25 , Robert Haas wrote:
>> On Wed, Jun 2, 2010 at 10:34 PM, Florian Pflug wrote:
Oh. Well, if that's the case, then I guess I lean toward applying the
patch as-is. Then there's no need for the caveat "and with
On Jun 3, 2010, at 5:25 , Robert Haas wrote:
> On Wed, Jun 2, 2010 at 10:34 PM, Florian Pflug wrote:
>>> Oh. Well, if that's the case, then I guess I lean toward applying the
>>> patch as-is. Then there's no need for the caveat "and without manual
>>> intervention".
>>
>> That still leaves the
On Mon, May 17, 2010 at 2:10 PM, Jim Nasby wrote:
> Any particular reason not to use directories to help organize things? IE:
>
> base/database_oid/pg_temp_rels/backend_pid/relfilenode
>
> Perhaps relfilenode should be something else.
>
> This seems to have several advantages:
>
> 1: It's more org
This is really a postgreSQL developers list; I suggest you post user
level questions to the -general list
--
Regards,
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi all
i wish know when will be possible to create databases and tables on my local
sql server but only like symlink to remote data specifying existing username
and password, fully transparent for app, explain: no external libraries needed,
no code adaptation for existing singledb apps, just
Alvaro Herrera wrote:
> Excerpts from Bruce Momjian's message of vie jun 04 15:39:07 -0400 2010:
> > Tom Lane wrote:
> > > Bruce Momjian writes:
> > > > With in-place VACUUM FULL gone in 9.0, will there be as much need for
> > > > xmin/xmax forensics?
> > >
> > > You know perfectly well that no o
On 6/4/2010 4:22 PM, Robert Haas wrote:
On Fri, Jun 4, 2010 at 3:35 PM, Jan Wieck wrote:
So that justifies adding code, that the community needs to maintain and
document, to the core system. If only I could find some monitoring case for
transaction commit orders ... sigh!
Dude, I'm not the on
On 6/4/2010 12:52 PM, Alvaro Herrera wrote:
Excerpts from Jan Wieck's message of jue jun 03 19:52:19 -0400 2010:
On 6/3/2010 7:11 PM, Alvaro Herrera wrote:
> Why not send separate numbers of tuple inserts/updates/deletes, which we
> already have from pgstats?
We only have them for the entire
Excerpts from Bruce Momjian's message of vie jun 04 15:39:07 -0400 2010:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > With in-place VACUUM FULL gone in 9.0, will there be as much need for
> > > xmin/xmax forensics?
> >
> > You know perfectly well that no one could answer that question.
> > (
On Fri, Jun 4, 2010 at 3:35 PM, Jan Wieck wrote:
> On 6/3/2010 10:57 PM, Robert Haas wrote:
>>
>> On Thu, Jun 3, 2010 at 8:47 PM, Jan Wieck wrote:
>>>
>>> On 5/27/2010 4:31 PM, Bruce Momjian wrote:
Also, what would be cool would be if you could run a query on the master
to view the
Bruce Momjian writes:
> Tom Lane wrote:
>> Bruce Momjian writes:
>>> With in-place VACUUM FULL gone in 9.0, will there be as much need for
>>> xmin/xmax forensics?
>>
>> You know perfectly well that no one could answer that question.
>> (Or at least not answer it on the basis of facts available
Heikki Linnakangas writes:
> On 04/06/10 22:33, Tom Lane wrote:
>> A counterexample: suppose we had a form of type "text" that carried a
>> collation specifier internally, and the comparison routine threw an
>> error if asked to compare values with incompatible specifiers. An index
>> built on a
On 6/4/2010 10:44 AM, Greg Stark wrote:
On Fri, Jun 4, 2010 at 2:32 AM, Robert Haas wrote:
I find the skeptical attitude on this thread altogether unwarranted.
Jan made his case and, at least IMHO, presented it pretty clearly.
Just to be clear I think the idea of exposing commit order is a
no
On 04/06/10 22:33, Tom Lane wrote:
Heikki Linnakangas writes:
On 04/06/10 17:33, Tom Lane wrote:
Maybe the entire idea is unworkable. I certainly don't find any comfort
in your proposal in the above-referenced message to trust index
operators; where is it written that those don't throw errors
On 6/3/2010 10:57 PM, Robert Haas wrote:
On Thu, Jun 3, 2010 at 8:47 PM, Jan Wieck wrote:
On 5/27/2010 4:31 PM, Bruce Momjian wrote:
Also, what would be cool would be if you could run a query on the master
to view the SR commit mode of each slave.
What would be the use case for such a query?
Tom Lane wrote:
> Bruce Momjian writes:
> > With in-place VACUUM FULL gone in 9.0, will there be as much need for
> > xmin/xmax forensics?
>
> You know perfectly well that no one could answer that question.
> (Or at least not answer it on the basis of facts available today.)
Well, guess then. I
Bruce Momjian writes:
> With in-place VACUUM FULL gone in 9.0, will there be as much need for
> xmin/xmax forensics?
You know perfectly well that no one could answer that question.
(Or at least not answer it on the basis of facts available today.)
regards, tom lane
--
S
Heikki Linnakangas writes:
> On 04/06/10 17:33, Tom Lane wrote:
>> Maybe the entire idea is unworkable. I certainly don't find any comfort
>> in your proposal in the above-referenced message to trust index
>> operators; where is it written that those don't throw errors?
> Let's consider b-tree o
On Fri, Jun 4, 2010 at 7:30 PM, Tom Lane wrote:
> Dave Page writes:
>> On Fri, Jun 4, 2010 at 4:30 PM, Tom Lane wrote:
>>> XLOG_PAGE_MAGIC --- bump on incompatible change in WAL contents
>
>> How can I get that from an existing data directory? I don't see it in
>> pg_controldata output (unless i
Dave Page writes:
> On Fri, Jun 4, 2010 at 4:30 PM, Tom Lane wrote:
>> XLOG_PAGE_MAGIC --- bump on incompatible change in WAL contents
> How can I get that from an existing data directory? I don't see it in
> pg_controldata output (unless it has a non-obvious alias).
You'd need to pull it out o
On Fri, Jun 4, 2010 at 4:30 PM, Tom Lane wrote:
> Dave Page writes:
>> On Fri, Jun 4, 2010 at 2:49 PM, Tom Lane wrote:
>>> Right, because the catalog contents didn't change. Seems to me you'd
>>> better teach the installers to look at PG_CONTROL_VERSION too.
>
>> Hmm, is there anything else tha
On Fri, Jun 4, 2010 at 1:46 PM, Heikki Linnakangas
wrote:
> On 04/06/10 17:33, Tom Lane wrote:
>>
>> Heikki Linnakangas writes:
>>>
>>> On 04/06/10 07:57, Tom Lane wrote:
The proposal some time back in this thread was to trust all built-in
functions and no others.
>>
>>> I thought
Tom Lane wrote:
> Bruce Momjian writes:
> > The idea that thousands of Postgres installations are slower just so we
> > can occasionally debug xmin/xmax issues seems way off balance to me.
>
> There's no evidence whatsoever that the scope of the problem is that large.
>
> > If people want debugg
Tom Lane wrote:
> Bruce Momjian writes:
>> The idea that thousands of Postgres installations are slower just
>> so we can occasionally debug xmin/xmax issues seems way off
>> balance to me.
>
> There's no evidence whatsoever that the scope of the problem is
> that large.
Well, are we agreed th
On 04/06/10 17:33, Tom Lane wrote:
Heikki Linnakangas writes:
On 04/06/10 07:57, Tom Lane wrote:
The proposal some time back in this thread was to trust all built-in
functions and no others.
I thought I debunked that idea already
(http://archives.postgresql.org/pgsql-hackers/2009-10/msg0142
Bruce Momjian writes:
> The idea that thousands of Postgres installations are slower just so we
> can occasionally debug xmin/xmax issues seems way off balance to me.
There's no evidence whatsoever that the scope of the problem is that large.
> If people want debugging, let them modify the freez
Excerpts from Jan Wieck's message of jue jun 03 19:52:19 -0400 2010:
> On 6/3/2010 7:11 PM, Alvaro Herrera wrote:
> > Why not send separate numbers of tuple inserts/updates/deletes, which we
> > already have from pgstats?
>
> We only have them for the entire database. The purpose of this is just
On Fri, 2010-06-04 at 10:33 -0400, Tom Lane wrote:
> Hmm ... that's a mighty interesting example, because it shows that any
> well-meaning change in error handling might render seemingly-unrelated
> functions "unsafe". And we're certainly not going to make error
> messages stop showing relevant in
Kevin Grittner wrote:
> Fair enough. I was thinking of them both as debugging features,
> which had various ideas roiling around in my head. Having run
> hundreds of databases 24/7 for years without ever needing this
> information, but paying the cost for it one way or another every
> day, my per
Tom Lane wrote:
> But Kevin's question seemed to be based on the assumption that
> runtime cost was the only negative. It wouldn't be terribly hard
> to make a variant of cassert that skips two or three of the most
> expensive things (particularly memory context checking and
> CLOBBER_FREED_MEM
Robert Haas writes:
> On Fri, Jun 4, 2010 at 11:45 AM, Tom Lane wrote:
>> The reason for not recommending cassert in production builds is not
>> cost but stability.
> We routinely castigate people for benchmarking done with cassert
> turned on, and tell them their numbers are meaningless.
I did
On Fri, Jun 4, 2010 at 11:45 AM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> In my experience with my own environment, I can honestly say that
>> it's clear that not freezing tuples quickly adds more cost than
>> running with cassert on. If we had to run in production with one or
>> the other,
Robert Haas writes:
> It would be nice to have all of these documented somewhere along with
> the criteria for bumping each one.
Go for it. I think you have all the raw data in this thread.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
"Kevin Grittner" writes:
> In my experience with my own environment, I can honestly say that
> it's clear that not freezing tuples quickly adds more cost than
> running with cassert on. If we had to run in production with one or
> the other, I would definitely choose cassert from a performance
>
Tom Lane wrote:
> Dave Page writes:
> > On Fri, Jun 4, 2010 at 2:49 PM, Tom Lane wrote:
> >> Right, because the catalog contents didn't change. ?Seems to me you'd
> >> better teach the installers to look at PG_CONTROL_VERSION too.
>
> > Hmm, is there anything else that might need to be checked?
Dave Page writes:
> On Fri, Jun 4, 2010 at 2:49 PM, Tom Lane wrote:
>> Right, because the catalog contents didn't change. Seems to me you'd
>> better teach the installers to look at PG_CONTROL_VERSION too.
> Hmm, is there anything else that might need to be checked?
Offhand I can think of thre
On Fri, Jun 4, 2010 at 11:06 AM, Dave Page wrote:
> On Fri, Jun 4, 2010 at 2:49 PM, Tom Lane wrote:
>> Bruce Momjian writes:
>>> Dave Page wrote:
Shouldn't we have bumped the catversion? The installers can't tell
that beta1 clusters won't work with beta2 :-(
>>
>>> That is an interesti
On Fri, Jun 4, 2010 at 10:44 AM, Greg Stark wrote:
> On Fri, Jun 4, 2010 at 2:32 AM, Robert Haas wrote:
>> I find the skeptical attitude on this thread altogether unwarranted.
>> Jan made his case and, at least IMHO, presented it pretty clearly.
>
> Just to be clear I think the idea of exposing c
Tom Lane wrote:
> Jan Wieck writes:
>> I just see a lot of cost caused by this "safety range". I yet
>> have to see its real value, other than "feel good".
>
> Jan, you don't know what you're talking about. I have repeatedly
> had cases where being able to look at xmin was critical to
> under
On Fri, Jun 4, 2010 at 2:49 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> Dave Page wrote:
>>> Shouldn't we have bumped the catversion? The installers can't tell
>>> that beta1 clusters won't work with beta2 :-(
>
>> That is an interesting point. Tom bumped the pg_control version, but
>> not th
On Fri, Jun 4, 2010 at 10:18 AM, Tom Lane wrote:
> Jan Wieck writes:
>> On 6/2/2010 3:10 PM, Alvaro Herrera wrote:
>>> I'd prefer a setting that would tell the system to freeze all tuples
>>> that fall within a safety range whenever any tuple in the page is frozen
>>> -- weren't you working on a
On Fri, Jun 4, 2010 at 2:32 AM, Robert Haas wrote:
> I find the skeptical attitude on this thread altogether unwarranted.
> Jan made his case and, at least IMHO, presented it pretty clearly.
Just to be clear I think the idea of exposing commit order is a
no-brainer. The specific interface is wha
Heikki Linnakangas writes:
> On 04/06/10 07:57, Tom Lane wrote:
>> The proposal some time back in this thread was to trust all built-in
>> functions and no others.
> I thought I debunked that idea already
> (http://archives.postgresql.org/pgsql-hackers/2009-10/msg01428.php). Not
> all built-in
Jan Wieck writes:
> On 6/2/2010 3:10 PM, Alvaro Herrera wrote:
>> I'd prefer a setting that would tell the system to freeze all tuples
>> that fall within a safety range whenever any tuple in the page is frozen
>> -- weren't you working on a patch to do this? (was it Jeff Davis?)
> I just see a
On Thu, Jun 03, 2010 at 10:57:05PM -0400, Robert Haas wrote:
> On Thu, Jun 3, 2010 at 8:47 PM, Jan Wieck wrote:
> > What would be the use case for such a query?
>
> Monitoring?
s/\?/!/;
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Bruce Momjian writes:
> Dave Page wrote:
>> Shouldn't we have bumped the catversion? The installers can't tell
>> that beta1 clusters won't work with beta2 :-(
> That is an interesting point. Tom bumped the pg_control version, but
> not the catalog version.
Right, because the catalog contents d
Dave Page wrote:
> On Thu, Jun 3, 2010 at 11:21 PM, Tom Lane wrote:
> > Florian Pflug writes:
> >> On Jun 3, 2010, at 19:00 , Tom Lane wrote:
> >>> Maybe we should just get rid of the hint.
> >
> >> FYI, Robert Haas suggested the same in the thread that lead to this patch
> >> being applied. The
On 04/06/10 07:57, Tom Lane wrote:
KaiGai Kohei writes:
(2010/06/04 11:55), Robert Haas wrote:
A (very) important part of this problem is determining which quals are
safe to push down.
At least, I don't have an idea to distinguish trusted functions from
others without any additional hints, b
On 6/2/2010 3:10 PM, Alvaro Herrera wrote:
Excerpts from Robert Haas's message of mié jun 02 14:16:33 -0400 2010:
We could, but I think we'd be better off just freezing at the time we
mark the page PD_ALL_VISIBLE and then using the visibility map for
both purposes. Keeping around the old xmin
On 6/2/2010 2:16 PM, Robert Haas wrote:
On Wed, Jun 2, 2010 at 2:05 PM, Tom Lane wrote:
Alvaro Herrera writes:
The problem is that vacuum doesn't know that a certain part of the table
is already frozen. It needs to scan it completely anyways. If we had a
"frozen" map, we could mark pages th
On Thu, Jun 3, 2010 at 11:21 PM, Tom Lane wrote:
> Florian Pflug writes:
>> On Jun 3, 2010, at 19:00 , Tom Lane wrote:
>>> Maybe we should just get rid of the hint.
>
>> FYI, Robert Haas suggested the same in the thread that lead to this patch
>> being applied. The arguments against doing that i
On Jun 4, 2010, at 7:05 , Gnanakumar wrote:
>> If some of those WAL segments still reside in pg_xlog, you'll either need
> to teach your restore_command to fetch them from there. Note that you cannot
> recover "in reverse".
>
> My pg_xlog/ and walarchive/ directory locations are
> "/usr/local/pgsq
(2010/06/04 18:26), Dimitri Fontaine wrote:
Tom Lane writes:
The proposal some time back in this thread was to trust all built-in
functions and no others. That's a bit simplistic, no doubt, but it
seems to me to largely solve the performance problem and to do so with
minimal effort. When and
On Thu, Jun 3, 2010 at 16:02, Andrew Dunstan wrote:
>
>
> Denis I. Polukarov wrote:
>
>> Hi!
>>
>> I'm to face a problem, and not at once resolve it.
>>
>>
> [default namespace mapped in xml "xmlns=" attribute requires corresponding
> mapping in third param of xpath()]
>
> It's a tolerably subtle
Tom Lane writes:
> The proposal some time back in this thread was to trust all built-in
> functions and no others. That's a bit simplistic, no doubt, but it
> seems to me to largely solve the performance problem and to do so with
> minimal effort. When and if you get to a solution that's committ
58 matches
Mail list logo
