Here is the comments in process_matched_tle() in rewriteHandler.c.
883 * such nodes; consider
884 * UPDATE tab SET col.fld1.subfld1 = x, col.fld2.subfld2 = y
885 * The two expressions produced by the parser will look like
886 * FieldStore(col, fld1, FieldStore(placeho
> >> Sorry, I missed this message and only cought up when reading your CF
> >> status mail. I've attached three patches:
> >
> > Could let me know how to get the CF status mail?
>
> I think he meant this email I sent last weekend:
>
> http://www.postgresql.org/message-id/542672d2.3060...@vmware.c
On 10/02/2014 07:52 AM, Peter Geoghegan wrote:
> Having been surprisingly successful at advancing our understanding of
> arguments for and against various approaches to "value locking", I
> decided to try the same thing out elsewhere. I have created a
> general-purpose UPSERT wiki page.
>
> The pa
On 10/02/2014 03:06 AM, Peter Geoghegan wrote:
> In my view, it makes sense to fix that, and to make INSERT ... ON
> CONFLICT IGNORE work with exclusion constraints. However, it does not
> make sense to have INSERT ... ON CONFLICT UPDATE work with exclusion
> constraints. The user-visible semantics
On 10/02/2014 12:19 AM, Ilya Kosmodemiansky wrote:
> From an Oracle DBA's point of view, currently we have a lack of
> performance diagnostics tools.
Agreed. Sometimes very frustratingly so.
> Even better idea is to collect daily LWLock distribution, find most
> frequent of them etc.
While we
Adam,
* Brightwell, Adam (adam.brightw...@crunchydatasolutions.com) wrote:
> > We, as a community, have gotten flak from time-to-time about the
> > superuser role. We also tend to wish to avoid unnecessary
> > optimization as it complicates the code base and makes folks reviewing
> > the c
Tomas Vondra wrote:
> On 12.9.2014 23:22, Robert Haas wrote:
>> My first thought is to revert to NTUP_PER_BUCKET=1, but it's
>> certainly arguable. Either method, though, figures to be better than
>> doing nothing, so let's do something.
>
> OK, but can we commit the remaining part first? Because
Having been surprisingly successful at advancing our understanding of
arguments for and against various approaches to "value locking", I
decided to try the same thing out elsewhere. I have created a
general-purpose UPSERT wiki page.
The page is: https://wiki.postgresql.org/wiki/UPSERT
Right now,
On Wed, Oct 1, 2014 at 2:42 PM, Simon Riggs wrote:
>> GiST supports exclusion constraints. That is one of the main reasons I want
>> to do promise tuples, instead of locking within the indexam: to support this
>> feature with exclusion constraints.
>
> That does sound interesting, but I am concern
Stephen,
We, as a community, have gotten flak from time-to-time about the
> superuser role. We also tend to wish to avoid unnecessary
> optimization as it complicates the code base and makes folks reviewing
> the code wonder at the exceptions.
>
I have attached a patch for consideration/
2014-10-02 0:41 GMT+09:00 Merlin Moncure :
> On Tue, Jul 8, 2014 at 6:55 AM, Kouhei Kaigai wrote:
>> * Syntax also reflects what the command does more. New syntax to
>> define custom plan provider is:
>> CREATE CUSTOM PLAN PROVIDER
>> FOR HANDLER ;
>
> -1 on 'cpp' prefix. I don't se
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Sep 29, 2014 at 12:05 PM, Stephen Frost wrote:
> > Perhaps I'm just being a bit over the top, but all this per-character
> > work feels a bit ridiculous.. When we're using MAXIMUM_ALIGNOF, I
> > suppose it's not so bad, but is there no hope t
On Wed, Oct 1, 2014 at 12:54 PM, Heikki Linnakangas
wrote:
> XactLockTableWait() waits until the end of transaction, that's not you want
> here. If the backend that inserted the promise tuple decides to not proceed
> with the insertion, and removes the promise tuple, the backend waiting on it
> ne
On Wed, Oct 1, 2014 at 4:34 AM, Simon Riggs wrote:
> Summary of algorithm to use "promise tuples" for concurrency control
> during UPSERT
> Index bloat is less of a problem than with normal inserts since there
> are additional ways of removing promise tuples. Only one index tuple
> at a time can
On 10/01/2014 02:34 PM, Simon Riggs wrote:
Summary of algorithm to use "promise tuples" for concurrency control
during UPSERT
1. Perform btree search to location of key, if it exists.
a) If an unkilled index tuple exists, we decide this is an UPDATE and
drop straight thru to step 2
b) If it does
On Wed, Oct 1, 2014 at 11:44 AM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> This kind of seems like throwing darts at the wall. It could be
>> better if we are right to skip the database already being vacuumed for
>> wraparound, or worse if we're not.
>
> Well, it only skips the DB for half th
On Wed, Oct 1, 2014 at 6:49 AM, Heikki Linnakangas
wrote:
> Well, if nothing else, it would be nice to fix the concurrency issue we have
> with exclusion constraints today, which is that if two backends insert the
> same value at the same time, they might both get an error, even though you'd
> onl
On 2014-10-01 20:54:39 +0200, Andres Freund wrote:
> Here we go.
>
> Postgres was configured with.
> -c shared_buffers=8GB \
> -c log_line_prefix="[%m %p] " \
> -c log_min_messages=debug1 \
> -p 5440 \
> -c checkpoint_segments=600
> -c max_connections=200
Robert reminded me that I missed to
On Wed, Oct 1, 2014 at 4:23 AM, Simon Riggs wrote:
> Quoting general research and other points about value locking are
> reasonable in the general section, but not in the description for 1.
I also made a similar comparison of #3. I don't think that reflects a bias.
> I'm glad you've called the f
On 2014-09-25 16:50:44 +0200, Andres Freund wrote:
> On 2014-09-25 10:44:40 -0400, Robert Haas wrote:
> > On Thu, Sep 25, 2014 at 10:42 AM, Robert Haas wrote:
> > > On Thu, Sep 25, 2014 at 10:24 AM, Andres Freund
> > > wrote:
> > >> On 2014-09-25 10:22:47 -0400, Robert Haas wrote:
> > >>> On Thu
On 10/01/2014 01:32 PM, Andres Freund wrote:
On 2014-10-01 13:22:53 -0400, Jan Wieck wrote:
On 10/01/2014 01:19 PM, Andres Freund wrote:
>On 2014-10-01 13:17:17 -0400, Jan Wieck wrote:
-static void StreamLog();
+static void StreamLogicalLog();
Not related at all to those patches, but
On 2014-10-01 13:22:53 -0400, Jan Wieck wrote:
> On 10/01/2014 01:19 PM, Andres Freund wrote:
> >On 2014-10-01 13:17:17 -0400, Jan Wieck wrote:
> -static void StreamLog();
> +static void StreamLogicalLog();
> Not related at all to those patches, but for correctness it is better to
> >>>
On 10/01/2014 01:19 PM, Andres Freund wrote:
On 2014-10-01 13:17:17 -0400, Jan Wieck wrote:
>>-static void StreamLog();
>>+static void StreamLogicalLog();
>>Not related at all to those patches, but for correctness it is better to
>>add a declaration "(void)".
>
>Agreed.
>
>>Except those small th
On 2014-10-01 13:17:17 -0400, Jan Wieck wrote:
> >>-static void StreamLog();
> >>+static void StreamLogicalLog();
> >>Not related at all to those patches, but for correctness it is better to
> >>add a declaration "(void)".
> >
> >Agreed.
> >
> >>Except those small things the changes look good to me
On 10/01/2014 08:59 AM, Andres Freund wrote:
On 2014-10-01 21:54:56 +0900, Michael Paquier wrote:
Thanks!
On Wed, Oct 1, 2014 at 8:38 PM, Andres Freund
wrote:
> 0001) Old WIP patch for pg_recvlogical tests. Useful for easier
> development.
>
From where is this patch? Is it some rest from the
On 01-10-14 01:19, Michael Paquier wrote:
> Looking at your patch, you should update the documentation as well,
> the list of authorized outputs being clearly listed:
> http://www.postgresql.org/docs/devel/static/datatype-net-types.html#DATATYPE-MACADDR
> This consists in adding simply one line to
Hi
SQL:2003 introduced the function NEXT VALUE FOR . Google
tells me that at least DB2, SQL Server and a few niche databases
understand it so far. As far as I can tell there is no standardised
equivalent of currval and setval (but I only have access to second
hand information about the standard,
Hi,
I have a patch which is actually not commitfest-ready now, but it
always better to start discussing proof of concept having some patch
instead of just an idea.
Since I'am a DBA rather than C programmer, I will appreciate any
suggestions/critics about the patch and code quality to make things
Hi,
I pushed the first part.
On 2014-10-01 21:54:56 +0900, Michael Paquier wrote:
> On Wed, Oct 1, 2014 at 8:38 PM, Andres Freund
> wrote:
> > 0001) Old WIP patch for pg_recvlogical tests. Useful for easier
> > development.
> From where is this patch? Is it some rest from the time when pg_recvlo
Robert Haas wrote:
> This kind of seems like throwing darts at the wall. It could be
> better if we are right to skip the database already being vacuumed for
> wraparound, or worse if we're not.
Well, it only skips the DB for half the naptime interval, so that other
databases have a chance to be
On Tue, Jul 8, 2014 at 6:55 AM, Kouhei Kaigai wrote:
> * Syntax also reflects what the command does more. New syntax to
> define custom plan provider is:
> CREATE CUSTOM PLAN PROVIDER
> FOR HANDLER ;
-1 on 'cpp' prefix. I don't see acronyms used in the syntax
documentation and cpp
On Tue, Sep 30, 2014 at 5:59 PM, Alvaro Herrera
wrote:
> Jeff Janes wrote:
>> > I think that instead of
>> > trying to get a single target database in that foreach loop, we could
>> > try to build a prioritized list (in-wraparound-danger first, then
>> > in-multixid-wraparound danger, then the one
On Tue, Sep 30, 2014 at 6:16 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> I favor option (a). There's something to be said for your proposal
>> in terms of logical consistency with what we have now, but to be
>> honest I'm not sure it's the behavior anyone wants (I would welcome
>> more fee
On Wed, Oct 1, 2014 at 10:50 AM, Andres Freund wrote:
> On 2014-10-01 10:45:13 -0400, Robert Haas wrote:
>> On Wed, Oct 1, 2014 at 7:00 AM, Andres Freund wrote:
>> > On 2014-09-29 14:46:20 -0400, Robert Haas wrote:
>> >> This happened again, and I investigated further.
>> >
>> > Uh. Interestingly
On 2014-10-01 10:45:13 -0400, Robert Haas wrote:
> On Wed, Oct 1, 2014 at 7:00 AM, Andres Freund wrote:
> > On 2014-09-29 14:46:20 -0400, Robert Haas wrote:
> >> This happened again, and I investigated further.
> >
> > Uh. Interestingly anole just succeeded twice:
> > http://buildfarm.postgresql.o
On Wed, Oct 1, 2014 at 7:00 AM, Andres Freund wrote:
> On 2014-09-29 14:46:20 -0400, Robert Haas wrote:
>> This happened again, and I investigated further.
>
> Uh. Interestingly anole just succeeded twice:
> http://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=anole&br=REL9_4_STABLE
>
> I pl
On Mon, Sep 29, 2014 at 12:06 PM, searcher s wrote:
> Hi,
> I am using postgres 9.2.2.
> The postgresql documentation says, full_page_writes is forcibly on after
> executing the function pg_start_backup. But in my server full_page_writes is
> still off (not changed).
The value of the GUC doe
On 2014-10-01 11:21:12 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
>
> > From d667f7a63cd62733d88ec5b7228dfd5d7136b9d7 Mon Sep 17 00:00:00 2001
> > From: Michael Paquier
> > Date: Mon, 1 Sep 2014 20:48:43 +0900
> > Subject: [PATCH 3/4] Refactoring of pg_basebackup utilities
> >
> > Code
On 09/30/2014 09:10 PM, Gregory Smith wrote:
On 9/29/14, 2:30 PM, Andres Freund wrote:
Can we explain those reasons in the form of documentation?
Yes. Try and benchmark it. It'll be hardware and workload dependant.
I missed this whole thing, and eventually I have to circle back to it.
I could
Andres Freund wrote:
> From d667f7a63cd62733d88ec5b7228dfd5d7136b9d7 Mon Sep 17 00:00:00 2001
> From: Michael Paquier
> Date: Mon, 1 Sep 2014 20:48:43 +0900
> Subject: [PATCH 3/4] Refactoring of pg_basebackup utilities
>
> Code duplication is reduced with the introduction of new APIs for each
>
On 10/01/2014 04:46 PM, Simon Riggs wrote:
On 1 October 2014 14:31, Simon Riggs wrote:
On 1 October 2014 13:43, Heikki Linnakangas wrote:
That does sound interesting, but I am concerned the semantics may cause
issues.
If I go to insert a row for 'UK' and find an existing row for
'Europe', d
On 9/29/14, 1:08 AM, Andres Freund wrote:
On 2014-09-28 20:32:30 -0400, Gregory Smith wrote:
There are already a wide range of human readable time interval output
formats available in the database; see the list at
http://www.postgresql.org/docs/current/static/datatype-datetime.html#INTERVAL-STY
On 10/01/2014 04:31 PM, Simon Riggs wrote:
On 1 October 2014 13:43, Heikki Linnakangas wrote:
That does sound interesting, but I am concerned the semantics may cause
issues.
If I go to insert a row for 'UK' and find an existing row for
'Europe', do we really want to update the population of E
On 1 October 2014 14:31, Simon Riggs wrote:
> On 1 October 2014 13:43, Heikki Linnakangas wrote:
>
>>> That does sound interesting, but I am concerned the semantics may cause
>>> issues.
>>>
>>> If I go to insert a row for 'UK' and find an existing row for
>>> 'Europe', do we really want to updat
On 1 October 2014 13:43, Heikki Linnakangas wrote:
>> That does sound interesting, but I am concerned the semantics may cause
>> issues.
>>
>> If I go to insert a row for 'UK' and find an existing row for
>> 'Europe', do we really want to update the population of Europe to be
>> the population of
On 10/01/2014 02:47 PM, Marko Tiikkaja wrote:
On 10/1/14 1:01 PM, Heikki Linnakangas wrote:
I think this is now ready for commit, but since I've changed it quite
significantly from what you originally submitted, please take a moment
to review this.
1) I see this compiler warning:
pg
On 2014-10-01 21:54:56 +0900, Michael Paquier wrote:
> Thanks!
>
> On Wed, Oct 1, 2014 at 8:38 PM, Andres Freund
> wrote:
>
> > 0001) Old WIP patch for pg_recvlogical tests. Useful for easier
> > development.
> >
> From where is this patch? Is it some rest from the time when pg_recvlogical
> was
Thanks!
On Wed, Oct 1, 2014 at 8:38 PM, Andres Freund
wrote:
> 0001) Old WIP patch for pg_recvlogical tests. Useful for easier
> development.
>
>From where is this patch? Is it some rest from the time when pg_recvlogical
was developed?
> 0002) Copy editing that should be in 9.4
>
Definitely ma
On 10/01/2014 02:42 PM, Simon Riggs wrote:
On 1 October 2014 11:58, Heikki Linnakangas wrote:
On 10/01/2014 01:50 PM, Simon Riggs wrote:
On 1 October 2014 10:44, Heikki Linnakangas
wrote:
I didn't realize that "promise index tuples" were even seriously
discussed.
I guess that can be made t
Hi all,
We already have IF NOT EXISTS for CREATE TABLE. There are some reason to
don't have to CREATE TABLE AS and CREATE MATERIALIZED VIEW??
Regards,
--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
>> Timbira: http://www.timbira.com.br
>> Blog: http://fabriziomello.github.io
>> Link
On 10/1/14 1:01 PM, Heikki Linnakangas wrote:
On 10/01/2014 11:58 AM, Marko Tiikkaja wrote:
On 10/1/14, 9:11 AM, Heikki Linnakangas wrote:
We have two options:
1. Throw an error if there are any non-ASCII characters in the key/value
arrays.
2. Don't convert them to UTF-8, but use the current d
On 1 October 2014 11:58, Heikki Linnakangas wrote:
> On 10/01/2014 01:50 PM, Simon Riggs wrote:
>>
>> On 1 October 2014 10:44, Heikki Linnakangas
>> wrote:
>>
>>> I didn't realize that "promise index tuples" were even seriously
>>> discussed.
>>> I guess that can be made to work, too, although I
On Wed, Oct 1, 2014 at 7:57 AM, José Luis Tallón
wrote:
>
> [snip]
>
> Please excuse my jumping in, but the EXPECTED syntax is:
>
> CREATE INDEX IF NOT EXISTS .
>
> whereas your current patch implements:
>
> CREATE [IF NOT EXISTS] INDEX
>
>
> if I'm reading the grammar correctly.
>
I thi
Hi,
I've split and edited patch 0001:
0001) Old WIP patch for pg_recvlogical tests. Useful for easier development.
0002) Copy editing that should be in 9.4
0003) Rebased patches of yours
0004) My changes to 0003 besides the rebase. This'll be squashed, but I
thought it might be interesting f
Summary of algorithm to use "promise tuples" for concurrency control
during UPSERT
1. Perform btree search to location of key, if it exists.
a) If an unkilled index tuple exists, we decide this is an UPDATE and
drop straight thru to step 2
b) If it does not exist, insert a "promise" tuple into uni
On 2014-09-26 16:19:33 -0700, Peter Geoghegan wrote:
> On Fri, Sep 26, 2014 at 3:25 PM, Peter Geoghegan wrote:
> > On Fri, Sep 26, 2014 at 3:11 PM, Alvaro Herrera
> > wrote:
> >> FWIW there are 28 callers of HeapTupleHeaderGetXmin.
>
> > Don't forget about direct callers to HeapTupleHeaderGetRaw
On 1 October 2014 09:44, Peter Geoghegan wrote:
> In the hope of unblocking things, I have created this Wiki page, which
> details the advantages and disadvantages of all 3 approaches that have
> been discussed, as suggested by myself and others:
>
> https://wiki.postgresql.org/wiki/Value_locking
On 10/01/2014 11:58 AM, Marko Tiikkaja wrote:
On 10/1/14, 9:11 AM, Heikki Linnakangas wrote:
We have two options:
1. Throw an error if there are any non-ASCII characters in the key/value
arrays.
2. Don't convert them to UTF-8, but use the current database encoding.
Both seem sane to me. If we
On 2014-09-29 14:46:20 -0400, Robert Haas wrote:
> This happened again, and I investigated further.
Uh. Interestingly anole just succeeded twice:
http://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=anole&br=REL9_4_STABLE
I plan to commit the mask/unmask patch regardless, but it's curious.
On 10/01/2014 01:50 PM, Simon Riggs wrote:
On 1 October 2014 10:44, Heikki Linnakangas wrote:
I didn't realize that "promise index tuples" were even seriously discussed.
I guess that can be made to work, too, although I don't see the point. It
wouldn't work with GiST indexes, for the same reas
On 1 October 2014 10:44, Heikki Linnakangas wrote:
> I didn't realize that "promise index tuples" were even seriously discussed.
> I guess that can be made to work, too, although I don't see the point. It
> wouldn't work with GiST indexes, for the same reasons as page-level locking
> won't work (
On 2014-09-30 21:57:56 +0200, Christoph Berg wrote:
> Hi,
>
> there's a #define clash between pg_config_manual.h and FreeBSD's
> /usr/include/machine-amd64/param.h which also defines CACHE_LINE_SIZE.
>
> It's probably not really a PostgreSQL bug, but it seems easy enough to
> rename that definiti
On 2014-10-01 12:44:25 +0300, Heikki Linnakangas wrote:
> I didn't realize that "promise index tuples" were even seriously discussed.
> I guess that can be made to work, too, although I don't see the point. It
> wouldn't work with GiST indexes, for the same reasons as page-level locking
> won't wor
On 10/01/2014 11:49 AM, Andres Freund wrote:
On 2014-10-01 01:44:04 -0700, Peter Geoghegan wrote:
In the hope of unblocking things, I have created this Wiki page, which
details the advantages and disadvantages of all 3 approaches that have
been discussed, as suggested by myself and others:
http
On 10/1/14, 9:11 AM, Heikki Linnakangas wrote:
I spent a little time cleaning up the regression tests and docs, and
ended up with the attached. But then I realized that there's a problem
with UTF-8 conversion in the armor() function. It returns the armored
blob as text, but forcibly converts the
On 2014-10-01 01:44:04 -0700, Peter Geoghegan wrote:
> In the hope of unblocking things, I have created this Wiki page, which
> details the advantages and disadvantages of all 3 approaches that have
> been discussed, as suggested by myself and others:
>
> https://wiki.postgresql.org/wiki/Value_loc
The current approach to "value locking" remains a controversial aspect
of my INSERT ... ON CONFLICT UPDATE patch. I must admit that this is a
very complicated area, and it's difficult to keep things straight,
particularly with the relevant discussion scattered all over the
place.
In the hope of un
On 09/30/2014 06:39 PM, Marko Tiikkaja wrote:
On 9/30/14 5:17 PM, Heikki Linnakangas wrote:
I'm actually now leaning towards providing just a single function,
pgp_armor_headers(text, key OUT text, value OUT text), which returns all
the keys and values. That gives maximum flexibility, and leaves
On Wed, Aug 27, 2014 at 3:53 PM, Michael Paquier
wrote:
> On Wed, Aug 27, 2014 at 3:41 PM, Andres Freund
> wrote:
> > Can you add it to the next CF? I'll try to look earlier, but can't
> > promise anything.
> >
> > I very much would like this to get committed in some form or another.
> Added it
69 matches
Mail list logo
