[HACKERS] hot_standby = on

2010-06-04 Thread Andrew Dunstan
The docs don't seem to contain any discussion I could find on why one might not want hot_standby on. Maybe it's just too obvious to most people, but this seems to be a bit lacking in the docs. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] [PATCH] Fix leaky VIEWs for RLS

2010-06-04 Thread Dimitri Fontaine
Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] rfc: changing documentation about xpath

2010-06-04 Thread Nikolay Samokhvalov
On Thu, Jun 3, 2010 at 16:02, Andrew Dunstan and...@dunslane.net 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

Re: [HACKERS] [PATCH] Fix leaky VIEWs for RLS

2010-06-04 Thread KaiGai Kohei
(2010/06/04 18:26), Dimitri Fontaine wrote: Tom Lanet...@sss.pgh.pa.us 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

Re: [HACKERS] PITR Recovery Question

2010-06-04 Thread Florian Pflug
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

Re: [HACKERS] Did we really want to force an initdb in beta2?

2010-06-04 Thread Dave Page
On Thu, Jun 3, 2010 at 11:21 PM, Tom Lane t...@sss.pgh.pa.us wrote: Florian Pflug f...@phlo.org 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

Re: [HACKERS] Idea for getting rid of VACUUM FREEZE on cold pages

2010-06-04 Thread Jan Wieck
On 6/2/2010 2:16 PM, Robert Haas wrote: On Wed, Jun 2, 2010 at 2:05 PM, Tom Lane t...@sss.pgh.pa.us wrote: Alvaro Herrera alvhe...@commandprompt.com 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

Re: [HACKERS] Idea for getting rid of VACUUM FREEZE on cold pages

2010-06-04 Thread Jan Wieck
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

Re: [HACKERS] [PATCH] Fix leaky VIEWs for RLS

2010-06-04 Thread Heikki Linnakangas
On 04/06/10 07:57, Tom Lane wrote: KaiGai Koheikai...@ak.jp.nec.com 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

Re: [HACKERS] Did we really want to force an initdb in beta2?

2010-06-04 Thread Bruce Momjian
Dave Page wrote: On Thu, Jun 3, 2010 at 11:21 PM, Tom Lane t...@sss.pgh.pa.us wrote: Florian Pflug f...@phlo.org 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

Re: [HACKERS] Did we really want to force an initdb in beta2?

2010-06-04 Thread Tom Lane
Bruce Momjian br...@momjian.us 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

Re: [HACKERS] Synchronization levels in SR

2010-06-04 Thread David Fetter
On Thu, Jun 03, 2010 at 10:57:05PM -0400, Robert Haas wrote: On Thu, Jun 3, 2010 at 8:47 PM, Jan Wieck janwi...@yahoo.com wrote: What would be the use case for such a query? Monitoring? s/\?/!/; Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778

Re: [HACKERS] Idea for getting rid of VACUUM FREEZE on cold pages

2010-06-04 Thread Tom Lane
Jan Wieck janwi...@yahoo.com 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

Re: [HACKERS] [PATCH] Fix leaky VIEWs for RLS

2010-06-04 Thread Tom Lane
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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

Re: [HACKERS] Exposing the Xact commit order to the user

2010-06-04 Thread Greg Stark
On Fri, Jun 4, 2010 at 2:32 AM, Robert Haas robertmh...@gmail.com 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

Re: [HACKERS] Idea for getting rid of VACUUM FREEZE on cold pages

2010-06-04 Thread Robert Haas
On Fri, Jun 4, 2010 at 10:18 AM, Tom Lane t...@sss.pgh.pa.us wrote: Jan Wieck janwi...@yahoo.com 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 --

Re: [HACKERS] Did we really want to force an initdb in beta2?

2010-06-04 Thread Dave Page
On Fri, Jun 4, 2010 at 2:49 PM, Tom Lane t...@sss.pgh.pa.us wrote: Bruce Momjian br...@momjian.us 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

Re: [HACKERS] Idea for getting rid of VACUUM FREEZE on cold pages

2010-06-04 Thread Kevin Grittner
Tom Lane t...@sss.pgh.pa.us wrote: Jan Wieck janwi...@yahoo.com 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

Re: [HACKERS] Exposing the Xact commit order to the user

2010-06-04 Thread Robert Haas
On Fri, Jun 4, 2010 at 10:44 AM, Greg Stark gsst...@mit.edu wrote: On Fri, Jun 4, 2010 at 2:32 AM, Robert Haas robertmh...@gmail.com 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

Re: [HACKERS] Did we really want to force an initdb in beta2?

