Excerpts from Tom Lane's message of vie jul 20 16:12:05 -0400 2012:
>
> Alvaro Herrera 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
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 (i.e
On Fri, Jul 20, 2012 at 3:45 PM, Tom Lane wrote:
> Robert Haas 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
>> pla
On 07/20/2012 04:17 PM, Tom Lane wrote:
Andrew Dunstan 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 sa
Andrew Dunstan 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 waste of cycl
Alvaro Herrera 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 think "CHECK constraints f
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 attach
On Fri, Jul 20, 2012 at 1:22 PM, Thom Brown 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 vari
On Fri, Jul 20, 2012 at 2:12 PM, Tom Lane 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 trivial way it w
Robert Haas 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 script... but that s
On Fri, Jul 20, 2012 at 1:52 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jun 12, 2012 at 5:12 PM, Tom Lane 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 beli
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 wh
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
Alvaro Herrera 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 any objection to t
Robert Haas writes:
> On Tue, Jun 12, 2012 at 5:12 PM, Tom Lane 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 some extent a
> cop-out.
I agree w
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 w
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,
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 e
On 20 July 2012 16:50, Robert Haas wrote:
> On Wed, Jul 18, 2012 at 10:22 AM, Robert Haas 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 topi
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
diff
Merlin Moncure writes:
> On Fri, Jul 20, 2012 at 1:31 AM, Tom Lane 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 scalar and whole-row
>> cases, wh
On Tue, Jun 12, 2012 at 5:12 PM, Tom Lane wrote:
> "Kevin Grittner" 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
>> might accidentally or maliciously al
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) Tak
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 (smal
Jeff Janes writes:
> On Fri, Jul 20, 2012 at 7:57 AM, Amit Kapila 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 on indexes?
Only for expression 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.
On Wed, Jul 18, 2012 at 10:22 AM, Robert Haas 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 don't think there's
On Fri, Jul 20, 2012 at 7:57 AM, Amit Kapila 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 them
> are built
> 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 1:31 AM, Tom Lane 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 columns in t
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 rangetype
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 Fri, Jul 20, 2012 at 10:56 AM, Benedikt Grundmann
wrote:
> On Fri, Jul 20, 2012 at 10:46 AM, Benedikt Grundmann
> 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 normally not a problem as most
> transaction
On Fri, Jul 20, 2012 at 10:46 AM, Benedikt Grundmann
wrote:
>
> DECLARE sqmlcursor51587 CURSOR FOR select
> entry_time,source,bad_fields,isin,sedol,cusip,bloomberg,reuters,exchange_code,currency,description,bbg_instrument_type,instrument_type,specifics,definer,primary_exchange,is_primary_security,
On Fri, Jul 20, 2012 at 9:10 AM, Heikki Linnakangas
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 select in a separate call t
First of all thanks to everyone who has replied so far.
On Fri, Jul 20, 2012 at 10:04 AM, Andres Freund 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 transaction a huge numb
On Thu, Jul 19, 2012 at 6:06 PM, Kohei KaiGai 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 "returned with feedbac
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 transac
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 me
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 a
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 PLy_traceback(
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, y
42 matches
Mail list logo
