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
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
On Thu, Nov 20, 2014 at 5:22 PM, Michael Paquier
michael.paqu...@gmail.com 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
Alex Shulgin a...@commandprompt.com 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
On Wed, Nov 19, 2014 at 4:34 PM, Alex Shulgin a...@commandprompt.com wrote:
Dag-Erling Smørgrav d...@des.no 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
Magnus Hagander mag...@hagander.net writes:
Alex Shulgin a...@commandprompt.com 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?
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
A-1
On Thu, Nov 20, 2014 at 10:19 AM, Dag-Erling Smørgrav d...@des.no wrote:
Magnus Hagander mag...@hagander.net writes:
Alex Shulgin a...@commandprompt.com writes:
* The code allows specifying SSLv2 and SSLv3 in the GUC, but removes
them forcibly after parsing the complete string (a warning
On 19 November 2014 22:47, Petr Jelinek p...@2ndquadrant.com wrote:
On 19/11/14 19:51, Simon Riggs wrote:
On 19 November 2014 16:11, Petr Jelinek p...@2ndquadrant.com wrote:
We need to be able to tell the difference between a crashed Startup
process and this usage.
As long as we can tell,
Dag-Erling Smørgrav d...@des.no writes:
Alex Shulgin a...@commandprompt.com 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
On 19 November 2014 23:29, Tom Lane t...@sss.pgh.pa.us wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
2014-11-19 23:54 GMT+01:00 Tom Lane t...@sss.pgh.pa.us:
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.
On Wed, Nov 12, 2014 at 11:09 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Nov 12, 2014 at 11:36 AM, Robert Haas robertmh...@gmail.com
wrote:
On Wed, Nov 12, 2014 at 11:19 AM, Andres Freund and...@2ndquadrant.com
wrote:
The question is whether the library is actually loaded in that
Alvaro Herrera alvhe...@2ndquadrant.com 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
Andres Freund and...@2ndquadrant.com 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
On 2014-11-20 17:26:02 +0300, Alex Shulgin wrote:
Andres Freund and...@2ndquadrant.com 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,
On Wed, Nov 19, 2014 at 2:33 PM, Peter Geoghegan p...@heroku.com 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
On Thu, Nov 20, 2014 at 7:30 AM, Amit Kapila amit.kapil...@gmail.com wrote:
Few compilation errors in the patch:
1contrib\postgres_fdw\postgres_fdw.c(2107): error C2198:
'set_config_option' : too few arguments for call
1contrib\postgres_fdw\postgres_fdw.c(2111): error C2198:
On Wed, Nov 19, 2014 at 4:16 PM, Josh Berkus j...@agliodbs.com 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
Robert Haas robertmh...@gmail.com 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
On Wed, Nov 19, 2014 at 10:27 PM, Amit Langote
langote_amit...@lab.ntt.co.jp 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
On Wed, Nov 19, 2014 at 11:11 PM, Peter Eisentraut pete...@gmx.net 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:
On Thu, Nov 20, 2014 at 4:21 AM, Jeff Davis pg...@j-davis.com 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
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:
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
On 2014-11-20 11:22:37 -0500, Robert Haas wrote:
On Thu, Nov 20, 2014 at 4:21 AM, Jeff Davis pg...@j-davis.com 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
Kouhei Kaigai kai...@ak.jp.nec.com 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
On Thu, Nov 20, 2014 at 12:12 PM, Jeff Davis pg...@j-davis.com 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.
On Thu, Nov 20, 2014 at 8:05 AM, Tom Lane t...@sss.pgh.pa.us 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
On Thu, Nov 20, 2014 at 7:32 AM, Robert Haas robertmh...@gmail.com 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
Tom Lane wrote:
Antonin Houska a...@cybertec.at writes:
Albe Laurenz laurenz.a...@wien.gv.at 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
On Thu, Nov 20, 2014 at 12:19 PM, Andres Freund and...@2ndquadrant.com 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
On Thu, Nov 20, 2014 at 1:30 PM, Peter Geoghegan p...@heroku.com 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
On Thu, Nov 20, 2014 at 1:56 PM, Albe Laurenz laurenz.a...@wien.gv.at 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
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
Robert Haas robertmh...@gmail.com writes:
On Thu, Nov 20, 2014 at 1:56 PM, Albe Laurenz laurenz.a...@wien.gv.at 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
On 11/20/2014 02:28 PM, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Nov 20, 2014 at 1:56 PM, Albe Laurenz laurenz.a...@wien.gv.at 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
On Thu, Nov 20, 2014 at 11:03 AM, Robert Haas robertmh...@gmail.com 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),
On Thu, Nov 20, 2014 at 3:00 PM, Peter Geoghegan p...@heroku.com wrote:
On Thu, Nov 20, 2014 at 11:03 AM, Robert Haas robertmh...@gmail.com 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
On 2014-11-20 13:57:25 -0500, Robert Haas wrote:
On Thu, Nov 20, 2014 at 12:19 PM, Andres Freund and...@2ndquadrant.com
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
On Thu, Nov 20, 2014 at 12:14 PM, Robert Haas robertmh...@gmail.com 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
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 those
Peter Geoghegan p...@heroku.com writes:
On Thu, Nov 20, 2014 at 11:03 AM, Robert Haas robertmh...@gmail.com 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
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
On Thu, Nov 20, 2014 at 12:26 PM, Tom Lane t...@sss.pgh.pa.us 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
On Thu, Nov 20, 2014 at 3:15 PM, Andres Freund and...@2ndquadrant.com 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
On Thu, Nov 20, 2014 at 3:20 PM, Peter Geoghegan p...@heroku.com wrote:
On Thu, Nov 20, 2014 at 12:14 PM, Robert Haas robertmh...@gmail.com 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
On Thu, Nov 20, 2014 at 12:50 PM, Robert Haas robertmh...@gmail.com 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:
On Thu, Nov 20, 2014 at 3:44 PM, Josh Berkus j...@agliodbs.com 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
Robert Haas wrote:
On Thu, Nov 20, 2014 at 3:44 PM, Josh Berkus j...@agliodbs.com 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
On 11/20/2014 01:03 PM, Robert Haas wrote:
On Thu, Nov 20, 2014 at 3:44 PM, Josh Berkus j...@agliodbs.com 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,
On Wed, Nov 19, 2014 at 10:37 PM, Anssi Kääriäinen
anssi.kaariai...@thl.fi 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
On 2014-11-20 15:47:39 -0500, Robert Haas wrote:
On Thu, Nov 20, 2014 at 3:15 PM, Andres Freund and...@2ndquadrant.com 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
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
Josh Berkus j...@agliodbs.com 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
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
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 -
On Thu, Nov 20, 2014 at 1:42 PM, Peter Geoghegan p...@heroku.com 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
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/memnodes.h
---
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
Robert Haas robertmh...@gmail.com 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
On Thu, Nov 20, 2014 at 4:45 PM, Andres Freund and...@2ndquadrant.com 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
On Thu, Nov 20, 2014 at 7:10 PM, Tom Lane t...@sss.pgh.pa.us 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,
On 2014-11-20 20:21:07 -0500, Robert Haas wrote:
On Thu, Nov 20, 2014 at 4:45 PM, Andres Freund and...@2ndquadrant.com 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
Robert Haas robertmh...@gmail.com 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
On Thu, Nov 20, 2014 at 7:10 PM, Tom Lane t...@sss.pgh.pa.us 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,
On 11/20/2014 01:47 PM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com 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
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
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
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
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 an
On Fri, Nov 21, 2014 at 2:06 AM, 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.
This comment on top of XLogRecordAssemble is not
On Wed, Nov 19, 2014 at 8:56 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Nov 18, 2014 at 8:53 AM, Amit Kapila amit.kapil...@gmail.com
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
72 matches
Mail list logo