2010-06-04 Thread Robert Haas
On Fri, Jun 4, 2010 at 11:06 AM, Dave Page dp...@pgadmin.org wrote: On Fri, Jun 4, 2010 at 2:49 PM, Tom Lane t...@sss.pgh.pa.us wrote: Bruce Momjian br...@momjian.us writes: Dave Page wrote: Shouldn't we have bumped the catversion? The installers can't tell that beta1 clusters won't work with

Re: [HACKERS] Did we really want to force an initdb in beta2?

2010-06-04 Thread Tom Lane
Dave Page dp...@pgadmin.org writes: On Fri, Jun 4, 2010 at 2:49 PM, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] Did we really want to force an initdb in beta2?

2010-06-04 Thread Bruce Momjian
Tom Lane wrote: Dave Page dp...@pgadmin.org writes: On Fri, Jun 4, 2010 at 2:49 PM, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] Idea for getting rid of VACUUM FREEZE on cold pages

2010-06-04 Thread Tom Lane
Kevin Grittner kevin.gritt...@wicourts.gov 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

Re: [HACKERS] Did we really want to force an initdb in beta2?

2010-06-04 Thread Tom Lane
Robert Haas robertmh...@gmail.com 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

Re: [HACKERS] Idea for getting rid of VACUUM FREEZE on cold pages

2010-06-04 Thread Robert Haas
On Fri, Jun 4, 2010 at 11:45 AM, Tom Lane t...@sss.pgh.pa.us wrote: Kevin Grittner kevin.gritt...@wicourts.gov 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

Re: [HACKERS] Idea for getting rid of VACUUM FREEZE on cold pages

2010-06-04 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On Fri, Jun 4, 2010 at 11:45 AM, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] Idea for getting rid of VACUUM FREEZE on cold pages

2010-06-04 Thread Kevin Grittner
Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] Idea for getting rid of VACUUM FREEZE on cold pages

2010-06-04 Thread Bruce Momjian
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

Re: [HACKERS] [PATCH] Fix leaky VIEWs for RLS

2010-06-04 Thread Marc Munro
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

Re: [HACKERS] Exposing the Xact commit order to the user

2010-06-04 Thread Alvaro Herrera
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 a

Re: [HACKERS] Idea for getting rid of VACUUM FREEZE on cold pages

2010-06-04 Thread Tom Lane
Bruce Momjian br...@momjian.us 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

Re: [HACKERS] [PATCH] Fix leaky VIEWs for RLS

2010-06-04 Thread Heikki Linnakangas
On 04/06/10 17:33, Tom Lane wrote: Heikki Linnakangasheikki.linnakan...@enterprisedb.com 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

Re: [HACKERS] Idea for getting rid of VACUUM FREEZE on cold pages

2010-06-04 Thread Kevin Grittner
Tom Lane t...@sss.pgh.pa.us wrote: Bruce Momjian br...@momjian.us 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.

Re: [HACKERS] Idea for getting rid of VACUUM FREEZE on cold pages

2010-06-04 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian br...@momjian.us 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

Re: [HACKERS] [PATCH] Fix leaky VIEWs for RLS

2010-06-04 Thread Robert Haas
On Fri, Jun 4, 2010 at 1:46 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: On 04/06/10 17:33, Tom Lane wrote: Heikki Linnakangasheikki.linnakan...@enterprisedb.com  writes: On 04/06/10 07:57, Tom Lane wrote: The proposal some time back in this thread was to trust all

Re: [HACKERS] Did we really want to force an initdb in beta2?

2010-06-04 Thread Dave Page
On Fri, Jun 4, 2010 at 4:30 PM, Tom Lane t...@sss.pgh.pa.us wrote: Dave Page dp...@pgadmin.org writes: On Fri, Jun 4, 2010 at 2:49 PM, Tom Lane t...@sss.pgh.pa.us wrote: Right, because the catalog contents didn't change.  Seems to me you'd better teach the installers to look at

Re: [HACKERS] Did we really want to force an initdb in beta2?

2010-06-04 Thread Tom Lane
Dave Page dp...@pgadmin.org writes: On Fri, Jun 4, 2010 at 4:30 PM, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] Did we really want to force an initdb in beta2?

2010-06-04 Thread Dave Page
On Fri, Jun 4, 2010 at 7:30 PM, Tom Lane t...@sss.pgh.pa.us wrote: Dave Page dp...@pgadmin.org writes: On Fri, Jun 4, 2010 at 4:30 PM, Tom Lane t...@sss.pgh.pa.us wrote: XLOG_PAGE_MAGIC --- bump on incompatible change in WAL contents How can I get that from an existing data directory? I don't

Re: [HACKERS] [PATCH] Fix leaky VIEWs for RLS

2010-06-04 Thread Tom Lane
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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

Re: [HACKERS] Idea for getting rid of VACUUM FREEZE on cold pages

