On 10/20/2014 11:02 PM, jes...@krogh.cc wrote:
I do suspect the majority is from 30 concurrent processes updating an
506GB GIN index, but it would be nice to confirm that. There is also a
message-queue in the DB with a fairly high turnaround.
A 506GB GIN index? Uh, interesting :). What's it
Hi,
I have been thinking about why we need to grab an AccessExclusiveLock on
the table with the PK when we add a foreign key. Adding new tables with
foreign keys to old ones is common so it would be really nice if the
lock strength could be reduced.
A comment in the code claims that we need
On Tue, Oct 21, 2014 at 7:56 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
On Wed, Oct 8, 2014 at 6:17 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-06-25 19:06:32 +0530, Amit Kapila wrote:
Today, I have verified all previous comments raised by
me and looked at new code and below
On Fri, Oct 10, 2014 at 10:08 PM, Craig Ringer cr...@2ndquadrant.com
wrote:
On 09/17/2014 08:27 PM, Craig Ringer wrote:
Hi all
Attached is a patch to switch 9.5 over to using the
GetSystemTimeAsFileTime call instead of separate GetSystemTime and
SystemTimeToFileTime calls.
Following
On 10/22/2014 04:12 PM, David Rowley wrote:
I was just having a quick look at this with the view of testing it on a
windows 8 machine.
Thankyou. I really appreciate your taking the time to do this, as one of
the barriers to getting Windows-specific patches accepted is that
usually people just
Florian Pflug f...@phlo.org wrote:
So in conclusion, the lock avoids raising constraint violation errors in
a few cases in READ COMMITTED mode. In REPEATABLE READ mode, it converts some
constraint violation errors into serialization failures. Or at least that's
how it looks to me.
I go the
On Tue, Oct 21, 2014 at 11:00 PM, Marti Raudsepp ma...@juffo.org wrote:
On Sun, Oct 19, 2014 at 1:22 PM, David Rowley dgrowle...@gmail.com
wrote:
the argument for this would
have been much stronger if anti join support had just been added last
week.
It's been quite a few years now and
Suggested patch adds GIN support contains operator for ranges over scalar
column.
It allows more effective GIN scan. Currently, queries like
SELECT * FROM test_int4 WHERE i = 1 and i = 1
will be excuted by GIN with two scans: one is from mines infinity to 1 and
another is from -1 to plus
Hi
On Wed, Oct 22, 2014 at 1:55 PM, Teodor Sigaev teo...@sigaev.ru wrote:
With patch it's possible to rewrite query with ranges
SELECT * FROM test_int4 WHERE i @ '[-1, 1]'::int4range
and GIN index will support this query with single scan from -1 to 1.
Shouldn't this be implemented in a more
In specific workload postgres could spend a lot of time in tbm_add_tuples, up
to 50% of query time. hash_search call is expensive and called twice for each
ItemPointer to insert. Suggested patch tries to cache last PagetableEntry
pointer in hope that next ItemPointer will be on the same
On 10/20/2014 09:26 AM, Michael Paquier wrote:
On Fri, Oct 17, 2014 at 10:37 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Fri, Oct 17, 2014 at 9:23 PM, Fujii Masao masao.fu...@gmail.com wrote:
In this case, the patch seems to make the restartpoint recycle even WAL files
which have
Shouldn't this be implemented in a more generic manner? An ordinary
Unfortunately I don't see a way for that. GIN is generalized - and it doesn't
know semantic. Actually, we could fix first five strategy numbers for BTree's
strategies, and then we could teach GIN core to use BTRee semantic, but
Here's an updated patch addressing David's points.
I haven't had a chance to test it yet, on win2k8 or win2k12 due to
pgconf.eu .
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
From
On 10/19/2014 11:29 AM, Peter Geoghegan wrote:
On Fri, Oct 10, 2014 at 12:33 AM, Peter Geoghegan p...@heroku.com wrote:
Attached
Have you looked at this?
Committed now, thanks.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Tom Lane t...@sss.pgh.pa.us writes:
This looks to me like re-fighting the last war. Such a GUC has zero value
*unless* some situation exactly like the POODLE bug comes up again, and
the odds of that are not high.
Many people would have said the exact same thing before POODLE, and
BEAST, and
Magnus Hagander mag...@hagander.net writes:
If anything, I think the default should be default, and then we have
that map out to something. Because once you've initdb'ed, the config
file wil be stuck with a default and we can't change that in a minor
release *if* something like POODLE shows up
Just replace tag_hash in tidbitmap which uses hash_any to direct call of
hash_uint32, it saves ~5% of execution time.
An example:
# create extension btree_gin;
# select (v / 10)::int4 as i into t from generate_series(1, 500) as v;
# create index idx on t using gin (i);
# set enable_seqscan
Tom Lane t...@sss.pgh.pa.us writes:
And in the end, if we set values like this from PG --- whether
hard-wired or via a GUC --- the SSL library people will have exactly
the same perspective with regards to *our* values. And not without
reason; we were forcing very obsolete settings up till
On Fri, Oct 17, 2014 at 2:23 PM, Fujii Masao masao.fu...@gmail.com wrote:
I found one problem in the 0002 patch. The patch changes the recovery so
that
it creates .done files for every WAL files which exist in pg_xlog
directory at
the end of recovery. But even WAL files which will have to be
Tom Lane t...@sss.pgh.pa.us writes:
As far as protocol version goes, I think our existing coding basically
says prefer newest available version, but at least TLS 1.0. I think
that's probably a reasonable approach.
The client side forces TLS 1.0:
SSL_context =
Magnus Hagander mag...@hagander.net writes:
Yes, it does that. Though it only does it on 9.4,but with the facts we
know now, what 9.4+ does is perfectly safe.
Agreed.
DES
--
Dag-Erling Smørgrav - d...@des.no
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On 10/17/2014 01:59 PM, Simon Riggs wrote:
On 17 October 2014 09:55, furu...@pm.nttdata.co.jp wrote:
A new parameter to send feedback should be called --feedback
A second parameter to decide whether to fsync should be called --fsync
I think keep using --reply-fsync and --fsync-interval
On Wed, Oct 22, 2014 at 3:12 PM, Dag-Erling Smørgrav d...@des.no wrote:
Tom Lane t...@sss.pgh.pa.us writes:
This looks to me like re-fighting the last war. Such a GUC has zero
value
*unless* some situation exactly like the POODLE bug comes up again, and
the odds of that are not high.
When we developed SP-GiST we missed analogue of GiST's compress method. There
was two reasons for that: lack of imagination to imagine case with different
types of indexed value and column, and we didn't want call some method while
index fit in one page. Some discussion on that
On 2014-10-22 13:32:07 +0530, Amit Kapila wrote:
On Tue, Oct 21, 2014 at 7:56 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
On Wed, Oct 8, 2014 at 6:17 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-06-25 19:06:32 +0530, Amit Kapila wrote:
Today, I have verified all
On 22 October 2014 14:26, Heikki Linnakangas hlinnakan...@vmware.com wrote:
We seem to be going in circles. You suggested having two options,
--feedback, and --fsync, which is almost exactly what Furuya posted
originally. I objected to that, because I think that user interface is too
Hi
2014-10-19 8:02 GMT+02:00 Ali Akbar the.ap...@gmail.com:
So, is there any idea how we will handle NULL and empty array in
array_agg(anyarray)?
I propose we just reject those input because the output will make no
sense:
- array_agg(NULL::int[]) -- the result will be indistinguished from
Andreas Karlsson andr...@proxel.se writes:
I have attached a proof of concept
patch which reduces the lock strength to ShareLock.
You're kidding, right? ShareLock isn't even self-exclusive.
regards, tom lane
--
Sent via pgsql-hackers mailing list
On 2014-10-21 19:56:05 +0530, Amit Kapila wrote:
On Wed, Oct 8, 2014 at 6:17 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-06-25 19:06:32 +0530, Amit Kapila wrote:
2.
LWLockWakeup()
{
..
#ifdef LWLOCK_STATS
lwstats-spin_delay_count += SpinLockAcquire(lock-mutex);
On Wed, Oct 15, 2014 at 09:50:16AM -0400, Tom Lane wrote:
The same thought had occurred to me. Probably the main use of the
datetime parsing code in ecpg is for interpreting outputs from the
server, and (at least by default) the server doesn't use timezone
abbreviations when printing
[ I think I responded earlier but don't see my mail in the archive... ]
Tom Lane t...@sss.pgh.pa.us wrote:
Antonin Houska a...@cybertec.at writes:
I noticed that - unlike join_collapse_limit - the from_collapse_limit does
not
enforce maximum length of the top-level list. Shouldn't it do?
Thanks for the review
2014-10-22 20:51 GMT+07:00 Pavel Stehule pavel.steh...@gmail.com:
I agree with your proposal. I have a few comments to design:
1. patch doesn't hold documentation and regress tests, please append it.
OK, i'll add the documentation and regression test
2. this
On Fri, Oct 17, 2014 at 10:47 AM, Merlin Moncure mmonc...@gmail.com wrote:
On Fri, Oct 17, 2014 at 10:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Fri, Oct 17, 2014 at 10:16 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I think it wouldn't; Merlin is
Michael Meskes mes...@postgresql.org writes:
On Wed, Oct 15, 2014 at 09:50:16AM -0400, Tom Lane wrote:
The same thought had occurred to me. Probably the main use of the
datetime parsing code in ecpg is for interpreting outputs from the
server, and (at least by default) the server doesn't use
Florian Pflug f...@phlo.org wrote:
Florian Pflug f...@phlo.org wrote:
But that's wrong. The transaction's snapshot *would* see that row, so we
ought to raise an error. Note that this applies also to mode SERIALIZABLE, and
breaks true serializability in some cases, since we don't do conflict
2014-10-22 16:58 GMT+02:00 Ali Akbar the.ap...@gmail.com:
Thanks for the review
2014-10-22 20:51 GMT+07:00 Pavel Stehule pavel.steh...@gmail.com:
I agree with your proposal. I have a few comments to design:
1. patch doesn't hold documentation and regress tests, please append it.
OK,
Hi
with new functions row_to_json(b), there is more often usage of ROW
constructor. Using names in fields is relative difficult. Because ROW has
special clause in parser, I am thinking so we can enable labeling inside
ROW constructor
so instead currently supported:
select row_to_json(r) from
here is a motivation, why I propose this feature
http://dba.stackexchange.com/questions/27732/set-names-to-attributes-when-creating-json-with-row-to-json
same query I have in Czech postgres users mailing list
Pavel
2014-10-22 18:21 GMT+02:00 Pavel Stehule pavel.steh...@gmail.com:
Hi
with
On Wed, Oct 22, 2014 at 11:21 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
Hi
with new functions row_to_json(b), there is more often usage of ROW
constructor. Using names in fields is relative difficult. Because ROW has
special clause in parser, I am thinking so we can enable labeling
This should not be considered a problem for repeatable read
transactions because the change in visible rows meet the definition
of phantom reads, which are allowed in repeatable read: A
transaction re-executes a query returning a set of rows that
satisfy a search condition and finds that the
Florian Pflug f...@phlo.org wrote:
This should not be considered a problem for repeatable read
transactions because the change in visible rows meet the
definition of phantom reads, which are allowed in repeatable
read: A transaction re-executes a query returning a set of rows
that satisfy a
2014-10-22 18:35 GMT+02:00 Merlin Moncure mmonc...@gmail.com:
On Wed, Oct 22, 2014 at 11:21 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Hi
with new functions row_to_json(b), there is more often usage of ROW
constructor. Using names in fields is relative difficult. Because ROW has
On Wed, Oct 22, 2014 at 03:14:26PM +0200, Dag-Erling Smørgrav wrote:
In a case like POODLE we probably wouldn't have done it anyway, as it
doesn't affect our connections (we're not http)
If I understand correctly, imaps has been shown to be vulnerable as
well, so I wouldn't be so sure.
On 10/22/2014 04:24 PM, Michael Paquier wrote:
On Wed, Oct 22, 2014 at 1:53 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
I think we should take a more wholesale approach to this. We should
enforce the rule that the server only ever archives WAL files belonging to
the same timeline
Martijn van Oosterhout klep...@svana.org writes:
Dag-Erling Smørgrav d...@des.no writes:
If I understand correctly, imaps has been shown to be vulnerable as
well, so I wouldn't be so sure.
Reference?
Sorry, no reference. I was told that Thunderbird was vulnerable to
POODLE when talking
On Tue, Sep 23, 2014 at 1:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Add a new p_tableref_hook function pointer, similar to p_paramref_hook.
Whenever the parser sees a RangeVar that it doesn't recognize (or actually,
I think it should call it *before* resolving regular tables, but let's
ignore
On 10/16/2014 08:08 AM, Andres Freund wrote:
On 2014-10-16 08:04:17 -0400, Jan Wieck wrote:
Hi,
PostgreSQL has for ages defined INT64_FORMAT and UINT64_FORMAT in
pg_config.h. This commit
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=ce486056ecd28050
moved those definitions to
On Wed, Oct 22, 2014 at 4:12 PM, Steve Singer st...@ssinger.info wrote:
So the header of c.h says Note that the definitions here are not intended
to be exposed to clients
but
postgres_fe.h says This should be the first file included by PostgreSQL
client libraries and
Should client programs
Robert Haas robertmh...@gmail.com writes:
On Wed, Oct 22, 2014 at 4:12 PM, Steve Singer st...@ssinger.info wrote:
So the header of c.h says Note that the definitions here are not intended
to be exposed to clients
but
postgres_fe.h says This should be the first file included by PostgreSQL
On 10/22/2014 11:10 PM, Robert Haas wrote:
On Tue, Sep 23, 2014 at 1:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Add a new p_tableref_hook function pointer, similar to p_paramref_hook.
Whenever the parser sees a RangeVar that it doesn't recognize (or actually,
I think it should call it *before*
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 10/22/2014 11:10 PM, Robert Haas wrote:
Studying this proposed design a bit further, I am a little fuzzy on
what is supposed to happen in this design during parse analysis. In
Kevin's current code, after checking whether a RangeVar might
On Wed, Oct 8, 2014 at 6:32 PM, Andres Freund and...@2ndquadrant.com wrote:
I got to ask: Why is it helpful that we have this in contrib? I have a
good share of blame to bear for that, but I think we need to stop
dilluting contrib evermore with test programs. These have a place, but I
don't
On 10/22/2014 04:03 PM, Robert Haas wrote:
On Wed, Oct 8, 2014 at 6:32 PM, Andres Freund and...@2ndquadrant.com wrote:
I got to ask: Why is it helpful that we have this in contrib? I have a
good share of blame to bear for that, but I think we need to stop
dilluting contrib evermore with test
Brightwell, Adam wrote:
All,
Thanks! Please add it to the next commitfest.
Sounds good. I'll update the patch and add accordingly.
Attached is an updated patch.
I noticed something strange while perusing this patch, but the issue
predates the patch. Some messages say must be
Sawada Masahiko wrote:
Thank you for reviewing.
I agree 2) - 5).
Attached patch is latest version patch I modified above.
Also, I noticed I had forgotten to add the patch regarding document of
reindexdb.
Please don't use pg_catalog in the regression test. That way we will
need to update
On Wed, Oct 22, 2014 at 7:12 PM, Joshua D. Drake j...@commandprompt.com wrote:
I don't think pg_background is merely a test program: I think it's a
quite useful piece of functionality. It can be used for running
VACUUM from a procedure, which is something people have asked for more
than once,
On Tue, Oct 21, 2014 at 1:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If you do any Postgres development on OS X, you've probably gotten
seriously annoyed by the way that, every single time you reinstall the
postmaster executable, you get a dialog box asking whether you'd like
to allow it to
What about moving it the opposite direction, from contrib all the way
into core? The main advantage of that in my book is that it might
make it easier to reduce the code duplication between pg_background
and exec_simple_query; the main disadvantage is that it reduces the
super-user's control,
Robert Haas robertmh...@gmail.com writes:
On Tue, Oct 21, 2014 at 1:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If you do any Postgres development on OS X, you've probably gotten
seriously annoyed by the way that, every single time you reinstall the
postmaster executable, you get a dialog box
On 10/22/2014 04:17 PM, Robert Haas wrote:
Slonik used to include postgre_fe.h but back in 2011 or so we stopped doing
so because it was causing issues (I think on win32 builds)
That seems like something we ought to consider fixing, but obviously
we'd need more details.
When I'll try to find
On 10/21/14 6:19 PM, Michael Paquier wrote:
On Wed, Oct 22, 2014 at 5:03 AM, Peter Eisentraut pete...@gmx.net
mailto:pete...@gmx.net wrote:
While looking at this, I wrote a few tests cases for sequence
privileges, because that was not covered at all. That patch is
attached.
2014-10-22 22:48 GMT+07:00 Pavel Stehule pavel.steh...@gmail.com:
2014-10-22 16:58 GMT+02:00 Ali Akbar the.ap...@gmail.com:
Thanks for the review
2014-10-22 20:51 GMT+07:00 Pavel Stehule pavel.steh...@gmail.com:
I agree with your proposal. I have a few comments to design:
1. patch
2014-10-23 4:00 GMT+02:00 Ali Akbar the.ap...@gmail.com:
2014-10-22 22:48 GMT+07:00 Pavel Stehule pavel.steh...@gmail.com:
2014-10-22 16:58 GMT+02:00 Ali Akbar the.ap...@gmail.com:
Thanks for the review
2014-10-22 20:51 GMT+07:00 Pavel Stehule pavel.steh...@gmail.com:
I agree with your
63 matches
Mail list logo
