On Thu, Jul 10, 2014 at 6:16 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Claudio Freire wrote:
An aggregate to generate a compressed set from several values
A function which adds a new value to the compressed set and returns
the new compressed set
A function which tests if a value is
On 2014-07-04 19:27:10 +0530, Rahila Syed wrote:
+ /* Allocates memory for compressed backup blocks according to the
compression
+ * algorithm used.Once per session at the time of insertion of first XLOG
+ * record.
+ * This memory stays till the end of session. OOM is
On Mon, 2014-07-07 at 01:21 -0700, Jeff Davis wrote:
On Sun, 2014-07-06 at 21:11 -0700, Jeff Davis wrote:
On Wed, 2014-04-16 at 12:50 +0100, Nicholas White wrote:
Thanks for the detailed feedback, I'm sorry it took so long to
incorporate it. I've attached the latest version of the patch,
(2014/07/10 18:12), Shigeru Hanada wrote:
2014-06-24 16:30 GMT+09:00 Etsuro Fujita fujita.ets...@lab.ntt.co.jp:
(2014/06/23 18:35), Ashutosh Bapat wrote:
Selecting tableoid on parent causes an error, ERROR: cannot extract
system attribute from virtual tuple. The foreign table has an OID
On 9 July 2014 23:54, Peter Geoghegan p...@heroku.com wrote:
On Wed, Jul 9, 2014 at 2:16 PM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
All this being said, I'm sticking to the name Minmax indexes. There
was a poll in pgsql-advocacy
On 10 July 2014 00:13, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Josh Berkus wrote:
On 07/09/2014 02:16 PM, Alvaro Herrera wrote:
The way it works now, each opclass needs to have three support
procedures; I've called them getOpers, maybeUpdateValues, and compare.
(I realize these
(2014/07/11 15:50), Etsuro Fujita wrote:
(2014/07/10 18:12), Shigeru Hanada wrote:
IIUC, you mean that tableoid can't be retrieved when a foreign table
is accessed via parent table,
No. What I want to say is that tableoid *can* be retrieved when a
foreign table is accessed via the parent
Hi,
Found new issues with latest patch:
Thank you for reviewing the patch with variable cases.
I have revised the patch, and attached latest patch.
A:
Will you please explain the idea behind these changes ?
I thought wrong about adding new to tail of query_buf.
The latest patch does
On 9 July 2014 18:54, Tomas Vondra t...@fuzzy.cz wrote:
(1) size the buckets for NTUP_PER_BUCKET=1 (and use whatever number
of batches this requires)
If we start off by assuming NTUP_PER_BUCKET = 1, how much memory does
it save to recalculate the hash bucket at 10 instead?
Resizing sounds
That is it possible to tell the planner that index is off limits i.e. don't
ever generate a plan using it?
Rationale: Schema changes on big tables. I might have convinced myself /
strong beliefs that for all queries that I need to be fast the planner does
not need to use a given index (e.g.
Greetings,
Attached modified patch to handle xmlCopyNode returning NULL. The patch is
larger because xmlerrcxt must be passed to xml_xmlnodetoxmltype (xmlerrcxt
is needed for calling xml_ereport).
From libxml2 source, it turns out that the other cases that xmlCopyNode
will return NULL will not
I've noticed that EXPLAIN ANALYZE shows no information on exact/lossy
blocks for a bitmap heap scan when both the numbers of exact/lossy pages
retrieved by the node are zero. Such an example is shown below. I
think it would be better to suppress the 'Heap Blocks' line in that
case, based on the
On Thursday, July 10, 2014, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jul 9, 2014 at 2:13 AM, Stephen Frost sfr...@snowman.net
javascript:; wrote:
Yes, this would be possible (and is nearly identical to the original
patch, except that this includes per-role considerations), however,
Is there a particular reason why pg_receivexlog only supports using
manually created slots but pg_recvlogical supports creating and
dropping them? Wouldn't it be good for consistency there?
I'm guessing it's related to not being exposed over the replication
protocol? We had a discussion earlier
On 2014-07-11 11:08:48 +0200, Magnus Hagander wrote:
Is there a particular reason why pg_receivexlog only supports using
manually created slots but pg_recvlogical supports creating and
dropping them? Wouldn't it be good for consistency there?
I've added it to recvlogical because logical
On Fri, Jul 11, 2014 at 11:14 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-07-11 11:08:48 +0200, Magnus Hagander wrote:
Is there a particular reason why pg_receivexlog only supports using
manually created slots but pg_recvlogical supports creating and
dropping them? Wouldn't it be
I think the following comment for store_returning_result() in
postgres_fdw.c is not right.
/* PGresult must be released before leaving this function. */
I think PGresult should not be released before leaving this function *on
success* in that function.
(I guess the comment has been copied
On 11 Červenec 2014, 9:27, Simon Riggs wrote:
On 9 July 2014 18:54, Tomas Vondra t...@fuzzy.cz wrote:
(1) size the buckets for NTUP_PER_BUCKET=1 (and use whatever number
of batches this requires)
If we start off by assuming NTUP_PER_BUCKET = 1, how much memory does
it save to
On 2014-07-11 11:18:58 +0200, Magnus Hagander wrote:
On Fri, Jul 11, 2014 at 11:14 AM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-07-11 11:08:48 +0200, Magnus Hagander wrote:
Is there a particular reason why pg_receivexlog only supports using
manually created slots but
Re: Bruce Momjian 2014-07-08 20140708202114.gd9...@momjian.us
I believe pg_upgrade itself still needs a fix. While it's not a
security problem to put the socket in $CWD while upgrading (it is
using -c unix_socket_permissions=0700), this behavior is pretty
unexpected, and does fail
Re: To Bruce Momjian 2014-07-11 20140711093923.ga3...@msg.df7cb.de
Re: Bruce Momjian 2014-07-08 20140708202114.gd9...@momjian.us
I believe pg_upgrade itself still needs a fix. While it's not a
security problem to put the socket in $CWD while upgrading (it is
using -c
On Fri, Jul 11, 2014 at 4:23 PM, Jeevan Chalke
jeevan.cha...@enterprisedb.com wrote:
Hi,
A.
However, this introduced new bug. As I told, when editor number of lines
reaches INT_MAX it starts giving negative number. You tried overcoming this
issue by adding 0 check. But I guess you again
On Wed, Jul 9, 2014 at 12:59 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David Rowley dgrow...@gmail.com writes:
On 9 July 2014 09:27, Tom Lane t...@sss.pgh.pa.us wrote:
On review it looks like analyzejoins.c would possibly benefit from an
earlier fast-path check as well.
Do you mean for
Hi
I noticed a minor inconsistency with the search_path separator used in the
default configuration.
The schemas of any search_path set using `SET search_path TO...` are
separated by , (comma, space), while the default value is only separated
by , (comma).
The attached patch against master
On Fri, Jul 11, 2014 at 5:45 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
I've noticed that EXPLAIN ANALYZE shows no information on exact/lossy
blocks for a bitmap heap scan when both the numbers of exact/lossy pages
retrieved by the node are zero. Such an example is shown below. I
On 11 July 2014 10:23, Tomas Vondra t...@fuzzy.cz wrote:
On 11 Červenec 2014, 9:27, Simon Riggs wrote:
On 9 July 2014 18:54, Tomas Vondra t...@fuzzy.cz wrote:
(1) size the buckets for NTUP_PER_BUCKET=1 (and use whatever number
of batches this requires)
If we start off by assuming
On Fri, Jul 11, 2014 at 12:01 AM, Vik Fearing vik.fear...@dalibo.com wrote:
On 07/10/2014 09:32 PM, Magnus Hagander wrote:
It seems psql is missing autocomplete entries for LC_COLLATE and
LC_CTYPE for the CREATE DATABASE command. Attached patch adds that.
I doubt this is important enough to
Hi,
On Fri, Jul 11, 2014 at 3:13 PM, Sawada Masahiko sawada.m...@gmail.com
wrote:
To my understating cleanly, you means that line number is not changed
when newline has reached to INT_MAX, is incorrect?
As per my thinking yes.
And the line number should be switched to 1 when line
On Fri, Jul 11, 2014 at 1:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
We could no doubt fix this by also insisting that the left-side vars
be provably not null, but that's going to make the patch even slower
and even less often applicable. I'm feeling discouraged about whether
Thank you for review.
So, you're compressing backup blocks one by one. I wonder if that's the
right idea and if we shouldn't instead compress all of them in one run to
increase the compression ratio.
The idea behind compressing blocks one by one was to keep the code as much
similar to the
Fujii Masao wrote:
On Thu, Jul 10, 2014 at 6:16 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Here's a new version of this patch, which is more generic the original
versions, and similar to what you describe.
I've not read the discussion so far at all, but I found the problem
when
On Fri, Jul 11, 2014 at 12:18:40AM -0400, Alvaro Herrera wrote:
Bruce Momjian wrote:
On Thu, Jul 10, 2014 at 06:38:26PM -0400, Bruce Momjian wrote:
I have thought some more on this. I thought I would need to open
pg_class in C and do complex backend stuff, but I now realize I can do
On Fri, Jul 11, 2014 at 09:48:06AM -0400, Bruce Momjian wrote:
Uh, why does this need to be in ALTER TABLE? Can't this be part of
table creation done by pg_dump?
Uh, I think you need to read the thread. We have to delay the toast
creation part so we don't use an oid that will later be
Jeevan Chalke wrote:
On Fri, Jul 11, 2014 at 3:13 PM, Sawada Masahiko sawada.m...@gmail.com
wrote:
And the line number should be switched to 1 when line number has
reached to INT_MAX?
Yes, when it goes beyond INT_MAX, wrap around to 1.
BTW, I wonder, can't we simply use unsigned int
Benedikt Grundmann wrote
That is it possible to tell the planner that index is off limits i.e.
don't
ever generate a plan using it?
Rationale: Schema changes on big tables. I might have convinced myself /
strong beliefs that for all queries that I need to be fast the planner
does
not
David Rowley dgrowle...@gmail.com writes:
On Fri, Jul 11, 2014 at 1:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Hm ... actually, there might be a better answer: what about transforming
WHERE (x,y) NOT IN (SELECT provably-not-null-values FROM ...)
to
WHERE antijoin condition AND x IS NOT NULL
David G Johnston david.g.johns...@gmail.com writes:
Benedikt Grundmann wrote
That is it possible to tell the planner that index is off limits i.e.
don't ever generate a plan using it?
Catalog hacking could work but not recommended (nor do I know the proper
commands and limitations). Do you
On 2014-07-11 11:07:21 -0400, Tom Lane wrote:
David G Johnston david.g.johns...@gmail.com writes:
Benedikt Grundmann wrote
That is it possible to tell the planner that index is off limits i.e.
don't ever generate a plan using it?
Catalog hacking could work but not recommended (nor do I
Andres Freund and...@2ndquadrant.com writes:
On 2014-07-11 11:07:21 -0400, Tom Lane wrote:
Hacking pg_index.indisvalid could work, given a reasonably recent PG.
I would not try it in production until I'd tested it ;-)
Works, but IIRC can cause problems at least 9.4 because concurrent
cache
On 2014-07-11 11:20:08 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-07-11 11:07:21 -0400, Tom Lane wrote:
Hacking pg_index.indisvalid could work, given a reasonably recent PG.
I would not try it in production until I'd tested it ;-)
Works, but IIRC can
Andres Freund and...@2ndquadrant.com writes:
On 2014-07-11 11:20:08 -0400, Tom Lane wrote:
If you're talking about SnapshotNow hazards, I think the risk would be
minimal, and probably no worse than cases that the system will cause
by itself.
Yes, SnapshotNow. I could reproduce it causing
On Fri, 2014-07-11 at 14:41 +0900, Fujii Masao wrote:
Could you add the patch into next CF?
Sure. The patch is so small I was thinking about committing it in a few
days (assuming no complaints), but I'm in no hurry.
The patch doesn't contain the change of the document. But I think that
it's
Jeff Davis pg...@j-davis.com writes:
Attached is a small patch to $SUBJECT.
In master, only single-byte characters are allowed as an escape. Of
course, with the patch it must still be a single character, but it may
be multi-byte.
I'm concerned about the performance cost of this patch. Have
On Fri, Jul 11, 2014 at 11:07:21AM -0400, Tom Lane wrote:
David G Johnston david.g.johns...@gmail.com writes:
Benedikt Grundmann wrote
That is it possible to tell the planner that index is off limits
i.e.
don't ever generate a plan using it?
Catalog hacking could work but not
On Fri, Jul 11, 2014 at 12:12 PM, Michael Banck mba...@gmx.net wrote:
On Fri, Jul 11, 2014 at 11:07:21AM -0400, Tom Lane wrote:
David G Johnston david.g.johns...@gmail.com writes:
Benedikt Grundmann wrote
That is it possible to tell the planner that index is off limits
i.e.
don't
On Thu, Jul 10, 2014 at 4:20 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Claudio Freire wrote:
On Wed, Jul 9, 2014 at 6:16 PM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Another thing I noticed is that version 8 of the patch blindly believed
the pages_per_range declared in
On Fri, Jul 11, 2014 at 11:01 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Jeevan Chalke wrote:
On Fri, Jul 11, 2014 at 3:13 PM, Sawada Masahiko sawada.m...@gmail.com
wrote:
And the line number should be switched to 1 when line number has
reached to INT_MAX?
Yes, when it goes
Sawada Masahiko wrote:
As you said, if line number reached UINT_MAX then I think that this
case is too strange.
I think INT_MAX is enough for line number.
My point is not whether 2 billion is a better number than 4 billion as a
maximum value. My point is that wraparound of signed int is, I
On 10.7.2014 21:33, Tomas Vondra wrote:
On 9.7.2014 16:07, Robert Haas wrote:
On Tue, Jul 8, 2014 at 5:16 PM, Tomas Vondra t...@fuzzy.cz wrote:
Thinking about this a bit more, do we really need to build the hash
table on the first pass? Why not to do this:
(1) batching
- read the
Heikki Linnakangas wrote:
I did again the refactoring you did back in 2006, patch attached.
One thing I did differently: I moved the raw, non-encrypted,
read/write functions to separate functions: pqsecure_raw_read and
pqsecure_raw_write. Those functions encapsulate the SIGPIPE
handling. The
On Fri, Jul 11, 2014 at 4:55 AM, Stephen Frost sfr...@snowman.net wrote:
On Thursday, July 10, 2014, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jul 9, 2014 at 2:13 AM, Stephen Frost sfr...@snowman.net wrote:
Yes, this would be possible (and is nearly identical to the original
patch,
On Thu, Jul 10, 2014 at 1:05 AM, Amit Kapila amit.kapil...@gmail.com wrote:
On Tue, Jul 8, 2014 at 1:27 AM, Robert Haas robertmh...@gmail.com wrote:
6. In general, I'm worried that it's going to be hard to keep the
overhead of parallel sort from leaking into the non-parallel case.
With the
Robert,
On Friday, July 11, 2014, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jul 11, 2014 at 4:55 AM, Stephen Frost sfr...@snowman.net
javascript:; wrote:
My feeling at the moment is that having them be per-table makes sense and
we'd still have flexibility to change later if we had
On Fri, Jul 11, 2014 at 6:00 PM, Claudio Freire klaussfre...@gmail.com wrote:
Marking as read-only is ok, or emitting a NOTICE so that if anyone
changes those parameters that change the shape of the index, they know
it needs a rebuild would be OK too. Both mechanisms work for me.
We don't
On Fri, Jul 11, 2014 at 3:47 PM, Greg Stark st...@mit.edu wrote:
On Fri, Jul 11, 2014 at 6:00 PM, Claudio Freire klaussfre...@gmail.com
wrote:
Marking as read-only is ok, or emitting a NOTICE so that if anyone
changes those parameters that change the shape of the index, they know
it needs a
This example in the regression database is a simplified version of a bug
I was shown off-list:
regression=# select (
select q from
( select 1,2,3 where f10
union all
select 4,5,6.0 where f1=0
) q
)
from int4_tbl;
ERROR: record type has not been registered
The reason for the problem is that
On Thu, Jul 10, 2014 at 08:46:55AM +0530, Amit Kapila wrote:
As per my understanding of the general theory around barriers,
read and write are defined to avoid reordering due to compiler and
full memory barriers are defined to avoid reordering due to processors.
There are some processors that
On Thu, Jul 10, 2014 at 2:52 AM, Tomonari Katsumata
katsumata.tomon...@po.ntts.co.jp wrote:
Several couple weeks ago, I posted a mail to pgsql-doc.
http://www.postgresql.org/message-id/53992ff8.2060...@po.ntts.co.jp
In this thread, I concluded that it's better to
round up the value which is
On Fri, 2014-07-11 at 11:51 -0400, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
Attached is a small patch to $SUBJECT.
In master, only single-byte characters are allowed as an escape. Of
course, with the patch it must still be a single character, but it may
be multi-byte.
I'm
On Thu, Jun 19, 2014 at 01:01:34PM -0400, Tom Lane wrote:
Noah Misch n...@leadboat.com writes:
On Thu, Jun 12, 2014 at 05:02:19PM -0400, Noah Misch wrote:
You can cause the at-exit crash by building PostgreSQL against OpenLDAP
2.4.31, connecting with LDAP authentication, and issuing LOAD
On Fri, Jul 11, 2014 at 11:15 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jul 10, 2014 at 1:05 AM, Amit Kapila amit.kapil...@gmail.com
wrote:
If there is an noticeable impact, then do you think having separate
file/infrastructure for parallel sort can help, basically non-parallel
On Sat, Jul 12, 2014 at 1:26 AM, Martijn van Oosterhout klep...@svana.org
wrote:
On Thu, Jul 10, 2014 at 08:46:55AM +0530, Amit Kapila wrote:
As per my understanding of the general theory around barriers,
read and write are defined to avoid reordering due to compiler and
full memory
62 matches
Mail list logo
