Re: [HACKERS] Refactoring identifier checks to consistently use strcmp

> On 17 Aug 2017, at 11:08, Daniel Gustafsson wrote: > >> On 16 Aug 2017, at 17:51, Tom Lane wrote: >> >> Heikki Linnakangas writes: >>> This no longer works: >> >>> postgres=# CREATE TEXT SEARCH DICTIONARY public.simple_dict ( >>>

Re: [HACKERS] Refactoring identifier checks to consistently use strcmp

> On 16 Aug 2017, at 17:51, Tom Lane wrote: > > Heikki Linnakangas writes: >> This no longer works: > >> postgres=# CREATE TEXT SEARCH DICTIONARY public.simple_dict ( >> TEMPLATE = pg_catalog.simple, >> "STOPWORds" = english >> ); >> ERROR:

Re: [HACKERS] Refactoring identifier checks to consistently use strcmp

On Wed, Aug 16, 2017 at 11:51 AM, Tom Lane wrote: > You have a point, but I'm not sure that this is such a bad compatibility > break as to be a reason not to change things to be more consistent. +1. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise

Re: [HACKERS] Refactoring identifier checks to consistently use strcmp

Heikki Linnakangas writes: > This no longer works: > postgres=# CREATE TEXT SEARCH DICTIONARY public.simple_dict ( > TEMPLATE = pg_catalog.simple, > "STOPWORds" = english > ); > ERROR: unrecognized simple dictionary parameter: "STOPWORds" > In hindsight, perhaps we

Re: [HACKERS] Refactoring identifier checks to consistently use strcmp

On 04/04/2017 10:13 AM, Daniel Gustafsson wrote: On 04 Apr 2017, at 05:52, Alvaro Herrera wrote: Daniel Gustafsson wrote: Testing DefElem options is done with both strcmp() and pg_strcasecmp() a bit mixed. Since the option defnames are all lowercased, either via

Re: [HACKERS] Refactoring identifier checks to consistently use strcmp

> On 04 Apr 2017, at 05:52, Alvaro Herrera wrote: > > Daniel Gustafsson wrote: >> Testing DefElem options is done with both strcmp() and pg_strcasecmp() a bit >> mixed. Since the option defnames are all lowercased, either via IDENT, >> keyword >> rules or “by hand”

Re: [HACKERS] Refactoring identifier checks to consistently use strcmp

