Alvaro Herrera alvhe...@2ndquadrant.com 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
On Wed, Jun 18, 2014 at 04:41:30PM -0400, Robert Haas wrote:
On Wed, Jun 18, 2014 at 3:53 PM, Josh Berkus j...@agliodbs.com wrote:
On 06/18/2014 12:32 PM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
There are plenty of badly-written applications which auto-begin, that
is, they
Robert Haas robertmh...@gmail.com wrote:
Kevin Grittner kgri...@ymail.com 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
On Wed, Jun 18, 2014 at 4:48 AM, Stephen Frost sfr...@snowman.net 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.
David Fetter da...@fetter.org wrote:
Robert Haas wrote:
Kevin Grittner kgri...@ymail.com 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
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 connections that
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. Unless
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 differently
Gurjeet Singh gurj...@singh.im writes:
On Tue, Jun 10, 2014 at 12:05 PM, Tom Lane t...@sss.pgh.pa.us 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:
Josh Berkus j...@agliodbs.com 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.
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 in user
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
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 to
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,
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 don't
On Wed, Jun 18, 2014 at 03:30:34PM -0700, Kevin Grittner wrote:
David Fetter da...@fetter.org wrote:
Robert Haas wrote:
Kevin Grittner kgri...@ymail.com wrote:
The good:
- Generating the tuplestores. Yay!
Thanks for that. ;-)
Sorry, I just can't resist references to Spaghetti
On Wed, Jun 18, 2014 at 6:54 PM, Ian Barwick i...@2ndquadrant.com 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
-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,
even if
On 19/06/14 11:58, Peter Geoghegan wrote:
On Wed, Jun 18, 2014 at 6:54 PM, Ian Barwick i...@2ndquadrant.com 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
Joe Conway m...@joeconway.com 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
On Wed, Jun 18, 2014 at 8:09 PM, Ian Barwick i...@2ndquadrant.com 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,
-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
On 19/06/14 12:30, Peter Geoghegan wrote:
On Wed, Jun 18, 2014 at 8:09 PM, Ian Barwick i...@2ndquadrant.com 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
Peter Geoghegan p...@heroku.com writes:
On Wed, Jun 18, 2014 at 8:09 PM, Ian Barwick i...@2ndquadrant.com 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
Joe Conway m...@joeconway.com 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
On Wed, Jun 18, 2014 at 8:35 PM, Tom Lane t...@sss.pgh.pa.us 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)
Joe Conway m...@joeconway.com 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/18/2014 08:45 PM, Tom Lane wrote:
Joe Conway m...@joeconway.com 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
On 19/06/14 12:35, Tom Lane wrote:
Peter Geoghegan p...@heroku.com writes:
On Wed, Jun 18, 2014 at 8:09 PM, Ian Barwick i...@2ndquadrant.com 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
David Fetter da...@fetter.org 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
-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 m...@joeconway.com writes:
I think the context deletion was missed in the first place
because storeRow() is the wrong place to create the context.
On Wed, Jan 22, 2014 at 9:12 PM, Heikki Linnakangas
hlinnakan...@vmware.com 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
101 - 133 of 133 matches
Mail list logo
