On Mon, Sep 29, 2014 at 2:20 PM, Kevin Grittner kgri...@ymail.com wrote:
The claims that you can't get a duplicate key error with an UPSERT
are completely bogus, IMV. The *best* you can do is avoid them on
the index used for matching (unless you're willing to ignore
problem input rows or
Andres Freund wrote:
I'm generally baffled at all the stuff postmaster does in signal
handlers... ProcessConfigFile(), load_hba() et al. It's all done with
signals disabled, but still.
As far as I recall, the rationale for why this is acceptable is that the
whole of postmaster is run with
On 2014-09-29 18:44:34 -0300, Alvaro Herrera wrote:
Andres Freund wrote:
I'm generally baffled at all the stuff postmaster does in signal
handlers... ProcessConfigFile(), load_hba() et al. It's all done with
signals disabled, but still.
As far as I recall, the rationale for why this is
Peter Geoghegan p...@heroku.com wrote:
I think the fact that no MERGE implementation does what you want
should be convincing. It is *horrifically* complicated to make
what you want work, if indeed it is technically feasible at all.
Isn't this already complicated enough?
What about the MERGE
On 2014-09-29 14:57:45 -0700, Kevin Grittner wrote:
Peter Geoghegan p...@heroku.com wrote:
I think the fact that no MERGE implementation does what you want
should be convincing. It is *horrifically* complicated to make
what you want work, if indeed it is technically feasible at all.
I see the following Valgrind warnings in a recent build of the master branch:
--1159-- REDIR: 0x5f73450 (strstr) redirected to 0x4a25720 (_vgnU_ifunc_wrapper)
--1159-- REDIR: 0x5f88cb0 (__strstr_sse2_unaligned) redirected to
0x4c31fa0 (strstr)
2014-09-29 14:49:24.342 PDT 1159 LOG: statement:
On Mon, Sep 29, 2014 at 3:02 PM, Andres Freund and...@2ndquadrant.com wrote:
That'll make it really hard to actually implement real MERGE.
Because suddenly there's no way for the user to know whether he's
written a ON condition that can implement UPSERT like properties
(i.e. the *precise*
Andres Freund and...@2ndquadrant.com wrote:
On 2014-09-29 14:57:45 -0700, Kevin Grittner wrote:
The initial implementation could restrict to these exact clauses
and require that the boolean-expression used equality-quals on all
columns of a unique index on only NOT NULL columns.
That'll
On 2014-09-29 15:08:36 -0700, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com wrote:
On 2014-09-29 14:57:45 -0700, Kevin Grittner wrote:
The initial implementation could restrict to these exact clauses
and require that the boolean-expression used equality-quals on all
columns
Andres Freund and...@2ndquadrant.com wrote:
Wrong. You can't realistically implement the guarantees of UPSERT
without a corresponding UNIQUE index.
You definitely can do it; the question is what you consider
reasonable in terms of development effort, performance, and
concurrency. I think the
On 2014-09-29 15:16:49 -0700, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com wrote:
Wrong. You can't realistically implement the guarantees of UPSERT
without a corresponding UNIQUE index.
You definitely can do it; the question is what you consider
reasonable in terms of
On Mon, Sep 29, 2014 at 3:08 PM, Kevin Grittner kgri...@ymail.com wrote:
Well, unless we abandon transactional semantics for other MERGE
statements, we should have a way that UPSERT logic continues to
work if you don't match a suitable index; it will just be slower --
potentially a lot slower,
Andres Freund and...@2ndquadrant.com writes:
On 2014-09-29 18:44:34 -0300, Alvaro Herrera wrote:
As far as I recall, the rationale for why this is acceptable is that the
whole of postmaster is run with signals blocked; they are only unblocked
during the sleeping select().
Yea, I wrote that
On 2014-09-28 00:54:21 +0200, Andres Freund wrote:
On 2014-09-27 21:12:43 +0200, Andres Freund wrote:
On 2014-09-03 15:09:54 +0300, Heikki Linnakangas wrote:
Sorry, I missed this message and only cought up when reading your CF
status mail. I've attached three patches:
0001: Allows
On 2014-09-22 15:46:14 +0900, Michael Paquier wrote:
In the documentation of pg_recvlogical here
(http://www.postgresql.org/docs/devel/static/app-pgrecvlogical.html),
there is the following sentence:
Create a new logical replication slot with the name specified in
--slot, using the output
On Mon, Sep 29, 2014 at 12:30:40PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Thu, Sep 25, 2014 at 02:39:37PM -0400, Tom Lane wrote:
BTW, it seems like there is consensus that we ought to reorder the items
in a jsonb object to have keys first and then values,
On Mon, Sep 29, 2014 at 4:19 PM, Michael Paquier michael.paqu...@gmail.com
wrote:
Michael
Btw, while looking at your patch, I actually hacked it a bit and finished
with the attached:
- changed process to use NumericVar instead of Numeric
- addition of custom step values with a function
On Tue, Sep 30, 2014 at 10:00 AM, Michael Paquier michael.paqu...@gmail.com
wrote:
On Mon, Sep 29, 2014 at 4:19 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
Michael
Btw, while looking at your patch, I actually hacked it a bit and finished
with the attached:
- changed process
Since we bit the bullet and changed the on-disk format for JSONB data,
the core committee feels that we should put out a new 9.4 beta release
as soon as possible. Accordingly, we plan to wrap 9.4beta3 on Monday
(Oct 6) for release Thursday Oct 9.
regards, tom lane
--
On 09/30/2014 01:59 AM, Peter Geoghegan wrote:
On Mon, Sep 29, 2014 at 7:21 AM, Simon Riggs si...@2ndquadrant.com wrote:
If you were an ORM developer reading the PostgreSQL Release Notes for
9.5, which URL would you visit to see a complete description of the
new feature, including how it works
On 09/30/2014 05:57 AM, Kevin Grittner wrote:
Peter Geoghegan p...@heroku.com wrote:
I think the fact that no MERGE implementation does what you want
should be convincing. It is *horrifically* complicated to make
what you want work, if indeed it is technically feasible at all.
Isn't this
On Tue, Sep 30, 2014 at 3:44 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
The items I see are:
- Remove xloginsert_slots/xloginsert_locks GUC - Not yet!!
The text seems to indicate that there's some disagreement on this
point. I don't have a strong
On 09/30/2014 01:09 PM, Shay Rojansky wrote:
The idea of using extended query protocol for non-prepared queries
raised another best practices question, which I'm hoping you can help
with. To get rid of text encoding (which is locale-dependent,
inefficient etc.) for certain fields, it seems
101 - 123 of 123 matches
Mail list logo