Daniel Gustafsson wrote: > Testing DefElem options is done with both strcmp() and pg_strcasecmp() a bit > mixed. Since the option defnames are all lowercased, either via IDENT, > keyword > rules or “by hand” with makeString(), using strcmp() is safe (and assumed to > be > so in quite a lot of

Re: [HACKERS] Refactoring of replication commands using printsimple

On Thu, Feb 2, 2017 at 4:05 AM, Robert Haas wrote: > On Tue, Jan 31, 2017 at 8:26 PM, Michael Paquier > wrote: >> pq_sendcountedtext() does some encoding conversion, which is why I >> haven't used because we deal only with integers in this

Re: [HACKERS] Refactoring of replication commands using printsimple

On Tue, Jan 31, 2017 at 8:26 PM, Michael Paquier wrote: > pq_sendcountedtext() does some encoding conversion, which is why I > haven't used because we deal only with integers in this patch... Now > if you wish to switch to that I have really no arguments against. OK, I

Re: [HACKERS] Refactoring of replication commands using printsimple

On Tue, Jan 31, 2017 at 11:59 PM, Robert Haas wrote: > Sorry, I have a little more nitpicking. Thanks for the input. > How about having > printsimple() use pq_sendcountedtext() instead of pq_sendint() > followed by pq_sendbytes(), as it does for TEXTOID? > > Other than

Re: [HACKERS] Refactoring of replication commands using printsimple

On Tue, Jan 31, 2017 at 12:19 AM, Michael Paquier wrote: > This is a follow up of the refactoring that has been discussed in the > thread to increase the default size of WAL segments: >

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Tue, Sep 27, 2016 at 2:13 PM, Tom Lane wrote: > I can see the value of processing unique indexes before non-unique ones. > I'm pretty suspicious of trying to prioritize primary keys first, though, > because (a) it's not clear why bother, and (b) PG is a tad squishy about >

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

Heikki Linnakangas writes: > On 09/24/2016 02:34 PM, Peter Geoghegan wrote: >> I go on to explain how this patch represents a partial solution to >> that [1]. That's what I mean by "useful practical consequences". As I >> say in [1], I think we could even get a full solution, if

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On 09/27/2016 11:38 AM, Peter Geoghegan wrote: On Tue, Sep 27, 2016 at 9:25 AM, Heikki Linnakangas wrote: I didn't think very hard about it, but yeah, think so.. Do you think it's worth a backpatch? Or, too early to tell? Too early to tell.. - Heikki -- Sent via

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Tue, Sep 27, 2016 at 9:25 AM, Heikki Linnakangas wrote: > I didn't think very hard about it, but yeah, think so.. Do you think it's worth a backpatch? Or, too early to tell? -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On 09/27/2016 11:22 AM, Peter Geoghegan wrote: On Tue, Sep 27, 2016 at 9:10 AM, Heikki Linnakangas wrote: Hmm, yeah, that'd be nice to fix. I'd like to see a patch specifically to fix that. I'm not convinced that we need all the complications of this patch, to get that fixed.

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Tue, Sep 27, 2016 at 9:10 AM, Heikki Linnakangas wrote: > Hmm, yeah, that'd be nice to fix. I'd like to see a patch specifically to > fix that. I'm not convinced that we need all the complications of this > patch, to get that fixed. (In particular, indexam's still wouldn't

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On 09/24/2016 02:34 PM, Peter Geoghegan wrote: On Tue, Sep 20, 2016 at 8:55 AM, Heikki Linnakangas wrote: Likewise, in ExecInsertIndexTuples(), this makes the deferred-index case work slightly differently from speculative insertion. It's not a big difference, but it again

Re: [HACKERS] Refactoring of heapam code.

On Tue, Sep 6, 2016 at 8:39 PM, Anastasia Lubennikova < a.lubennik...@postgrespro.ru> wrote: > 06.09.2016 07:44, Pavan Deolasee: > > > I don't know what to do with the CF entry itself. I could change the > status to "waiting on author" but then the design draft may not get enough > attention. So

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Tue, Sep 20, 2016 at 8:55 AM, Heikki Linnakangas wrote: > Thanks for working on this, and sorry for disappearing and dropping this on > the floor earlier. This doesn't apply anymore, thanks to 9c810a2e. Shouldn't > be hard to fix. Thanks for looking at it again. > I was in

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On 03/17/2016 01:43 AM, Peter Geoghegan wrote: I attach a revision, that makes all the changes that Heikki suggested, except one. As already noted several times, following this suggestion would have added a bug. Alvaro preferred my original approach here in any case. I refer to my original

Re: [HACKERS] Refactoring of heapam code.

On Mon, Sep 12, 2016 at 7:12 PM, Pavan Deolasee wrote: > I was thinking about locking, bulk reading (like page-mode API) etc. While > you've added an API for vacuuming, we would probably also need an API to > collect dead tuples, pruning etc (not sure if that can be

Re: [HACKERS] Refactoring of heapam code.

On Tue, Sep 6, 2016 at 8:39 PM, Anastasia Lubennikova < a.lubennik...@postgrespro.ru> wrote: > 06.09.2016 07:44, Pavan Deolasee: > > 2. I don't understand the difference between PageGetItemHeapHeaderOnly() > and PageGetItemHeap(). They seem to do exactly the same thing and can be > used

Re: [HACKERS] Refactoring of heapam code.

06.09.2016 07:44, Pavan Deolasee: On Mon, Aug 8, 2016 at 3:13 PM, Anastasia Lubennikova > wrote: Thank you for the review, I'll fix these problems in final version. Posting the first message I intended to raise

Re: [HACKERS] Refactoring of heapam code.

On Mon, Aug 8, 2016 at 3:13 PM, Anastasia Lubennikova < a.lubennik...@postgrespro.ru> wrote: > >> > Thank you for the review, I'll fix these problems in final version. > > Posting the first message I intended to raise the discussion. Patches > were attached mainly to illustrate the problem and to

Re: [HACKERS] Refactoring of heapam code.

08.08.2016 12:43, Anastasia Lubennikova: 08.08.2016 03:51, Michael Paquier: On Sat, Aug 6, 2016 at 2:56 AM, Alvaro Herrera wrote: Anastasia Lubennikova wrote: So there is a couple of patches. They do not cover all mentioned problems, but I'd like to get a feedback

Re: [HACKERS] Refactoring of heapam code.

Anastasia Lubennikova wrote: > By the way, I thought about looking at the mentioned patch and > probably reviewing it, but didn't find any of your patches on the > current commitfest. Could you point out the thread? Sorry, I haven't posted anything yet. > >Agreed. But changing its name while

Re: [HACKERS] Refactoring of heapam code.

08.08.2016 03:51, Michael Paquier: On Sat, Aug 6, 2016 at 2:56 AM, Alvaro Herrera wrote: Anastasia Lubennikova wrote: So there is a couple of patches. They do not cover all mentioned problems, but I'd like to get a feedback before continuing. I agree that we could

Re: [HACKERS] Refactoring of heapam code.

05.08.2016 20:56, Alvaro Herrera: Anastasia Lubennikova wrote: Working on page compression and some other issues related to access methods, I found out that the code related to heap looks too complicated. Much more complicated, than it should be. Since I anyway got into this area, I want to

Re: [HACKERS] Refactoring of heapam code.

On Sat, Aug 6, 2016 at 2:56 AM, Alvaro Herrera wrote: > Anastasia Lubennikova wrote: >> So there is a couple of patches. They do not cover all mentioned problems, >> but I'd like to get a feedback before continuing. > > I agree that we could improve things in this

Re: [HACKERS] Refactoring of heapam code.

Anastasia Lubennikova wrote: > Working on page compression and some other issues related to > access methods, I found out that the code related to heap > looks too complicated. Much more complicated, than it should be. > Since I anyway got into this area, I want to suggest a set of improvements.

Re: [HACKERS] Refactoring of heapam code.

05.08.2016 16:30, Kevin Grittner: On Fri, Aug 5, 2016 at 2:54 AM, Anastasia Lubennikova wrote: They can be logically separated into three categories: "primary storage" - r, S, t, v. They store data and visibility information. The only implementation is heapam.c

Re: [HACKERS] Refactoring of heapam code.

On Fri, Aug 5, 2016 at 2:54 AM, Anastasia Lubennikova wrote: > They can be logically separated into three categories: > "primary storage" - r, S, t, v. They store data and visibility information. > The only implementation is heapam.c > "secondary index" - i. They

Re: [HACKERS] Refactoring of heapam code.

On 5 August 2016 at 08:54, Anastasia Lubennikova wrote: > Working on page compression and some other issues related to > access methods, I found out that the code related to heap > looks too complicated. Much more complicated, than it should be. > Since I anyway got

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Tue, Apr 5, 2016 at 9:47 PM, Robert Haas wrote: >> I do not pursue something like this without good reason. I'm >> optimistic that the patch will be accepted if it is carefully >> considered. > > This patch has attracted no reviewers. Any volunteers? Since nobody has

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Wed, Mar 16, 2016 at 7:43 PM, Peter Geoghegan wrote: > On Wed, Mar 16, 2016 at 11:25 AM, Robert Haas wrote: >> Sure, and if everybody does that, then there will be 40 patches that >> get updated in the last 2 days if the CommitFest, and that will be >>

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Wed, Mar 16, 2016 at 11:25 AM, Robert Haas wrote: > Sure, and if everybody does that, then there will be 40 patches that > get updated in the last 2 days if the CommitFest, and that will be > impossible. Come on. You're demanding a degree of preferential > treatment

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Mon, Mar 14, 2016 at 8:17 PM, Peter Geoghegan wrote: > On Mon, Mar 14, 2016 at 5:04 PM, Robert Haas wrote: >> There hasn't been a new version of this patch in 9 months, you're >> clearly not in a hurry to produce one, and nobody else seems to feel >>

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Mon, Mar 14, 2016 at 5:21 PM, Andres Freund wrote: > So? You're not the only one. I don't see why we shouldn't move this to > 'returned with feedback' until there's a new version. I don't see any point in that; I intend to get a revision in to the ongoing CF. But fine. --

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On 2016-03-14 17:17:02 -0700, Peter Geoghegan wrote: > On Mon, Mar 14, 2016 at 5:04 PM, Robert Haas wrote: > > There hasn't been a new version of this patch in 9 months, you're > > clearly not in a hurry to produce one, and nobody else seems to feel > > strongly that this

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Mon, Mar 14, 2016 at 5:04 PM, Robert Haas wrote: > There hasn't been a new version of this patch in 9 months, you're > clearly not in a hurry to produce one, and nobody else seems to feel > strongly that this is something that needs to be done at all. I think > we could

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Sat, Mar 12, 2016 at 5:53 PM, Peter Geoghegan wrote: > On Sat, Mar 12, 2016 at 2:43 PM, Michael Paquier > wrote: >> Only one version of this patch has been sent at the beginning of this >> thread, and Heikki has clearly expressed his disagreement

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Sat, Mar 12, 2016 at 2:53 PM, Peter Geoghegan wrote: > I said "basically uncontroversial", not "uncontroversial". That is a > perfectly accurate characterization of the patch, and if you disagree > than I suggest you re-read the thread. In particular, note that Alvaro

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Sat, Mar 12, 2016 at 2:43 PM, Michael Paquier wrote: > Only one version of this patch has been sent at the beginning of this > thread, and Heikki has clearly expressed his disagreement about at > least a portion of it at the beginning of this thread, so I find it >

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Sat, Mar 12, 2016 at 11:24 PM, Peter Geoghegan wrote: > On Fri, Mar 11, 2016 at 5:26 AM, Robert Haas wrote: >> This patch was reviewed during CF 2016-01 and has not been updated for >> CF 2016-03. I think we should mark it Returned with Feedback. > > I

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Fri, Mar 11, 2016 at 5:26 AM, Robert Haas wrote: > This patch was reviewed during CF 2016-01 and has not been updated for > CF 2016-03. I think we should mark it Returned with Feedback. I have a full plate at the moment, Robert, both as a reviewer and as a patch

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Mon, Jan 18, 2016 at 3:14 PM, Peter Geoghegan wrote: > On Mon, Jan 18, 2016 at 11:56 AM, Alvaro Herrera > wrote: >>> That's because I believe this is quite broken, as already pointed out. >> >> I think I like your approach better. > > That makes

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

Peter Geoghegan wrote: > On Fri, Dec 18, 2015 at 12:55 PM, Robert Haas wrote: > > I only see one patch version on the thread. > > I'm not going to post a revision until I thrash out the tiny issues > with Heikki. He kind of trailed off. So maybe that kills it >

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Mon, Jan 18, 2016 at 8:36 AM, Alvaro Herrera wrote: > If you refuse to post an updated version of the patch until Heikki > weighs in some more, and given that Heikki has (for the purposes of this > patch) completely vanished, I think we should mark this rejected. I

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

Peter Geoghegan wrote: > On Mon, Jan 18, 2016 at 8:36 AM, Alvaro Herrera > wrote: > > If you refuse to post an updated version of the patch until Heikki > > weighs in some more, and given that Heikki has (for the purposes of this > > patch) completely vanished, I think

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Mon, Jan 18, 2016 at 11:56 AM, Alvaro Herrera wrote: >> That's because I believe this is quite broken, as already pointed out. > > I think I like your approach better. That makes things far simpler, then. >> Your premise here is that what Heikki said in passing

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Sat, Dec 19, 2015 at 3:26 PM, Michael Paquier wrote: > +1. There are folks around doing tests using 9.5 now, it is not > correct to impact the effort they have been putting on it until now. This is a total misrepresentation of what I've said. -- Peter Geoghegan

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Sat, Dec 19, 2015 at 1:58 AM, Robert Haas wrote: > No, it's far too late to be pushing this into 9.5. We are at RC1 now > and hoping to cut a final release right after Christmas. I think it's > quite wrong to argue that these changes have no risk of destabilizing > 9.5. Nobody is exempt from

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Thu, Dec 17, 2015 at 2:55 AM, Peter Geoghegan wrote: > On Wed, Dec 16, 2015 at 11:44 PM, Peter Geoghegan wrote: >>> In any case, at this point 9.5 is really aimed to be stabilized, so >>> targeting only master is a far saner approach IMO for this patch. >>>

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Fri, Dec 18, 2015 at 8:58 AM, Robert Haas wrote: > No, it's far too late to be pushing this into 9.5. We are at RC1 now > and hoping to cut a final release right after Christmas. I think it's > quite wrong to argue that these changes have no risk of destabilizing >

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Fri, Dec 18, 2015 at 2:04 PM, Peter Geoghegan wrote: > It isn't true that Heikki was not basically in favor of this. This > should have been committed as part of the original patch, really. Maybe he wasn't against the whole thing, but he's posted two messages to this thread

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Fri, Dec 18, 2015 at 12:55 PM, Robert Haas wrote: > On Fri, Dec 18, 2015 at 2:04 PM, Peter Geoghegan wrote: >> It isn't true that Heikki was not basically in favor of this. This >> should have been committed as part of the original patch, really. > >

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Fri, Dec 18, 2015 at 4:31 PM, Peter Geoghegan wrote: > On Thu, Dec 17, 2015 at 11:06 PM, Michael Paquier > wrote: >> Now per the two points listed in >> the first sentence in this paragraph, perhaps this opinion is fine as >> moot :) I didn't get

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Thu, Dec 17, 2015 at 4:55 PM, Peter Geoghegan wrote: > On Wed, Dec 16, 2015 at 11:44 PM, Peter Geoghegan wrote: >>> In any case, at this point 9.5 is really aimed to be stabilized, so >>> targeting only master is a far saner approach IMO for this patch. >>>

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Thu, Dec 17, 2015 at 11:06 PM, Michael Paquier wrote: >> I should add: I think that the chances of this patch destabilizing the >> code are very slim, once it receives the proper review. Certainly, I >> foresee no possible downside to not inserting the doomed

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Sun, Oct 4, 2015 at 2:07 AM, Peter Geoghegan wrote: > On Sat, Oct 3, 2015 at 6:38 AM, Andres Freund wrote: >> I'm not arguing against any of this - but I don't think this needs to be >> on the 9.5 open items list. I plan to remove from there. > > Obviously

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Wed, Dec 16, 2015 at 11:44 PM, Peter Geoghegan wrote: >> In any case, at this point 9.5 is really aimed to be stabilized, so >> targeting only master is a far saner approach IMO for this patch. >> Pushing that in 9.5 a couple of months back may have given enough >> reason to

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Wed, Dec 16, 2015 at 11:20 PM, Michael Paquier wrote: > (A couple of months later) > This is not an actual fix, but an optimization, no? > UNIQUE_CHECK_SPECULATIVE is just used to optimize a couple of code > paths in the case of a insert conflicting during btree

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

