I wrote:
I think the way to solve this is to do whatever it takes to get access
to the subplan targetlist. We could then do something a bit cleaner
than what the named-rowtype code is currently doing: if there are
resjunk columns in the subplan targetlist, use the tlist to create a
On 18/07/12 17:17, Heikki Linnakangas wrote:
On 14.07.2012 17:50, Jan Urbański wrote:
If pg_do_encoding_conversion() throws an error, you don't get a chance
to call Py_DECREF() to release the string. Is that a problem?
If an error occurs in PLy_traceback(), after incrementing
recursion_depth,
On 20/07/12 08:59, Jan Urbański wrote:
On 18/07/12 17:17, Heikki Linnakangas wrote:
On 14.07.2012 17:50, Jan Urbański wrote:
If pg_do_encoding_conversion() throws an error, you don't get a chance
to call Py_DECREF() to release the string. Is that a problem?
If an error occurs in
We yesterday encountered a program that in a degenerate case issued in
a single transaction a huge number of selects (in a single transaction
but each select in a separate call to PGExec) (huge = ~ 400,000).
That transaction would continue to eat memory up until a point where
calls to malloc (in
On 20.07.2012 10:19, Benedikt Grundmann wrote:
We yesterday encountered a program that in a degenerate case issued in
a single transaction a huge number of selects (in a single transaction
but each select in a separate call to PGExec) (huge = ~ 400,000).
That transaction would continue to eat
Hi,
On Friday, July 20, 2012 09:19:31 AM Benedikt Grundmann wrote:
We yesterday encountered a program that in a degenerate case issued in
a single transaction a huge number of selects (in a single transaction
but each select in a separate call to PGExec) (huge = ~ 400,000).
That transaction
On Thu, Jul 19, 2012 at 6:06 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
Hanada-san,
What about the status of your patch?
Sorry for absence. I have been struggling with connection recovery
issue, but I haven't fixed it yet. So I'd like to withdraw this patch
from this CF and mark it as
First of all thanks to everyone who has replied so far.
On Fri, Jul 20, 2012 at 10:04 AM, Andres Freund and...@2ndquadrant.com wrote:
Hi,
On Friday, July 20, 2012 09:19:31 AM Benedikt Grundmann wrote:
We yesterday encountered a program that in a degenerate case
issued in a single
On Fri, Jul 20, 2012 at 9:10 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 20.07.2012 10:19, Benedikt Grundmann wrote:
We yesterday encountered a program that in a degenerate case issued in
a single transaction a huge number of selects (in a single transaction
but each
On Fri, Jul 20, 2012 at 10:46 AM, Benedikt Grundmann
bgrundm...@janestreet.com wrote:
DECLARE sqmlcursor51587 CURSOR FOR select
On Fri, Jul 20, 2012 at 10:56 AM, Benedikt Grundmann
bgrundm...@janestreet.com wrote:
On Fri, Jul 20, 2012 at 10:46 AM, Benedikt Grundmann
bgrundm...@janestreet.com wrote:
Actually I believe this must be it. I just went back and checked the library
and it does not CLOSE the cursors. This is
Hi,
On Friday, July 20, 2012 11:56:09 AM Benedikt Grundmann wrote:
I also noticed just know that all TopMemoryContext's after the first one
look significantly different. They contain large PortalMemory sections.
Are those related to cursors?
Yes.
Andres
--
Andres Freund
On 13.07.2012 02:00, Alexander Korotkov wrote:
Done. There are separate patch for get rid of TrickFunctionCall2 and
version of SP-GiST for ranges based on that patch.
Looking at the SP-GiST patch now..
It would be nice to have an introduction, perhaps as a file comment at
the top of
On Fri, Jul 20, 2012 at 1:31 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
I think the way to solve this is to do whatever it takes to get access
to the subplan targetlist. We could then do something a bit cleaner
than what the named-rowtype code is currently doing: if there are
resjunk
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Jeff Janes
Sent: Friday, July 20, 2012 5:36 AM
Is there a reason to vacuum the pgbench_* tables after the indexes on them
are built, rather than before?
Since the indexes are on fresh tables,
On Fri, Jul 20, 2012 at 7:57 AM, Amit Kapila amit.kap...@huawei.com wrote:
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Jeff Janes
Sent: Friday, July 20, 2012 5:36 AM
Is there a reason to vacuum the pgbench_* tables after the indexes on
On Wed, Jul 18, 2012 at 10:22 AM, Robert Haas robertmh...@gmail.com wrote:
The next step here is obviously to complete the work necessary to
actually be able to fire these triggers, as opposed to just saying
that we fire them. I'll write up my thoughts on that topic in a
separate email. I
On Tue, Jul 17, 2012 at 06:02:40PM -0400, Bruce Momjian wrote:
Second, the user files (large) are certainly identical, it is only the
system tables (small) that _might_ be different, so rsync'ing just those
would add the guarantee, but I know of no easy way to rsync just the
system tables.
Jeff Janes jeff.ja...@gmail.com writes:
On Fri, Jul 20, 2012 at 7:57 AM, Amit Kapila amit.kap...@huawei.com wrote:
The command it executes is vacuum analyze .., so it will do analyze also
on table which means
it will collect stats corresponding to table and index.
Are there stats collected
If you're wanting to automatically do some upgrades wouldn't an easier route be:
1) run pg_upgrade, up to the point where it actually start's
copying/linking in old cluster data files, and stop the new
postmaster.
2) Take a base backup style copy (tar, rsync, $FAVOURITE) of the new
cluster
On Fri, Jul 20, 2012 at 12:39:12PM -0400, Aidan Van Dyk wrote:
If you're wanting to automatically do some upgrades wouldn't an easier route
be:
1) run pg_upgrade, up to the point where it actually start's
copying/linking in old cluster data files, and stop the new
postmaster.
2) Take a
On Tue, Jun 12, 2012 at 5:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Rather than trying to enforce this in the
ALTER FUNCTION implementation, maybe we should just advise that if
you're going to grant ownership of a C function to a role which
Merlin Moncure mmonc...@gmail.com writes:
On Fri, Jul 20, 2012 at 1:31 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Here's a draft patch for that. It wasn't quite as ugly as I feared.
A lot of the apparent bulk of the patch is because I chose to split
ExecEvalVar into separate functions for the
On 07/19/2012 09:54 AM, Andrew Dunstan wrote:
Meanwhile, I would like to remove the prepared_transactions test from
the main isolation schedule, and add a new Make target which runs that
test explicitly. Is there any objection to that?
Here's the patch for that.
cheers
andrew
On 20 July 2012 16:50, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jul 18, 2012 at 10:22 AM, Robert Haas robertmh...@gmail.com wrote:
The next step here is obviously to complete the work necessary to
actually be able to fire these triggers, as opposed to just saying
that we fire them.
Excerpts from Andrew Dunstan's message of vie jul 20 13:15:12 -0400 2012:
On 07/19/2012 09:54 AM, Andrew Dunstan wrote:
Meanwhile, I would like to remove the prepared_transactions test from
the main isolation schedule, and add a new Make target which runs that
test explicitly. Is
Excerpts from Noah Misch's message of mar jul 17 16:28:32 -0400 2012:
On Tue, Jul 17, 2012 at 01:56:19PM -0400, Alvaro Herrera wrote:
However, there's more work to do in isolation testing. It'd be good to
have it being routinely run in serializable isolation level, for
example, not
On 07/20/2012 01:37 PM, Alvaro Herrera wrote:
Excerpts from Andrew Dunstan's message of vie jul 20 13:15:12 -0400 2012:
On 07/19/2012 09:54 AM, Andrew Dunstan wrote:
Meanwhile, I would like to remove the prepared_transactions test from
the main isolation schedule, and add a new Make target
Robert Haas robertmh...@gmail.com writes:
On Tue, Jun 12, 2012 at 5:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah, the just-code-defensively option is worth considering too.
After rereading this thread, I think I agree with Kevin as well. ...
Having said that, I do believe that answer is to
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Andrew Dunstan's message of vie jul 20 13:15:12 -0400 2012:
Meanwhile, I would like to remove the prepared_transactions test from
the main isolation schedule, and add a new Make target which runs that
test explicitly. Is there
The Windows buildfarm members don't seem too happy with the latest
patch.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 07/20/2012 01:56 PM, Tom Lane wrote:
I'm not thrilled with replicating the test-list file either. But it is
not necessary: look at the way the bigtest target is defined in the
main regression makefile. You can just add some more test names on the
command line, to be done in addition to
On Fri, Jul 20, 2012 at 1:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jun 12, 2012 at 5:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah, the just-code-defensively option is worth considering too.
After rereading this thread, I think I agree with
Robert Haas robertmh...@gmail.com writes:
I don't particularly care for that solution; it seems like a kludge.
I've kind of wondered whether we ought to have checks in all the ALTER
routines that spit up if you try to ALTER an extension member from any
place other than an extension upgrade
On Fri, Jul 20, 2012 at 2:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The Windows buildfarm members don't seem too happy with the latest
patch.
I'm looking at this now, but am so far mystified. Something's
obviously broken as regards how the trigger flags get set up, but if
that were broken in a
On Fri, Jul 20, 2012 at 1:22 PM, Thom Brown t...@linux.com wrote:
I've just run my own set of tests against these changes, which tests
every supported DDL command (with the exception of CREATE USER
MAPPING, ALTER USER MAPPING, DROP USER MAPPING, CREATE LANGUAGE
and DROP LANGUAGE), and many
Excerpts from Peter Eisentraut's message of mié jul 18 17:49:37 -0400 2012:
Sorry to raise this once again, but I still find this CHECK NO INHERIT
syntax to a bit funny. We are currently using something like
CHECK NO INHERIT (foo 0)
But we already have a different syntax for attaching
Alvaro Herrera alvhe...@commandprompt.com writes:
True. I have added an error check at creation time. Please suggest
improved wording for the message:
alvherre=# create domain positiveint2 as int check (value 0) no inherit;
ERROR: CHECK constraints for domains cannot be NO INHERIT
I
Andrew Dunstan and...@dunslane.net writes:
Remove prepared transactions from main isolation test schedule.
There is no point in running this test when prepared transactions are
disabled,
which is the default. New make targets that include the test are provided.
This
will save some useless
On 07/20/2012 04:17 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Remove prepared transactions from main isolation test schedule.
There is no point in running this test when prepared transactions are disabled,
which is the default. New make targets that include the test are
On Fri, Jul 20, 2012 at 3:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I don't particularly care for that solution; it seems like a kludge.
I've kind of wondered whether we ought to have checks in all the ALTER
routines that spit up if you try to ALTER an
Hello,
apologize for bumping the question to -hackers but I got no answer
from -general. If there is a better ML to post it let me know.
In a libpq application, if there is an application error between
PQsendQuery and PQgetResult, is there a way to revert a connection
back to an usable state
Excerpts from Tom Lane's message of vie jul 20 16:12:05 -0400 2012:
Alvaro Herrera alvhe...@commandprompt.com writes:
True. I have added an error check at creation time. Please suggest
improved wording for the message:
alvherre=# create domain positiveint2 as int check (value 0) no
43 matches
Mail list logo
