I found one glitch with our merge of the original dup row fix. With that
corrected AND Alvaro’s Friday fix things are solid.
No dup’s. No index corruption.
Thanks so much.
On 10/10/17, 7:25 PM, "Michael Paquier" wrote:
On Tue, Oct 10, 2017 at 11:14 PM, Alvaro Herrera
wrote:
> I
I’m unclear on what is being repro’d in 9.6. Are you getting the duplicate
rows problem or just the reindex problem? Are you testing with asserts
enabled(I’m not)?
If you are getting the dup rows consider the code in the block in heapam.c that
starts with the comment “replace multi by update
9 AM, Wood, Dan wrote:
> Whatever you do make sure to also test 250 clients running lock.sql.
Even with the communities fix plus YiWen’s fix I can still get duplicate rows.
What works for “in-block” hot chains may not work when spanning blocks.
Interesting. Which version did you t
Whatever you do make sure to also test 250 clients running lock.sql. Even with
the communities fix plus YiWen’s fix I can still get duplicate rows. What
works for “in-block” hot chains may not work when spanning blocks.
Once nearly all 250 clients have done their updates and everybody is waiti
| 49155 | 36963 | 36961
7 | (0,7) | 8032 | 11010 | 32771 | 36961 | 0
(7 rows)
On 10/3/17, 6:20 PM, "Peter Geoghegan" wrote:
On Tue, Oct 3, 2017 at 6:09 PM, Wood, Dan wrote:
> I’ve just started looking at this again after a fe
I’ve just started looking at this again after a few weeks break.
There is a tangled web of issues here. With the community fix we get a
corrupted page(invalid redirect ptr from indexed item). The cause of that is:
pruneheap.c:
/*
* Check the tuple XMIN agai
gistration is now open at http://www.pgcon.org/2017/registration.php
<http://www.pgcon.org/2017/registration.php>
--
Dan Langille - BSDCan / PGCon
d...@langille.org <mailto:d...@langille.org>
If someone wanted to donate a SuperServer 6028TR-D72R
(http://www.supermicro.com/products/system/2U/6028/SYS-6028TR-D72R.cfm) to the
PostgreSQL project, would it be used?
--
Dan Langille - BSDCan / PGCon
d...@langille.org
7/papers.php>>
Instructions for submitting a proposal to PGCon 2017 are available
from: <http://www.pgcon.org/2017/submissions.php
<http://www.pgcon.org/2017/submissions.php>>
--
Dan Langille - BSDCan / PGCon
d...@langille.org <mailto:d...@langille.org>
Hello
There is one week left in the PGCon CFP. Details below. Please submit.
Thanks.
PGCon 2016 will be on 17-21 May 2016 at University of Ottawa.
* 17-18 (Tue-Wed) tutorials
* 19 & 20 (Thu-Fri) talks - the main part of the conference
* 17 & 21 (Wed & Sat) The Developer Unconference & the Us
In case you've overlooked it, you have about two weeks to submit your proposal.
PGCon 2016 will be on 17-21 May 2016 at University of Ottawa.
* 17-18 (Tue-Wed) tutorials
* 19 & 20 (Thu-Fri) talks - the main part of the conference
* 17 & 21 (Wed & Sat) The Developer Unconference & the User Unconfe
If there's anything I can try on my servers to help diagnose the issues,
please let me know. If desired, I can arrange access for debugging.
On Sat, Jun 6, 2015 at 12:51 AM, Thomas Munro wrote:
> On Sat, Jun 6, 2015 at 1:25 PM, Alvaro Herrera
> wrote:
> > Thomas Munro wrote:
> >
> >> My idea w
pgsql/data/pg_subtrans] # ls -l
total 1
-rw--- 1 pgsql pgsql 8192 Jun 5 19:04 0032
This not not a high throughput server.
—
Dan Langille
http://langille.org/
signature.asc
Description: Message signed with OpenPGP using GPGMail
> On May 27, 2015, at 12:06 PM, Alexander Korotkov
> wrote:
>
> On Wed, May 27, 2015 at 7:00 PM, Dan Langille <mailto:d...@langille.org>> wrote:
> Have you been to PGCon before? Do you remember the hacker lounge? Do you
> remember going there to work on stuff? D
Have you been to PGCon before? Do you remember the hacker lounge? Do you
remember going there to work on stuff? Do you recall anything about it?
—
Dan Langille
http://langille.org/
signature.asc
Description: Message signed with OpenPGP using GPGMail
want to be there. Don't leave it much longer.
—
Dan Langille
http://langille.org/
signature.asc
Description: Message signed with OpenPGP using GPGMail
week, but we felt that our
changes
were already disruptive and wanted to minimize the effects this late change may
have on people who have already booked travel / accommodation. To those
affected, we apologize and hope that this new structure will benefit everyone.
—
Dan Langille
ht
Today is your last day to submit your PGCon 2015 proposal.
--
Dan Langille
http://langille.org/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Is your PGCon 2015 submission going in today or tomorrow?
--
Dan Langille
http://langille.org/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
015/papers.php>
Instructions for submitting a proposal to PGCon 2015 are available
from: <http://www.pgcon.org/2015/submissions.php>
—
Dan Langille
http://langille.org/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
<http://www.pgcon.org/2015/submissions.php>
—
Dan Langille
http://langille.org/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Oct 29, 2014 at 7:17 AM, Alvaro Herrera
wrote:
> Dan Robinson wrote:
> > Hi all,
> >
> > If I'm reading correctly in src/backend/commands/tablecmds.c, it looks
> like
> > PostgreSQL does a full table scan in validateCheckConstraint and in the
&
rue already if you do the same with
enable_indexscan off, but that requires knowing that PostgreSQL is going to
do the seq scan no matter what.)
Would y'all be open to a patch that made this change?
Best,
-Dan
HEADS UP.
PGCon 2015 will be in June. That’s a few weeks later than in previous years.
—
Dan Langille
signature.asc
Description: Message signed with OpenPGP using GPGMail
<http://www.pgcon.org/2014/submissions.php>
--
Dan Langille - http://langille.org
signature.asc
Description: Message signed with OpenPGP using GPGMail
ransactions are (intentionally) not included in those checks. W1 is
therefore allowed to commit; the apparent serial order of execution is
W1 followed by W2, and the results of the aborted transaction R aren't
consistent with that.
Dan
--
Dan R. K. PortsUW CSE
will go out very close to the conference.
Do not submit lightning talks proposals until then.
See also <http://www.pgcon.org/2014/papers.php>
Instructions for submitting a proposal to PGCon 2014 are available
from: <http://www.pgcon.org/2014/submissions.php>
--
Dan Lan
gt; page-level lock, which would also create unnecessary conflicts.
Dan
--
Dan R. K. PortsUW CSEhttp://drkp.net/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ful thought is needed
here...
> It seems to me that a change such as you are now suggesting is
> likely to be too invasive to back-patch. Do you agree that it
> would make sense to apply the patch I have proposed, back to 9.1,
> and then consider any alternative as 9.4 material?
I agr
ALIZABLEXACTs and RWConflicts, the SerializableXidHash
table, the latest SxactCommitSeqno and SxactGlobalXmin, etc.
I'm trying to swap back in my notes about how to address this. It is
bound to be a substantial project, however.
Dan
--
Dan R. K. PortsUW CSE
now we've been upgrading things in the hope that the problem
will go away, but since we've got one server up to fbsd9.1/pg9.2.3 and
still seeing the problem we're a little stumped. Any ideas about how
we can go about debugging this would be appreciated.
Thanks,
Dan
On 13 March 2013 07
by developers and users of
PostgreSQL.
Be sure to submit your proposal soon because time is running out.
--
Dan Langille - http://langille.org
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
On Dec 11, 2012 9:28 PM, "David Gould" wrote:
>
> Thank you. I got the example via cut and paste from email and pasted it
> into psql on different hosts. od tells me it ends each line with:
>
> \n followed by 0xC2 0xA0 and then normal spaces. The C2A0 thing is
> apparently NO-BREAK SPACE. Invi
php>
Instructions for submitting a proposal to PGCon 2013 are available
from: <http://www.pgcon.org/2013/submissions.php>
--
Dan Langille - http://langille.org
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.po
Hi John:
On Sun, Sep 30, 2012 at 11:45 PM, john knightley
wrote:
> Dear Dan,
>
> thank you for your reply.
>
> The OS I am using is Ubuntu 12.04, with PostgreSQL 9.1.5 installed on
> a utf8 local
>
> A short 5 line dictionary file is sufficient to test:-
>
at indexing "search path"-the-concept is useful for
translations, and the Japanese translation includes an index (I
couldn't find the index for the French translation).
--
Dan Scott
Laurentian University
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
think they should
behave - and we could start building some test cases as a first step?
--
Dan Scott
Laurentian University
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
a specific file or directory beyond a
renaming event.
git blame will show you the commit that renamed the file, by default,
but then you can request the revision prior to that using the commit
hash || '^', for example. "git blame 2fb6cc90^ --
src/backend/parser/gram.y" to work
transactions to execute concurrently!)
What I was getting at in my previous mail was that there aren't any
situations where COMMIT will return a serialization failure for
a read-only transaction.
Dan
--
Dan R. K. PortsUW CSEhttp://drkp.net/
--
Sent via pg
I ran across a minor typo while reviewing the full-text search
documentation. Attached is a patch to address the one usage of "lexems"
in a sea of "lexemes".
diff --git a/doc/src/sgml/textsearch.sgml b/doc/src/sgml/textsearch.sgml
new file mode 100644
index 978aa54..5305198
*** a/doc/src/sgml/text
instead of COMMIT, T2
would be allowed to proceed.
Dan
--
Dan R. K. PortsUW CSEhttp://drkp.net/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
This is a bit of a corner case in all honesty, but if you have a short
table (under 20 rows), the 10% heuristic used that decides whether
distinct values scale with the row count will result in rather odd
values for stadistinct in pg_statistic, such as '-0.2' or '-0.67',
rather than the expecte
;t right either -- they may not be serializable, but that
isn't the reason why.
I don't particularly object to the warning that "the tests in this
routine are correct" (although indeed the fact that they've changed
over the years does seem to belie it).
So I
turb a comment just before its 19th birthday, the
bit about two-phase locking and serializability hasn't been correct
since around 1999 (when MVCC was added). :-)
Dan
--
Dan R. K. Ports MIT CSAILhttp://drkp.net/
--
Sent via pgsql-hackers mailing list (pgsql-hack
block
device would do the trick of flushing the disk cache.
Dan
- Original Message -
From: "Andres Freund"
To: pgsql-hackers@postgresql.org
Cc: "Dan Scales"
Sent: Monday, February 27, 2012 12:43:49 PM
Subject: Re: [HACKERS] possible new option for wal_sync_method
Hi,
options for ext3. I don't think that I have seen a
significant different when the DBT2 workload for ext3 option
data=ordered.
I will measure all these numbers again tonight, but with barrier=0, so as
to try to confirm that the write flush itself isn't costing a lot for
this configuratio
nterest in this change, or comments on its
usefulness/correctness? It would be just an extra option for
wal_sync_method that users can try out and has benefits for certain
configurations.
Dan
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 266c0de..a830a01 1
On Tue, Feb 14, 2012 at 09:27:58AM -0600, Kevin Grittner wrote:
> Heikki Linnakangas wrote:
> > On 14.02.2012 04:57, Dan Ports wrote:
> >> The easiest answer would be to just treat every prepared
> >> transaction found during recovery as though it had a conflict in
>
gy if we wanted to go
that route. I hadn't really considered it because I'm not that familiar
with the xlog code (plus, the commit record already contains a variable
length field, making it that much more difficult to add another).
Dan
--
Dan R. K. Ports MIT CSAIL
one we could plausibly backpatch
to 9.1. But if the extra aborts after recovery seem too expensive, we
may want to consider one of the other options for future releases.
Dan
--
Dan R. K. Ports MIT CSAILhttp://drkp.net/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
hat the combination of that code and this
patch would ensure full serializability for TRUNCATE operations.
Dan
--
Dan R. K. Ports MIT CSAILhttp://drkp.net/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
gh. I did write the code so that any process
can write a completed batch if the batch is not currently being flushed (so as
to deal with crashes by backends). Having the backends flush the batches as
they fill them up was just simpler for a first prototype.
Dan
- Original Message -----
Fro
f double writes were in use, they might be
automatically switched over to full page writes for the duration of the base
backup. And the double write file should not be part of the base backup.
Dan
- Original Message -
From: "Fujii Masao"
To: "Dan Scales"
Cc: &qu
the double-write files can be stored on.
Thanks,
Dan
- Original Message -
From: "Robert Haas"
To: "Dan Scales"
Cc: "PG Hackers"
Sent: Friday, February 3, 2012 1:48:54 PM
Subject: Re: [HACKERS] double writes using "double-write buffer" app
more efficient.
Can you let me know what the shared_buffers and RAM sizes were for your pgbench
run? I can try running the same workload. If the size of shared_buffers is
especially small compared to RAM, then we should increase the size of
shared_buffers when using double_writes.
Thanks,
D
<http://www.pgcon.org/2012/papers.php>
Instructions for submitting a proposal to PGCon 2012 are available
from: <http://www.pgcon.org/2012/submissions.php>
--
Dan Langille - http://langille.org
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make cha
e checksum calculation
(PageSetVerificationInfo) to mdextend() (or preferably smgrextend()) as well?
Otherwise, you won't be checksumming a bunch of the new pages.
Dan
- Original Message -
From: "Robert Haas"
To: "Dan Scales"
Cc: "Noah Misch" , "Heikki
n 2012 are available
from: <http://www.pgcon.org/2012/submissions.php>
--
Dan Langille - http://langille.org
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
rue, right?
bufmgr.c, line 1914 - bufToWrite no longer exists. You could revert changes
from 1912-1920
localbuf.c, line 203 - as mentioned below, this comment is no longer
relevant, you are checksumming local buffers now
Dan
- Original Message -
From: "Noah Misch"
T
py to hear all comments/suggestions. Thanks,
Dan
- Original Message -----
From: "Dan Scales"
To: "Heikki Linnakangas"
Cc: "PG Hackers" , jks...@gmail.com, "David
Fetter"
Sent: Wednesday, January 11, 2012 1:25:21 PM
Subject: Re: [HACKERS] [WIP] Do
sions.php>
--
Dan Langille - http://langille.org
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
point on time, even with the double writes.
And just wanted to reiterate one other benefit of double writes -- it greatly
reduces the size of the WAL logs.
Thanks,
Dan
- Original Message -
From: "Heikki Linnakangas"
To: "David Fetter"
Cc: "PG Hackers" , jks
t I
also reworked some of the surrounding code to make it obvious that r/o
and r/w transactions are handled differently -- the existing code felt
a bit too clever.
Dan
--
Dan R. K. Ports MIT CSAILhttp://drkp.net/
>From 39f8462332f998d7363058adabac412c7654befe Mon Sep
_database). But it wouldn't hurt to keep it from pointlessly
registering a serializable transaction.
Dan
--
Dan R. K. Ports MIT CSAILhttp://drkp.net/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
ht
UUM on a large table can take a long
time, this could affect many concurrent transactions.
My one-liner fix for this was to set
DefaultXactIsoLevel = XACT_READ_COMMITTED;
in AutoVacWorkerMain.
Dan
--
Dan R. K. Ports MIT CSAILhttp://drkp.net/
--
Sent via pgsql-
give it a try
and see what it looks like, but if anyone has any thoughts, let me know.
Dan
--
Dan R. K. Ports MIT CSAILhttp://drkp.net/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Oct 20, 2011 at 07:33:59AM -0500, Kevin Grittner wrote:
> Dan Ports wrote:
> > The part that's harder is building the list of potential conflicts
> > that's used to identify safe snapshots for r/o transactions. That
> > (currently) has to happen
at them in the next couple days (with my
MacPorts hat on), unless someone beats me to it.
Dan
--
Dan R. K. Ports MIT CSAILhttp://drkp.net/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql
e one of them -- but I really want starting a
serializable xact to not take any exclusive locks.)
Dan
--
Dan R. K. Ports MIT CSAILhttp://drkp.net/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I'm also travelling for most of the next two
weeks and probably won't be able to do any serious hacking on it until
I'm back to the office.
Dan
--
Dan R. K. Ports MIT CSAILhttp://drkp.net/
--
Sent via pgsql-hackers mailing list (pgsql-hacker
the synchronized snapshots patch yet, so I can't (yet) offer
any suggestions about how to implement it.
> Which might
> be another good reason for changing predicate.c so that we don't hold
> the latter while taking a snapshot ...
It'd be great if we could do that, but
nk the best we can do here
is to acquire a lock in shared mode when registering a serializable
transaction and in exclusive mode when committing. (Which is what you'd
expect, I guess; it's the same story as ProcArrayLock, and for most of
the same reasons.) Obviously, we'll also wa
is with the
> latter, which seems like a harder problem.
No, not that I recall -- if SerializablePredicateLockListLock was on
the list of contended locks, it was pretty far down.
SerializableXactHashLock was the main bottleneck, and
SerializableXactFinishedListLock was a lesser but still signif
lure checks need to examine a node's
neighbors in the dependency graph.
Dan
--
Dan R. K. Ports MIT CSAILhttp://drkp.net/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ck might
become a scalability bottleneck.
Dan
--
Dan R. K. Ports MIT CSAILhttp://drkp.net/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Sep 23, 2011 at 2:49 PM, Robert Haas wrote:
> On Mon, Sep 19, 2011 at 4:36 PM, Dan McGee wrote:
>> [ patch ]
>
> I suppose it's Tom who really needs to comment on this, but I'm not
> too enthusiastic about this approach. Duplicating the Linux kernel
>
This attempts to be as simple as it gets while reducing function call
depth, and should be viewed as a proof of concept. It is also untested
as of now, but will try to do that and report back.
I'm hoping I followed the rabbit hole correctly and are correctly
comparing the right pointers to each ot
On Mon, Sep 19, 2011 at 3:11 PM, Dan McGee wrote:
> This is one way to prevent the kernel warning message without having to
> introduce a new constant. Scale the old oom_adj-style value the same way
> the kernel internally does it and use that instead if oom_score_adj is
> available
This is one way to prevent the kernel warning message without having to
introduce a new constant. Scale the old oom_adj-style value the same way
the kernel internally does it and use that instead if oom_score_adj is
available for writing.
Signed-off-by: Dan McGee
---
This addresses some of the
;t want to emit barriers in between on architectures where
it's not actually necessary. That argues for another operation that's
defined to be a barrier (mb) on the Alpha but a no-op elsewhere.
Certainly the Linux kernel found it useful to do so
(read_barrier_depends)
Alternatively, one might q
potential conflict
if so. We can also skip adding a doomed transaction to the list of
possible conflicts because we know it won't commit.
This is not really a related issue, but Kevin and I found it while
looking into this issue, and it was included in the patch we sent out.
Dan
--
a new victim if we think we want to abort a transaction with
that flag set).
prepareSeqNo is being used as a lower bound on the transaction's commit
sequence number. It's currently set at the same time as the PREPARED
flag, but it doesn't have to be.
Dan
--
Dan R. K. Ports MIT
by a flag. That only happens if "writer" has
previously called ReleasePredicateLocks.
Dan
--
Dan R. K. Ports MIT CSAILhttp://drkp.net/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e that doesn't. If the two steps are separated, that isn't true: two
transactions might get their commitSeqNos in one order and make them
visible in the other. We should be able to deal with that, but it will
make some of the commit ordering checks more complicated.
Dan
--
Dan R. K. Ports
ckly!
To partially toot my own horn but also show where a user like me
encountered this, after some packaging hacking, anyone running Arch
Linux should be able to do a pg_upgrade from here on out by installing
the postgresql-old-upgrade package
(http://www.archlinux.org/packages/extra/x86_64
nt to lock.
I am rather uneasy about making changes here unless we can be
absolutely certain they're right...
Dan
--
Dan R. K. Ports MIT CSAILhttp://drkp.net/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subsc
version, just
as the -B datadir has to be the correct version.
I'm not on the mailing list nor do I have a lot of free time to keep
up with normal development, but if there are quick things I can do to
get these patches in let me know.
-Dan
From 840bdd22b62c8d45796abf7eb9e7b3da0329dce8 Mon Sep
On Wed, Jun 22, 2011 at 01:31:11AM -0400, Dan Ports wrote:
> Yes, I suspect it can be done better. The reason it's tricky is a lock
> ordering issue; part of releasing a SerializableXact has to be done
> while holding SerializableXactHashLock and part has to be done without
&g
it was intended to
fail anyway, just with a different error. I didn't think too hard about
which error would take precedence.
Dan
--
Dan R. K. Ports MIT CSAILhttp://drkp.net/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e checking that flag is
cheaper than doing a hash lookup in the local predicate lock table
before bailing out.
Dan
--
Dan R. K. Ports MIT CSAILhttp://drkp.net/
diff --git a/src/backend/executor/nodeSeqscan.c b/src/backend/executor/nodeSeqscan.c
index f356874..32a8
On Tue, Jun 21, 2011 at 06:51:20PM -0400, Tom Lane wrote:
> I find this to be poor style, and would like to see if there's any
> support for getting rid of the "const" keywords.
I'm in favor of removing them too.
Dan
--
Dan R. K. Ports MIT CSAIL
tests actually hits this bug.
I removed the anomaly from the duplicate-gids test so that it fails in
the intended way, and added a new test to check serialization failures
with a prepared transaction.
Dan
--
Dan R. K. Ports MIT CSAILhttp://drkp.net/
diff --git a/src/bac
tation.
It seems like we do need that SXACT_FLAG_ROLLED_BACK after all, even
though it's only set for this brief interval. We need to be able to
distinguish a transaction that's just been marked for death (doomed)
from one that's already called ReleasePredicateLocks.
Dan
--
Dan R. K. Ports
On Fri, Jun 17, 2011 at 12:32:46AM -0400, Robert Haas wrote:
> Perhaps it would be best to remove the general item and replace it
> with a list of more specific things that need doing - which might just
> mean #5.
Done.
--
Dan R. K. Ports MIT CSAILhttp:/
) isn't an issue -- maybe we want to add a comment, someplace but
I'm not convinced even that is necessary
- (3) is a regression test, and is already on the list separately
- (5) is a doc issue only
There are no open issues with the code that I'm aware of.
Dan
--
Dan R.
.
> I don't see how there can be a ww-dependency between T0 and Tin. There
> can't be a rw-conflict because Tin is read-only, so surely there can't
> be a ww-conflict either?
Yes, it can only be a wr-conflict. Good catch.
Dan
--
Dan R. K. Ports MIT CSAIL
future tense, probably because they were written long ago), and
remove a couple items from the "R&D Issues" list that have since
been addressed.
Dan
--
Dan R. K. Ports MIT CSAILhttp://drkp.net/
diff --git a/src/backend/storage/lmgr/README-SSI
On Mon, Jun 13, 2011 at 03:33:24PM -0400, Tom Lane wrote:
> We can either change that now, or undo the
> unnecessary change in existing RM IDs. I vote for the latter.
Sounds good to me. I'd offer a patch, but it'd probably take you longer
to apply than to make the change yoursel
On Mon, Jun 13, 2011 at 10:22:19PM +0300, Heikki Linnakangas wrote:
> As far as I can tell it was for purely cosmetic reasons, to have lock
> and predicate lock lines together.
Yes, that is the only reason.
Dan
--
Dan R. K. Ports MIT CSAILhttp://dr
pointing to) is in
backend-local memory, so it won't change under us.
The volatile qualifier (as written) doesn't help with that anyway, it
attaches to the data being pointed to, not the pointer itself.
Dan
--
Dan R. K. Ports MIT CSAILhttp://drkp.net/
--
1 - 100 of 303 matches
Mail list logo