Hi, On 2015-06-10 16:19:27 -0700, Peter Geoghegan wrote: > Currently, speculative insertion (the INSERT ... ON CONFLICT DO UPDATE > executor/storage infrastructure) uses checkUnique == > UNIQUE_CHECK_PARTIAL for unique indexes, which is a constant > originally only used by deferred unique

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Sat, Oct 3, 2015 at 6:38 AM, Andres Freund wrote: > I'm not arguing against any of this - but I don't think this needs to be > on the 9.5 open items list. I plan to remove from there. Obviously I don't think that this is a critical fix. I do think that it would be nice to

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Thu, Jul 2, 2015 at 2:58 PM, Peter Geoghegan p...@heroku.com wrote: As with row locking, with insertion, if there is a conflict, any outcome (UPDATE or INSERT) is then possible. Where are we on this? It would be nice to get this out of the way before a 9.5 beta is put out. Thanks -- Peter

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On 07/01/2015 09:19 PM, Peter Geoghegan wrote: On Wed, Jul 1, 2015 at 10:45 AM, Peter Geoghegan p...@heroku.com wrote: On Tue, Jun 30, 2015 at 11:19 AM, Heikki Linnakangas hlinn...@iki.fi wrote: I agree it would be cleaner to have a separate CHECK_UNIQUE_XXX code for speculative insertions.

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Thu, Jul 2, 2015 at 1:30 AM, Heikki Linnakangas hlinn...@iki.fi wrote: Sure, if a speculative inserter detects a conflict, it still has to wait. But not in the aminsert call, and not until it cleans up its physical insertion (by super-deleting). Clearly a CHECK_UNIQUE_SPECULATIVE would have

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Thu, Jul 2, 2015 at 10:49 AM, Peter Geoghegan p...@heroku.com wrote: Well, waiting means getting a ShareLock on the other session's XID. You can't do that without first releasing your locks, unless you're okay with unprincipled deadlocks. Besides, if the other session wins the race and

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Wed, Jul 1, 2015 at 10:45 AM, Peter Geoghegan p...@heroku.com wrote: On Tue, Jun 30, 2015 at 11:19 AM, Heikki Linnakangas hlinn...@iki.fi wrote: I agree it would be cleaner to have a separate CHECK_UNIQUE_XXX code for speculative insertions. You've defined CHECK_UNIQUE_SPECULATIVE as like

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Tue, Jun 30, 2015 at 11:19 AM, Heikki Linnakangas hlinn...@iki.fi wrote: I agree it would be cleaner to have a separate CHECK_UNIQUE_XXX code for speculative insertions. You've defined CHECK_UNIQUE_SPECULATIVE as like CHECK_UNIQUE_PARTIAL, but you don't have to insert the index tuple if

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Wed, Jul 1, 2015 at 10:45 AM, Peter Geoghegan p...@heroku.com wrote: You can construct a theoretical case where lock starvation occurs with unique constraint enforcement. I think it helps with nbtree here that someone will reliably *not* see a conflict when concurrently inserting, because

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On 06/11/2015 02:19 AM, Peter Geoghegan wrote: Currently, speculative insertion (the INSERT ... ON CONFLICT DO UPDATE executor/storage infrastructure) uses checkUnique == UNIQUE_CHECK_PARTIAL for unique indexes, which is a constant originally only used by deferred unique constraints. It occurred

