On Tue, Apr 7, 2020 at 12:14 PM Thomas Munro wrote:
> On Sun, Apr 5, 2020 at 11:31 AM Thomas Munro wrote:
> > On Sun, Apr 5, 2020 at 10:34 AM Mark Dilger
> > wrote:
> > > The "xid8_" warts are partly motivated by having a type named "xid8",
> > > which is a bit of a wart in itself.
> >
> >
On 2020-Apr-17, Andres Freund wrote:
> Yes? But that type doesn't exist in isolation. Having yet another
> significantly different representation of 64bit xids (as plain 64 bit
> integers, and as some 32/32 epoch/xid split) would make an already
> confusing situation even more complex.
On the
Hi,
On 2020-04-17 14:07:07 -0400, Robert Haas wrote:
> On Fri, Apr 17, 2020 at 1:45 PM Andres Freund wrote:
> > You seem to be entirely disregarding my actual point, namely that
> > txid_current(), as well as some other txid_* functions, have returned
> > 64bit xids for many many years.
On Fri, Apr 17, 2020 at 1:45 PM Andres Freund wrote:
> You seem to be entirely disregarding my actual point, namely that
> txid_current(), as well as some other txid_* functions, have returned
> 64bit xids for many many years. txid_current() is the only function to
> get the current xid in a
Hi,
On 2020-04-17 13:33:53 -0400, Robert Haas wrote:
> On Thu, Apr 2, 2020 at 5:13 PM Andres Freund wrote:
> > Given that txid_current() "always" has been a plain 64 bit integer, and
> > the various txid_* functions always have returned 64 bit integers, I
> > really don't think arguing for some
On Thu, Apr 2, 2020 at 5:13 PM Andres Freund wrote:
> Given that txid_current() "always" has been a plain 64 bit integer, and
> the various txid_* functions always have returned 64 bit integers, I
> really don't think arguing for some 32bit/32bit situation now makes
> sense.
I'm not sure what
On Fri, Apr 17, 2020 at 3:44 AM Mark Dilger
wrote:
> Hmm, I should have spoken sooner...
>
> src/backend/replication/walsender.c:static bool
> TransactionIdInRecentPast(TransactionId xid, uint32 epoch);
> src/backend/utils/adt/xid8funcs.c:TransactionIdInRecentPast(FullTransactionId
> fxid,
> On Apr 6, 2020, at 5:14 PM, Thomas Munro wrote:
>
> On Sun, Apr 5, 2020 at 11:31 AM Thomas Munro wrote:
>> On Sun, Apr 5, 2020 at 10:34 AM Mark Dilger
>> wrote:
>>> The "xid8_" warts are partly motivated by having a type named "xid8", which
>>> is a bit of a wart in itself.
>>
>> Just a
On Sun, Apr 5, 2020 at 11:31 AM Thomas Munro wrote:
> On Sun, Apr 5, 2020 at 10:34 AM Mark Dilger
> wrote:
> > The "xid8_" warts are partly motivated by having a type named "xid8", which
> > is a bit of a wart in itself.
>
> Just a thought for the future, not sure if it's a good one: would it
>
On Sun, Apr 5, 2020 at 10:34 AM Mark Dilger
wrote:
> > On Apr 4, 2020, at 7:11 AM, Thomas Munro wrote:
> > However, I am getting cold feet about the new function names. The
> > existing naming structure made sense when all this stuff originated in
> > a contrib module with "txid_" as a prefix
> On Apr 4, 2020, at 7:11 AM, Thomas Munro wrote:
>
> On Sat, Apr 4, 2020 at 4:45 AM Mark Dilger
> wrote:
>> FYI, (not the responsibility of this patch), we never quite define what the
>> abbreviation "xip" stands for. If "Active xid8s at the time of the
>> snapshot." were rewritten as
> On Apr 2, 2020, at 7:39 PM, Thomas Munro wrote:
>
>
These apply cleanly, build and pass check-world on mac, and the documentation
and regression test changes surrounding txid look good to me.
FYI, (not the responsibility of this patch), we never quite define what the
abbreviation "xip"
Hi,
On 2020-04-02 14:26:41 -0700, Mark Dilger wrote:
> Since Thomas's patch is really just focused on transitioning from txid
> -> xid8, I think this conversation is a bit beyond scope for this
> patch, except that "xid8" sounds an awful lot like the new type that
> all user facing xid output
> On Apr 2, 2020, at 2:13 PM, Andres Freund wrote:
>
> Hi,
>
> On 2020-04-02 11:47:32 -0700, Mark Dilger wrote:
>> I agree with transitioning to 64-bit xids with 32 bit xid/epoch pairs
>> as an internal implementation and storage detail only, but we still
>> have user facing views that don't
Hi,
On 2020-04-02 11:47:32 -0700, Mark Dilger wrote:
> I agree with transitioning to 64-bit xids with 32 bit xid/epoch pairs
> as an internal implementation and storage detail only, but we still
> have user facing views that don't treat it that way.
Note that epochs are not really a thing
On Thu, Apr 2, 2020 at 2:47 PM Mark Dilger wrote:
>
>
>
> > On Apr 2, 2020, at 11:01 AM, Andres Freund wrote:
> >
> >>
> >> Hmm, for some reason I had it in my head that we would make these use an
> >> "epoch/val" output format rather than raw uint64 values.
> >
> > Why would we do that? IMO the
Andres Freund writes:
> On 2020-04-02 14:33:18 -0300, Alvaro Herrera wrote:
>> Hmm, for some reason I had it in my head that we would make these use an
>> "epoch/val" output format rather than raw uint64 values.
> Why would we do that? IMO the goal should be to reduce awareness of the
>
> On Apr 2, 2020, at 11:01 AM, Andres Freund wrote:
>
>>
>> Hmm, for some reason I had it in my head that we would make these use an
>> "epoch/val" output format rather than raw uint64 values.
>
> Why would we do that? IMO the goal should be to reduce awareness of the
> 32bitness of normal
Hi,
On 2020-04-02 14:33:18 -0300, Alvaro Herrera wrote:
> On 2020-Apr-02, Thomas Munro wrote:
>
> > On Sat, Mar 21, 2020 at 11:14 AM Thomas Munro
> > wrote:
> > > * updated OIDs to avoid collisions
> > > * added btequalimage to btree/xid8_ops
> >
> > Here's the version I'm planning to commit
On 2020-Apr-02, Thomas Munro wrote:
> On Sat, Mar 21, 2020 at 11:14 AM Thomas Munro wrote:
> > * updated OIDs to avoid collisions
> > * added btequalimage to btree/xid8_ops
>
> Here's the version I'm planning to commit tomorrow, if no one objects.
> Changes:
>
> * txid.c renamed to
> On Apr 2, 2020, at 9:06 AM, Mark Dilger wrote:
>
> ("xid8_current" is not exercised by name anywhere in the regression suite,
> that I can see.)
I spoke too soon. That's exercised in the new xid.sql test file. It didn't
show up in my 'git diff', because it's new. Sorry about that.
—
> On Apr 1, 2020, at 8:21 PM, Thomas Munro wrote:
>
> On Sat, Mar 21, 2020 at 11:14 AM Thomas Munro wrote:
>> * updated OIDs to avoid collisions
>> * added btequalimage to btree/xid8_ops
>
> Here's the version I'm planning to commit tomorrow, if no one objects.
> Changes:
>
> * txid.c
On Sat, Mar 21, 2020 at 11:14 AM Thomas Munro wrote:
> * updated OIDs to avoid collisions
> * added btequalimage to btree/xid8_ops
Here's the version I'm planning to commit tomorrow, if no one objects. Changes:
* txid.c renamed to xid8funcs.c
* remaining traces of "txid" replaced various
On Fri, Feb 14, 2020 at 6:31 PM Thomas Munro wrote:
> On Wed, Jan 29, 2020 at 12:43 AM Fujii Masao
> wrote:
> > /*
> > - * do a TransactionId -> txid conversion for an XID near the given epoch
> > + * Do a TransactionId -> fxid conversion for an XID that is known to
> > precede
> > + * the
Hello Fujii-san,
Thanks for your review!
On Wed, Jan 29, 2020 at 12:43 AM Fujii Masao
wrote:
> Isn't it better to add also xid8lt, xid8gt, xid8le, and xid8ge?
xid doesn't have these operators, probably to avoid confusion about
wraparound. But you're right, we should add them for xid8,
On 2020/01/28 14:05, Thomas Munro wrote:
On Tue, Dec 3, 2019 at 6:56 AM Mark Dilger wrote:
On 11/30/19 5:14 PM, Thomas Munro wrote:
On Sun, Dec 1, 2019 at 12:22 PM Mark Dilger wrote:
These two patches (v3) no longer apply cleanly. Could you please
rebase?
Hi Mark,
Thanks. Here's v4.
On Tue, Dec 3, 2019 at 6:56 AM Mark Dilger wrote:
> On 11/30/19 5:14 PM, Thomas Munro wrote:
> > On Sun, Dec 1, 2019 at 12:22 PM Mark Dilger wrote:
> >> These two patches (v3) no longer apply cleanly. Could you please
> >> rebase?
> >
> > Hi Mark,
> > Thanks. Here's v4.
>
> Thanks, Thomas.
>
>
On 11/30/19 5:14 PM, Thomas Munro wrote:
On Sun, Dec 1, 2019 at 12:22 PM Mark Dilger wrote:
These two patches (v3) no longer apply cleanly. Could you please
rebase?
Hi Mark,
Thanks. Here's v4.
Thanks, Thomas.
The new patches apply cleanly and pass 'installcheck'.
--
Mark Dilger
On Sun, Dec 1, 2019 at 12:22 PM Mark Dilger wrote:
> These two patches (v3) no longer apply cleanly. Could you please
> rebase?
Hi Mark,
Thanks. Here's v4.
0001-Add-SQL-type-xid8-to-expose-FullTransactionId-to--v4.patch
Description: Binary data
On 11/3/19 2:43 PM, Thomas Munro wrote:
On Tue, Oct 29, 2019 at 5:23 PM btfujiitkp wrote:
Thomas Munro writes:
On Sun, Sep 1, 2019 at 5:04 PM Thomas Munro
wrote:
Adding to CF.
Rebased. An OID clashed so re-roll the dice. Also spotted a typo.
I have some questions in this code.
On Wed, Nov 20, 2019 at 5:43 PM imai.yoshik...@fujitsu.com
wrote:
> Is there any agreement we can throw the wraparound problem away if we adopt
> FullTransactionId?
Here is one argument for why 64 bits ought to be enough: we use 64 bit
LSNs for the WAL, and it usually takes more than one byte of
Hi Thomas,
Please let me ask something about wraparound problem.
+static FullTransactionId
+convert_xid(TransactionId xid, FullTransactionId next_fxid)
{
- uint64 epoch;
+ TransactionId next_xid = XidFromFullTransactionId(next_fxid);
+ uint32 epoch =
On Tue, Oct 29, 2019 at 5:23 PM btfujiitkp
wrote:
> Thomas Munro writes:
>> On Sun, Sep 1, 2019 at 5:04 PM Thomas Munro
>> wrote:
>>> Adding to CF.
>
>> Rebased. An OID clashed so re-roll the dice. Also spotted a typo.
>
I have some questions in this code.
Thanks for looking at the
On Tue, Oct 29, 2019 at 5:23 PM btfujiitkp wrote:
> > Thomas Munro writes:
> >> On Sun, Sep 1, 2019 at 5:04 PM Thomas Munro
> >> wrote:
> >>> Adding to CF.
> >
> >> Rebased. An OID clashed so re-roll the dice. Also spotted a typo.
> >
>
> I have some questions in this code.
Thanks for
Thomas Munro writes:
On Sun, Sep 1, 2019 at 5:04 PM Thomas Munro
wrote:
Adding to CF.
Rebased. An OID clashed so re-roll the dice. Also spotted a typo.
I have some questions in this code.
First,
"FullTransactionIdPrecedes(xmax, val)" is not equal to "val >= xmax" of
the previous
Thomas Munro writes:
> On Sun, Sep 1, 2019 at 5:04 PM Thomas Munro wrote:
>> Adding to CF.
> Rebased. An OID clashed so re-roll the dice. Also spotted a typo.
FWIW, I'd move *all* the OIDs added by this patch up to >= 8000.
I don't feel a strong need to fill in the gaps in the low-numbered
On Sun, Sep 1, 2019 at 5:04 PM Thomas Munro wrote:
> Adding to CF.
Rebased. An OID clashed so re-roll the dice. Also spotted a typo.
--
Thomas Munro
https://enterprisedb.com
0001-Add-SQL-type-xid8-to-expose-FullTransactionId-to--v2.patch
Description: Binary data
On Fri, Aug 2, 2019 at 10:42 PM Thomas Munro wrote:
> On Thu, Jul 25, 2019 at 1:11 PM Thomas Munro wrote:
> > On Thu, Jul 25, 2019 at 12:42 PM Tom Lane wrote:
> > > Andres Freund writes:
> > > > On 2019-07-24 20:34:39 -0400, Tom Lane wrote:
> > > >> Yeah, I would absolutely NOT recommend that
On Thu, Jul 25, 2019 at 1:11 PM Thomas Munro wrote:
> On Thu, Jul 25, 2019 at 12:42 PM Tom Lane wrote:
> > Andres Freund writes:
> > > On 2019-07-24 20:34:39 -0400, Tom Lane wrote:
> > >> Yeah, I would absolutely NOT recommend that you open that can of worms
> > >> right now. We have looked at
On Thu, Jul 25, 2019 at 12:42 PM Tom Lane wrote:
> Andres Freund writes:
> > On 2019-07-24 20:34:39 -0400, Tom Lane wrote:
> >> Yeah, I would absolutely NOT recommend that you open that can of worms
> >> right now. We have looked at adding unsigned integer types in the past
> >> and it looked
Andres Freund writes:
> On 2019-07-24 20:34:39 -0400, Tom Lane wrote:
>> Yeah, I would absolutely NOT recommend that you open that can of worms
>> right now. We have looked at adding unsigned integer types in the past
>> and it looked like a mess.
> I assume Thomas was thinking more of another
Hi,
On 2019-07-24 20:34:39 -0400, Tom Lane wrote:
> Yeah, I would absolutely NOT recommend that you open that can of worms
> right now. We have looked at adding unsigned integer types in the past
> and it looked like a mess.
I assume Thomas was thinking more of another bespoke type like xid,
Andres Freund writes:
> On 2019-07-25 12:20:58 +1200, Thomas Munro wrote:
>> On Thu, Jul 25, 2019 at 12:06 PM Andres Freund wrote:
>>> Seems easiest to just add xid_current(), or add a cast from int8 to xid
>>> (probably explicit?) that handles the wraparound logic correctly?
>> Yeah, I was
Hi,
On 2019-07-25 12:20:58 +1200, Thomas Munro wrote:
> On Thu, Jul 25, 2019 at 12:06 PM Andres Freund wrote:
> > we have txid_current(), which returns an int8. But there's no convenient
> > way to convert that to type 'xid'. Which is fairly inconvenient, given
> > that we expose xids in various
On Thu, Jul 25, 2019 at 12:06 PM Andres Freund wrote:
> we have txid_current(), which returns an int8. But there's no convenient
> way to convert that to type 'xid'. Which is fairly inconvenient, given
> that we expose xids in various places.
>
> My current need for this was just a regression
Hi,
we have txid_current(), which returns an int8. But there's no convenient
way to convert that to type 'xid'. Which is fairly inconvenient, given
that we expose xids in various places.
My current need for this was just a regression test to make sure that
system columns (xmin/xmax in
46 matches
Mail list logo
