Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
[ latest version of snapshot-taking patch ]
I started to look at this, and find myself fairly confused as to what
the purpose is anymore. Reviewing the thread, there has been a lot of
discussion of refactoring the API of pg_parse_and_rewrite
On Mon, Feb 28, 2011 at 1:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
[ latest version of snapshot-taking patch ]
I started to look at this, and find myself fairly confused as to what
the purpose is anymore. Reviewing the thread, there has
Robert Haas robertmh...@gmail.com writes:
On Mon, Feb 28, 2011 at 1:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
So: exactly what is the intended behavioral change as of now, and what
is the argument supporting that change?
IIUC, this is the result of countless rounds of communal bikeshedding
On Mon, Feb 28, 2011 at 1:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Feb 28, 2011 at 1:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
So: exactly what is the intended behavioral change as of now, and what
is the argument supporting that change?
On 2011-02-28 8:22 PM, Tom Lane wrote:
Marko Tiikkajamarko.tiikk...@cs.helsinki.fi writes:
[ latest version of snapshot-taking patch ]
I started to look at this, and find myself fairly confused as to what
the purpose is anymore. Reviewing the thread, there has been a lot of
discussion of
Robert Haas robertmh...@gmail.com writes:
On Mon, Feb 28, 2011 at 1:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm afraid that the goals of this patch might be similarly obsolete.
No, I don't think so. IIUC, the problem is that EXPLAIN ANALYZE runs
the rewrite products with different snapshot
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 2011-02-28 8:22 PM, Tom Lane wrote:
So: exactly what is the intended behavioral change as of now, and what
is the argument supporting that change?
The only intended change is what I was wondering in the original post:
snapshot handling
On Mon, Feb 28, 2011 at 2:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Feb 28, 2011 at 1:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm afraid that the goals of this patch might be similarly obsolete.
No, I don't think so. IIUC, the problem is
On 2011-02-28 9:03 PM, Tom Lane wrote:
Marko Tiikkajamarko.tiikk...@cs.helsinki.fi writes:
On 2011-02-28 8:22 PM, Tom Lane wrote:
So: exactly what is the intended behavioral change as of now, and what
is the argument supporting that change?
The only intended change is what I was wondering
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 2011-02-28 9:03 PM, Tom Lane wrote:
OK, and which behavior is getting changed, to what? I am not interested
in trying to reverse-engineer a specification from the patch.
My recollection is (and the archives seem to agree) that normal
On 2011-02-28 9:36 PM, Tom Lane wrote:
Marko Tiikkajamarko.tiikk...@cs.helsinki.fi writes:
On 2011-02-28 9:03 PM, Tom Lane wrote:
OK, and which behavior is getting changed, to what? I am not interested
in trying to reverse-engineer a specification from the patch.
My recollection is (and
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 2011-02-28 9:36 PM, Tom Lane wrote:
OK, so the intent is that in all cases, we just advance CID and don't
take a new snapshot between queries that were generated (by rule
expansion) from a single original parsetree? But we still take a
On Thu, Feb 24, 2011 at 11:02 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 2011-02-24 5:21 PM, Tom Lane wrote:
Oh, did we decide to do it that way? OK with me, but the submitted docs
are woefully inadequate on the point. This behavior is
Robert Haas robertmh...@gmail.com writes:
Tom/Alvaro, have the two of you hammered out who is going to finish
this one off? I *believe* Alvaro told me on IM that he was leaving
this one for Tom.
Last I heard, the ball was in my court. I'll try to get it done over
the weekend.
Excerpts from Alvaro Herrera's message of mié feb 23 21:35:13 -0300 2011:
Excerpts from Tom Lane's message of mié feb 23 19:39:23 -0300 2011:
My recollection is that this was pretty tightly coupled to the wCTE
patch. I had been intending to review them together, and have just
now come up
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 2011-02-24 2:31 AM, Tom Lane wrote:
The connection is the question of where to do CommandCounterIncrement
between successive DML WITH operations in a single command.
.. what? We decided *not* to do any CommandCounterIncrements between
On 2011-02-24 5:21 PM, Tom Lane wrote:
Oh, did we decide to do it that way? OK with me, but the submitted docs
are woefully inadequate on the point. This behavior is going to have to
be explained extremely clearly (and even so, I bet we'll get bug reports
about it :-().
I'm ready to put more
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 2011-02-24 5:21 PM, Tom Lane wrote:
Oh, did we decide to do it that way? OK with me, but the submitted docs
are woefully inadequate on the point. This behavior is going to have to
be explained extremely clearly (and even so, I bet we'll
Excerpts from Marko Tiikkaja's message of sáb ene 15 17:30:14 -0300 2011:
On 2010-10-21 3:32 PM +0200, Marko Tiikkaja wrote:
patch
Here's the patch rebased against the master. No code changes since the
last patch I sent.
Having a look at this.
--
Álvaro Herrera
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Marko Tiikkaja's message of sáb ene 15 17:30:14 -0300 2011:
On 2010-10-21 3:32 PM +0200, Marko Tiikkaja wrote:
patch
Here's the patch rebased against the master. No code changes since the
last patch I sent.
Having a look
On 2011-02-24 12:39 AM, Tom Lane wrote:
My recollection is that this was pretty tightly coupled to the wCTE
patch.
It was, but isn't anymore. Now it's just a bugfix.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 2011-02-24 12:39 AM, Tom Lane wrote:
My recollection is that this was pretty tightly coupled to the wCTE
patch.
It was, but isn't anymore. Now it's just a bugfix.
The connection is the question of where to do CommandCounterIncrement
Excerpts from Tom Lane's message of mié feb 23 19:39:23 -0300 2011:
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Marko Tiikkaja's message of sáb ene 15 17:30:14 -0300 2011:
On 2010-10-21 3:32 PM +0200, Marko Tiikkaja wrote:
patch
Here's the patch rebased against the
On 2011-02-24 2:31 AM, Tom Lane wrote:
Marko Tiikkajamarko.tiikk...@cs.helsinki.fi writes:
On 2011-02-24 12:39 AM, Tom Lane wrote:
My recollection is that this was pretty tightly coupled to the wCTE
patch.
It was, but isn't anymore. Now it's just a bugfix.
The connection is the question
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Tom Lane's message of mié feb 23 19:39:23 -0300 2011:
My recollection is that this was pretty tightly coupled to the wCTE
patch. I had been intending to review them together, and have just
now come up for air enough to start
On 2011-02-24 2:35 AM, Alvaro Herrera wrote:
There was some restructuring in code in postgres.c to be
done near this patch, which wasn't attacked at all by Marko AFAICS.
Maybe I should be looking at that instead.
I don't feel at all comfortable doing the restructuring you guys have
been
On Wed, Oct 20, 2010 at 6:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
It strikes me that if we really want to restructure things to divide
client interaction from other query-processing routines, we should
create another file, say
On 2010-10-21 3:32 PM +0200, Marko Tiikkaja wrote:
patch
Here's the patch rebased against the master. No code changes since the
last patch I sent.
Regards,
Marko Tiikkaja
*** a/src/backend/catalog/pg_proc.c
--- b/src/backend/catalog/pg_proc.c
***
*** 759,765
Hi,
Here's an updated patch.
I'm still not too fond of the logic in spi.c, but I can't see a better
way to do this. If someone sees a better way, I'm not going to object.
I also made some changes to the SQL functions now that we have a
different API. The previous code pushed and popped
Excerpts from Tom Lane's message of lun oct 04 10:31:26 -0400 2010:
In the particular case at hand here, I rather wonder why SQL functions
are depending on postgres.c at all. It might be better to just
duplicate a bit of code to make them independent. pg_parse_and_rewrite
would then be dead
Excerpts from Alvaro Herrera's message of mié oct 20 16:33:12 -0300 2010:
The only quarrel I have with this code shuffling is that
pg_rewrite_query is being called from exec_parse_message. Since it's
now a static function, it would have to stop being static so that it can
be called from both
Alvaro Herrera alvhe...@commandprompt.com writes:
It strikes me that if we really want to restructure things to divide
client interaction from other query-processing routines, we should
create another file, say src/backend/tcop/queries.c; this would have
stuff like pg_plan_query,
Excerpts from Tom Lane's message of mar oct 12 20:49:28 -0300 2010:
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 2010-10-13 2:10 AM +0300, Tom Lane wrote:
BTW, this patch seems to be also the time to remove the AtStart_Cache()
call in CommandCounterIncrement, as foreseen in the
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
Here's a new version of the patch, deprecating pg_parse_and_rewrite.
I started looking at this patch, and I'm wondering why you inserted all
the Register/UnregisterSnapshot calls that weren't there before (eg, why
did spi.c have to change at
On 2010-10-13 1:21 AM +0300, Tom Lane wrote:
Marko Tiikkajamarko.tiikk...@cs.helsinki.fi writes:
Here's a new version of the patch, deprecating pg_parse_and_rewrite.
I started looking at this patch, and I'm wondering why you inserted all
the Register/UnregisterSnapshot calls that weren't
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 2010-10-13 1:21 AM +0300, Tom Lane wrote:
I started looking at this patch, and I'm wondering why you inserted all
the Register/UnregisterSnapshot calls that weren't there before
That's actually just my ignorance I forgot to mention. As
On 2010-10-13 2:10 AM +0300, Tom Lane wrote:
Marko Tiikkajamarko.tiikk...@cs.helsinki.fi writes:
That's actually just my ignorance I forgot to mention. As I understand
it, our code currently first pushes one snapshot and then does multiple
PushActiveSnapshot (or
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 2010-10-13 2:10 AM +0300, Tom Lane wrote:
BTW, this patch seems to be also the time to remove the AtStart_Cache()
call in CommandCounterIncrement, as foreseen in the comment there.
Frankly, I have no idea what to do about this.
Just
On Sun, 10 Oct 2010, Marko Tiikkaja wrote:
On 2010-10-07 5:21 AM +0300, Steve Singer wrote:
Since no one else has proposed a better idea and the commit fest is ticking
away I think you should go ahead and do that.
Here's a new version of the patch, deprecating pg_parse_and_rewrite.
I
On 2010-10-07 5:21 AM +0300, Steve Singer wrote:
Since no one else has proposed a better idea and the commit fest is ticking
away I think you should go ahead and do that.
Here's a new version of the patch, deprecating pg_parse_and_rewrite.
I duplicated the parse/rewrite logic in the two
On 2010-10-04 5:31 PM +0300, Tom Lane wrote:
Marko Tiikkajamarko.tiikk...@cs.helsinki.fi writes:
Nope. I think I grepped contrib/ at some point and none of those were
using pg_parse_and_rewrite() so this is all just speculation. And yes,
it's not really part of any stable API but breaking
On Mon, 4 Oct 2010, Marko Tiikkaja wrote:
the patch does, modules start behaving weirdly. So what I'm suggesting is:
- Deprecate pg_parse_and_rewrite(). I have no idea how the project
has done this in the past, but grepping the source code for
deprecated suggests that we just remove
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 2010-10-04 6:19 AM, Steve Singer wrote:
Is there any third party code in particular that your thinking of? I don't
see anything that says pg_parse_and_rewrite is part of a stable server
side API (in contrast to SPI or something an third
On 2010-10-04 6:19 AM, Steve Singer wrote:
I also noticed that functions.c is now generating a warning that should be
easy to clean up.
functions.c: In function 'sql_exec_error_callback':
functions.c:989: warning: 'es' may be used uninitialized in this function
functions.c: In function
On 2010-10-03 5:08 AM +0300, Steve Singer wrote:
The patch applies against master (a13f12b3a18da0a61571cb134fdecea03a10d6f)
However initdb fails with:
FATAL: return type mismatch in function declared to return record
DETAIL: Function's final statement must be SELECT or INSERT/UPDATE/DELETE
On Mon, 4 Oct 2010, Marko Tiikkaja wrote:
On 2010-10-03 5:08 AM +0300, Steve Singer wrote:
Hmm.. I can't reproduce this. What platform are you on?
Sorry, I it seems the changes to one file (pg_proc.c) didn't get applied to
my source repository. Now that I've applied them initdb works
This is my review on the Fix snapshot taking inconsistencies patch.
The patch applies against master (a13f12b3a18da0a61571cb134fdecea03a10d6f)
However initdb fails with:
FATAL: return type mismatch in function declared to return record
DETAIL: Function's final statement must be SELECT or
47 matches
Mail list logo