Re: [HACKERS] Refactoring pgbench.c

Hi, On 06/28/2015 08:10 AM, Fabien COELHO wrote: Hello Tatsuo, Main pgbench logic consists of single file pgbench.c which is 4036 lines of code as of today. This is not a small number and I think it would be nice if it is divided into smaller files because it will make it easier to maintain,

Re: [HACKERS] Refactoring pgbench.c

Hello Tatsuo, Main pgbench logic consists of single file pgbench.c which is 4036 lines of code as of today. This is not a small number and I think it would be nice if it is divided into smaller files because it will make it easier to maintain, add or change features of pgbench. I do not

Re: [HACKERS] Refactoring pgbench.c

I do not think that this large file is a so big a problem (good editors help navigation in the code), and I'm not sure that splitting it would achieve much: there are not that many functions, some of them are maybe long (main, threadRun, doCustom) but mostly for good reasons. My thoughts,

Re: [HACKERS] Refactoring pgbench.c

On 06/28/15 18:56, Tatsuo Ishii wrote: I do not think that this large file is a so big a problem (good editors help navigation in the code), and I'm not sure that splitting it would achieve much: there are not that many functions, some of them are maybe long (main, threadRun, doCustom) but

Re: [HACKERS] Refactoring pgbench.c

This is kind of surprising to me that two people are against refactoring proposal (I understand that Fabien has pending patches for pgbench and that could be a motivation for this though). I think that's a misunderstanding. I'm not against refactoring - not at all, and neither is Fabien I

