On Wed, Nov 19, 2014 at 8:56 PM, Robert Haas wrote:
>
> On Tue, Nov 18, 2014 at 8:53 AM, Amit Kapila
wrote:
> >> After thinking about these cases for a bit, I came up with a new
> >> possible approach to this problem. Suppose that, at the beginning of
> >> parallelism, when we decide to start up
On Fri, Nov 21, 2014 at 2:06 AM, Heikki Linnakangas wrote:
> As you may have noticed, I committed this (after some more cleanup). Of
> course, feel free to still review it, and please point out any issues you
> may find.
>
This comment on top of XLogRecordAssemble is not adapted as
page_writes_o
On Thu, 2014-11-20 at 13:42 -0800, Peter Geoghegan wrote:
> > I am a developer of the Django ORM. Django reports to the user whether a
> > row was inserted or updated. It is possible to know which rows were
> > inserted by returning the primary key value. If something is returned,
> > then it was a
Hi all,
Please find attached a simple patch adding fillfactor as storage parameter
for GIN indexes. The default value is the same as the one currently aka 100
to have the pages completely packed when a GIN index is created.
Note that to have this feature correctly working, the fix I sent yesterda
I thought it might be useful to add a few words at the top
of 'src/test/regress/regress.c' to explain what it does and
to help differentiate it from 'pg_regress.c' and
'pg_regress_main.c'.
Regards
Ian Barwick
--
Ian Barwick http://www.2ndQuadrant.com/
PostgreSQL Development
On Thu, Nov 20, 2014 at 10:36 PM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
>
> As you may have noticed, I committed this (after some more cleanup). Of
course, feel free to still review it, and please point out any issues you
may find.
>
Few minor observations:
1. Readme
void XLogReset
On 11/20/2014 01:47 PM, Tom Lane wrote:
> Josh Berkus writes:
>> Well, the first thing that comes to mind is that template0 should be
>> "permanently frozen". That is, all objects in it should be created with
>> frozen xid and mxids. After all, nobody can modify anything in it.
>
> That sounds
> On Thu, Nov 20, 2014 at 7:10 PM, Tom Lane wrote:
> > I've done some preliminary cleanup on this patch, but I'm still pretty
> > desperately unhappy about some aspects of it, in particular the way
> > that it gets custom scan providers directly involved in setrefs.c,
> > finalize_primnode, and re
> Robert Haas writes:
> > I've committed parts 1 and 2 of this, without the documentation, and
> > with some additional cleanup. I am not sure that this feature is
> > sufficiently non-experimental that it deserves to be documented, but
> > if we're thinking of doing that then the documentation n
On 2014-11-20 20:21:07 -0500, Robert Haas wrote:
> On Thu, Nov 20, 2014 at 4:45 PM, Andres Freund wrote:
> >> And you haven't answered how you'd like to fix that. The
> >> only answer you've given so far, that I can see, is that maybe we can
> >> foresee all the locks that the child might take an
On Thu, Nov 20, 2014 at 7:10 PM, Tom Lane wrote:
> I've done some preliminary cleanup on this patch, but I'm still pretty
> desperately unhappy about some aspects of it, in particular the way that
> it gets custom scan providers directly involved in setrefs.c,
> finalize_primnode, and replace_nest
On Thu, Nov 20, 2014 at 4:45 PM, Andres Freund wrote:
>> And you haven't answered how you'd like to fix that. The
>> only answer you've given so far, that I can see, is that maybe we can
>> foresee all the locks that the child might take and not initiate
>> parallelism if any of them conflict wit
Robert Haas writes:
> I've committed parts 1 and 2 of this, without the documentation, and
> with some additional cleanup. I am not sure that this feature is
> sufficiently non-experimental that it deserves to be documented, but
> if we're thinking of doing that then the documentation needs a lot
On 19/11/14 17:30, Steve Singer wrote:
On 11/19/2014 08:22 AM, Alvaro Herrera wrote:
I think we're overblowing the pg_upgrade issue. Surely we don't need to
preserve commit_ts data when upgrading across major versions; and
pg_upgrade is perfectly prepared to remove old data when upgrading
(act
On 2014-11-17 21:03:07 +0100, Tomas Vondra wrote:
> On 17.11.2014 19:46, Andres Freund wrote:
> > On 2014-11-17 19:42:25 +0100, Tomas Vondra wrote:
> >> On 17.11.2014 18:04, Andres Freund wrote:
> >>> Hi,
> >>>
> >>> On 2014-11-16 23:31:51 -0800, Jeff Davis wrote:
> *** a/src/include/nodes/mem
On Thu, Nov 20, 2014 at 1:42 PM, Peter Geoghegan wrote:
> Would you be happy to just know that certain
> rows were either inserted or updated in the context of an UPSERT (and
> not cancelled by a BEFORE ROW INSERT or UPDATE trigger returning
> NULL)
Of course, having the WHERE clause in the auxil
On 2014-11-05 17:10:17 -0500, Adam Brightwell wrote:
> Attached is two separate patches to address previous
> comments/recommendations:
>
> * superuser-cleanup-shortcuts_11-5-2014.patch
> * has_privilege-cleanup_11-5-2014.patch
>
> -Adam
>
> --
> Adam Brightwell - adam.brightw...@crunchydatasol
On 11/5/14 5:10 PM, Adam Brightwell wrote:
> Attached is two separate patches to address previous
> comments/recommendations:
>
> * superuser-cleanup-shortcuts_11-5-2014.patch
Seeing that the regression tests had to be changed in this patch
indicates that there is a change of functionality, even
Josh Berkus writes:
> Well, the first thing that comes to mind is that template0 should be
> "permanently frozen". That is, all objects in it should be created with
> frozen xid and mxids. After all, nobody can modify anything in it.
That sounds about as unsafe as can be. You can't stop superu
Andres Freund-3 wrote
> I think something simplistic like levenshtein, even with modified
> distances, is good to catch typos. But not to find terms that are
> related in more complex ways.
Tom Lane-2 wrote
> The big picture is that this is more or less our first venture into
> heuristic suggest
On 2014-11-20 15:47:39 -0500, Robert Haas wrote:
> On Thu, Nov 20, 2014 at 3:15 PM, Andres Freund wrote:
> >> Haven't I responded to this a few times already?
> > Not in a particularly convincing way at least.
>
> That's not a very helpful response.
Well...
> >> I see no way, even theoretically
On Wed, Nov 19, 2014 at 10:37 PM, Anssi Kääriäinen
wrote:
> I think the biggest problem with the current approach is that there is
> no way to know if a row was skipped by the where clause when using
> INSERT ON CONFLICT UPDATE ... WHERE.
Well, there could have always been an UPDATE in a trigger
On 11/20/2014 01:03 PM, Robert Haas wrote:
> On Thu, Nov 20, 2014 at 3:44 PM, Josh Berkus wrote:
>>> So that we can have two ways to lose data?
>>>
>>> Forbidding connections to a database doesn't prevent XID or MXID wraparound.
>>
>> It does prevent the user from doing anything about it, though,
Robert Haas wrote:
> On Thu, Nov 20, 2014 at 3:44 PM, Josh Berkus wrote:
> >> So that we can have two ways to lose data?
> >>
> >> Forbidding connections to a database doesn't prevent XID or MXID
> >> wraparound.
> >
> > It does prevent the user from doing anything about it, though, since
> > the
On Thu, Nov 20, 2014 at 3:44 PM, Josh Berkus wrote:
>> So that we can have two ways to lose data?
>>
>> Forbidding connections to a database doesn't prevent XID or MXID wraparound.
>
> It does prevent the user from doing anything about it, though, since
> they can't manually vacuum template0 witho
On Thu, Nov 20, 2014 at 12:50 PM, Robert Haas wrote:
> I've got a few +1s, too, if you notice.
Then maybe I spoke too soon.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-
On Thu, Nov 20, 2014 at 3:20 PM, Peter Geoghegan wrote:
> On Thu, Nov 20, 2014 at 12:14 PM, Robert Haas wrote:
>> Seems fine to me. If you typed relid rather than indexrelid or key
>> rather than indkey, that's a thinko, not a typo. ikey for indkey
>> could plausible be a typo, though you'd hav
On Thu, Nov 20, 2014 at 3:15 PM, Andres Freund wrote:
>> Haven't I responded to this a few times already?
> Not in a particularly convincing way at least.
That's not a very helpful response.
>> I see no way, even theoretically, that it can be sane for
>> CheckTableNotInUse() to succeed in a para
On Thu, Nov 20, 2014 at 12:26 PM, Tom Lane wrote:
> I do not have a problem with deciding that that is not a "regression";
> in fact, not giving that hint seems like a good conservative behavior
> here. By your logic, we should also be prepared to suggest
> "supercalifragilisticexpialidocious" wh
> So that we can have two ways to lose data?
>
> Forbidding connections to a database doesn't prevent XID or MXID wraparound.
It does prevent the user from doing anything about it, though, since
they can't manually vacuum template0 without knowing unpublished hackery.
--
Josh Berkus
PostgreSQL
Peter Geoghegan writes:
> On Thu, Nov 20, 2014 at 11:03 AM, Robert Haas wrote:
>> That does seem to give better results, but it still seems awfully
>> complicated. If we just used Levenshtein with all-default cost
>> factors and a distance cap equal to Max(strlen(what_user_typed),
>> strlen(cand
On Thu, Nov 20, 2014 at 12:14 PM, Robert Haas wrote:
> Seems fine to me. If you typed relid rather than indexrelid or key
> rather than indkey, that's a thinko, not a typo. ikey for indkey
> could plausible be a typo, though you'd have to be having a fairly bad
> day at the keyboard.
I can tell
On 2014-11-20 12:00:51 -0800, Peter Geoghegan wrote:
> In more concrete terms, this gets no suggestion:
>
> postgres=# select key from pg_index;
> ERROR: 42703: column "key" does not exist
> LINE 1: select key from pg_index;
>^
I don't think that's a bad thing. Yes, for a human t
On 2014-11-20 13:57:25 -0500, Robert Haas wrote:
> On Thu, Nov 20, 2014 at 12:19 PM, Andres Freund
> wrote:
> > Except that it opens us up for all kinds of concurrency bugs. I'm pretty
> > strictly set against granting any self exclusive locks en-masse. If we
> > do this by default for all grante
On Thu, Nov 20, 2014 at 3:00 PM, Peter Geoghegan wrote:
> On Thu, Nov 20, 2014 at 11:03 AM, Robert Haas wrote:
>> That does seem to give better results, but it still seems awfully
>> complicated. If we just used Levenshtein with all-default cost
>> factors and a distance cap equal to Max(strlen(
On Thu, Nov 20, 2014 at 11:03 AM, Robert Haas wrote:
> That does seem to give better results, but it still seems awfully
> complicated. If we just used Levenshtein with all-default cost
> factors and a distance cap equal to Max(strlen(what_user_typed),
> strlen(candidate_match), 3), what cases th
On 11/20/2014 02:28 PM, Tom Lane wrote:
Robert Haas writes:
On Thu, Nov 20, 2014 at 1:56 PM, Albe Laurenz wrote:
I don't think that there is a universally compelling right or wrong to
questions like this, it is more a matter of taste. Is it more important to
protect
the casual DBA from hur
Robert Haas writes:
> On Thu, Nov 20, 2014 at 1:56 PM, Albe Laurenz wrote:
>> I don't think that there is a universally compelling right or wrong to
>> questions like this, it is more a matter of taste. Is it more important to
>> protect
>> the casual DBA from hurting himself or herself, or is
execAmi.c points out that
* (However, since the only present use of mark/restore is in mergejoin,
* there is no need to support mark/restore in any plan type that is not
* capable of generating ordered output. So the seqscan, tidscan,
* and valuesscan support is actually useless code at prese
On Thu, Nov 20, 2014 at 1:56 PM, Albe Laurenz wrote:
> I don't think that there is a universally compelling right or wrong to
> questions like this, it is more a matter of taste. Is it more important to
> protect
> the casual DBA from hurting himself or herself, or is it more important to
> prov
On Thu, Nov 20, 2014 at 1:30 PM, Peter Geoghegan wrote:
> I mean the suggestion of raising the cost threshold more gradually,
> not as a step function of the number of characters in the string [1]
> where it's either over 6 characters and must pass the 50% test, or
> isn't and has no absolute qual
On Thu, Nov 20, 2014 at 12:19 PM, Andres Freund wrote:
> Except that it opens us up for all kinds of concurrency bugs. I'm pretty
> strictly set against granting any self exclusive locks en-masse. If we
> do this by default for all granted locks when starting a worker backend
> it'll get *so* much
Tom Lane wrote:
> Antonin Houska writes:
>> Albe Laurenz wrote:
>>> Currently it is possible to change the behaviour of a function with
>>> CREATE OR REPLACE FUNCTION even if the function is part of an index
>>> definition.
>>>
>>> I think that should be forbidden, because it is very likely to c
On Thu, Nov 20, 2014 at 7:32 AM, Robert Haas wrote:
>> In general, I think the cost of a bad suggestion is much lower than
>> the benefit of a good one. You seem to be suggesting that they're
>> equal. Or that they're equally likely in an organic situation. In my
>> estimation, this is not the cas
On Thu, Nov 20, 2014 at 8:05 AM, Tom Lane wrote:
> I'm not particularly convinced that the "f1" -> "f2" example is a useful
> behavior, and I'm downright horrified by the "qty" -> "quantity" case.
> If the hint mechanism thinks the latter two are close enough together
> to suggest, it's going to b
On Thu, Nov 20, 2014 at 12:12 PM, Jeff Davis wrote:
> On Thu, 2014-11-20 at 11:22 -0500, Robert Haas wrote:
>> 2. Propagate pre-existing locks from the user backend to all the workers.
>>
>> I initially proposed #1, but now I think #2 solves more of the
>> problems for less code.
>
> OK. The prima
Kouhei Kaigai writes:
> The attached obvious patch adds T_CustomScan on case-switch of
> ExplainTargetRel() that was oversight.
Applied, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
On 2014-11-20 11:22:37 -0500, Robert Haas wrote:
> On Thu, Nov 20, 2014 at 4:21 AM, Jeff Davis wrote:
> >> The
> >> bad news, to borrow a phrase from Peter Geoghegan, is that it's an
> >> unprincipled deadlock; a user confronted with the news that her
> >> parallel scan has self-deadlocked will
On Thu, 2014-11-20 at 11:22 -0500, Robert Haas wrote:
> 2. Propagate pre-existing locks from the user backend to all the workers.
>
> I initially proposed #1, but now I think #2 solves more of the
> problems for less code.
OK. The primary concern with that is unintended consequences. But it's
rea
As you may have noticed, I committed this (after some more cleanup). Of
course, feel free to still review it, and please point out any issues
you may find.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgres
On Thu, Nov 20, 2014 at 4:21 AM, Jeff Davis wrote:
>> The
>> bad news, to borrow a phrase from Peter Geoghegan, is that it's an
>> unprincipled deadlock; a user confronted with the news that her
>> parallel scan has self-deadlocked will be justifiably dismayed.
>
> You seem to be raising this as
On Wed, Nov 19, 2014 at 11:11 PM, Peter Eisentraut wrote:
> The applicable parts of
> that patch could be backpatched as a bug fix (but evidently no one cares
> about building contrib with pgxs (except when I submit a patch to remove
> it)).
Touché.
--
Robert Haas
EnterpriseDB: http://www.enter
On Wed, Nov 19, 2014 at 10:27 PM, Amit Langote
wrote:
>> Maybe as anyarray, but I think pg_node_tree
>> might even be better. That can also represent data of some arbitrary
>> type, but it doesn't enforce that everything is uniform. So you could
>> have a list of objects of the form {RANGEPARTI
Robert Haas writes:
> ... In other words, I think there's value in trying to clue somebody in
> when they've made a typo, but not when they've made a think-o. We
> won't be able to do the latter accurately enough to make it more
> useful than annoying.
FWIW, I concur with Robert's analysis that
On Wed, Nov 19, 2014 at 4:16 PM, Josh Berkus wrote:
> On 11/19/2014 01:03 PM, Alvaro Herrera wrote:
>> Josh Berkus wrote:
>>> On 11/12/2014 06:57 PM, Alvaro Herrera wrote:
> How did template0 even get a MultiXact? That sounds like they're really
> abusing the template databases. :( (Do ke
On Thu, Nov 20, 2014 at 7:30 AM, Amit Kapila wrote:
> Few compilation errors in the patch:
> 1>contrib\postgres_fdw\postgres_fdw.c(2107): error C2198:
> 'set_config_option' : too few arguments for call
> 1>contrib\postgres_fdw\postgres_fdw.c(2111): error C2198:
> 'set_config_option' : too few argu
On Wed, Nov 19, 2014 at 2:33 PM, Peter Geoghegan wrote:
> I don't think that's the case. Other RTEs are penalized for having
> non-matching aliases here.
The point I made did not, as far as I can see, have anything to do
with non-matching aliases; it could arise with just a single RTE.
> In gene
On 2014-11-20 17:26:02 +0300, Alex Shulgin wrote:
>
> Andres Freund writes:
> >
> > On 2014-11-19 15:09:10 -0800, Josh Berkus wrote:
> >> One patch that got deferred from 9.4 was the merger of recovery.conf and
> >> postgresql.conf, due to conflicts with ALTER SYSTEM SET. However, this
> >> is s
Andres Freund writes:
>
> On 2014-11-19 15:09:10 -0800, Josh Berkus wrote:
>> One patch that got deferred from 9.4 was the merger of recovery.conf and
>> postgresql.conf, due to conflicts with ALTER SYSTEM SET. However, this
>> is still a critical TODO, because recovery.conf is still an ongoing
Alvaro Herrera writes:
>> CLUSTER and VACUUM are not part of the supported commands anymore, so
>> I think that we could replace that by the addition of a reference
>> number in the cell of ALTER TABLE for the event table_rewrite and
>> write at the bottom of the table a description of how this ev
On Wed, Nov 12, 2014 at 11:09 PM, Robert Haas wrote:
>
> On Wed, Nov 12, 2014 at 11:36 AM, Robert Haas
wrote:
> > On Wed, Nov 12, 2014 at 11:19 AM, Andres Freund
wrote:
> >> The question is whether the library is actually loaded in that case?
> >> Because that normally only happens early during
On 19 November 2014 23:29, Tom Lane wrote:
> Pavel Stehule writes:
>> 2014-11-19 23:54 GMT+01:00 Tom Lane :
>>> The core of that complaint is that we'd have to make ASSERT a plpgsql
>>> reserved word, which is true enough as things stand today. However,
>>> why is it that plpgsql statement-intro
Dag-Erling Smørgrav writes:
> Alex Shulgin writes:
>> * The patch works as advertised, though the only way to verify that
>> connections made with the protocol disabled by the GUC are indeed
>> rejected is to edit fe-secure-openssl.c to only allow specific TLS
>> versions. Adding configu
On 19 November 2014 22:47, Petr Jelinek wrote:
> On 19/11/14 19:51, Simon Riggs wrote:
>>
>> On 19 November 2014 16:11, Petr Jelinek wrote:
>>
We need to be able to tell the difference between a crashed Startup
process and this usage.
As long as we can tell, I don't mind how w
On Thu, Nov 20, 2014 at 10:19 AM, Dag-Erling Smørgrav wrote:
> Magnus Hagander writes:
>> Alex Shulgin writes:
>> > * The code allows specifying SSLv2 and SSLv3 in the GUC, but removes
>> > them forcibly after parsing the complete string (a warning is issued).
>> > Should we also add a note
On Wed, 2014-11-19 at 11:03 -0500, Robert Haas wrote:
> But your proposal does not solve this problem:
>
> 1. Backend A-1 acquires AccessExclusiveLock on relation R.
> 2. Backend A-2 waits for AccessShareLock on relation R.
>
> The good news is that the deadlock detector should realize that since
Magnus Hagander writes:
> Alex Shulgin writes:
> > * The code allows specifying SSLv2 and SSLv3 in the GUC, but removes
> > them forcibly after parsing the complete string (a warning is issued).
> > Should we also add a note about this to the documentation?
> I see no reason to accept them at
On Wed, Nov 19, 2014 at 4:34 PM, Alex Shulgin wrote:
>
> Dag-Erling Smørgrav writes:
>>
>> The attached patches add an ssl_protocols configuration option which
>> control which versions of SSL or TLS the server will use. The syntax is
>> similar to Apache's SSLProtocols directive, except that th
Alex Shulgin writes:
> * The patch works as advertised, though the only way to verify that
> connections made with the protocol disabled by the GUC are indeed
> rejected is to edit fe-secure-openssl.c to only allow specific TLS
> versions. Adding configuration on the libpq side as suggested
On Thu, Nov 20, 2014 at 5:22 PM, Michael Paquier
wrote:
> Patch is attached.
A cleaner fix may be btw to pass the build stats in
ginPrepareEntryScan and set the flag directly there.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscri
Hi all,
While playing with the GIN code for an upcoming patch, I noticed that
when inserting a new entry in a new index, this code path is not able
to make the difference if the index is in a build state or not.
Basically, when entering in ginEntryInsert@gininsert.c GinBtree built
via ginPrepareEn
At 2014-11-20 09:52:01 +0530, a...@2ndquadrant.com wrote:
>
> To address (a), I am timing a standby restoring the same 11GB of WAL
> via restore_command with and without the CRC patch.
I ran "perf record -F 100 --call-graph=dwarf bin/postgres -D backup",
where:
(a) bin/postgres was compiled, as b
72 matches
Mail list logo
