On Fri, 2008-11-14 at 02:21 +, Gregory Stark wrote:
On the other hand what does occur to me in retrospect is that I regret
that I didn't think about how I was disparaging the importance of
mental illness and hope nobody took offense for that reason.
Your comments surprise me because you
On Thu, Nov 13, 2008 at 03:57:49PM -0500, Tom Lane wrote:
Michael Meskes [EMAIL PROTECTED] writes:
That's what I did first, but Magnus had a good reasoning to not keep
preproc.y
if we keep preproc.c in our tarball. And I agreed that there doesn't seem
to be
an advantage.
Other than
Heikki Linnakangas wrote:
Another thing that does need to be fixed, is the way that the extension
and truncation of the visibility map is handled; that's broken in the
current patch. I started working on the patch a long time ago, before
the FSM rewrite was finished, and haven't gotten around
On Fri, Nov 14, 2008 at 8:10 AM, Simon Riggs [EMAIL PROTECTED] wrote:
On Fri, 2008-11-14 at 02:21 +, Gregory Stark wrote:
On the other hand what does occur to me in retrospect is that I regret
that I didn't think about how I was disparaging the importance of
mental illness and hope
Heikki Linnakangas [EMAIL PROTECTED] writes:
The next question is whether the pending rel deletion stuff in smgr.c should
be moved to the new file too. It seems like it would belong there better. That
would leave smgr.c as a very thin wrapper around md.c
Well it's just a switch, albeit with
On Fri, 2008-11-14 at 08:57 +, Dave Page wrote:
On Fri, Nov 14, 2008 at 8:10 AM, Simon Riggs [EMAIL PROTECTED] wrote:
On Fri, 2008-11-14 at 02:21 +, Gregory Stark wrote:
On the other hand what does occur to me in retrospect is that I regret
that I didn't think about how I was
On Fri, Nov 14, 2008 at 9:48 AM, Simon Riggs [EMAIL PROTECTED] wrote:
On Fri, 2008-11-14 at 08:57 +, Dave Page wrote:
On Fri, Nov 14, 2008 at 8:10 AM, Simon Riggs [EMAIL PROTECTED] wrote:
On Fri, 2008-11-14 at 02:21 +, Gregory Stark wrote:
On the other hand what does occur to me
On Thu, Nov 13, 2008 at 03:10:04PM -0500, Tom Lane wrote:
VPATH build. (Parts of this patch have that right and part don't.
You might want to test in a VPATH build before committing.)
Did that and fixed the remaining problems. Attached you'll find the latest
version. I already committed the
On Thu, Nov 13, 2008 at 09:03:41PM -0300, Alvaro Herrera wrote:
The first idea that comes to mind is skipping hint bits in the CRC too.
That does away with a lot of the trouble (PD_UNLOGGED_CHANGE, the
necessity of WAL-logging hint bits, etc). The problem, again, is that
the checksumming
On Tue, Nov 11, 2008 at 9:12 AM, Simon Riggs [EMAIL PROTECTED] wrote:
On Mon, 2008-11-10 at 18:22 +0900, Fujii Masao wrote:
Yeah, I also add walsender as new auxiliary process at first. But,
during coding,
I made out that this is more complicated for code and user.
First problem : Which
Josh Berkus wrote:
Greg,
BTW, I think this is still in enough flux that we really ought to make
it a pgfoundry project. I don't think we'll have anything ready for 8.4
contrib.
[Been trying to find the right point to post this reply.]
Is it only me that thinks this should be a service on
internal-accepting functions together this way. So what I propose is
that we allow STYPE = internal to be specified in CREATE AGGREGATE,
but only by superusers, who are trusted not to create security holes
anyway.
Does that mean that it's possible to use as STYPE pointer to complex C-structure
I updated the patch set of SE-PostgreSQL (revision 1216).
There are no new features and bugfixes, but it was rebased to the latest
CVS HEAD, because the previous r1206 got a few conflictions.
These patches are ready for reviewing.
We need your help to make progress them so much!
[1/6]
Michael Meskes wrote:
+$(srcdir)/preproc.y: $(top_srcdir)/src/backend/parser/gram.y
+ $(PERL) $(srcdir)/parse.pl $(srcdir) $ $@
Why are you passing $(srcdir) as a parameter here? It doesn't look like
the script uses it at all, or does it?
--
Alvaro Herrera
4. what we do now, but document loudly that PGEventProc must be static.
If it can't be referenced outside the DLL directly then the issue can't
arise. If you need the function address for calls to PQinstanceData, an
implementor can create a public function that returns their private
On Fri, Nov 14, 2008 at 09:03:34AM -0300, Alvaro Herrera wrote:
+$(srcdir)/preproc.y: $(top_srcdir)/src/backend/parser/gram.y
+ $(PERL) $(srcdir)/parse.pl $(srcdir) $ $@
Why are you passing $(srcdir) as a parameter here? It doesn't look like
the script uses it at all, or does it?
Alvaro Herrera wrote:
I'll probably fix both things and submit an updated version tomorrow.
Here it is. This applies cleanly to current CVS HEAD and passes the
regression tests. Apart from fixing the conflicts, I updated psql's \z
with the new array aggregate, and changed the Schema_pg_*
Alvaro Herrera wrote:
Alvaro Herrera wrote:
I'll probably fix both things and submit an updated version tomorrow.
Here it is.
Really attached this time.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
Thank you for a possible solution.
But what about the database which exists and works correctly (and conforms
all the standards from the documentation), but dump+restore sequence is
failed for it? Does it mean that pg_dump should be improved to pass
dump+restore sequence?
Besides that, for
You can certainly screw yourself up by connecting some incompatible
internal-accepting functions together this way. So what I propose is
that we allow STYPE = internal to be specified in CREATE AGGREGATE,
but only by superusers, who are trusted not to create security holes
anyway.
On Thu, 2008-11-13 at 10:44 +0900, KaiGai Kohei wrote:
It's unclear for me what is the point you said.
I guess you concern the fixed length field is always allocated in
the case when any security feature is not enabled also, or performance
degradation on the large scale databases.
If
On Fri, 2008-11-14 at 02:21 +, Gregory Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Your factual comments are accurate, but for Josh's stated target of Data
Warehousing, a stats target of 400 is not unreasonable in some cases.
What you forget to mention is that sample size is
Teodor Sigaev [EMAIL PROTECTED] writes:
Does that mean that it's possible to use as STYPE pointer to complex
C-structure
with internal pointers?
That's exactly what array_agg is doing. You have to be careful about
which context you keep the data in ...
regards, tom
Robert Haas [EMAIL PROTECTED] writes:
I would feel a lot better about it if we could invent some way of
distinguishing between different types of internal, based on what is
actually being pointed to.
Yeah, we discussed that awhile ago, but nothing's been done about it.
At this point I doubt it
I have experienced some brittleness in the regression test setup that
causes the tests to be run against a different server instance or fail
in confusing ways when you have multiple instances running.
For some historic reasons, I have my local scripts set up so that they
build development
On Fri, Nov 14, 2008 at 2:52 AM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Other systems do it. For example, Oracle tracks column usage and
attempts to determine the optimal statistics for that column (based on
the queries that used it) on an iterative basis. We don't track
column usage at
Due to some code reshuffling, xmlconcat(NULL) will crash in 8.3 and 8.4.
The pfree(buf.data) in ExecEvalXml() frees a buffer that is actuall
only initialized in the XMLFOREST case. So then the xmlconcat(NULL)
falls through to the pfree() it crashes. I have attached a patch for
8.3 and 8.4
Michael Meskes [EMAIL PROTECTED] writes:
Does anyone see a problem with these changes? Or else I will commit.
preproc.y should be removed by make maintainer-clean. For consistency
it probably ought to be listed in the distprep target too, even though
it would be indirectly updated by the
Jonah H. Harris wrote:
Oracle already thought of that a long time ago, which is why the plan
has to come out better for it to take effect.
Huh? We would never willingly choose a worse plan, of course, but the
point is that what looks like a better plan, with a smaller cost
estimate, is
Martijn van Oosterhout [EMAIL PROTECTED] writes:
But I understand the problem is that you want to continue in the face
of torn pages, something which is AFAICS ambitious. At least MS-SQL
just blows up on a torn page, havn't found results for other
databases...
I don't think it's too ambitious
On Fri, Nov 14, 2008 at 10:50 AM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Oracle already thought of that a long time ago, which is why the plan
has to come out better for it to take effect.
Huh? We would never willingly choose a worse plan, of course, but the point
is that what looks like
Simon Riggs wrote:
On Thu, 2008-11-13 at 10:44 +0900, KaiGai Kohei wrote:
It's unclear for me what is the point you said.
I guess you concern the fixed length field is always allocated in
the case when any security feature is not enabled also, or performance
degradation on the large scale
Peter Eisentraut wrote:
So even if I configured my local scripts to use ports that are all
different from each other and from 65432, this problem would still exist.
Only if you choose the private port to be above . The standard
buildfarm config file contains a warning against using
Michael Meskes wrote:
Does anyone see a problem with these changes? Or else I will commit.
FWIW, I have looked at this a bit. I want to refactor it at some stage
because it's ugly and fragile and rather obtuse, but the refactoring
won't be happening for a while.
cheers
andrew
On Fri, Nov 14, 2008 at 10:12 AM, Tom Lane [EMAIL PROTECTED] wrote:
Robert Haas [EMAIL PROTECTED] writes:
I would feel a lot better about it if we could invent some way of
distinguishing between different types of internal, based on what is
actually being pointed to.
Yeah, we discussed that
Dmitry Koterov [EMAIL PROTECTED] writes:
Thank you for a possible solution.
But what about the database which exists and works correctly (and conforms
all the standards from the documentation), but dump+restore sequence is
failed for it? Does it mean that pg_dump should be improved to pass
On Sat, 2008-11-15 at 00:58 +0900, KaiGai Kohei wrote:
Sorry, it seems to me you misunderstand something.
Yep, seems so. Thank goodness for that. Thanks for putting me straight.
I would also like to see the feature part of normal Postgres, rather
than as a compile time option. The per-row
On Fri, Nov 14, 2008 at 10:44:08AM -0500, Tom Lane wrote:
preproc.y should be removed by make maintainer-clean. For consistency
it probably ought to be listed in the distprep target too, even though
it would be indirectly updated by the preproc.c target. I suspect it
would be a good idea to
Robert Haas [EMAIL PROTECTED] writes:
On Fri, Nov 14, 2008 at 10:12 AM, Tom Lane [EMAIL PROTECTED] wrote:
Robert Haas [EMAIL PROTECTED] writes:
I would feel a lot better about it if we could invent some way of
distinguishing between different types of internal, based on what is
actually being
Heikki Linnakangas [EMAIL PROTECTED] writes:
You're right, I haven't, but yes I know that's a problem. We've chatted
about that with Greg sometimes. It would be nice to have more stable
plans. My favorite idea is to stop using the current relation size in
the planner, and use the value
On Fri, Nov 14, 2008 at 11:43 AM, Tom Lane [EMAIL PROTECTED] wrote:
IMHO, the only thing worse than an unstable plan is a stable one.
Your opinion contradicts the majority of the industry then, I'm
afraid. Like query hints, people are sometimes smarter than the
optimizer.
--
Jonah H. Harris,
Peter Eisentraut [EMAIL PROTECTED] writes:
For some historic reasons, I have my local scripts set up so that they
build development instances using the hardcoded port 65432. This will
cause a temp install regression test to attempt to use port 565432 which
will be rejected silently by
Michael Meskes [EMAIL PROTECTED] writes:
Added.
Looks alright to me now --- you might as well commit and let the
buildfarm find any remaining problems.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Fujii Masao wrote:
Attached is the latest version of Synch Rep patch.
Why do we need a separate XLogsndRqst variable in shared memory? Don't
we always want to send the WAL up to the same point as we flush it?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via
On Thu, Nov 13, 2008 at 01:05, Magnus Hagander [EMAIL PROTECTED] wrote:
It means I will go ahead and apply it once I have looked it over once more.
Thanks for review+testing!
You may now move on to the next ssl patch if you're interested ;)
Sure thing probably wont get to it till tomorrow...
On Fri, 2008-11-14 at 19:00 +0200, Heikki Linnakangas wrote:
Fujii Masao wrote:
Attached is the latest version of Synch Rep patch.
Why do we need a separate XLogsndRqst variable in shared memory? Don't
we always want to send the WAL up to the same point as we flush it?
If we're doing
Jonah H. Harris [EMAIL PROTECTED] writes:
On Fri, Nov 14, 2008 at 11:43 AM, Tom Lane [EMAIL PROTECTED] wrote:
IMHO, the only thing worse than an unstable plan is a stable one.
Your opinion contradicts the majority of the industry then, I'm
afraid. Like query hints, people are sometimes
Hi.
As I wanted to change the order of columns of some tables (I know, I
know, my code does not depend
on that; but I prefer that \dt gives me a more organized ouput...)
I've added an option to pg_dump to reorder
columns in the ouput CREATE TABLE dump.
The specified order is given in a external
Simon Riggs wrote:
On Fri, 2008-11-14 at 19:00 +0200, Heikki Linnakangas wrote:
Why do we need a separate XLogsndRqst variable in shared memory? Don't
we always want to send the WAL up to the same point as we flush it?
If we're doing synch rep and we're committing.
You flush and send the
On Fri, Nov 14, 2008 at 12:07 PM, Tom Lane [EMAIL PROTECTED] wrote:
And, very often, they're not --- or more likely, they were smarter than
the optimizer last year, but now conditions have changed. Failing to
adapt to new conditions is exactly the problem with query hints, and
in general with
hernan gonzalez [EMAIL PROTECTED] writes:
I've added an option to pg_dump to reorder
columns in the ouput CREATE TABLE dump.
This doesn't seem like a particularly good idea to me. In the first
place, pg_dump is a tool for reproducing your database, not altering it,
so it seems like basically
On Fri, 2008-11-14 at 19:23 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Fri, 2008-11-14 at 19:00 +0200, Heikki Linnakangas wrote:
Why do we need a separate XLogsndRqst variable in shared memory? Don't
we always want to send the WAL up to the same point as we flush it?
If
Tom Lane wrote:
Jonah H. Harris [EMAIL PROTECTED] writes:
On Fri, Nov 14, 2008 at 11:43 AM, Tom Lane [EMAIL PROTECTED] wrote:
IMHO, the only thing worse than an unstable plan is a stable one.
Your opinion contradicts the majority of the industry then, I'm
afraid. Like query hints, people
On Fri, Nov 14, 2008 at 4:12 PM, Tom Lane [EMAIL PROTECTED] wrote:
hernan gonzalez [EMAIL PROTECTED] writes:
I've added an option to pg_dump to reorder
columns in the ouput CREATE TABLE dump.
This doesn't seem like a particularly good idea to me. In the first
place, pg_dump is a tool for
On Thu, Nov 13, 2008 at 11:53 AM, Tom Lane [EMAIL PROTECTED] wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
A lot of people have suggested raising our default_statistics target,
and it has been rejected because there's some O(n^2) behavior in the
planner, and it makes ANALYZE slower, but
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
I'm submitting 2 contrib modules and there 3 patches to core for them
from me and Martin, but they confict each other and there are some hunks
and rejections already. Here is an assorted patch of them.
Can I ask you to review the patches in this form?
Jeff Davis [EMAIL PROTECTED] writes:
On Thu, 2008-11-13 at 14:31 -0500, Tom Lane wrote:
This patch seems to contain a subset of the contrib infrastructure
patch that's listed separately on the commitfest page. While I have
no strong objection to what's here, I'm wondering what sort of process
Martin Pihlak [EMAIL PROTECTED] writes:
ITAGAKI Takahiro wrote:
But is the idea of extending QueryDesc generally acceptable? Is it OK
to make a copy of the query string?
The only thing I'm worried about is that QueryDesc lives longer than
its queryText. Can I assume it never occurs?
I
On Fri, 14 Nov 2008, Richard Huxton wrote:
Is it only me that thinks this should be a service on the website too
(or even first)? Fill in web form, click button, get sample
postgresql.conf (with comments) back.
Sounds familiar...ah, here it is:
Fujii Masao wrote:
Attached is a patch of signal handling changes for Synch Rep.
It seems that we wouldn't need to use the BackendPidGetProc function,
nor the new AuxiliaryPidGetProc function, if we stored a PGPROC *
instead of the pid in ProcState.procPid.
--
Heikki Linnakangas
I found the following behavior surprising. Is there a reason for it?
This is 8.3.5. ...Robert
rhaas=# BEGIN WORK;
BEGIN
rhaas=# CREATE TABLE test_table (id serial, foo integer, bar integer);
NOTICE: CREATE TABLE will create implicit sequence
test_table_id_seq for serial column test_table.id
Alvaro Herrera wrote:
I didn't check the rest of the code, so don't count this as a review.
I had a look at aclchk.c and didn't like your change to
objectNamesToOids; seems rather baroque. I changed it per the attached
patch.
Moreover I didn't very much like the way aclcheck_error_col is
Tom Lane wrote:
I did this:
http://archives.postgresql.org/pgsql-committers/2008-11/msg00156.php
to try to fix this:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=narwhaldt=2008-11-12%2021:00:01
only to get this:
Andrew Dunstan [EMAIL PROTECTED] writes:
Your second go at fixing this seems to have almost worked. Is there a
reason why, alone of the utility programs, pg_resetxlog.c uses
postgres.h rather than postgres_fe.h?
It doesn't compile otherwise.
We could possibly refactor the backend includes
Robert Haas [EMAIL PROTECTED] writes:
I found the following behavior surprising. Is there a reason for it?
This is 8.3.5. ...Robert
rhaas=# DECLARE c CURSOR FOR SELECT id FROM test_table ORDER BY foo FOR
UPDATE;
DECLARE CURSOR
Skimming the code we don't support WHERE CURRENT OF on a
... meanwhile, the MSVC port has got its own issues:
Generating win32ver.rc for src\backend
Building src\pl\plperl\SPI.c...
Could not determine contrib module type for intagg
at build.pl line 37
I am not sure what if anything that script needs to do for a contrib
module with no .c files.
Robert Haas [EMAIL PROTECTED] writes:
I found the following behavior surprising. Is there a reason for it?
Yes.
regards, tom lane
(Oh, you wanted to know what the reason is? It's because a sort step
is not going to pass through any tuple identity information.)
--
Tom Lane wrote:
... meanwhile, the MSVC port has got its own issues:
Generating win32ver.rc for src\backend
Building src\pl\plperl\SPI.c...
Could not determine contrib module type for intagg
at build.pl line 37
I am not sure what if anything that script needs to do for a contrib
module
Gregory Stark [EMAIL PROTECTED] writes:
Robert Haas [EMAIL PROTECTED] writes:
I found the following behavior surprising. Is there a reason for it?
This is 8.3.5. ...Robert
rhaas=# DECLARE c CURSOR FOR SELECT id FROM test_table ORDER BY foo FOR
UPDATE;
Skimming the code we don't
[ dept of second thoughts... ] Actually, given that he said FOR UPDATE,
the plan should be propagating the tuple identity through to top level
so that execMain can do its thing. So in principle we could probably
get the information without widespread changes. This would fit
reasonably well
Robert Haas [EMAIL PROTECTED] writes:
I was pretty leery about reviewing this one due to the feeling that I
might well be in over my head, but they talked me into it, so here
goes nothin'. Apologies in advance for any deficiencies in this
review.
- Overall, this looks pretty clean.
-
As this hasn't happened and I haven't been able to demonstrate it being useful
myself I guess it makes more sense to separate the two now and set the
sequential scan stuff aside until someone can demonstrate it being useful.
Sounds good. How soon do you think you can post updated patches?
Andrew Chernow [EMAIL PROTECTED] writes:
On the whole I vote for #4 out of these.
I attached a patch for the docs. Its documented as a NOTE to the
PGEventProc.
Applied, but I editorialized on the wording a bit. Let me know if you
think this is wrong ...
regards,
On Friday 14 November 2008 13:37:05 hernan gonzalez wrote:
On Fri, Nov 14, 2008 at 4:12 PM, Tom Lane [EMAIL PROTECTED] wrote:
hernan gonzalez [EMAIL PROTECTED] writes:
I've added an option to pg_dump to reorder
columns in the ouput CREATE TABLE dump.
This doesn't seem like a
I wrote:
[ dept of second thoughts... ] Actually, given that he said FOR UPDATE,
the plan should be propagating the tuple identity through to top level
so that execMain can do its thing. So in principle we could probably
get the information without widespread changes. This would fit
Hitoshi Harada wrote:
david=# explain select date,lag(date,1) over (order by date) from
meter_Readings order by date;
QUERY PLAN
Robert Haas [EMAIL PROTECTED] writes:
What's particularly unfortunate is Greg's comment that this would work
if the planner chose an index scan. Had I defined an index on the
columns in question, my code might have worked and been deployed to
production - and then broken if the planner
Here's a draft patch (no docs, no regression test) for that. It doesn't
look as ugly as I expected. Comments? I'm hesitant to call this a bug
fix, and we are past feature freeze ...
Considering the number of and invasiveness of the patches remaining in
the queue, I'm inclined to consider
Tom Lane [EMAIL PROTECTED] wrote:
Now that I look closer, the contrib infrastructure item is just a
combination of the auto_explain and pg_stat_statements items, and I
guess the reason you and Matthew were shown as reviewers was that
you'd each been assigned one of those two items. As far
However ... the more I think about it, the more I wonder if we shouldn't
rip out the current search-the-plan-tree hack and allow WHERE CURRENT OF
*only* for cursors that say FOR UPDATE. Aside from the above issue,
there's an already known and documented risk if you omit FOR UPDATE,
which is
This is the whole patch of Synch Rep against head. This also contain
Infrastructure changes for recover patch by Simon because I'd like to
make walreceiver work in consistent recovery mode.
Given that both this patch and Simon's hot standby patches need this
infrastructure, it seems like it
Tom Lane [EMAIL PROTECTED] wrote:
I'm trying to figure out what is the status of this patch? I'm not sure
if there's any point in applying it, when contrib/pg_stat_statements
hasn't been updated to make use of it.
Here is an updated patch to use QueryDesc.queryText and supports nested
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
On the whole I vote for #4 out of these.
I attached a patch for the docs. Its documented as a NOTE to the
PGEventProc.
Applied, but I editorialized on the wording a bit. Let me know if you
think this is wrong ...
It's correct,
Tom Lane [EMAIL PROTECTED] writes:
Robert Haas [EMAIL PROTECTED] writes:
What's particularly unfortunate is Greg's comment that this would work
if the planner chose an index scan. Had I defined an index on the
columns in question, my code might have worked and been deployed to
production -
On Fri, 14 Nov 2008, Gregory Stark wrote:
In particular I was hoping Zoltan who original reported the sequential
file strategy stuff being helpful might be able to see if this works for
him.
The original message there suggested it was particularly valuable when
working with a somewhat
85 matches
Mail list logo