Re: [HACKERS] Refactoring pgbench.c

On Sat, Jun 27, 2015 at 5:10 PM, Tatsuo Ishii is...@postgresql.org wrote: Main pgbench logic consists of single file pgbench.c which is 4036 lines of code as of today. This is not a small number and I think it would be nice if it is divided into smaller files because it will make it easier to

Re: [HACKERS] Refactoring GUC unit conversions

On Fri, Feb 13, 2015 at 10:26 PM, Heikki Linnakangas hlinnakan...@vmware.com wrote: In the redesign checkpoint_segments patch, Robert suggested keeping the settings' base unit as number of segments, but allow conversions from MB, GB etc. I started looking into that and found that adding a new

Re: [HACKERS] Refactoring GUC unit conversions

On 2/13/15 7:26 AM, Heikki Linnakangas wrote: In the redesign checkpoint_segments patch, Robert suggested keeping the settings' base unit as number of segments, but allow conversions from MB, GB etc. I started looking into that and found that adding a new unit to guc.c is quite messy. The

Re: [HACKERS] Refactoring GUC unit conversions

On 02/13/2015 07:34 PM, Jim Nasby wrote: On 2/13/15 7:26 AM, Heikki Linnakangas wrote: In the redesign checkpoint_segments patch, Robert suggested keeping the settings' base unit as number of segments, but allow conversions from MB, GB etc. I started looking into that and found that adding a

