From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Erik Rijkers <er(at)xs4all(dot)nl>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Changeset Extraction v7.6.1 |
Date: | 2014-02-24 14:48:26 |
Message-ID: | 20140224144826.GC6718@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2014-02-15 17:29:04 -0500, Robert Haas wrote:
> On Fri, Feb 14, 2014 at 4:55 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> + /*
> + * XXX: It's impolite to ignore our argument and keep decoding until the
> + * current position.
> + */
>
> Eh, what?
So, the background here is that I was thinking of allowing to specify a
limit for the number of returned rows. For the sql interface that sounds
like a good idea. I am just not so sure anymore that allowing to specify
a LSN as a limit is sufficient. Maybe simply allow to limit the number
of changes and check everytime a transaction has been replayed?
It's all trivial codewise, I am just wondering about the interface most
users would want.
> + * We misuse the original meaning of SnapshotData's xip and
> subxip fields
> + * to make the more fitting for our needs.
> [...]
> + * XXX: Do we want extra fields instead of misusing existing
> ones instead?
>
> If we're going to do this, then it surely needs to be documented in
> snapshot.h. On the second question, you're not the first hacker to
> want to abuse the meanings of the existing fields; SnapshotDirty
> already does it. It's tempting to think we need a more principled
> approach to this, like what we've done with Node i.e. typedef enum ...
> SnapshotType; and then a separate struct definition for each kind, all
> beginning with SnapshotType type.
Hm, essentially that's what the ->satisfies pointer already is, right?
There's already documentation of the extra fields in snapbuild, but I
understand you'd rather have them moved?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2014-02-24 15:02:28 | Re: often PREPARE can generate high load (and sometimes minutes long unavailability) |
Previous Message | Robert Haas | 2014-02-24 14:47:01 | Re: should we add a XLogRecPtr/LSN SQL type? |