Alvaro Herrera wrote:
> Kevin Grittner wrote:
> TRUNCATE triggers shouldn't have delta relations, that's for
> sure, or it'd completely negate the point of TRUNCATE triggers.
> I don't think we have any other event, do we? People who get
> delta relations for deleting all rows should be using DE
On Wed, Jun 18, 2014 at 04:41:30PM -0400, Robert Haas wrote:
> On Wed, Jun 18, 2014 at 3:53 PM, Josh Berkus wrote:
> > On 06/18/2014 12:32 PM, Tom Lane wrote:
> >> Josh Berkus writes:
> >>> There are plenty of badly-written applications which "auto-begin", that
> >>> is, they issue a "BEGIN;" im
Robert Haas wrote:
> Kevin Grittner wrote:
> Can you describe what the standard syntax for the row variables
> is, as opposed to our syntax? Also, what's the standard syntax
> for the the transition relations?
If you want either (or both), the standard has you using a
REFERENCING clause right
On Wed, Jun 18, 2014 at 4:48 AM, Stephen Frost wrote:
> I'm fine with having these start out as external tools which are doing
> checks, but I've been specifically asked about (and have desired myself
> from time-to-time...) an in-core capability to check index/heap/etc
> validity. Folks coming f
David Fetter wrote:
> Robert Haas wrote:
>> Kevin Grittner wrote:
> The good:
> - Generating the tuplestores. Yay!
Thanks for that. ;-)
> The bad:
> - Generating them exactly and only for AFTER triggers
The standard only allows them for AFTER triggers, and I'm not sure
what the sema
On 06/02/2014 11:38 AM, Andrew Dunstan wrote:
On 06/02/2014 10:22 AM, Andrew Dunstan wrote:
On 06/02/2014 10:02 AM, Robert Haas wrote:
On Thu, May 29, 2014 at 7:34 AM, Dmitry Dolgov
<9erthali...@gmail.com> wrote:
I'm little confused by the convertJsonbValue functon at jsonb_utils.c
Maybe I
On 06/18/2014 02:52 PM, Bruce Momjian wrote:
> On Wed, Jun 18, 2014 at 04:41:30PM -0400, Robert Haas wrote:
>> The only problem I see is that it makes the semantics kind of weird
>> and confusing. "Kill connections that are idle in transaction for too
>> long" is a pretty clear spec; "kill connect
On 2014-06-19 1:46 AM, Josh Berkus wrote:
Robert's right, not killing the "BEGIN;" only transactions is liable to
result in user confusion unless we label those sessions differently in
pg_stat_activity.
Wouldn't they be labeled differently already? i.e. the last query would
be "BEGIN". Unles
On 06/18/2014 04:54 PM, Marko Tiikkaja wrote:
> On 2014-06-19 1:46 AM, Josh Berkus wrote:
>> Robert's right, not killing the "BEGIN;" only transactions is liable to
>> result in user confusion unless we label those sessions differently in
>> pg_stat_activity.
>
> Wouldn't they be labeled different
Gurjeet Singh writes:
> On Tue, Jun 10, 2014 at 12:05 PM, Tom Lane wrote:
>> If we're going to do this, I would say that we should also take the
>> opportunity to get out from under the question of which kernel API
>> we're dealing with. So perhaps a design like this:
>>
>> 1. If the environmen
Josh Berkus writes:
> Counter-argument: most app frameworks which do an automatic BEGIN; also
> do other stuff like SET TIMEZONE each time as well. Is this really a
> case worth worrying about?
SET TIMEZONE doesn't result in taking a snapshot either.
regards, tom lane
On Wed, Jun 18, 2014 at 8:01 PM, Josh Berkus [via PostgreSQL] <
ml-node+s1045698n5807868...@n5.nabble.com> wrote:
> On 06/18/2014 04:54 PM, Marko Tiikkaja wrote:
> > On 2014-06-19 1:46 AM, Josh Berkus wrote:
> >> Robert's right, not killing the "BEGIN;" only transactions is liable to
> >> result i
On 06/19/2014 01:50 AM, Shreesha wrote:
> However in my case, I don't know why there wasn't a default database
> with name 'root' got created or why the server rejects the client when
> it tries to connect to the default database.
Take a look at the initdb manual, the tutorial, and the
installat
I was going to answer each message, but Fabrízio summarized everything so
far really nicely. Thanks Fabrízio.
On Wed, Jun 18, 2014 at 5:25 PM, Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
> Then, to summarize Matheus must do:
> * use an option instead of change the syntax and catalog
Hi
I've just run into an index issue on 9.5 HEAD on a slave (master and slave
both compiled from 66802246e22d51858cd543877fcfddf24e6812f2); details
below (I have only found one index on the slave where the issue occurs so far).
The setup is admittedly slightly unusual; master is OS X 10.7.5, slave
I wrote:
> I do see growth in the per-query context as well. I'm not sure
> where that's coming from, but we probably should try to find out.
> A couple hundred bytes per iteration is going to add up, even if it's
> not as fast as 8K per iteration. I'm not sure it's dblink's fault,
> because I do
On Wed, Jun 18, 2014 at 03:30:34PM -0700, Kevin Grittner wrote:
> David Fetter wrote:
> > Robert Haas wrote:
> >> Kevin Grittner wrote:
>
> > The good:
> > - Generating the tuplestores. Yay!
>
> Thanks for that. ;-)
Sorry, I just can't resist references to Spaghetti Westerns.
https://en.
On Wed, Jun 18, 2014 at 6:54 PM, Ian Barwick wrote:
> I've just run into an index issue on 9.5 HEAD on a slave (master and slave
> both compiled from 66802246e22d51858cd543877fcfddf24e6812f2); details
> below (I have only found one index on the slave where the issue occurs so
> far).
Would you m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/18/2014 07:29 PM, Tom Lane wrote:
> I wrote:
>> I do see growth in the per-query context as well. I'm not sure
>> where that's coming from, but we probably should try to find
>> out. A couple hundred bytes per iteration is going to add up,
>> e
On 19/06/14 11:58, Peter Geoghegan wrote:
On Wed, Jun 18, 2014 at 6:54 PM, Ian Barwick wrote:
I've just run into an index issue on 9.5 HEAD on a slave (master and slave
both compiled from 66802246e22d51858cd543877fcfddf24e6812f2); details
below (I have only found one index on the slave where th
Joe Conway writes:
> On a side note, while perusing this section of code:
> 8<-- at dblink.c:1176 --
> /* make sure we have a persistent copy of the tupdesc */
> tupdesc = CreateTupleDescCopy(tupdesc);
> Shouldn't that CreateTupleDescCopy() happe
On Wed, Jun 18, 2014 at 8:09 PM, Ian Barwick wrote:
> Interesting, I'll take a look later.
I'm pretty suspicious of incompatibilities that may exist between the
two sets of OS collations involved here. We aren't very clear on the
extent to which what you're doing is supported, but it's certainly
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/18/2014 08:19 PM, Tom Lane wrote:
> Actually, I was wondering whether we couldn't remove that
> CreateTupleDescCopy call entirely.
Apparently not, at least without some additional surgery.
ExecMakeTableFunctionResult() tries to free the tuplede
On 19/06/14 12:30, Peter Geoghegan wrote:
On Wed, Jun 18, 2014 at 8:09 PM, Ian Barwick wrote:
Interesting, I'll take a look later.
I'm pretty suspicious of incompatibilities that may exist between the
two sets of OS collations involved here. We aren't very clear on the
extent to which what yo
Peter Geoghegan writes:
> On Wed, Jun 18, 2014 at 8:09 PM, Ian Barwick wrote:
>> Interesting, I'll take a look later.
> I'm pretty suspicious of incompatibilities that may exist between the
> two sets of OS collations involved here. We aren't very clear on the
> extent to which what you're doing
Joe Conway writes:
> On 06/18/2014 08:19 PM, Tom Lane wrote:
>> Actually, I was wondering whether we couldn't remove that
>> CreateTupleDescCopy call entirely.
> Apparently not, at least without some additional surgery.
> ExecMakeTableFunctionResult() tries to free the tupledesc and segfaults.
On Wed, Jun 18, 2014 at 8:35 PM, Tom Lane wrote:
>> Still, it should be possible to
>> determine if that's the problem using btreecheck.
>
> Does btreecheck attempt to verify that the sort ordering of the index
> matches the comparison behavior of the datatype? That would (in general)
> require c
Joe Conway writes:
> On 06/18/2014 07:29 PM, Tom Lane wrote:
>> With the attached patch on top of yours, I see no leak anymore.
> I can confirm that -- rock solid with 1 million iterations. I assume
> that should not be back-patched though?
Well, we usually think memory leaks are back-patchable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/18/2014 08:45 PM, Tom Lane wrote:
> Joe Conway writes:
>> On 06/18/2014 07:29 PM, Tom Lane wrote:
>>> With the attached patch on top of yours, I see no leak
>>> anymore.
>
>> I can confirm that -- rock solid with 1 million iterations. I
>> assu
On 19/06/14 12:35, Tom Lane wrote:
Peter Geoghegan writes:
On Wed, Jun 18, 2014 at 8:09 PM, Ian Barwick wrote:
Interesting, I'll take a look later.
I'm pretty suspicious of incompatibilities that may exist between the
two sets of OS collations involved here. We aren't very clear on the
e
David Fetter wrote:
> On Wed, Jun 18, 2014 at 03:30:34PM -0700, Kevin Grittner wrote:
>> the more I think about it (and discuss it) the more I'm
>> inclined to suffer the additional complexity of the standard
>> syntax for specifying transition relations in order to avoid
>> unnecessary overhead
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/18/2014 12:14 PM, Joe Conway wrote:
> On 06/18/2014 12:09 PM, Tom Lane wrote:
>> Joe Conway writes:
>>> I think the context deletion was missed in the first place
>>> because storeRow() is the wrong place to create the context.
>>> Rather than
On Wed, Jan 22, 2014 at 9:12 PM, Heikki Linnakangas
wrote:
> On 01/22/2014 03:39 AM, Tomas Vondra wrote:
>>
>> What annoys me a bit is the huge size difference between the index
>> updated incrementally (by a sequence of INSERT commands), and the index
>> rebuilt from scratch using VACUUM FULL. It
101 - 133 of 133 matches
Mail list logo