Re: [HACKERS] Refactoring GUC unit conversions

On 2/13/15 11:44 AM, Heikki Linnakangas wrote: On 02/13/2015 07:34 PM, Jim Nasby wrote: On 2/13/15 7:26 AM, Heikki Linnakangas wrote: In the redesign checkpoint_segments patch, Robert suggested keeping the settings' base unit as number of segments, but allow conversions from MB, GB etc. I

Re: [HACKERS] Refactoring standby mode logic

On 29 November 2012 09:06, Heikki Linnakangas hlinnakan...@vmware.com wrote: The code that reads the WAL from the archive, from pg_xlog, and from a master server via walreceiver, is quite complicated. I'm talking about the WaitForWALToBecomeAvailable() function in xlog.c. I got frustrated with

Re: [HACKERS] Refactoring standby mode logic

On 30.11.2012 13:11, Dimitri Fontaine wrote: Hi, Heikki Linnakangashlinnakan...@vmware.com writes: Attached is a patch to refactor that logic into a more straightforward state machine. It's always been a kind of a state machine, but it's been hard to see, as the code wasn't explicitly written

Re: [HACKERS] Refactoring standby mode logic

Heikki Linnakangas hlinnakan...@vmware.com writes: I'm not understanding the sequence difference well enough to comment here, but I think some people are currently playing tricks in their failover scripts with moving files directly to the pg_xlog of the server to be promoted. That's still

