>
>
> Please explain in detail your idea of how it will work.
>
>
OK. I will try to explain the abstract idea, i have.
a) Referential integrity gets violated, when there are referencing key
values, not present in the referenced key values. We are maintaining the
integrity by taking a Select for Sha
On Wed, Mar 7, 2012 at 10:18 AM, Gokulakannan Somasundaram
wrote:
>>
>> Insert, Update and Delete don't take locks they simply mark the tuples
>> they change with an xid. Anybody else wanting to "wait on the lock"
>> just waits on the xid. We do insert a lock row for each xid, but not
>> one per r
>
>
> Insert, Update and Delete don't take locks they simply mark the tuples
> they change with an xid. Anybody else wanting to "wait on the lock"
> just waits on the xid. We do insert a lock row for each xid, but not
> one per row changed.
>
I mean the foreign key checks here. They take a Select f
On Wed, Mar 7, 2012 at 9:24 AM, Gokulakannan Somasundaram
wrote:
> I feel sad, that i followed this topic very late. But i still want to put
> forward my views.
> Have we thought on the lines of how Robert has implemented relation level
> locks. In short it should go like this
>
> a) The locks for
I feel sad, that i followed this topic very late. But i still want to put
forward my views.
Have we thought on the lines of how Robert has implemented relation level
locks. In short it should go like this
a) The locks for enforcing Referential integrity should be taken only when
the rarest of the
On Tue, Mar 6, 2012 at 4:27 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of mar mar 06 18:10:16 -0300 2012:
>>
>> Preliminary comment:
>>
>> This README is very helpful.
>
> Thanks. I feel silly that I didn't write it earlier.
>
>> On Tue, Mar 6, 2012 at 2:39 PM, Alvaro Herrera
On Tue, Mar 6, 2012 at 9:10 PM, Robert Haas wrote:
> Preliminary comment:
>
> This README is very helpful.
>
> On Tue, Mar 6, 2012 at 2:39 PM, Alvaro Herrera
> wrote:
>> We provide four levels of tuple locking strength: SELECT FOR KEY UPDATE is
>> super-exclusive locking (used to delete tuples an
Excerpts from Robert Haas's message of mar mar 06 18:10:16 -0300 2012:
>
> Preliminary comment:
>
> This README is very helpful.
Thanks. I feel silly that I didn't write it earlier.
> On Tue, Mar 6, 2012 at 2:39 PM, Alvaro Herrera
> wrote:
> > We provide four levels of tuple locking strength
Preliminary comment:
This README is very helpful.
On Tue, Mar 6, 2012 at 2:39 PM, Alvaro Herrera
wrote:
> We provide four levels of tuple locking strength: SELECT FOR KEY UPDATE is
> super-exclusive locking (used to delete tuples and more generally to update
> tuples modifying the values of the
On Tue, Mar 6, 2012 at 7:39 PM, Alvaro Herrera
wrote:
> We provide four levels of tuple locking strength: SELECT FOR KEY UPDATE is
> super-exclusive locking (used to delete tuples and more generally to update
> tuples modifying the values of the columns that make up the key of the tuple);
> SELEC
On Mon, Mar 5, 2012 at 8:35 PM, Simon Riggs wrote:
>>> * Why do we need multixact to be persistent? Do we need every page of
>>> multixact to be persistent, or just particular pages in certain
>>> circumstances?
>>
>> Any page that contains at least one multi with an update as a member
>> must pe
Excerpts from Simon Riggs's message of lun mar 05 16:34:10 -0300 2012:
> It does however, illustrate my next review comment which is that the
> comments and README items are sorely lacking here. It's quite hard to
> see how it works, let along comment on major design decisions. It
> would help my
On Mon, Mar 5, 2012 at 7:53 PM, Alvaro Herrera
wrote:
>> My other comments so far are
>>
>> * some permutations commented out - no comments as to why
>> Something of a fault with the isolation tester that it just shows
>> output, there's no way to record expected output in the spec
>
> The reason
Excerpts from Simon Riggs's message of lun mar 05 16:34:10 -0300 2012:
> On Mon, Mar 5, 2012 at 6:37 PM, Alvaro Herrera
> wrote:
> It does however, illustrate my next review comment which is that the
> comments and README items are sorely lacking here. It's quite hard to
> see how it works, let
On Mon, Mar 5, 2012 at 6:37 PM, Alvaro Herrera
wrote:
>
> Excerpts from Simon Riggs's message of lun mar 05 15:28:59 -0300 2012:
>>
>> On Mon, Feb 27, 2012 at 2:47 AM, Robert Haas wrote:
>
>> > From a performance standpoint, we really need to think not only about
>> > the cases where the patch wi
Excerpts from Simon Riggs's message of lun mar 05 15:28:59 -0300 2012:
>
> On Mon, Feb 27, 2012 at 2:47 AM, Robert Haas wrote:
> > From a performance standpoint, we really need to think not only about
> > the cases where the patch wins, but also, and maybe more importantly,
> > the cases where
On Mon, Feb 27, 2012 at 2:47 AM, Robert Haas wrote:
> On Thu, Feb 23, 2012 at 11:01 AM, Alvaro Herrera
> wrote:
>>> This
>>> seems like a horrid mess that's going to be unsustainable both from a
>>> complexity and a performance standpoint. The only reason multixacts
>>> were tolerable at all was
On Tue, Feb 28, 2012 at 12:28 AM, Noah Misch wrote:
> On Mon, Feb 27, 2012 at 02:13:32PM +0200, Heikki Linnakangas wrote:
>> On 23.02.2012 18:01, Alvaro Herrera wrote:
>>> As far as complexity, yeah, it's a lot more complex now -- no question
>>> about that.
>>
>> How about assigning a new, real,
On Mon, Feb 27, 2012 at 02:13:32PM +0200, Heikki Linnakangas wrote:
> On 23.02.2012 18:01, Alvaro Herrera wrote:
>> As far as complexity, yeah, it's a lot more complex now -- no question
>> about that.
>
> How about assigning a new, real, transaction id, to represent the group
> of transaction id
On 23.02.2012 18:01, Alvaro Herrera wrote:
Excerpts from Tom Lane's message of jue feb 23 12:28:20 -0300 2012:
Alvaro Herrera writes:
Sure. The problem is that we are allowing updated rows to be locked (and
locked rows to be updated). This means that we need to store extended
Xmax informat
On Thu, Feb 23, 2012 at 11:01 AM, Alvaro Herrera
wrote:
>> This
>> seems like a horrid mess that's going to be unsustainable both from a
>> complexity and a performance standpoint. The only reason multixacts
>> were tolerable at all was that they had only one semantics. Changing
>> it so that ma
Vik Reykja wrote:
> Kevin Grittner wrote:
>
>> One of the problems that Florian was trying to address is that
>> people often have a need to enforce something with a lot of
>> similarity to a foreign key, but with more subtle logic than
>> declarative foreign keys support. One example would be t
On Thu, Feb 23, 2012 at 19:44, Kevin Grittner
wrote:
> One of the problems that Florian was trying to address is that
> people often have a need to enforce something with a lot of
> similarity to a foreign key, but with more subtle logic than
> declarative foreign keys support. One example would
On 2012-02-23 22:12, Noah Misch wrote:
That alone would not simplify the patch much. INSERT/UPDATE/DELETE on the
foreign side would still need to take some kind of tuple lock on the primary
side to prevent primary-side DELETE. You then still face the complicated case
of a tuple that's both loc
On Thu, Feb 23, 2012 at 12:43:11PM -0300, Alvaro Herrera wrote:
> Excerpts from Simon Riggs's message of jue feb 23 06:18:57 -0300 2012:
> > On Wed, Feb 22, 2012 at 5:00 PM, Noah Misch wrote:
> >
> > >> All in all, I think this is in pretty much final shape. ??Only pg_upgrade
> > >> bits are stil
On Thu, Feb 23, 2012 at 06:36:42PM -0300, Alvaro Herrera wrote:
>
> Excerpts from Noah Misch's message of mi?? feb 22 14:00:07 -0300 2012:
> >
> > On Mon, Feb 13, 2012 at 07:16:58PM -0300, Alvaro Herrera wrote:
>
> > On Mon, Jan 30, 2012 at 06:48:47PM -0500, Noah Misch wrote:
> > > On Tue, Jan 2
Excerpts from Noah Misch's message of mié feb 22 14:00:07 -0300 2012:
>
> On Mon, Feb 13, 2012 at 07:16:58PM -0300, Alvaro Herrera wrote:
> On Mon, Jan 30, 2012 at 06:48:47PM -0500, Noah Misch wrote:
> > On Tue, Jan 24, 2012 at 03:47:16PM -0300, Alvaro Herrera wrote:
> > > * Columns that are par
On Thu, Feb 23, 2012 at 02:08:28PM +0100, Jeroen Vermeulen wrote:
> On 2012-02-23 10:18, Simon Riggs wrote:
>
>> However, review of such a large patch should not be simply pass or
>> fail. We should be looking back at the original problem and ask
>> ourselves whether some subset of the patch could
Alvaro Herrera wrote:
> Excerpts from Kevin Grittner's message:
>> Since the limitation on what can be stored in xmax was the killer
>> for Florian's attempt to support SELECT FOR UPDATE in a form
>> which was arguably more useful (and certainly more convenient for
>> those converting from other
On Thu, Feb 23, 2012 at 4:01 PM, Alvaro Herrera
wrote:
> As far as complexity, yeah, it's a lot more complex now -- no question
> about that.
As far as complexity goes, would it be easier if we treated the UPDATE
of a primary key column as a DELETE plus an INSERT?
There's not really a logical r
On 02/23/2012 01:04 PM, Alvaro Herrera wrote:
"manual vacuum is teh sux0r"
I think you've just named my next conference talk submission.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Excerpts from Greg Smith's message of jue feb 23 14:48:13 -0300 2012:
> On 02/23/2012 10:43 AM, Alvaro Herrera wrote:
> > I completely understand that you don't want to review this latest
> > version of the patch; it's a lot of effort and I wouldn't inflict it on
> > anybody who hasn't not volunte
On 02/23/2012 10:43 AM, Alvaro Herrera wrote:
I completely understand that you don't want to review this latest
version of the patch; it's a lot of effort and I wouldn't inflict it on
anybody who hasn't not volunteered. However, it doesn't seem to me that
this is reason to boot the patch from th
Excerpts from Kevin Grittner's message of jue feb 23 13:31:36 -0300 2012:
>
> Alvaro Herrera wrote:
>
> > As for sanity -- I regard multixacts as a way to store extended
> > Xmax information. The original idea was obviously much more
> > limited in that the extended info was just locking info
Alvaro Herrera wrote:
> As for sanity -- I regard multixacts as a way to store extended
> Xmax information. The original idea was obviously much more
> limited in that the extended info was just locking info. We've
> extended it but I don't think it's such a stretch.
Since the limitation on
Excerpts from Tom Lane's message of jue feb 23 12:28:20 -0300 2012:
>
> Alvaro Herrera writes:
> > Sure. The problem is that we are allowing updated rows to be locked (and
> > locked rows to be updated). This means that we need to store extended
> > Xmax information in tuples that goes beyond
Excerpts from Simon Riggs's message of jue feb 23 12:12:13 -0300 2012:
> On Thu, Feb 23, 2012 at 3:04 PM, Alvaro Herrera
> wrote:
> > Sure. The problem is that we are allowing updated rows to be locked (and
> > locked rows to be updated). This means that we need to store extended
> > Xmax info
Excerpts from Simon Riggs's message of jue feb 23 06:18:57 -0300 2012:
>
> On Wed, Feb 22, 2012 at 5:00 PM, Noah Misch wrote:
>
> >> All in all, I think this is in pretty much final shape. Only pg_upgrade
> >> bits are still missing. If sharp eyes could give this a critical look
> >> and knuc
Alvaro Herrera writes:
> Sure. The problem is that we are allowing updated rows to be locked (and
> locked rows to be updated). This means that we need to store extended
> Xmax information in tuples that goes beyond mere locks, which is what we
> were doing previously -- they may now have locks
On Thu, Feb 23, 2012 at 3:04 PM, Alvaro Herrera
wrote:
>
> Excerpts from Simon Riggs's message of jue feb 23 11:15:45 -0300 2012:
>> On Sun, Dec 4, 2011 at 12:20 PM, Noah Misch wrote:
>>
>> > Making pg_multixact persistent across clean shutdowns is no bridge to cross
>> > lightly, since it means
Excerpts from Simon Riggs's message of jue feb 23 11:15:45 -0300 2012:
> On Sun, Dec 4, 2011 at 12:20 PM, Noah Misch wrote:
>
> > Making pg_multixact persistent across clean shutdowns is no bridge to cross
> > lightly, since it means committing to an on-disk format for an indefinite
> > period.
On Thu, Feb 23, 2012 at 1:08 PM, Jeroen Vermeulen wrote:
> Simon, I think you had a reason why it couldn't work, but I didn't quite get
> your meaning and didn't want to distract things further at that stage. You
> wrote that it "doesn't do what KEY LOCKS are designed to do"... any chance
> you
On Sun, Dec 4, 2011 at 12:20 PM, Noah Misch wrote:
> Making pg_multixact persistent across clean shutdowns is no bridge to cross
> lightly, since it means committing to an on-disk format for an indefinite
> period. We should do it; the benefits of this patch justify it, and I haven't
> identifie
On 2012-02-23 10:18, Simon Riggs wrote:
However, review of such a large patch should not be simply pass or
fail. We should be looking back at the original problem and ask
ourselves whether some subset of the patch could solve a useful subset
of the problem. For me, that seems quite likely and th
On Wed, Feb 22, 2012 at 5:00 PM, Noah Misch wrote:
>> All in all, I think this is in pretty much final shape. Only pg_upgrade
>> bits are still missing. If sharp eyes could give this a critical look
>> and knuckle-cracking testers could give it a spin, that would be
>> helpful.
>
> Lack of pg_u
On Mon, Feb 13, 2012 at 07:16:58PM -0300, Alvaro Herrera wrote:
> Okay, so this patch fixes the truncation and wraparound issues through a
> mechanism much like pg_clog's: it keeps track of the oldest possibly
> existing multis on each and every table, and then during tuple freezing
> those are rem
Excerpts from Jim Nasby's message of mié feb 01 21:33:47 -0300 2012:
>
> On Jan 31, 2012, at 10:58 AM, Alvaro Herrera wrote:
> >> I think it's butt-ugly, but it's only slightly uglier than
> >> relfrozenxid which we're already stuck with. The slight amount of
> >> additional ugliness is that you
On Jan 31, 2012, at 10:58 AM, Alvaro Herrera wrote:
>> I think it's butt-ugly, but it's only slightly uglier than
>> relfrozenxid which we're already stuck with. The slight amount of
>> additional ugliness is that you're going to use an XID column to store
>> a uint4 that is not an XID - but I don
On Tue, Jan 31, 2012 at 11:58 AM, Alvaro Herrera
wrote:
> Well, we're already storing a multixact in Xmax, so it's not like we
> don't assume that we can store multis in space normally reserved for
> Xids. What I've been wondering is not how ugly it is, but rather of the
> fact that we're bloatin
Excerpts from Robert Haas's message of mar ene 31 13:18:30 -0300 2012:
>
> On Tue, Jan 31, 2012 at 9:19 AM, Alvaro Herrera
> wrote:
> > Excerpts from Robert Haas's message of mar ene 31 10:17:40 -0300 2012:
> >> I suspect you are right that it is unlikely, but OTOH that sounds like
> >> an extre
On Tue, Jan 31, 2012 at 9:19 AM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of mar ene 31 10:17:40 -0300 2012:
>> I suspect you are right that it is unlikely, but OTOH that sounds like
>> an extremely painful recovery procedure. We probably don't need to
>> put a ton of thought i
Excerpts from Robert Haas's message of mar ene 31 10:17:40 -0300 2012:
> I suspect you are right that it is unlikely, but OTOH that sounds like
> an extremely painful recovery procedure. We probably don't need to
> put a ton of thought into handling this case as efficiently as
> possible, but I
On Mon, Jan 30, 2012 at 6:48 PM, Noah Misch wrote:
> On Tue, Jan 24, 2012 at 03:47:16PM -0300, Alvaro Herrera wrote:
>> The biggest item remaining is the point you raised about multixactid
>> wraparound. This is closely related to multixact truncation and the way
>> checkpoints are to be handled.
On Tue, Jan 24, 2012 at 03:47:16PM -0300, Alvaro Herrera wrote:
> The biggest item remaining is the point you raised about multixactid
> wraparound. This is closely related to multixact truncation and the way
> checkpoints are to be handled. If we think that MultiXactId wraparound
> is possible,
Excerpts from Alvaro Herrera's message of mar ene 24 15:47:16 -0300 2012:
> Need more code changes for the following:
> * export FOR KEY UPDATE lock mode in SQL
While doing this, I realized that there's an open item here regarding a
transaction that locks a tuple, and then in an aborted savepoi
On Wed, Jan 18, 2012 at 05:18:31PM -0300, Alvaro Herrera wrote:
> Excerpts from Heikki Linnakangas's message of mar ene 17 03:21:28 -0300 2012:
> > On 16.01.2012 21:52, Alvaro Herrera wrote:
> > > I was initially thinking that pg_multixact should return the
> > > empty set if requested members of
Excerpts from Heikki Linnakangas's message of mar ene 17 03:21:28 -0300 2012:
>
> On 16.01.2012 21:52, Alvaro Herrera wrote:
> >
> > Excerpts from Heikki Linnakangas's message of lun ene 16 16:17:42 -0300
> > 2012:
> >>
> >> On 15.01.2012 06:49, Alvaro Herrera wrote:
> >>> - pg_upgrade bits are
On Mon, Jan 16, 2012 at 04:52:36PM -0300, Alvaro Herrera wrote:
> Excerpts from Heikki Linnakangas's message of lun ene 16 16:17:42 -0300 2012:
> > On 15.01.2012 06:49, Alvaro Herrera wrote:
> > > --- 164,178
> > > #define HEAP_HASVARWIDTH0x0002/* has variable-width
> > > attrib
On Sun, Jan 15, 2012 at 01:49:54AM -0300, Alvaro Herrera wrote:
> - I'm not sure that the multixact truncation code is sane on
> checkpoints. It might be that I need to tweak more the pg_control info
> we keep about truncation. The whole truncation thing needs more
> testing, too.
My largest out
On 16.01.2012 21:52, Alvaro Herrera wrote:
Excerpts from Heikki Linnakangas's message of lun ene 16 16:17:42 -0300 2012:
On 15.01.2012 06:49, Alvaro Herrera wrote:
- pg_upgrade bits are missing.
I guess we'll need to rewrite pg_multixact contents in pg_upgrade. Is
the page format backwards-
Excerpts from Heikki Linnakangas's message of lun ene 16 16:17:42 -0300 2012:
>
> On 15.01.2012 06:49, Alvaro Herrera wrote:
> > --- 164,178
> > #define HEAP_HASVARWIDTH0x0002/* has variable-width
> > attribute(s) */
> > #define HEAP_HASEXTERNAL0x0004/* has exter
On 15.01.2012 06:49, Alvaro Herrera wrote:
--- 164,178
#define HEAP_HASVARWIDTH 0x0002 /* has variable-width
attribute(s) */
#define HEAP_HASEXTERNAL 0x0004 /* has external stored
attribute(s) */
#define HEAP_HASOID 0x0008 /* has
Sounds like there's still a few things left to research out on Alvaro's
side, and I'm thinking there's a performance/reliability under load
testing side of this that will take some work to validate too. Since I
can't see all that happening fast enough to commit for a bit, I'm going
to mark it
Noah Misch writes:
> On Tue, Dec 13, 2011 at 06:36:21PM -0300, Alvaro Herrera wrote:
>> Yeah, I've been wondering about this: do we have a problem already with
>> exclusion constraints? I mean, if a concurrent inserter doesn't see the
>> tuple that we've marked here as deleted while we toast it,
On Tue, Dec 13, 2011 at 06:36:21PM -0300, Alvaro Herrera wrote:
> Excerpts from Noah Misch's message of dom dic 04 09:20:27 -0300 2011:
> > > @@ -2725,11 +2884,20 @@ l2:
> > > oldtup.t_data->t_infomask &= ~(HEAP_XMAX_COMMITTED |
> > > HEAP_XMAX_INVA
Excerpts from Noah Misch's message of dom dic 04 09:20:27 -0300 2011:
> > +/*
> > + * If the tuple we're updating is locked, we need to preserve this in
> > the
> > + * new tuple's Xmax as well as in the old tuple. Prepare the new xmax
> > + * value for these uses.
> > + *
>
On Tue, Dec 13, 2011 at 01:09:46PM -0300, Alvaro Herrera wrote:
>
> Excerpts from Noah Misch's message of mar dic 13 11:44:49 -0300 2011:
> >
> > On Mon, Dec 12, 2011 at 05:20:39PM -0300, Alvaro Herrera wrote:
> > > Excerpts from Noah Misch's message of dom dic 04 09:20:27 -0300 2011:
> > >
> >
Excerpts from Noah Misch's message of mar dic 13 11:44:49 -0300 2011:
>
> On Mon, Dec 12, 2011 at 05:20:39PM -0300, Alvaro Herrera wrote:
> > Excerpts from Noah Misch's message of dom dic 04 09:20:27 -0300 2011:
> >
> > > Second, I tried a SELECT FOR SHARE on a table of 1M tuples; this might
>
On Mon, Dec 12, 2011 at 05:20:39PM -0300, Alvaro Herrera wrote:
> Excerpts from Noah Misch's message of dom dic 04 09:20:27 -0300 2011:
>
> > Second, I tried a SELECT FOR SHARE on a table of 1M tuples; this might incur
> > some cost due to the now-guaranteed use of pg_multixact for FOR SHARE. See
Excerpts from Alvaro Herrera's message of lun dic 12 17:20:39 -0300 2011:
> I found that this is caused by mxid_to_string being leaked all over the
> place :-( I "fixed" it by making the returned string be a static that's
> malloced and then freed on the next call. There's still virtsize growth
Noah,
Many thanks for this review. I'm going through items on it; definitely
there are serious issues here, as well as minor things that also need
fixing. Thanks for all the detail.
I'll post an updated patch shortly (probably not today though); in the
meantime, this bit:
Excerpts from Noah M
Robert Haas writes:
> On Sat, Nov 19, 2011 at 10:36 AM, Tom Lane wrote:
>> It's already the case that RI triggers require access to special
>> executor features that are not accessible at the SQL level. I don't
>> think the above argument is a compelling reason for exposing more
>> such features
On Sat, Nov 19, 2011 at 10:36 AM, Tom Lane wrote:
> Simon Riggs writes:
>> On Thu, Nov 3, 2011 at 6:12 PM, Alvaro Herrera
>> wrote:
>>> So Noah Misch proposed using the FOR KEY SHARE syntax, and that's what I
>>> have implemented here. (There was some discussion that instead of
>>> inventing n
Simon Riggs writes:
> On Thu, Nov 3, 2011 at 6:12 PM, Alvaro Herrera
> wrote:
>> So Noah Misch proposed using the FOR KEY SHARE syntax, and that's what I
>> have implemented here. (There was some discussion that instead of
>> inventing new SQL syntax we could pass the necessary lock mode
>> int
On Thu, Nov 3, 2011 at 6:12 PM, Alvaro Herrera wrote:
> So Noah Misch proposed using the FOR KEY SHARE syntax, and that's what I
> have implemented here. (There was some discussion that instead of
> inventing new SQL syntax we could pass the necessary lock mode
> internally in the ri_triggers co
On Thu, Nov 10, 2011 at 8:17 PM, Christopher Browne wrote:
> On Sun, Nov 6, 2011 at 2:28 AM, Jeroen Vermeulen wrote:
>> On 2011-11-04 01:12, Alvaro Herrera wrote:
>>
>>> I would like some opinions on the ideas on this patch, and on the patch
>>> itself. If someone wants more discussion on implem
On 2011-11-12 00:30, David Kerr wrote:
Is this being suggested in lieu of Alvaro's patch? because it seems to be adding
complexity to the system (multiple types of primary key definitions) instead of
just fixing an obvious problem (over-aggressive locking done on FK checks).
It wouldn't be a n
>> An UPDATE that modifies the key columns will be blocked, just as now.
>> Same with a DELETE.
>
> OK, so it prevents non-key data modifications from spilling to the
> referred rows --- nice.
Yes. Eliminates the leading cause of deadlocks in Postgres applications.
--
Josh Berkus
PostgreSQL E
On Thu, Nov 10, 2011 at 03:17:59PM -0500, Christopher Browne wrote:
- On Sun, Nov 6, 2011 at 2:28 AM, Jeroen Vermeulen wrote:
- > On 2011-11-04 01:12, Alvaro Herrera wrote:
- >
- >> I would like some opinions on the ideas on this patch, and on the patch
- >> itself. If someone wants more discussi
Alvaro Herrera wrote:
>
> Excerpts from Bruce Momjian's message of jue nov 10 16:59:20 -0300 2011:
> > Alvaro Herrera wrote:
> > > Hello,
> > >
> > > After some rather extensive rewriting, I submit the patch to improve
> > > foreign key locks.
> > >
> > > To recap, the point of this patch is to
Excerpts from Bruce Momjian's message of jue nov 10 16:59:20 -0300 2011:
> Alvaro Herrera wrote:
> > Hello,
> >
> > After some rather extensive rewriting, I submit the patch to improve
> > foreign key locks.
> >
> > To recap, the point of this patch is to introduce a new lock tuple mode,
> > tha
On Thu, Nov 10, 2011 at 3:29 PM, Kevin Grittner
wrote:
> Christopher Browne wrote:
>
>> There's value in having an "immutability" constraint on a column,
>> where, in effect, you're not allowed to modify the value of the
>> column, once assigned.
>
> +1 We would definitely use such a feature, sh
Christopher Browne wrote:
> There's value in having an "immutability" constraint on a column,
> where, in effect, you're not allowed to modify the value of the
> column, once assigned.
+1 We would definitely use such a feature, should it become
available.
-Kevin
--
Sent via pgsql-hackers
2011/11/10 Christopher Browne :
> On Sun, Nov 6, 2011 at 2:28 AM, Jeroen Vermeulen wrote:
>> On 2011-11-04 01:12, Alvaro Herrera wrote:
>>
>>> I would like some opinions on the ideas on this patch, and on the patch
>>> itself. If someone wants more discussion on implementation details of
>>> each
On Sun, Nov 6, 2011 at 2:28 AM, Jeroen Vermeulen wrote:
> On 2011-11-04 01:12, Alvaro Herrera wrote:
>
>> I would like some opinions on the ideas on this patch, and on the patch
>> itself. If someone wants more discussion on implementation details of
>> each part of the patch, I'm happy to provid
Alvaro Herrera wrote:
> Hello,
>
> After some rather extensive rewriting, I submit the patch to improve
> foreign key locks.
>
> To recap, the point of this patch is to introduce a new lock tuple mode,
> that lets the RI code obtain a lighter lock on tuples, which doesn't
> conflict with updates
On 2011-11-04 01:12, Alvaro Herrera wrote:
I would like some opinions on the ideas on this patch, and on the patch
itself. If someone wants more discussion on implementation details of
each part of the patch, I'm happy to provide a textual description --
please just ask.
Jumping in a bit late
101 - 187 of 187 matches
Mail list logo