Marko Tiikkaja 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 new
>> snap between orig
On 2011-02-28 9:36 PM, Tom Lane wrote:
Marko Tiikkaja 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) tha
Marko Tiikkaja 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
> execution and SQL funct
On 2011-02-28 9:03 PM, Tom Lane wrote:
Marko Tiikkaja 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
On Mon, Feb 28, 2011 at 2:01 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Feb 28, 2011 at 1:45 PM, Tom Lane 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 w
Marko Tiikkaja 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 between normal executi
Robert Haas writes:
> On Mon, Feb 28, 2011 at 1:45 PM, Tom Lane 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 handling than the regular
> execut
On 2011-02-28 8:22 PM, Tom Lane wrote:
Marko Tiikkaja 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_
On Mon, Feb 28, 2011 at 1:45 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Feb 28, 2011 at 1:22 PM, Tom Lane 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 c
Robert Haas writes:
> On Mon, Feb 28, 2011 at 1:22 PM, Tom Lane 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 around:
Quite :-(. But I'm not sur
On Mon, Feb 28, 2011 at 1:22 PM, Tom Lane wrote:
> Marko Tiikkaja 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 t
Marko Tiikkaja 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 and related
functions exporte
Robert Haas 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.
regards,
On Thu, Feb 24, 2011 at 11:02 AM, Tom Lane wrote:
> Marko Tiikkaja 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
Marko Tiikkaja 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 get bug reports
>> abo
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 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
> DML WITHs.
Oh, did we
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 co
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 talki
Alvaro Herrera 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 doing that. Do you rea
On 2011-02-24 2:31 AM, Tom Lane wrote:
Marko Tiikkaja 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 CommandCounter
Excerpts from Tom Lane's message of mié feb 23 19:39:23 -0300 2011:
> Alvaro Herrera 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:
> >
> >>
> >> Here's the patch rebased against the master. No code c
Marko Tiikkaja 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
between successive DML WIT
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 subscri
Alvaro Herrera 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:
>
>>
>> Here's the patch rebased against the master. No code changes since the
>> last patch I sent.
> Having a look at this.
My recollect
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:
> >
>
> Here's the patch rebased against the master. No code changes since the
> last patch I sent.
Having a look at this.
--
Álvaro Herrera
The PostgreSQL Company
On Wed, Oct 20, 2010 at 6:15 PM, Tom Lane wrote:
> Alvaro Herrera 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
On 2010-10-21 3:32 PM +0200, Marko Tiikkaja wrote:
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 fmgr_sql_validator(
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 sna
Alvaro Herrera 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, pg_plan_queries, pg_rewrite_query, a
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 b
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 d
Excerpts from Tom Lane's message of mar oct 12 20:49:28 -0300 2010:
> Marko Tiikkaja 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.
>
> >
Marko Tiikkaja 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 delete the call. The only
On 2010-10-13 2:10 AM +0300, Tom Lane wrote:
Marko Tiikkaja 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 PushUpdatedSnapshot)/PopActiveSnapshot rounds
before popping
Marko Tiikkaja 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 I understand
> it, our
On 2010-10-13 1:21 AM +0300, Tom Lane wrote:
Marko Tiikkaja 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 h
Marko Tiikkaja 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 all?). ISTM either these are
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 duplica
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 places
On 2010-10-04 5:31 PM +0300, Tom Lane wrote:
Marko Tiikkaja 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 third party modules
needlessly i
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
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 'fmgr_sql
Marko Tiikkaja 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 party index access meth
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 a
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
R
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