Re: [HACKERS] Refactoring standby mode logic

Hi, Heikki Linnakangas hlinnakan...@vmware.com writes: Attached is a patch to refactor that logic into a more straightforward state machine. It's always been a kind of a state machine, but it's been hard to see, as the code wasn't explicitly written that way. Any objections? On a quick glance

Re: [HACKERS] Refactoring simplify_function (was: Caching constant stable expressions)

On Fri, Mar 23, 2012 at 7:41 PM, Marti Raudsepp ma...@juffo.org wrote: Yeah, I'm still working on addressing the comments from your last email. Haven't had much time to work on it for the last 2 weeks, but I hope to finish most of it this weekend. Since the updated patch seems never to have

Re: [HACKERS] Refactoring simplify_function (was: Caching constant stable expressions)

Marti Raudsepp ma...@juffo.org writes: Per Tom's request, I split out this refactoring from my CacheExpr patch. Basically I'm just centralizing the eval_const_expressions_mutator() call on function arguments, from multiple different places to a single location. Without this, it would be a lot

Re: [HACKERS] Refactoring simplify_function (was: Caching constant stable expressions)

On Sat, Mar 24, 2012 at 01:17, Tom Lane t...@sss.pgh.pa.us wrote: I've applied a slightly-modified version of this after reconciling it with the protransform fixes. Cool, thanks!  I assume you are going to submit a rebased version of the main CacheExpr patch? Yeah, I'm still working on