2010-06-04 Thread Tom Lane
Bruce Momjian br...@momjian.us 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,

Re: [HACKERS] Idea for getting rid of VACUUM FREEZE on cold pages

2010-06-04 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian br...@momjian.us 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

Re: [HACKERS] Synchronization levels in SR

2010-06-04 Thread Jan Wieck
On 6/3/2010 10:57 PM, Robert Haas wrote: On Thu, Jun 3, 2010 at 8:47 PM, Jan Wieck janwi...@yahoo.com 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

Re: [HACKERS] [PATCH] Fix leaky VIEWs for RLS

2010-06-04 Thread Heikki Linnakangas
On 04/06/10 22:33, Tom Lane wrote: Heikki Linnakangasheikki.linnakan...@enterprisedb.com 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

Re: [HACKERS] Exposing the Xact commit order to the user

2010-06-04 Thread Jan Wieck
On 6/4/2010 10:44 AM, Greg Stark wrote: On Fri, Jun 4, 2010 at 2:32 AM, Robert Haas robertmh...@gmail.com 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

Re: [HACKERS] [PATCH] Fix leaky VIEWs for RLS

2010-06-04 Thread Tom Lane
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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

Re: [HACKERS] Idea for getting rid of VACUUM FREEZE on cold pages

2010-06-04 Thread Tom Lane
Bruce Momjian br...@momjian.us writes: Tom Lane wrote: Bruce Momjian br...@momjian.us 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

Re: [HACKERS] Synchronization levels in SR

2010-06-04 Thread Robert Haas
On Fri, Jun 4, 2010 at 3:35 PM, Jan Wieck janwi...@yahoo.com wrote: On 6/3/2010 10:57 PM, Robert Haas wrote: On Thu, Jun 3, 2010 at 8:47 PM, Jan Wieck janwi...@yahoo.com 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

Re: [HACKERS] Idea for getting rid of VACUUM FREEZE on cold pages

2010-06-04 Thread Alvaro Herrera
Excerpts from Bruce Momjian's message of vie jun 04 15:39:07 -0400 2010: Tom Lane wrote: Bruce Momjian br...@momjian.us 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.

Re: [HACKERS] Exposing the Xact commit order to the user

2010-06-04 Thread Jan Wieck
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

Re: [HACKERS] Synchronization levels in SR

2010-06-04 Thread Jan Wieck
On 6/4/2010 4:22 PM, Robert Haas wrote: On Fri, Jun 4, 2010 at 3:35 PM, Jan Wieck janwi...@yahoo.com 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!

Re: [HACKERS] Idea for getting rid of VACUUM FREEZE on cold pages

2010-06-04 Thread Bruce Momjian
Alvaro Herrera wrote: Excerpts from Bruce Momjian's message of vie jun 04 15:39:07 -0400 2010: Tom Lane wrote: Bruce Momjian br...@momjian.us 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

[HACKERS]

2010-06-04 Thread daniel cordero
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

Re: [HACKERS]

2010-06-04 Thread Peter Geoghegan
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

Re: [HACKERS] including PID or backend ID in relpath of temp rels

2010-06-04 Thread Robert Haas
On Mon, May 17, 2010 at 2:10 PM, Jim Nasby deci...@decibel.org 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:

Re: [HACKERS] recovery getting interrupted is not so unusual as it used to be

2010-06-04 Thread Florian Pflug
On Jun 3, 2010, at 5:25 , Robert Haas wrote: On Wed, Jun 2, 2010 at 10:34 PM, Florian Pflug f...@phlo.org 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

Re: [HACKERS] recovery getting interrupted is not so unusual as it used to be

2010-06-04 Thread Robert Haas
On Fri, Jun 4, 2010 at 8:21 PM, Florian Pflug f...@phlo.org wrote: On Jun 3, 2010, at 5:25 , Robert Haas wrote: On Wed, Jun 2, 2010 at 10:34 PM, Florian Pflug f...@phlo.org 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

Re: [HACKERS] functional call named notation clashes with SQL feature

2010-06-04 Thread Joseph Adams
On Wed, May 26, 2010 at 9:28 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Wed, May 26, 2010 at 8:21 PM, Tom Lane t...@sss.pgh.pa.us wrote: If we go with the spec's syntax I think we'd have no realistic choice except to forbid = altogether as an operator

Re: [HACKERS] recovery getting interrupted is not so unusual as it used to be

2010-06-04 Thread Greg Stark
On Sat, Jun 5, 2010 at 2:20 AM, Robert Haas robertmh...@gmail.com 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

Re: [HACKERS] functional call named notation clashes with SQL feature

2010-06-04 Thread Joseph Adams
On Fri, Jun 4, 2010 at 9:55 PM, Joseph Adams joeyadams3.14...@gmail.com 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