On Thu, Aug 7, 2014 at 8:20 AM, Jeff Janes jeff.ja...@gmail.com wrote:
It needs to go into 9_4_STABLE as well.
It is worth noticing that the buildfarm is completely in red because
this patch was not backpatched to REL9_4_STABLE:
http://buildfarm.postgresql.org/cgi-bin/show_status.pl
Regards,
--
On Thu, Aug 7, 2014 at 12:36 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Wed, Aug 6, 2014 at 1:32 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Jul 29, 2014 at 9:26 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
The reason is that during startup DataDir is not set by the time
On Thu, Aug 7, 2014 at 12:28 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Wed, Aug 6, 2014 at 11:39 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Aug 5, 2014 at 12:49 PM, Fujii Masao masao.fu...@gmail.com
wrote:
On Mon, Aug 4, 2014 at 11:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Hi,
2014-08-07 13:47 GMT+09:00 Fujii Masao masao.fu...@gmail.com:
On Thu, Aug 7, 2014 at 3:59 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 08/06/2014 08:39 PM, Fujii Masao wrote:
The WAL files that pg_receivexlog writes will not be re-read soon
basically,
so we can advise
IMHO, while worst case performance is a very useful tool for analyzing
algorithms (particularly their worst case time complexity), a worst
case should be put in its practical context. For example, if we had
reason to be concerned about *adversarial* inputs, I think that there
is a good chance
Hello John,
[...]
In fact, the mentioned paper says this about the subject Moreover, if
worst-case performance is important, Quicksort is the wrong algorithm.
I fully agree with this conclusion.
--
Fabien
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On 08/07/2014 10:10 AM, Mitsumasa KONDO wrote:
2014-08-07 13:47 GMT+09:00 Fujii Masao masao.fu...@gmail.com:
On Thu, Aug 7, 2014 at 3:59 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 08/06/2014 08:39 PM, Fujii Masao wrote:
The WAL files that pg_receivexlog writes will not be
On Wed, Aug 6, 2014 at 10:36 PM, Peter Geoghegan p...@heroku.com wrote:
This *almost* applies to patched Postgres if you pick a benchmark that
is very sympathetic to my patch. To my surprise, work_mem = '10MB'
(which results in an external tape sort) is sometimes snapping at the
heels of a
Okay, applied the patch.
I heavily modified your patch based on the master that the refactoring
patch has been applied. Attached is that modified version. Could you
review that?
Thank you for the patch.
I did a review of the patch.
No problem in the patch.
Behavior after the true return
Fabien,
I have not tested, but the patch looks ok in principle.
Thanks for the review. I have registered it to Aug Commit fest.
https://commitfest.postgresql.org/action/patch_view?id=1532
I'm not sure of the variable name is_non_init_parameter_set. I would
suggest benchmarking_option_set?
On 6 August 2014 17:27, Bruce Momjian br...@momjian.us wrote:
On Wed, Aug 6, 2014 at 01:15:32PM -0300, Claudio Freire wrote:
On Wed, Aug 6, 2014 at 12:20 PM, Bruce Momjian br...@momjian.us wrote:
Well, for file-level backups we have:
1) use file modtime (possibly inaccurate)
On 08/05/2014 10:44 PM, Shaun Thomas wrote:
On 08/05/2014 12:56 AM, Mark Kirkwood wrote:
The moral of the story for this case is that mapping Oracle to Postgres
datatypes can require some careful thought. Using 'native' types (like
integer, float8 etc) will generally give vastly quicker
Hi!
I have a questions about setting transaction's wraparound limits. Function
SetTransactionIdLimit() in access/transam/varsup.c:
1)
xidWrapLimit = oldest_datfrozenxid + (MaxTransactionId 1);
if (xidWrapLimit FirstNormalTransactionId)
xidWrapLimit +=
Hi!
Here is a report of what has been discussed yesterday on IRC.
The kmedoids module now seems to work correctly on basic datasets. I've
also implemented its variants with different seeding methods: random
initial medoids, and initial medoids distributed among the points (similar
to kmeans++
On Thu, Aug 7, 2014 at 4:15 AM, Craig Ringer cr...@2ndquadrant.com wrote:
I'm thinking about adding a new message type in the protocol that gets
sent immediately before CommandComplete, containing the LSN of the
commit. Clients would need to enable the sending of this message with a
GUC that
On Thu, Aug 7, 2014 at 5:02 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 08/07/2014 10:10 AM, Mitsumasa KONDO wrote:
2014-08-07 13:47 GMT+09:00 Fujii Masao masao.fu...@gmail.com:
On Thu, Aug 7, 2014 at 3:59 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 08/06/2014
On Thu, Aug 7, 2014 at 12:20 AM, Bruce Momjian br...@momjian.us wrote:
On Wed, Aug 6, 2014 at 06:48:55AM +0100, Simon Riggs wrote:
On 6 August 2014 03:16, Bruce Momjian br...@momjian.us wrote:
On Wed, Aug 6, 2014 at 09:17:35AM +0900, Michael Paquier wrote:
On Wed, Aug 6, 2014 at 9:04 AM,
On Thu, Aug 7, 2014 at 8:11 PM, Fujii Masao masao.fu...@gmail.com wrote:
There are some data which don't have LSN, for example, postgresql.conf.
When such data has been modified since last backup, they also need to
be included in incremental backup? Probably yes.
Definitely yes. That's as well
On 21 June 2014 23:36, Kevin Grittner kgri...@ymail.com wrote:
Kevin Grittner kgri...@ymail.com wrote:
I didn't change the tuplestores to TID because it seemed to me that
it would preclude using transition relations with FDW triggers, and
it seemed bad not to support that. Does anyone see a
On Thu, May 8, 2014 at 10:28 PM, Andres Freund and...@2ndquadrant.com wrote:
Well, we have to live with it for now :)
I just had a look at the first patch and got some comments:
1) Instead of using an assertion here, wouldn't it be better to error
out if name is NULL, and truncate the name if it
On 08/07/2014 01:34 PM, Teodor Sigaev wrote:
Hi!
I have a questions about setting transaction's wraparound limits. Function
SetTransactionIdLimit() in access/transam/varsup.c:
1)
xidWrapLimit = oldest_datfrozenxid + (MaxTransactionId 1);
if (xidWrapLimit FirstNormalTransactionId)
On Fri, May 23, 2014 at 9:38 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, May 20, 2014 at 4:02 AM, Yuto HAYAMIZU y.hayam...@gmail.com wrote:
The failing assertion is for prohibiting memory allocation in a critical
section, which is introduced by commit 4a170ee9 on 2014-04-04.
This
On Wed, Aug 6, 2014 at 9:35 PM, Bruce Momjian br...@momjian.us wrote:
On Sun, Jan 12, 2014 at 12:53:40PM -0500, Noah Misch wrote:
On Sat, Jan 11, 2014 at 02:10:01PM -0500, Bruce Momjian wrote:
On Mon, Jun 3, 2013 at 03:07:27PM -0400, Noah Misch wrote:
A colleague, Korry Douglas, observed a
On Wed, Aug 6, 2014 at 7:20 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Wed, Aug 6, 2014 at 8:35 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Aug 5, 2014 at 6:05 PM, Jeff Janes jeff.ja...@gmail.com wrote:
I think you missed one of the regression tests, see attached
Woops. Thanks,
On Wed, Aug 6, 2014 at 4:06 PM, Nicolas Barbier
nicolas.barb...@gmail.com wrote:
2014-08-06 Claudio Freire klaussfre...@gmail.com:
So, I like blockfilter a lot. I change my vote to blockfilter ;)
+1 for blockfilter, because it stresses the fact that the physical
arrangement of rows in blocks
FabrÃzio de Royes Mello wrote:
On Tue, Aug 5, 2014 at 10:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com writes:
BTW, while there's unlikely to be a good reason to put search_path in
pg.conf with appends, there are a LOT of reasons to want to be able to
append
On 7 August 2014 14:53, Robert Haas robertmh...@gmail.com wrote:
On Wed, Aug 6, 2014 at 4:06 PM, Nicolas Barbier
nicolas.barb...@gmail.com wrote:
2014-08-06 Claudio Freire klaussfre...@gmail.com:
So, I like blockfilter a lot. I change my vote to blockfilter ;)
+1 for blockfilter, because it
On Thu, Aug 7, 2014 at 11:16 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 7 August 2014 14:53, Robert Haas robertmh...@gmail.com wrote:
On Wed, Aug 6, 2014 at 4:06 PM, Nicolas Barbier
nicolas.barb...@gmail.com wrote:
2014-08-06 Claudio Freire klaussfre...@gmail.com:
So, I like blockfilter
Thanks for your review and comments, Amit!
Amit Khandekar amit.khande...@enterprisedb.com wrote:
On 21 June 2014 23:36, Kevin Grittner kgri...@ymail.com wrote:
Kevin Grittner kgri...@ymail.com wrote:
I didn't change the tuplestores to TID because it seemed to me that
it would preclude using
On Wed, Jul 2, 2014 at 4:26 AM, Abhijit Menon-Sen a...@2ndquadrant.com wrote:
Hi.
Do we have any consensus about what to do with these two patches?
1. Introduce a log_replication_command setting.
2. Change log_statement to be a list of tokens.
If I understand correctly, there weren't any
On Thu, Aug 7, 2014 at 5:12 AM, Craig Ringer cr...@2ndquadrant.com wrote:
New Intel hardware supports IEEE 754:2008 decimal floating point in
hardware, and I'm quite interested in implementing DECFLOAT(n) for
PostgreSQL to take advantage of that.
+1
merlin
--
Sent via pgsql-hackers mailing
Simon Riggs wrote:
On 7 August 2014 14:53, Robert Haas robertmh...@gmail.com wrote:
On Wed, Aug 6, 2014 at 4:06 PM, Nicolas Barbier
nicolas.barb...@gmail.com wrote:
2014-08-06 Claudio Freire klaussfre...@gmail.com:
So, I like blockfilter a lot. I change my vote to blockfilter ;)
+1
On Thu, Aug 7, 2014 at 10:16 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 7 August 2014 14:53, Robert Haas robertmh...@gmail.com wrote:
On Wed, Aug 6, 2014 at 4:06 PM, Nicolas Barbier
nicolas.barb...@gmail.com wrote:
2014-08-06 Claudio Freire klaussfre...@gmail.com:
So, I like blockfilter
On Tue, Aug 5, 2014 at 8:15 PM, Peter Geoghegan p...@heroku.com wrote:
The adversarial method works for almost any polymorphic program
recognizable as quicksort. The subject quicksort may copy values at
will, or work with lists rather than arrays. It may even pick the
pivot at random. The
Hello Tatsuo-san,
Thanks for the review. I have registered it to Aug Commit fest.
https://commitfest.postgresql.org/action/patch_view?id=1532
I'm not sure of the variable name is_non_init_parameter_set. I would
suggest benchmarking_option_set?
Ok, I will replace the variable name as you
On Thu, Aug 7, 2014 at 08:35:53PM +0900, Michael Paquier wrote:
On Thu, Aug 7, 2014 at 8:11 PM, Fujii Masao masao.fu...@gmail.com wrote:
There are some data which don't have LSN, for example, postgresql.conf.
When such data has been modified since last backup, they also need to
be included
On Thu, Aug 7, 2014 at 11:03:40AM +0100, Simon Riggs wrote:
Well, there is a huge difference between file-level and block-level backup.
Designing, writing and verifying block-level backup to the point that
it is acceptable is a huge effort. (Plus, I don't think accumulating
block numbers as
+1 for BRIN !
On Thu, Aug 7, 2014 at 6:16 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 7 August 2014 14:53, Robert Haas robertmh...@gmail.com wrote:
On Wed, Aug 6, 2014 at 4:06 PM, Nicolas Barbier
nicolas.barb...@gmail.com wrote:
2014-08-06 Claudio Freire klaussfre...@gmail.com:
So, I
On Wed, Aug 6, 2014 at 9:15 PM, Craig Ringer cr...@2ndquadrant.com wrote:
To support transparent client-side failover in BDR, it's necessary to
know what the LSN of a node was at the time a transaction committed and
keep track of that in the client/proxy.
I doubt whether it makes sense to do
Il 07/08/14 17:29, Bruce Momjian ha scritto:
I am a little worried that many users will not realize this until they
try it and are disappointed, e.g. Why is PG writing to my static data
so often? --- then we get beaten up about our hint bits and freezing
behavior. :-(
I am just trying to
Il 07/08/14 17:25, Bruce Momjian ha scritto:
On Thu, Aug 7, 2014 at 08:35:53PM +0900, Michael Paquier wrote:
On Thu, Aug 7, 2014 at 8:11 PM, Fujii Masao masao.fu...@gmail.com wrote:
There are some data which don't have LSN, for example, postgresql.conf.
When such data has been modified since
At 2014-08-07 23:22:43 +0900, masao.fu...@gmail.com wrote:
That is, we log replication commands only when log_statement is set to
all. Neither new parameter is introduced nor log_statement is
redefined as a list.
That sounds good to me.
-- Abhijit
--
Sent via pgsql-hackers mailing list
On Thu, Aug 7, 2014 at 11:07 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Aug 5, 2014 at 8:15 PM, Peter Geoghegan p...@heroku.com wrote:
The adversarial method works for almost any polymorphic program
recognizable as quicksort. The subject quicksort may copy values at
will, or work
On Thu, Aug 7, 2014 at 8:07 AM, Robert Haas robertmh...@gmail.com wrote:
So here. You may not agree that the mitigation strategies for which
others are asking for are worthwhile, but you can't expect everyone
else to agree with your assessment of which cases are likely to occur
in practice.
Hi Marco,
With the current full backup procedure they are backed up, so I think
that having them backed up with a rsync-like algorithm is what an user
would expect for an incremental backup.
Exactly. I think a simple, flexible and robust method for file based
incremental backup is all we
2014-08-07 Oleg Bartunov obartu...@gmail.com:
+1 for BRIN !
+1, rolls off the tongue smoothly and captures the essence :-).
Nicolas
--
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On 07/08/14 16:16, Simon Riggs wrote:
A better description would be block range index since we are
indexing a range of blocks (not just one block). Perhaps a better one
would be simply range index, which we could abbreviate to RIN or
BRIN.
+1 for block range index (BRIN)
--
Petr Jelinek
On Thu, Aug 7, 2014 at 1:16 PM, Peter Geoghegan p...@heroku.com wrote:
On Thu, Aug 7, 2014 at 8:07 AM, Robert Haas robertmh...@gmail.com wrote:
So here. You may not agree that the mitigation strategies for which
others are asking for are worthwhile, but you can't expect everyone
else to agree
On Tue, Aug 5, 2014 at 07:31:21PM -0400, Bruce Momjian wrote:
On Thu, Jul 10, 2014 at 06:38:26PM -0400, Bruce Momjian wrote:
On Thu, Jul 10, 2014 at 06:17:14PM -0400, Bruce Momjian wrote:
Well, we are going to need to call internal C functions, often bypassing
their typical call sites
On Thu, Aug 7, 2014 at 11:33 AM, Robert Haas robertmh...@gmail.com wrote:
I think that's actually not a very unrealistic case at all. In
general, I think that if a particular data distribution is a
reasonable scenario, that data distribution plus it's already sorted
is also reasonable. Data
On Wed, Aug 6, 2014 at 7:18 PM, Peter Geoghegan p...@heroku.com wrote:
On Wed, Aug 6, 2014 at 1:11 PM, Robert Haas robertmh...@gmail.com wrote:
I've committed the patch I posted yesterday. I did not see a good
reason to meld that together in a single commit with the first of the
patches you
On Thu, Aug 7, 2014 at 3:15 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Aug 6, 2014 at 7:18 PM, Peter Geoghegan p...@heroku.com wrote:
On Wed, Aug 6, 2014 at 1:11 PM, Robert Haas robertmh...@gmail.com wrote:
I've committed the patch I posted yesterday. I did not see a good
reason to
Robert Haas robertmh...@gmail.com writes:
On Sat, Aug 2, 2014 at 9:15 AM, Daniele Varrazzo
daniele.varra...@gmail.com wrote:
I'd definitely replace /arg/argument/. Furthermore I'd avoid the form
argument 1: something is wrong: the string is likely to end up in
sentences with other colons so
2014-08-07 7:10 GMT+02:00 Fujii Masao masao.fu...@gmail.com:
On Thu, Aug 7, 2014 at 6:26 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Hello
updated version patch in attachment
Thanks! But ISTM you forgot to attached the patch.
grr .. I am sorry
+/* all psql known
On Thu, Aug 7, 2014 at 12:15 PM, Robert Haas robertmh...@gmail.com wrote:
In my original patch, I wrote NUL, as in the NUL character. You've
changed it to NULL, but the original was correct. NULL is a pointer
value that is not relevant here; the character with value 0 is NUL.
NULL-terminated
Craig Ringer cr...@2ndquadrant.com writes:
Hi all
To support transparent client-side failover in BDR, it's necessary to
know what the LSN of a node was at the time a transaction committed and
keep track of that in the client/proxy.
I'm thinking about adding a new message type in the protocol
On Thu, Aug 7, 2014 at 12:17 PM, Robert Haas robertmh...@gmail.com wrote:
Gah. Hit send to soon. Also, as much as I'd prefer to avoid
relitigating the absolutely stupid debate about how to expand the
buffers, this is no good:
+ tss-buflen1 = Max(len1 + 1, tss-buflen1 * 2);
Hi,
Still translating the 9.4 manual, and found another typo. Patch attached.
Thanks.
--
Guillaume.
http://blog.guillaume.lelarge.info
http://www.dalibo.com
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index d3fcb82..cf174f0 100644
---
On Thu, Aug 7, 2014 at 12:06 PM, Peter Geoghegan p...@heroku.com wrote:
I think that pre-sorted, all-unique text datums, that have all
differences beyond the first 8 bytes, that the user happens to
actually want to sort are fairly rare.
Actually, you could use that case to justify not doing
On Thu, Aug 7, 2014 at 3:06 PM, Peter Geoghegan p...@heroku.com wrote:
I think that pre-sorted, all-unique text datums, that have all
differences beyond the first 8 bytes, that the user happens to
actually want to sort are fairly rare.
While I'm sure it's not common, I've seen a couple of
Tom Lane-2 wrote
Robert Haas lt;
robertmhaas@
gt; writes:
On Sat, Aug 2, 2014 at 9:15 AM, Daniele Varrazzo
lt;
daniele.varrazzo@
gt; wrote:
I'd definitely replace /arg/argument/. Furthermore I'd avoid the form
argument 1: something is wrong: the string is likely to end up in
On Thu, Aug 7, 2014 at 2:23 PM, Rod Taylor rod.tay...@gmail.com wrote:
While I'm sure it's not common, I've seen a couple of ten-million tuple
tables having a URL column as primary key where 98% of the entries begin
with 'http://www.'
So, that exact scenario is out there.
Sure, that scenario
Sigh. Found another example.
A table with 15 million entries and a unique key on filesystem location for
things users created via a web interface.
Entries all begin with /usr/home/ ...
This one is frequently sorted as batch operations against the files are
performed in alphabetical order to
On Thu, Aug 7, 2014 at 2:34 PM, Rod Taylor rod.tay...@gmail.com wrote:
This one is frequently sorted as batch operations against the files are
performed in alphabetical order to reduce conflict issues that a random
ordering may cause between jobs.
Sure. There are cases out there. But, again, I
Alvaro Herrera alvhe...@2ndquadrant.com writes:
FabrÃzio de Royes Mello wrote:
On Tue, Aug 5, 2014 at 10:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com writes:
BTW, while there's unlikely to be a good reason to put search_path in
pg.conf with appends, there
Hello,
I know this has been brought up before:
http://www.postgresql.org/message-id/20140724080902.ga28...@msg.df7cb.de
But this is just plain wrong. I don't care that the FAQ (on the wiki)
says we are doing it wrong for good reasons. When I (or anyone else)
pulls postgresql-$version-dev, I
James Cloos cl...@jhcloos.com writes:
ST == Shaun Thomas stho...@optionshouse.com writes:
ST That said, the documentation here says FLOAT4 is an alias for REAL,
ST so it's somewhat nonintuitive for FLOAT4 to be so much slower than
ST FLOAT8, which is an alias for DOUBLE PRECISION.
There are
On 08/07/2014 04:48 PM, Tom Lane wrote:
plpgsql is not efficient at all about coercions performed as a side
effect of assignments; if memory serves, it always handles them by
converting to text and back. So basically the added cost here came
from float8out() and float4in(). There has been
Guillaume Lelarge guilla...@lelarge.info writes:
Still translating the 9.4 manual, and found another typo. Patch attached.
Applied, thanks!
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 08/07/2014 08:38 AM, Oleg Bartunov wrote:
+1 for BRIN !
On Thu, Aug 7, 2014 at 6:16 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 7 August 2014 14:53, Robert Haas robertmh...@gmail.com wrote:
A better description would be block range index since we are
indexing a range of blocks (not
On 08/08/2014 03:54 AM, Tom Lane wrote:
Craig Ringer cr...@2ndquadrant.com writes:
Hi all
To support transparent client-side failover in BDR, it's necessary to
know what the LSN of a node was at the time a transaction committed and
keep track of that in the client/proxy.
I'm thinking about
On Fri, Aug 8, 2014 at 9:47 AM, Josh Berkus j...@agliodbs.com wrote:
On 08/07/2014 08:38 AM, Oleg Bartunov wrote:
+1 for BRIN !
On Thu, Aug 7, 2014 at 6:16 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 7 August 2014 14:53, Robert Haas robertmh...@gmail.com wrote:
A better description would
David G Johnston david.g.johns...@gmail.com writes:
Tom Lane-2 wrote
Surely that was meant to read invalid number OF arguments. The errhint
is only charitably described as English, as well. I'd suggest something
like Arguments of json_build_object() must be pairs of keys and values.
--- but
On Thu, Aug 7, 2014 at 7:58 AM, Robert Haas robertmh...@gmail.com wrote:
range index might get confused with range types; block range index
seems better. I like summary, but I'm fine with block range index or
block filter index, too.
+1
--
Peter Geoghegan
--
Sent via pgsql-hackers
Craig Ringer cr...@2ndquadrant.com writes:
On 08/08/2014 03:54 AM, Tom Lane wrote:
FWIW, I think it's a seriously bad idea to expose LSNs in the protocol
at all. What happens five years from now when we switch to some other
implementation that doesn't have LSNs?
Everyone who's relying on
On 08/07/2014 11:42 PM, Robert Haas wrote:
I doubt whether it makes sense to do this without a broader
understanding of how the client-side failover mechanism would work.
If we're going to add something like this, it should include libpq
support for actually doing something useful with it.
On Thu, Aug 7, 2014 at 5:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David G Johnston david.g.johns...@gmail.com writes:
Tom Lane-2 wrote
Surely that was meant to read invalid number OF arguments. The
errhint
is only charitably described as English, as well. I'd suggest something
like
On 08/08/2014 09:02 AM, Tom Lane wrote:
Craig Ringer cr...@2ndquadrant.com writes:
On 08/08/2014 03:54 AM, Tom Lane wrote:
FWIW, I think it's a seriously bad idea to expose LSNs in the protocol
at all. What happens five years from now when we switch to some other
implementation that doesn't
On 08/07/2014 05:52 PM, Michael Paquier wrote:
On Fri, Aug 8, 2014 at 9:47 AM, Josh Berkus j...@agliodbs.com wrote:
On 08/07/2014 08:38 AM, Oleg Bartunov wrote:
+1 for BRIN !
On Thu, Aug 7, 2014 at 6:16 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 7 August 2014 14:53, Robert Haas
On Fri, Aug 8, 2014 at 9:50 AM, Craig Ringer cr...@2ndquadrant.com wrote:
On 08/08/2014 03:54 AM, Tom Lane wrote:
Craig Ringer cr...@2ndquadrant.com writes:
Hi all
To support transparent client-side failover in BDR, it's necessary to
know what the LSN of a node was at the time a transaction
On 08/08/2014 10:58 AM, Fujii Masao wrote:
ISTM that the proper solution to that problem is the introduction of
new synchronous replication mode which makes the transaction wait for
its WAL to be replayed by the standby. If this mode is used, a client
doesn't need to track the LSN of each
On Fri, Aug 8, 2014 at 11:58 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, Aug 8, 2014 at 9:50 AM, Craig Ringer cr...@2ndquadrant.com wrote:
ISTM that the proper solution to that problem is the introduction of
new synchronous replication mode which makes the transaction wait for
its WAL
I looked into the issue reported in bug #11109. The problem appears to be
that jsonb's on-disk format is designed in such a way that the leading
portion of any JSON array or object will be fairly incompressible, because
it consists mostly of a strictly-increasing series of integer offsets.
This
On 08/08/2014 09:51 AM, Tom Lane wrote:
AFAIK we don't _have_ a fancy negotiation system in the protocol, with
back-and-forth exchanges of capabilities information.
Maybe it's time to invent that. It would be positively foolish to
create any such behavior without a protocol version bump
Hi, thank you for the comment.
Hi Kyotaro,
I looked at the patches and felt that the approach taken here is too
intrusive, considering that the feature is only for foreign scans.
I agree to you premising that it's only for foreign scans but I
regard it as an example of parallel execution
Hi,
We can specify the unit when setting autovacuum_vacuum_cost_delay
GUC as follows.
ALTER SYSTEM SET autovacuum_vacuum_cost_delay TO '80ms';
OTOH we cannot specify the unit when setting autovacuum_vacuum_cost_delay
as storage parameter as follows.
CREATE TABLE test (col1 int) WITH
Hello,
Although, yes, you're right, irrespective of the common
something, and even if the dropped index was i_t1_pkey_2, which
is on t1(a, b), the result tuples are sorted as expected only by
the pathkey (t.a = t1.a, t1.b). It is because both t and t1 are
still unique so the joined
Fujii Masao wrote:
Hi,
We can specify the unit when setting autovacuum_vacuum_cost_delay
GUC as follows.
ALTER SYSTEM SET autovacuum_vacuum_cost_delay TO '80ms';
OTOH we cannot specify the unit when setting autovacuum_vacuum_cost_delay
as storage parameter as follows.
CREATE
Apologies if this is a ridiculous suggestion, but I believe that swapping
out the compression algorithm (for Snappy, for example) has been discussed
in the past. I wonder if that algorithm is sufficiently different that it
would produce a better result, and if that might not be preferable to some
On Thu, Aug 7, 2014 at 12:36 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Aug 7, 2014 at 12:36 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
On Wed, Aug 6, 2014 at 1:32 PM, Fujii Masao masao.fu...@gmail.com
wrote:
What about picking up only data_directory at the first pass?
I
On Fri, Aug 8, 2014 at 12:56 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Fujii Masao wrote:
Hi,
We can specify the unit when setting autovacuum_vacuum_cost_delay
GUC as follows.
ALTER SYSTEM SET autovacuum_vacuum_cost_delay TO '80ms';
OTOH we cannot specify the unit when
Fujii Masao wrote:
On Fri, Aug 8, 2014 at 12:56 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Hm, what's with the parse_int signature change and the hintmsg thing?
Is it just me or the patch is incomplete?
Sorry, probably I failed to see your point. You mean that the signature
of
JD,
* Joshua D. Drake (j...@commandprompt.com) wrote:
But this is just plain wrong. I don't care that the FAQ (on the
wiki) says we are doing it wrong for good reasons. When I (or anyone
else) pulls postgresql-$version-dev, I want the libpq for my
version. I do not want 9.3.
No, it isn't
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I looked into the issue reported in bug #11109. The problem appears to be
that jsonb's on-disk format is designed in such a way that the leading
portion of any JSON array or object will be fairly incompressible, because
it consists mostly of a
Fabien,
Hello Tatsuo-san,
Thanks for the review. I have registered it to Aug Commit fest.
https://commitfest.postgresql.org/action/patch_view?id=1532
I'm not sure of the variable name is_non_init_parameter_set. I would
suggest benchmarking_option_set?
Ok, I will replace the variable
On Fri, Aug 8, 2014 at 2:12 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Fujii Masao wrote:
On Fri, Aug 8, 2014 at 12:56 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Hm, what's with the parse_int signature change and the hintmsg thing?
Is it just me or the patch is incomplete?
96 matches
Mail list logo