Re: [HACKERS] Refactoring log_newpage

On Thu, Feb 2, 2012 at 7:26 AM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Well, you can obviously check the catalogs for that, but you must be assuming that you don't have access to the catalogs or this would be a non-issue. You can also identify the kind of page by

Re: [HACKERS] Refactoring log_newpage

On 02.02.2012 11:35, Simon Riggs wrote: On Thu, Feb 2, 2012 at 7:26 AM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Well, you can obviously check the catalogs for that, but you must be assuming that you don't have access to the catalogs or this would be a non-issue. You can

Re: [HACKERS] Refactoring log_newpage

Simon Riggs si...@2ndquadrant.com writes: On Wed, Feb 1, 2012 at 10:42 PM, Jim Nasby j...@nasby.net wrote: But we already had RelFileNode; wouldn't that be enough to tell what rmgr was responsible for the new page? Can 2 different rmgrs write to the same file node? No, but which one? No

Re: [HACKERS] Refactoring log_newpage

On Feb 1, 2012, at 4:25 AM, Simon Riggs wrote: At present log_newpage() produces log records called XLOG_HEAP_NEWPAGE. That routine is used by HEAP, BTREE, GIN, SPGIST rmgrs, as well as various forks. WAL contains no information as to which rmgr the data refers to, making debugging much

Re: [HACKERS] Refactoring log_newpage

On Wed, Feb 1, 2012 at 10:42 PM, Jim Nasby j...@nasby.net wrote: On Feb 1, 2012, at 4:25 AM, Simon Riggs wrote: At present log_newpage() produces log records called XLOG_HEAP_NEWPAGE. That routine is used by HEAP, BTREE, GIN, SPGIST rmgrs, as well as various forks. WAL contains no

Re: [HACKERS] Refactoring log_newpage

On 02.02.2012 08:19, Simon Riggs wrote: On Wed, Feb 1, 2012 at 10:42 PM, Jim Nasbyj...@nasby.net wrote: On Feb 1, 2012, at 4:25 AM, Simon Riggs wrote: At present log_newpage() produces log records called XLOG_HEAP_NEWPAGE. That routine is used by HEAP, BTREE, GIN, SPGIST rmgrs, as well as

Re: [HACKERS] Refactoring on DROP/ALTER SET SCHEMA/ALTER RENAME TO statement

2011/11/30 Robert Haas robertmh...@gmail.com: On Sun, Nov 27, 2011 at 3:14 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote: If we add new properties that required by AlterObjectNamespace, as you suggested, it will allow to reduce number of caller of this routine mechanically with small changes.

Re: [HACKERS] Refactoring on DROP/ALTER SET SCHEMA/ALTER RENAME TO statement

On Sun, Nov 27, 2011 at 3:14 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote: If we add new properties that required by AlterObjectNamespace, as you suggested, it will allow to reduce number of caller of this routine mechanically with small changes. Should I try this reworking with this way? Yeah,

Re: [HACKERS] Refactoring on DROP/ALTER SET SCHEMA/ALTER RENAME TO statement

2011/11/21 Robert Haas robertmh...@gmail.com: Now, what you have here is a much broader reworking.  And that's not necessarily bad, but at the moment I'm not really seeing how it benefits us. In my point, if individual object types need to have its own handler for alter commands, points of

Re: [HACKERS] Refactoring on DROP/ALTER SET SCHEMA/ALTER RENAME TO statement

On Sat, Nov 19, 2011 at 1:49 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote: But I'm not sure why we do.  My thought here was that we should extended the ObjectProperty array in objectaddress.c so that AlterObjectNamespace can get by with fewer arguments - specifically, it seems like the following

  1   2   >