On Tue, Sep 30, 2014 at 10:22 PM, Michael Paquier
wrote:
>
> On Wed, Oct 1, 2014 at 10:03 AM, Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
>>
>> Done.
>
> You should consider adding that to the next commit fest.
>
Sure. Added [1]
Regards,
[1] https://commitfest.postgresql.org/actio
On Wed, Oct 1, 2014 at 10:03 AM, Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
> Done.
>
You should consider adding that to the next commit fest.
--
Michael
On Tue, Sep 30, 2014 at 9:12 PM, Josh Berkus wrote:
>
> On 09/30/2014 04:58 PM, Fabrízio de Royes Mello wrote:
> > On Tue, Sep 30, 2014 at 8:47 PM, Josh Berkus wrote:
> >>
> >> On 09/30/2014 04:16 PM, Andres Freund wrote:
> >>> On 2014-09-30 16:03:01 -0700, Josh Berkus wrote:
> On 09/30/2014
Hi Álvaro,
I have a stack trace from a crash to share, when querying a table with
a brin index. Let me know what else you need in addition to the stack trace:
#0 0x0077b0eb in pfree (pointer=0x1dcf1a8) at mcxt.c:754
#1 0x0045fe4a in bringetbitmap (fcinfo=) at brin.c:398
#2 0x0
On 09/30/2014 04:58 PM, Fabrízio de Royes Mello wrote:
> On Tue, Sep 30, 2014 at 8:47 PM, Josh Berkus wrote:
>>
>> On 09/30/2014 04:16 PM, Andres Freund wrote:
>>> On 2014-09-30 16:03:01 -0700, Josh Berkus wrote:
On 09/30/2014 03:53 PM, Andres Freund wrote:
> Good point. I think it's fair
On Tue, Sep 30, 2014 at 8:47 PM, Josh Berkus wrote:
>
> On 09/30/2014 04:16 PM, Andres Freund wrote:
> > On 2014-09-30 16:03:01 -0700, Josh Berkus wrote:
> >> On 09/30/2014 03:53 PM, Andres Freund wrote:
> >>> Good point. I think it's fair enough to only allow CINE on named
> >>> indexes.
> >>
> >
On 09/30/2014 04:16 PM, Andres Freund wrote:
> On 2014-09-30 16:03:01 -0700, Josh Berkus wrote:
>> On 09/30/2014 03:53 PM, Andres Freund wrote:
>>> Good point. I think it's fair enough to only allow CINE on named
>>> indexes.
>>
>> On the other hand, the way we form system-generated names is predic
On Tue, Sep 30, 2014 at 4:28 PM, Simon Riggs wrote:
> A clear description of the feature being added is necessary to agree
> its acceptance. When we implement a SQL Standard feature, we can just
> look in the standard to see how it should work and compare. When we go
> off-piste, we need more info
On 30 September 2014 19:49, Josh Berkus wrote:
> On 09/30/2014 11:20 AM, Peter Geoghegan wrote:
>>> > For example, this patch for UPSERT doesn't support updatable views.
>>> > But I can't see anyone that didn't read the patch would know that.
>> By reading the CREATE VIEW docs. Maybe there could s
On Mon, Sep 29, 2014 at 6:30 PM, Herwin Weststrate
wrote:
> Some devices send the MAC address in RADIUS requests in the format
> --. I've seen this with a 3com switch, but there may be
> others. Currently, postgresql doesn't understand this format.
>
> This patch adds an extra line to
On 2014-09-30 16:03:01 -0700, Josh Berkus wrote:
> On 09/30/2014 03:53 PM, Andres Freund wrote:
> > On 2014-09-30 18:47:24 -0400, Tom Lane wrote:
> >> Josh Berkus writes:
> >>> On 09/30/2014 02:43 PM, Tom Lane wrote:
> =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?=
> writes:
> > What's y
On 09/30/2014 03:53 PM, Andres Freund wrote:
> On 2014-09-30 18:47:24 -0400, Tom Lane wrote:
>> Josh Berkus writes:
>>> On 09/30/2014 02:43 PM, Tom Lane wrote:
=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes:
> What's your thoughts about we implement IF NOT EXISTS for CREATE INDEX?
>>
>>
On 2014-09-30 18:47:24 -0400, Tom Lane wrote:
> Josh Berkus writes:
> > On 09/30/2014 02:43 PM, Tom Lane wrote:
> >> =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes:
> >>> What's your thoughts about we implement IF NOT EXISTS for CREATE INDEX?
>
> >> It's got the same semantic problems as every
Josh Berkus writes:
> On 09/30/2014 02:43 PM, Tom Lane wrote:
>> =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes:
>>> What's your thoughts about we implement IF NOT EXISTS for CREATE INDEX?
>> It's got the same semantic problems as every other variant of CINE.
> I do think it should be name-bas
On Tue, Sep 30, 2014 at 7:01 PM, Josh Berkus wrote:
>
> On 09/30/2014 02:43 PM, Tom Lane wrote:
> > =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?=
writes:
> >> What's your thoughts about we implement IF NOT EXISTS for CREATE INDEX?
> >
> > It's got the same semantic problems as every other variant of C
On Tue, Sep 30, 2014 at 2:15 PM, Andres Freund wrote:
> Well. People have given you outlines of approaches. And Heikki even gave
> you a somewhat working prototype. I don't think you can fairly expect
> more.
I don't expect anything, really. I asked nicely - that's all. I don't
know why there is
Andres Freund wrote:
> On 2014-09-30 14:57:43 -0700, Josh Berkus wrote:
>
>> Regardless, I don't think there's any theoretical way to support
>> UPSERT without a unique constraint.
>
> You can do stuff like blocking predicate locking. But without indexes to
> support it that gets awfully complicat
Alvaro Herrera wrote:
> The attached patch implements that. I only tested it on HEAD, but
> AFAICS it applies cleanly to 9.4 and 9.3; fairly sure it won't apply to
> 9.2. Given the lack of complaints, I'm unsure about backpatching
> further back than 9.3 anyway.
FWIW my intention is to make sur
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 feedback on what people actually want). I think we should view
On 2014-09-30 17:01, Josh Berkus wrote:
> On 09/30/2014 02:43 PM, Tom Lane wrote:
> =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes:
> What's your thoughts about we implement IF NOT EXISTS for CREATE INDEX? It's
> got the same semantic problems as every other variant of CINE. If there were
On 2014-09-30 14:57:43 -0700, Josh Berkus wrote:
> Regardless, I don't think there's any theoretical way to support UPSERT
> without a unique constraint.
You can do stuff like blocking predicate locking. But without indexes to
support it that gets awfully complicated and unfunny. I don't think we
On Tue, Sep 30, 2014 at 3:01 PM, Andres Freund wrote:
> I think it'd be acceptable. Alternatively we'll just accept that you can
> get uniqueness violations under concurrency. I many cases that'll be
> fine.
I think living with unique violations is the right thing with MERGE, fwiw.
--
Peter Ge
On 2014-09-30 14:51:57 -0700, Kevin Grittner wrote:
> Josh Berkus wrote:
> > On 09/30/2014 02:39 PM, Kevin Grittner wrote:
> >> Josh Berkus wrote:
> >>> On 09/30/2014 07:15 AM, Kevin Grittner wrote:
> >>>
> At the risk of pushing people away from this POV, I'll point out
> that this is
On 09/30/2014 02:43 PM, Tom Lane wrote:
> =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes:
>> What's your thoughts about we implement IF NOT EXISTS for CREATE INDEX?
>
> It's got the same semantic problems as every other variant of CINE.
>
> If there were a huge groundswell of demand for it, may
On 09/30/2014 02:51 PM, Kevin Grittner wrote:
> Josh Berkus wrote:
>> On 09/30/2014 02:39 PM, Kevin Grittner wrote:
>>> Josh Berkus wrote:
On 09/30/2014 07:15 AM, Kevin Grittner wrote:
> At the risk of pushing people away from this POV, I'll point out
> that this is somewhat sim
Josh Berkus wrote:
> On 09/30/2014 02:39 PM, Kevin Grittner wrote:
>> Josh Berkus wrote:
>>> On 09/30/2014 07:15 AM, Kevin Grittner wrote:
>>>
At the risk of pushing people away from this POV, I'll point out
that this is somewhat similar to what we do for unlogged bulk loads
-- if
Since PostgreSQL started down that road for so many other relations, I
think many people just expect this to happen as a logical extension.
It certainly makes life a lot easier in combination with build
management systems.
/kirk
On 2014-09-30 16:43, Tom Lane wrote:
> =?UTF-8?Q?Fabr=C3=AD
On 09/30/2014 02:39 PM, Kevin Grittner wrote:
> Josh Berkus wrote:
>> On 09/30/2014 07:15 AM, Kevin Grittner wrote:
>
>>> At the risk of pushing people away from this POV, I'll point out
>>> that this is somewhat similar to what we do for unlogged bulk loads
>>> -- if all the conditions for doing
=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes:
> What's your thoughts about we implement IF NOT EXISTS for CREATE INDEX?
It's got the same semantic problems as every other variant of CINE.
If there were a huge groundswell of demand for it, maybe we'd hold our
noses and do it anyway. But I'm a
Josh Berkus wrote:
> On 09/30/2014 07:15 AM, Kevin Grittner wrote:
>> At the risk of pushing people away from this POV, I'll point out
>> that this is somewhat similar to what we do for unlogged bulk loads
>> -- if all the conditions for doing it the fast way are present, we
>> do it the fast way
Hi all,
What's your thoughts about we implement IF NOT EXISTS for CREATE INDEX? As
it holds data (like sequences and tables) I think we can do that.
Regards,
--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
>> Timbira: http://www.timbira.com.br
>> Blog: http://fabriziomello.github.io
On 2014-09-30 12:05:46 -0700, Peter Geoghegan wrote:
> On Tue, Sep 30, 2014 at 11:51 AM, Andres Freund
> wrote:
> > What's blocking it is that (afaik) no committer agrees with the approach
> > taken to solve the concurrency problems. And several (Heikki, Robert,
> > me) have stated their dislike
On 2014-09-30 13:42:11 -0700, Peter Geoghegan wrote:
> On Tue, Sep 30, 2014 at 12:57 PM, Christoph Berg wrote:
> > It's probably not really a PostgreSQL bug, but it seems easy enough to
> > rename that definition now as it's only present in 9.4+. It's only
> > used in one file, xlog.c: 375d8526f29
On Tue, Sep 30, 2014 at 12:57 PM, Christoph Berg wrote:
> It's probably not really a PostgreSQL bug, but it seems easy enough to
> rename that definition now as it's only present in 9.4+. It's only
> used in one file, xlog.c: 375d8526f2900d0c377f44532f6d09ee06531f67
I agree. It should be renamed
Please don't top post, initial context is important, especially Tom's! :-)
(see my reply below)
On 01/10/14 03:52, Bogdan Pilch wrote:
How about, the format of psql duration can be set via some ...
backslash command or commdn line switch? And the default of course
remains the current behavior?
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 definition now as it's only present in 9.4+. It's only
used in one file, x
On 30 September 2014 20:17, Stephen Frost wrote:
> * Dean Rasheed (dean.a.rash...@gmail.com) wrote:
>> On 30 September 2014 16:52, Stephen Frost wrote:
>> > If the user only has column-level privileges on the table then I'm not
>> > really sure how useful the detail will be.
>>
>> One of the main
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 30 September 2014 16:52, Stephen Frost wrote:
> > If the user only has column-level privileges on the table then I'm not
> > really sure how useful the detail will be.
>
> One of the main things that detail is useful for is identifying the
> f
On Tue, Sep 30, 2014 at 11:51 AM, Andres Freund wrote:
> What's blocking it is that (afaik) no committer agrees with the approach
> taken to solve the concurrency problems. And several (Heikki, Robert,
> me) have stated their dislike of the proposed approach.
Well, it depends on what you mean by
On 09/30/2014 07:15 AM, Kevin Grittner wrote:
> There are certainly other ways to do it, although they require more
> work. As far as UPSERT goes, I agree that we should require such
> an index, at least for the initial implementation and into the
> foreseeable future. What I'm saying is that if
On 09/30/2014 11:51 AM, Andres Freund wrote:
>> All of these things sound like good ideas for documentation
>> > improvements, but hardly anything which should block the patch. It has
>> > documentation, more than we'd require for a lot of other patches, and
>> > it's not like the 9.5 release is n
On 2014-09-30 11:49:21 -0700, Josh Berkus wrote:
> On 09/30/2014 11:20 AM, Peter Geoghegan wrote:
> >> > For example, this patch for UPSERT doesn't support updatable views.
> >> > But I can't see anyone that didn't read the patch would know that.
> > By reading the CREATE VIEW docs. Maybe there cou
How about, the format of psql duration can be set via some ...
backslash command or commdn line switch? And the default of course
remains the current behavior?
bogdan
> Andres Freund writes:
> > On 2014-09-28 20:32:30 -0400, Gregory Smith wrote:
> >> On 9/28/14, 7:49 AM, Bogdan Pilch wrote:
> >>>
Hello,
Some devices send the MAC address in RADIUS requests in the format
--. I've seen this with a 3com switch, but there may be
others. Currently, postgresql doesn't understand this format.
This patch adds an extra line to the macaddr parsing in postgres to
support this format as we
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).
On 09/30/2014 11:20 AM, Peter Geoghegan wrote:
>> > For example, this patch for UPSERT doesn't support updatable views.
>> > But I can't see anyone that didn't read the patch would know that.
> By reading the CREATE VIEW docs. Maybe there could stand to be a
> compatibility note in the main INSERT
On 30 September 2014 16:52, Stephen Frost wrote:
> * Dean Rasheed (dean.a.rash...@gmail.com) wrote:
>> On 29 September 2014 16:46, Stephen Frost wrote:
>> > * Robert Haas (robertmh...@gmail.com) wrote:
>> >> Well, I think that's an acceptable approach from the point of view of
>> >> fixing the se
On Tue, Sep 30, 2014 at 8:30 AM, Simon Riggs wrote:
> On 29 September 2014 18:59, Peter Geoghegan wrote:
>> On Mon, Sep 29, 2014 at 7:21 AM, Simon Riggs wrote:
>>> If you were an ORM developer reading the PostgreSQL Release Notes for
>>> 9.5, which URL would you visit to see a complete descripti
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 do it this week. Could you (or someone el
Peter,
* Peter Geoghegan (p...@heroku.com) wrote:
> I see the following Valgrind warnings in a recent build of the master branch:
[...]
> This appears a few times, but always seems to occur with the same call stack.
Many thanks, I've worked out the issue (rsecpolname needs to be filled
in with th
On Tue, Sep 30, 2014 at 8:30 AM, Simon Riggs wrote:
> No explanation of why the CONFLICTING() syntax differs from OLD./NEW.
> syntax used in triggers
Why should it be the same?
>>>
>>> Because it would be a principled approach to do that.
>>
>> That is just an assertion. The MERG
On 09/30/2014 04:56 AM, Heikki Linnakangas wrote:
> There seems to be no decisive consensus here. I'm going to put my foot
> on the ground and go remove it, as I'm leaning towards that option, and
> we need to get the release out. But if someone objects loudly enough to
> actually write the documen
2014-09-30 17:18 GMT+02:00 Alvaro Herrera :
>
> I have pushed this fix, except that instead of parsing the OID from the
> dropStmt as in your patch, I used te->catalogId.oid, which is much
> simpler.
>
yes, it is much better
>
> I tested this by pg_restoring to 8.4 (which doesn't have
> pg_larg
Heikki Linnakangas wrote:
> hash join - dynamic bucket count
> ---
>
> Kevin: Could you review the latest patch, please?
Will post a code review later today. Benchmarks might take a bit
longer...
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent v
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 29 September 2014 16:46, Stephen Frost wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> >> Well, I think that's an acceptable approach from the point of view of
> >> fixing the security exposure, but it's far from ideal. Good error
>
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 it up to
the user to decide what to do with dup
On 29 September 2014 18:59, Peter Geoghegan wrote:
> On Mon, Sep 29, 2014 at 7:21 AM, Simon Riggs 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 concurren
I have pushed this fix, except that instead of parsing the OID from the
dropStmt as in your patch, I used te->catalogId.oid, which is much
simpler.
I tested this by pg_restoring to 8.4 (which doesn't have
pg_largeobject_metadata); there is no error raised:
LOG: sentencia: SELECT CASE WHEN EXIST
On 09/30/2014 05:45 PM, Marko Tiikkaja wrote:
On 9/30/14 4:37 PM, Heikki Linnakangas wrote:
On 09/29/2014 05:38 PM, Marko Tiikkaja wrote:
Maybe I just suck at $SEARCH_ENGINE, but extracting armor headers
programmatically doesn't seem to be very popular. I could only find one
example, which ret
On Wed, Sep 17, 2014 at 01:07:56PM +, Matthew Kelly wrote:
> * Unless you keep _all_ of your clusters on the same OS, machines
> from your database spare pool probably won't be the right OS when you
> add them to the cluster because a member failed.
There has been discussion about having ma
Heikki Linnakangas wrote:
Happened to land on the middle of the regression test by accident and
noticed:
> +select armor('zooka', array['Version', 'Comment'], array['Created by
> pgcrypto', 'PostgreSQL, the world''s most most advanced open source
> database']);
> +
On 9/30/14 4:37 PM, Heikki Linnakangas wrote:
On 09/29/2014 05:38 PM, Marko Tiikkaja wrote:
Maybe I just suck at $SEARCH_ENGINE, but extracting armor headers
programmatically doesn't seem to be very popular. I could only find one
example, which returned the last instance of the key. But that s
On 09/29/2014 05:38 PM, Marko Tiikkaja wrote:
On 9/29/14 3:02 PM, Heikki Linnakangas wrote:
Is there any real life examples or tools out there to generate armors
with headers with duplicate keys? RFC 4880 says:
Note that some transport methods are sensitive to line length. While
the
Peter Geoghegan wrote:
> On Mon, Sep 29, 2014 at 3:08 PM, Kevin Grittner 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 --
>> potential
On 2014-10-01 01:03:35 +1300, David Rowley wrote:
> On Wed, Oct 1, 2014 at 12:01 AM, Andres Freund
> wrote:
>
> > On 2014-09-30 23:25:45 +1300, David Rowley wrote:
> > >
> > > I've not quite gotten my head around how we might stop the unneeded
> > > relation from being the primary path to join th
On Wed, Oct 1, 2014 at 12:01 AM, Andres Freund
wrote:
> On 2014-09-30 23:25:45 +1300, David Rowley wrote:
> >
> > I've not quite gotten my head around how we might stop the unneeded
> > relation from being the primary path to join the other inner relations,
> > i.e. what would stop the planner ma
On 09/29/2014 11:41 PM, Andres Freund wrote:
On 2014-09-29 16:35:12 -0400, Tom Lane wrote:
Andres Freund writes:
On 2014-09-29 16:16:38 -0400, Tom Lane wrote:
I wonder why it's a fixed constant at all, and not something like
"wal_buffers / 8".
Because that'd be horrible performancewise on
On 2014-09-30 23:25:45 +1300, David Rowley wrote:
> On Tue, Sep 30, 2014 at 12:42 AM, Andres Freund
> wrote:
>
> > On 2014-09-29 22:42:57 +1300, David Rowley wrote:
> >
> > > I've made a change to the patch locally to ignore foreign
> > > keys that are marked as deferrable.
> >
> > I have serious
On Tue, Sep 30, 2014 at 12:42 AM, Andres Freund
wrote:
> On 2014-09-29 22:42:57 +1300, David Rowley wrote:
>
> > I've made a change to the patch locally to ignore foreign
> > keys that are marked as deferrable.
>
> I have serious doubts about the general usefulness if this is onlyu
> going to be
On 2014-09-26 21:02:16 +0300, Heikki Linnakangas wrote:
> I propose the attached patch. It adds a new flag ImmediateDieOK, which is a
> weaker form of ImmediateInterruptOK that only allows handling a pending
> die-signal in the signal handler.
>
> Robert, others, do you see a problem with this?
P
On 09/30/2014 10:05 AM, Kyotaro HORIGUCHI wrote:
By the way,
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.postgresq
On 29 September 2014 16:46, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> Well, I think that's an acceptable approach from the point of view of
>> fixing the security exposure, but it's far from ideal. Good error
>> messages are important for usability. I can live with t
By the way,
> 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?
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hacker
73 matches
Mail list logo
