Hello Guys,
Lately, I saw this syntax in ./src/backend/parser/Gray.y as following!
CreateFunctionStmt:
CREATE opt_or_replace FUNCTION func_name
func_args_with_defaults
RETURNS func_return createfunc_opt_list opt_definition
On 26.07.2011 10:22, _ʯͷ wrote:
I do not know how to use the second syntax:RETURNS TABLE '('
table_func_column_list ')' createfunc_opt_list opt_definition.
This is hardly a question related to PostgreSQL development,
pgsql-general mailing list would've been more appropriate.
8.4 had this change:
*
Force child tables to inherit CHECK constraints from parents
(Alex Hunsaker, Nikhil Sontakke, Tom)
You're not the only one who occasionally bangs his head against it.
Sorry for the occasional head bumps :)
Yeah. I think it's
Here's another small change to the patch, it works fine for me and it quite
saved my day.
I try to submit the patch by email.
diff --git a/contrib/vacuumlo/vacuumlo.c b/contrib/vacuumlo/vacuumlo.c
index f6e2a28..1f88d72 100644
--- a/contrib/vacuumlo/vacuumlo.c
+++ b/contrib/vacuumlo/vacuumlo.c
thank you!
-- 原始邮件 --
发件人: Heikki Linnakangas;
发送时间: 2011年7月26日(星期二) 下午3:58
收件人: _??;
抄送: pgsql-hackers;
主题: Re: [HACKERS] How to use CreateFunctionStmt's RETURN TABLE?
On 26.07.2011 10:22, _?? wrote:
I do not know how to use the second
On Jul26, 2011, at 01:57 , Noah Misch wrote:
On Mon, Jul 25, 2011 at 09:06:41PM +0200, Florian Pflug wrote:
On Jul25, 2011, at 20:37 , Bernd Helmle wrote:
Ah, but i got now what's wrong here: configure is confusing both libxml2
installations, and a quick look into config.log proves that: it
On Mon, Jul 25, 2011 at 10:14 PM, Greg Smith g...@2ndquadrant.com wrote:
On 07/25/2011 04:07 PM, Robert Haas wrote:
I did 5-minute pgbench runs with unlogged tables and with permanent
tables, restarting the database server and reinitializing the tables
between each run.
Database scale? One
On Tue, Jul 26, 2011 at 4:12 AM, Nikhil Sontakke
nikhil.sonta...@enterprisedb.com wrote:
Yeah. I think it's good that there's a barrier to blindly dropping a
constraint that may be important to have on children, but there should
be a way to override that.
Hmmm, but then it does open up the
Why do we get this warning on Mingw?:
x86_64-w64-mingw32-gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -Wformat-security -fno-strict-aliasing
-fwrapv -g -I../../../../src/include
On 07/26/2011 09:08 AM, Robert Haas wrote:
On Tue, Jul 26, 2011 at 4:12 AM, Nikhil Sontakke
nikhil.sonta...@enterprisedb.com wrote:
Yeah. I think it's good that there's a barrier to blindly dropping a
constraint that may be important to have on children, but there should
be a way to
Florian Pflug f...@phlo.org writes:
What's more, xml.c actually does attempt to protect against this situation
by calling LIBXML_TEST_VERSION in pg_xml_init_library().
But that check doesn't fire in our case, because it explicitly allows the
actual library version to be newer than the header
On Mon, Jul 25, 2011 at 10:29 PM, Josh Kupershmidt schmi...@gmail.com wrote:
That seems like a good way to document this; patch for master updated.
I avoided mucking with the documentation for COMMENT ON RULE and
COMMENT ON TRIGGER this time; they both say table when they really
mean table or
On Tue, Jul 26, 2011 at 9:52 AM, Tom Lane t...@sss.pgh.pa.us wrote:
As a side note, we don't add an rpath for libxml2 like we do for Perl and
Python.
Sounds like we should change that.
I don't think so. It would just be another headache for packagers ---
in Red Hat distros, at least,
On Mon, Jul 25, 2011 at 2:29 PM, Jeff Davis pg...@j-davis.com wrote:
On Fri, 2011-07-22 at 23:35 +0300, Peter Eisentraut wrote:
On ons, 2011-07-13 at 11:26 -0400, Tom Lane wrote:
Our standard reason for not implementing UNIQUE constraints on
expressions has been that then you would have a
On Jul26, 2011, at 15:52 , Tom Lane wrote:
Florian Pflug f...@phlo.org writes:
The only fix I can come up with is to explicitly test whether or not we're
able to restore the structured error context in pg_xml_init_library().
Yeah, I think you are right.
The downside of this is that a
Florian Pflug f...@phlo.org writes:
On further reflection, instead of checking whether we can restore the error
handler in pg_xml_init_library(), we could simply upgrade the elog(WARNING)
in pg_xml_done() to ereport(ERROR), and include a hint that explains the
probably cause.
The upside
Excerpts from Aron's message of mar jul 26 04:18:55 -0400 2011:
Here's another small change to the patch, it works fine for me and it quite
saved my day.
I try to submit the patch by email.
There's a problem with this patch: long lines are being wrapped by
your email client, which makes it
On Jul26, 2011, at 16:22 , Tom Lane wrote:
Florian Pflug f...@phlo.org writes:
On further reflection, instead of checking whether we can restore the error
handler in pg_xml_init_library(), we could simply upgrade the elog(WARNING)
in pg_xml_done() to ereport(ERROR), and include a hint that
Robert Haas robertmh...@gmail.com writes:
On Tue, Jul 26, 2011 at 4:12 AM, Nikhil Sontakke
nikhil.sonta...@enterprisedb.com wrote:
Hmmm, but then it does open up the possibility of naive users shooting
themselves in the foot. It can be easy to conjure up a
parent-only-constraint that does not
Robert Haas robertmh...@gmail.com writes:
On Tue, Jul 26, 2011 at 9:52 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't think so. It would just be another headache for packagers ---
in Red Hat distros, at least, packages are explicitly forbidden from
containing any rpath settings.
So what do
Florian Pflug f...@phlo.org writes:
What about the suggested upgrade of the elog(ERROR) in xml_errorHandler
to elog(FATAL)? Shall I do that too, or leave it for now?
No objection here --- I had considered writing it that way myself.
I refrained for fear of making a bad situation even worse, but
Hi Tim,
you correctly assumed I was just trying to clean up the code. There was no
reason to change the behavior, so please ignore my change to the patch.
Aron
On 26.07.2011, at 15:44, Tim Lewis wrote:
Hi Aron,
Thanks for the input. The small change you suggest would change the
Hi Tim,
I have to correct my previous answer, my change does not alter the behavior of
your patch significantly.
The difference:
In your version of the patch vacuumlo will stop after N lo_unlink(OID)
attempts.
The previous behavior of the patch is that vacuumlo will stop after N
Excerpts from Aron's message of mar jul 26 04:18:55 -0400 2011:
Here's another small change to the patch, it works fine for me and it quite
saved my day.
I try to submit the patch by email.
There's a problem with this patch: long lines are being wrapped by
your email client, which makes
Tom Lane t...@sss.pgh.pa.us writes:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jul 26, 2011 at 9:52 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't think so. It would just be another headache for packagers ---
in Red Hat distros, at least, packages are explicitly forbidden from
On Tue, Jul 26, 2011 at 9:07 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jul 25, 2011 at 10:14 PM, Greg Smith g...@2ndquadrant.com wrote:
On 07/25/2011 04:07 PM, Robert Haas wrote:
I did 5-minute pgbench runs with unlogged tables and with permanent
tables, restarting the database
On Tue, Jul 26, 2011 at 10:51:58AM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jul 26, 2011 at 4:12 AM, Nikhil Sontakke
nikhil.sonta...@enterprisedb.com wrote:
Hmmm, but then it does open up the possibility of naive users shooting
themselves in the foot. It
Hi Aron,
Thanks for the input. The small change you suggest would change the
behavior of the patch which I would prefer not to do as I have reasons for
the previous behavior.
Because you gave no reasons and stop after removing LIMIT LOs was not
changed to stop after attempting to remove LIMIT LOs
Hello Guys,
Lately, I saw this syntax in ./src/backend/parser/Gray.y as following!
CreateFunctionStmt:
CREATE opt_or_replace FUNCTION func_name
func_args_with_defaults
RETURNS func_return createfunc_opt_list opt_definition
Andrew Dunstan and...@dunslane.net writes:
On 07/25/2011 10:31 PM, Jerry Sievers wrote:
Hackers;
I just noticed that somewhere between 8.2 and 8.4, an exception is
raised trying to alter table ONLY some_partition_parent ADD CHECK
(foo).
8.4 had this change:
*
Force
On Tue, Jul 26, 2011 at 02:09:13PM +0200, Florian Pflug wrote:
On Jul26, 2011, at 01:57 , Noah Misch wrote:
We could rearrange things so the xml2-config -L
flags (or lack thereof) take priority over a --with-libraries directory for
the purpose of finding libxml2.
Hm, how would we do that
I'm not sure what David did for me so as per Roberts suggestion I have
addedhttps://commitfest.postgresql.org/action/patch_view?id=609this
patch to the commit fest.
I'm hoping I have not put this patch in more than one
On Jul26, 2011, at 18:04 , Noah Misch wrote:
On Tue, Jul 26, 2011 at 02:09:13PM +0200, Florian Pflug wrote:
On Jul26, 2011, at 01:57 , Noah Misch wrote:
We could rearrange things so the xml2-config -L
flags (or lack thereof) take priority over a --with-libraries directory for
the purpose of
On Tue, Jul 26, 2011 at 11:40 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
On Tue, Jul 26, 2011 at 9:07 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jul 25, 2011 at 10:14 PM, Greg Smith g...@2ndquadrant.com wrote:
On 07/25/2011 04:07 PM, Robert Haas wrote:
I did 5-minute pgbench
On Tue, Jul 26, 2011 at 12:18:31PM -0400, Timothy D. F. Lewis wrote:
On Mon, Jul 25, 2011 at 7:28 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jul 25, 2011 at 9:37 AM, Tim elatl...@gmail.com wrote:
Updated the patch to also apply when the no-action flag is enabled.
You may want
On Tue, Jul 26, 2011 at 12:24 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jul 26, 2011 at 11:40 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
On Tue, Jul 26, 2011 at 9:07 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jul 25, 2011 at 10:14 PM, Greg Smith
On Tue, Jul 26, 2011 at 12:29 PM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
So many transactions trying to update a small set of rows in a table.
Is that what we really want to measure ? My thinking is that we might
see different result if they are updating different parts of the table
On Tue, Jul 26, 2011 at 4:40M, Pavan Deolasee pavan.deola...@gmail.com wrote:
On Tue, Jul 26, 2011 at 9:07 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jul 25, 2011 at 10:14 PM, Greg Smith g...@2ndquadrant.com wrote:
On 07/25/2011 04:07 PM, Robert Haas wrote:
I did 5-minute pgbench
On Mon, Jul 25, 2011 at 6:24 PM, Noah Misch n...@2ndquadrant.com wrote:
On Fri, Jul 22, 2011 at 03:54:03PM -0400, Robert Haas wrote:
On Fri, Jul 22, 2011 at 3:28 PM, Noah Misch n...@2ndquadrant.com wrote:
This is attractive, and I don't see any problems with it. (In theory, you
could
hit
Robert Haas robertmh...@gmail.com writes:
On further reflection, I don't see that this helps: it just moves the
problem around. With resetState as a separate variable, nextMsgNum is
never changed by anyone other than the owner, so we can never have a
stale load. But if we overload nextMsgNum
After reinstalling mingw is ok.
2011/7/25, pasman pasmański pasma...@gmail.com:
After googling i found that mingw's gcc works with 64 bit integers.
But printf is incompatible :( . Possible workaround: include
inttypes.h , define macros and convert printf strings:
printf(% LL,(long
Excerpts from Tom Lane's message of mar jul 26 13:43:08 -0400 2011:
Uh, yes. I've lost count of the number of times I've seen people hit
one-instruction-wide race condition windows, SIGSEGV crash based on
accessing only one byte past the valid data structure, etc etc.
I think you need a
On 07/26/2011 12:33 PM, Pavan Deolasee wrote:
I think what I am suggesting is that the default pgbench test setup
would probably not give you a good scalability as number of clients
are increased and one reason could be the contention in the small
table. So it might be a good idea to get rid of
On Tue, Jul 26, 2011 at 6:36 PM, Robert Haas robertmh...@gmail.com wrote:
Now, as you say, it seems really, really
difficult to hit that in practice, but I don't see a way of getting
rid of the theoretical possibility without either (1) a spinlock or
(2) a fence. (Of course, on x86, the
On Jul26, 2011, at 17:07 , Tom Lane wrote:
Florian Pflug f...@phlo.org writes:
What about the suggested upgrade of the elog(ERROR) in xml_errorHandler
to elog(FATAL)? Shall I do that too, or leave it for now?
No objection here --- I had considered writing it that way myself.
I refrained for
Excerpts from Simon Riggs's message of mar jul 26 14:11:19 -0400 2011:
Let me ask a few questions to stimulate a different solution
* Can we do this using an active technique (e.g. signals) rather than
a passive one (reading a counter?)
Signals are already in use for special cases (queue is
On Tue, Jul 26, 2011 at 7:24 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Simon Riggs's message of mar jul 26 14:11:19 -0400 2011:
Let me ask a few questions to stimulate a different solution
* Can we do this using an active technique (e.g. signals) rather than
a
On Tue, Jul 26, 2011 at 2:56 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, Jul 26, 2011 at 7:24 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Simon Riggs's message of mar jul 26 14:11:19 -0400 2011:
Let me ask a few questions to stimulate a different solution
*
Simon Riggs si...@2ndquadrant.com writes:
On Tue, Jul 26, 2011 at 7:24 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Signals are already in use for special cases (queue is full), and I
think going through the kernel to achieve much more will lower
performance significantly.
If there
On Tue, Jul 26, 2011 at 8:11 PM, Robert Haas robertmh...@gmail.com wrote:
It wouldn't, although it might be bad in the case where there are lots
of temp tables being created and dropped.
Do temp tables cause relcache invalidations?
That seems like something we'd want to change in itself.
--
On 2011-07-22 17:35, Hitoshi Harada wrote:
2011/7/23 Yeb Havingayebhavi...@gmail.com:
Works like a charm :-). However, now there is always a copyObject of a
subquery even when the subquery is not safe for qual pushdown. The problem
with the previous issafe was that it was only assigned for
On Tue, Jul 26, 2011 at 9:24 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
That was a quite off-the-cuff remark, so I took the patch and culled out
loaded-tree bookkeeping. A lot of other changes fell off from that, so it
took me quite some time to get it working again,
On Tue, Jul 26, 2011 at 8:11 PM, Robert Haas robertmh...@gmail.com wrote:
* Can we partition the sinval lock, so we have multiple copies? That
increases the task for those who trigger an invalidation, but will
relieve the pressure for most readers.
Not sure there's a way to meaningfully
Noah Misch n...@2ndquadrant.com writes:
On Thu, Jul 21, 2011 at 11:37:27PM -0400, Robert Haas wrote:
I think I have a simpler idea, though:
before acquiring any locks, just have SIGetDataEntries() do this:
+ if (stateP-nextMsgNum == segP-maxMsgNum !stateP-resetState)
+
Florian Pflug f...@phlo.org writes:
Patch attached.
Will check and apply this.
I've pondered whether to add a check to configure which verifies that
the headers match the libxml version exactly at compile time. In the end,
I didn't do that, for two reasons. First, there isn't anything wrong
On Tue, Jul 26, 2011 at 03:40:32PM -0400, Tom Lane wrote:
Noah Misch n...@2ndquadrant.com writes:
On Thu, Jul 21, 2011 at 11:37:27PM -0400, Robert Haas wrote:
I think I have a simpler idea, though:
before acquiring any locks, just have SIGetDataEntries() do this:
+ if
On Tue, Jul 26, 2011 at 01:36:26PM -0400, Robert Haas wrote:
On Mon, Jul 25, 2011 at 6:24 PM, Noah Misch n...@2ndquadrant.com wrote:
On Fri, Jul 22, 2011 at 03:54:03PM -0400, Robert Haas wrote:
On Fri, Jul 22, 2011 at 3:28 PM, Noah Misch n...@2ndquadrant.com wrote:
This is attractive, and
Hi
While reviewing the (now applied) XPATH escaping patches, Radoslaw found one
case where the previous failure of XPATH to escape its return value was offset
by XMLATTRIBUTES insistence to escape all input values, even if they're
already of type XML.
To wit, if you do
SELECT XMLELEMENT(NAME
After committing Noah's patch to fix the isolation tests, there have
been two more failures in Rémi's machines pika and coypu:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=pikadt=2011-07-24%2006%3A45%3A45
Noah Misch n...@2ndquadrant.com writes:
On Tue, Jul 26, 2011 at 03:40:32PM -0400, Tom Lane wrote:
After some further reflection I believe this patch actually is pretty
safe, although Noah's explanation of why seems a bit confused.
Here's the way it can fail:
1. Backend enters
Yeb Havinga yebhavi...@gmail.com writes:
A few days ago I read Tomas Vondra's blog post about dss tpc-h queries
on PostgreSQL at
http://fuzzy.cz/en/articles/dss-tpc-h-benchmark-with-postgresql/ - in
which he showed how to manually pull up a dss subquery to get a large
speed up. Initially
On Tue, Jul 26, 2011 at 05:05:15PM -0400, Tom Lane wrote:
Noah Misch n...@2ndquadrant.com writes:
That's the theoretical risk I wished to illustrate. Though this appears
possible on an abstract x86_64 system, I think it's unrealistic to suppose
that
a dirty cache line could persist
Noah Misch n...@2ndquadrant.com writes:
On Tue, Jul 26, 2011 at 05:05:15PM -0400, Tom Lane wrote:
Dirty cache line, maybe not, but what if the assembly code commands the
CPU to load those variables into CPU registers before doing the
comparison? If they're loaded with maxMsgNum coming in last
This seems like a mechanical check. Should it be part of what gets
checked when people push?
Cheers,
David.
On Tue, Jul 26, 2011 at 08:30:16PM +, Peter Eisentraut wrote:
Add missing newlines at end of error messages
Branch
--
master
Details
---
On Jul 25, 2011, at 6:22 PM, Robert Haas wrote:
On Mon, Jul 25, 2011 at 6:26 PM, Jim Nasby j...@nasby.net wrote:
Hrm, don't we only pull in ZIC info on a reload? Or do we actually refer to
it dynamically all the time? Perhaps we can enforce that we'll only
recognize new TZ info as part of a
On Tue, Jul 26, 2011 at 6:45 PM, Jim Nasby j...@nasby.net wrote:
On Jul 25, 2011, at 6:22 PM, Robert Haas wrote:
On Mon, Jul 25, 2011 at 6:26 PM, Jim Nasby j...@nasby.net wrote:
Hrm, don't we only pull in ZIC info on a reload? Or do we actually refer to
it dynamically all the time? Perhaps we
On Jul 25, 2011, at 9:59 PM, Jerry Sievers wrote:
That our version of partitioning can be overloaded like this though I
think adds power. A bit of which we lost adding the restrictgion.
That's why I'd be opposed to any partitioning scheme that removed the ability
to have different fields in
On Jul 26, 2011, at 5:56 PM, Christopher Browne wrote:
I'm assuming that the issue here is that multiple backends could be
connected to the same database, and we don't want all of them to try to
actually do the updates, only the first one that discovers the change. If
that's the problem you
Jim,
That's why I'd be opposed to any partitioning scheme that removed the ability
to have different fields in different children. We've found that ability to
be very useful. Likewise, I think we need to have intelligent plans involving
a parent table that's either completely empty or
On Tue, Jul 26, 2011 at 9:53 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jul 25, 2011 at 10:29 PM, Josh Kupershmidt schmi...@gmail.com wrote:
I think this is basically the right approach but I found what you did
here a bit wordy, so I simplified it, committed it, and back-patched
to
On Tue, Jul 26, 2011 at 3:34 PM, Simon Riggs si...@2ndquadrant.com wrote:
You might be right, but I think we have little knowledge of how some
memory barrier code you haven't written yet effects performance on
various architectures.
A spinlock per backend would cache very nicely, now you
On Tue, Jul 26, 2011 at 3:25 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, Jul 26, 2011 at 8:11 PM, Robert Haas robertmh...@gmail.com wrote:
It wouldn't, although it might be bad in the case where there are lots
of temp tables being created and dropped.
Do temp tables cause relcache
On Tue, Jul 26, 2011 at 4:38 PM, Noah Misch n...@2ndquadrant.com wrote:
No new ideas come to mind, here.
OK, I have a new idea. :-)
1. Add a new flag to each procState called something like timeToPayAttention.
2. Each call to SIGetDataEntries() iterates over all the ProcStates
whose index is
73 matches
Mail list logo
