On 2014-11-02 19:27:25 +0100, Petr Jelinek wrote:
Well, Michael has point that the extradata is pretty much useless currently,
perhaps it would help to add the interface to set extradata?
Only accessible via C and useless aren't the same thing. But sure, add
it.
Greetings,
Andres Freund
--
On 11/04/2014 07:31 AM, Álvaro Hernández Tortosa wrote:
Thank you for your comment, Tom. However I think this behavior, as
seen from a user perspective, it's not the expected one.
That may be the case, but I think it's the SQL-standard behaviour, so we
can't really mess with it.
The spec
On Sat, Nov 1, 2014 at 10:00 PM, Michael Paquier michael.paqu...@gmail.com
wrote:
More comments:
I have done a couple of tests on my laptop with pgbench like that to
generate a maximum of transaction commits:
$ pgbench --no-vacuum -f ~/Desktop/commit.sql -T 60 -c 24 -j 24
$ cat
On 2014-11-04 17:19:18 +0900, Michael Paquier wrote:
5) Reading the code, TransactionTreeSetCommitTimestamp is always called
with do_xlog = false, making that actually no timestamps are WAL'd... Hence
WriteSetTimestampXlogRec is just dead code with the latest version of the
patch. IMO, this
On Tue, Nov 4, 2014 at 5:05 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-11-02 19:27:25 +0100, Petr Jelinek wrote:
Well, Michael has point that the extradata is pretty much useless
currently,
perhaps it would help to add the interface to set extradata?
Only accessible via C and
On Tue, Nov 4, 2014 at 5:23 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-11-04 17:19:18 +0900, Michael Paquier wrote:
5) Reading the code, TransactionTreeSetCommitTimestamp is always called
with do_xlog = false, making that actually no timestamps are WAL'd...
Hence
David Fetter wrote:
On Tue, Nov 04, 2014 at 07:51:06AM +0900, Tatsuo Ishii wrote:
Just out of curiosity, why is Oracle's NUMBER (I assume you are
talking about this) so fast?
I suspect that what happens is that NUMBER is stored as a native type
(int2, int4, int8, int16) that depends on its
On 3 November 2014 22:18, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
So here's v21. I also attach a partial diff from v20, just in case
anyone wants to give it a look.
Looks really good.
I'd like to reword this sentence in the readme, since one of the main
use cases would be tables
On 2014-11-04 17:29:04 +0900, Michael Paquier wrote:
On Tue, Nov 4, 2014 at 5:23 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-11-04 17:19:18 +0900, Michael Paquier wrote:
5) Reading the code, TransactionTreeSetCommitTimestamp is always called
with do_xlog = false, making
On 10/27/2014 06:02 PM, Heikki Linnakangas wrote:
I came up with the attached patches. They do three things:
1. Get rid of the 64-bit CRC code. It's not used for anything, and
haven't been for years, so it doesn't seem worth spending any effort to
fix them.
2. Switch to CRC-32C (Castagnoli)
On Mon, Nov 3, 2014 at 2:18 PM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
So here's v21. I also attach a partial diff from v20, just in case
anyone wants to give it a look.
This needs a bump to 1.3, or the extension won't install:
contrib/pageinspect/pageinspect.control
During crash
Mon, 3 Nov 2014 22:55:02 -0200 от Fabrízio de Royes Mello
fabriziome...@gmail.com:
On Mon, Nov 3, 2014 at 7:25 PM, Alexey Vasiliev leopard...@inbox.ru wrote:
Mon, 3 Nov 2014 19:18:51 -0200 от Fabrízio de Royes Mello
fabriziome...@gmail.com :
Should I change my
On 10/13/2014 01:01 PM, Petr Jelinek wrote:
Hi,
I rewrote the patch with different API along the lines of what was
discussed.
Thanks, that's better.
It would be good to see an alternative seqam to implement this API, to
see how it really works. The local one is too dummy to expose any
Michael Paquier wrote:
I'm still on a -1 for that. You mentioned that there is perhaps no reason
to delay a decision on this matter, but IMO there is no reason to rush
either in doing something we may regret. And I am not the only one on this
thread expressing concern about this extra data
On Mon, Nov 3, 2014 at 4:44 PM, Peter Eisentraut pete...@gmx.net wrote:
On 10/29/14 8:42 AM, Robert Haas wrote:
I'm sympathetic to that line of reasoning, but I really think that if
you want to keep this infrastructure, it needs to be made portable.
Let me clarify that this was my intention.
On Tue, Nov 4, 2014 at 4:47 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
I hear none, so committed with some small fixes.
Are you going to get the slice-by-N stuff working next, to speed this up?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL
On 2014-11-04 10:01:00 -0300, Alvaro Herrera wrote:
Michael Paquier wrote:
I'm still on a -1 for that. You mentioned that there is perhaps no reason
to delay a decision on this matter, but IMO there is no reason to rush
either in doing something we may regret. And I am not the only one on
On 2014-11-04 08:21:13 -0500, Robert Haas wrote:
On Tue, Nov 4, 2014 at 4:47 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
I hear none, so committed with some small fixes.
Are you going to get the slice-by-N stuff working next, to speed this up?
I don't plan to do anything serious
Hi,
On 2014-11-03 14:04:00 +0300, Alexey Vasiliev wrote:
* What the patch does in a short paragraph: This patch should add option
recovery_timeout, which help to control timeout of restore_command nonzero
status code. Right now default value is 5 seconds. This is useful, if I using
for
On Tue, Nov 04, 2014 at 11:44:22AM +0900, Michael Paquier wrote:
On Sun, Nov 2, 2014 at 2:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
In the case of hash indexes, because we still have to have the hash
opclasses in core, there's no way that it could be pushed out as an
extension module even
Feng Tian ft...@vitessedata.com wrote:
Performance different between Money and Numeric is *HUGE*. For
TPCH Q1, the performance difference is 5x for stock postgres, and
~20x for vitesse.
Stock postgres, for my laptop, TPCH 1G, Q1, use money type ~ 9s,
use Numeric (15, 2) is ~53s.
test=#
On 11/02/2014 06:41 PM, Tom Lane wrote:
I wrote:
Either way, requiring a dump/reload for upgrade is surely a better answer
for users of the type than just summarily screwing them.
BTW, after reflecting a bit more I'm less than convinced that this
datatype is completely useless. Even if you
On Tue, Nov 4, 2014 at 8:16 AM, Kevin Grittner kgri...@ymail.com wrote:
In any event, I'm against removing or re-deprecating the money
type. There are some problems with money; there are other problems
with numeric. If the docs are failing to make the trade-offs
clear, we should fix the
On 11/03/2014 10:11 PM, Tom Lane wrote:
Josh Berkusj...@agliodbs.com writes:
On 11/02/2014 11:41 AM, Tom Lane wrote:
Nothing that I recall at the moment, but there is certainly plenty of
stuff of dubious quality in there. I'd argue that chkpass, intagg,
intarray, isn, spi, and xml2 are all
Tue, 4 Nov 2014 14:41:56 +0100 от Andres Freund and...@2ndquadrant.com:
Hi,
On 2014-11-03 14:04:00 +0300, Alexey Vasiliev wrote:
* What the patch does in a short paragraph: This patch should add option
recovery_timeout, which help to control timeout of restore_command nonzero
On 7/11/14 4:36 AM, Ali Akbar wrote:
But i found some bug in libxml2's code, because we call xmlCopyNode with
1 as the second parameter, internally xmlCopyNode will call
xmlStaticCopyNode recursively via xmlStaticCopyNodeList. And
xmlStaticCopyNodeList doesn't check the return of
On 7/8/14 6:03 AM, Ali Akbar wrote:
If we put 1 as the parameter, the resulting Node will link to the
existing children. In this case, the namespace problem for the children
might be still exists. If any of the children uses different
namespace(s) than the parent, the namespace definition will
On 10/6/14 10:24 PM, Ali Akbar wrote:
While reviewing the patch myself, i spotted some formatting problems in
the code. Fixed in this v5 patch.
Also, this patch uses context patch format (in first versions, because
of the small modification, context patch format obfucates the changes.
After
On Tue, Oct 7, 2014 at 10:33 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
Some time ago, when debugging a GIN bug, I wrote these pageinspect
functions to inspect GIN indexes. They were very useful; we should add them.
I think these functions will be quite useful for debugging purpose
Craig Ringer cr...@2ndquadrant.com writes:
On 11/03/2014 03:41 AM, Tom Lane wrote:
Nothing that I recall at the moment, but there is certainly plenty of
stuff of dubious quality in there. I'd argue that chkpass, intagg,
intarray, isn, spi, and xml2 are all in worse shape than the money type.
On Mon, 2014-11-03 at 22:08 -0500, Tom Lane wrote:
spockFascinating./spock
:-)
I believe what is happening is:
[ . . . ]
This is not mission-critical for me but I'd be grateful for suggestions for
work-arounds.
I don't see any workaround that's much easier than fixing the bug.
But
On 10/9/14 1:58 PM, Fujii Masao wrote:
Also I think that it's useful to allow ALTER ROLE/DATABASE SET to
set PGC_BACKEND and PGC_SU_BACKEND parameters. So, what
about applying the attached patch? This patch allows that and
changes the context of session_preload_libraries to PGC_SU_BACKEND.
On Nov 4, 2014, at 12:55 AM, Craig Ringer cr...@2ndquadrant.com wrote:
On 11/04/2014 07:56 AM, Mikko Tiihonen wrote:
I also think the async I/O is the way to go. Luckily that has already been
done
in the pgjdbc-ng (https://github.com/impossibl/pgjdbc-ng), built on top
of netty java NIO
I wrote:
However: at no point in this sequence did we flush the original catalog
blocks out of shared buffers. Therefore, a read of the database's
pg_class or pg_type at this point is likely to find the previous states of
those pages (pre-composite-type-drop) as valid, matching entries, so
Peter Eisentraut pete...@gmx.net writes:
On 10/9/14 1:58 PM, Fujii Masao wrote:
Also I think that it's useful to allow ALTER ROLE/DATABASE SET to
set PGC_BACKEND and PGC_SU_BACKEND parameters. So, what
about applying the attached patch? This patch allows that and
changes the context of
On 10/27/14 11:40 AM, Stephen Frost wrote:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
As I started looking at this, there are multiple other places where
these types of error messages occur (opclasscmds.c, user.c,
postinit.c, miscinit.c are just a few), not just around the changes in
here's a patch for a utility function to look up the cast function for a
from/to pair of types, as recently suggested by Alvaro. Although it only
contains one use (in json.c), the upcoming jsonb generators would also
use it twice. I'd like to get this committed fairly quickly so I can
missing patch
Regards
Pavel
2014-11-04 18:57 GMT+01:00 Andrew Dunstan and...@dunslane.net:
here's a patch for a utility function to look up the cast function for a
from/to pair of types, as recently suggested by Alvaro. Although it only
contains one use (in json.c), the upcoming jsonb
On 11/04/2014 12:57 PM, Andrew Dunstan wrote:
here's a patch for a utility function to look up the cast function for
a from/to pair of types, as recently suggested by Alvaro. Although it
only contains one use (in json.c), the upcoming jsonb generators would
also use it twice. I'd like to
--On 3. November 2014 18:15:04 +0100 Sven Wegener
sven.wege...@stealer.net wrote:
I've check git master and 9.x and all show the same behaviour. I came up
with the patch below, which is against curent git master. The patch
modifies the COPY TO code to create a new snapshot, after acquiring
Andrew Dunstan and...@dunslane.net writes:
here's a patch for a utility function to look up the cast function for
a from/to pair of types, as recently suggested by Alvaro. Although it
only contains one use (in json.c), the upcoming jsonb generators would
also use it twice. I'd like to get
Bernd Helmle maili...@oopsware.de writes:
--On 3. November 2014 18:15:04 +0100 Sven Wegener
sven.wege...@stealer.net wrote:
I've check git master and 9.x and all show the same behaviour. I came up
with the patch below, which is against curent git master. The patch
modifies the COPY TO code
On 11/04/2014 01:51 PM, Tom Lane wrote:
Bernd Helmle maili...@oopsware.de writes:
--On 3. November 2014 18:15:04 +0100 Sven Wegener
sven.wege...@stealer.net wrote:
I've check git master and 9.x and all show the same behaviour. I came up
with the patch below, which is against curent git
On Tue, 4 Nov 2014, Bernd Helmle wrote:
--On 3. November 2014 18:15:04 +0100 Sven Wegener sven.wege...@stealer.net
wrote:
I've check git master and 9.x and all show the same behaviour. I came up
with the patch below, which is against curent git master. The patch
modifies the COPY TO
On Tue, 4 Nov 2014, Tom Lane wrote:
Bernd Helmle maili...@oopsware.de writes:
--On 3. November 2014 18:15:04 +0100 Sven Wegener
sven.wege...@stealer.net wrote:
I've check git master and 9.x and all show the same behaviour. I came up
with the patch below, which is against curent git
On 11/04/2014 07:33 AM, Tom Lane wrote:
More generally, it seems like a grab bag of not terribly well designed
features, and the features that do seem well designed seem like they
ought to be more generic than just for int4 arrays. So to me it feels
like proof-of-concept experimentation
Thanks for looking at this patch.
I suggest moving the rest of the changes into separate patches.
Hmmm... perhaps the following?
* superuser-cleanup - contains above mentioned superuser shortcuts only.
* has_privilege-cleanup - contains has_*_priviledge cleanup only.
Would that also require
On 2014-11-04 13:51:23 -0500, Tom Lane wrote:
Bernd Helmle maili...@oopsware.de writes:
--On 3. November 2014 18:15:04 +0100 Sven Wegener
sven.wege...@stealer.net wrote:
I've check git master and 9.x and all show the same behaviour. I came up
with the patch below, which is against curent
Michael Paquier wrote:
On Mon, Jul 14, 2014 at 6:14 PM, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp wrote:
Although I doubt necessity of the flexibility seeing the current
testing framework, I don't have so strong objection about
that. Nevertheless, perhaps you are appreciated to put
Kevin Wooten kd...@me.com wrote:
On Nov 4, 2014, at 12:55 AM, Craig Ringer cr...@2ndquadrant.com wrote:
I have to say I like some aspects of how pgjdbc-ng is being done - in
particular use of Maven and being built around non-blocking I/O.
OTOH, the use of Google Guava I find pretty
On 10/20/14 4:51 PM, Peter Eisentraut wrote:
On 10/20/14 2:59 PM, Tom Lane wrote:
What do we want to do about this? I think a minimum expectation would be
for pg_basebackup to notice and complain when it's trying to create an
unworkably long symlink entry, but it would be far better if we
On 04/11/14 13:11, Heikki Linnakangas wrote:
On 10/13/2014 01:01 PM, Petr Jelinek wrote:
Hi,
I rewrote the patch with different API along the lines of what was
discussed.
Thanks, that's better.
It would be good to see an alternative seqam to implement this API, to
see how it really works.
On 04/11/14 09:05, Andres Freund wrote:
On 2014-11-02 19:27:25 +0100, Petr Jelinek wrote:
Well, Michael has point that the extradata is pretty much useless currently,
perhaps it would help to add the interface to set extradata?
Only accessible via C and useless aren't the same thing. But
Michael Paquier wrote:
On Mon, Jul 14, 2014 at 6:14 PM, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp wrote:
Although I doubt necessity of the flexibility seeing the current
testing framework, I don't have so strong objection about
that. Nevertheless, perhaps you are appreciated to put
On 04/11/14 09:19, Michael Paquier wrote:
On Sat, Nov 1, 2014 at 10:00 PM, Michael Paquier
michael.paqu...@gmail.com mailto:michael.paqu...@gmail.com wrote:
More comments:
Here are also more comments about the code that I found while focusing
on committs.c:
1) When the GUC is not enabled,
On 11/3/14 5:17 PM, Petr Jelinek wrote:
Please don't name anything committs. That looks like a misspelling of
something.
There is nothing wrong with
pg_get_transaction_commit_timestamp()
If you want to reduce the length, lose the get.
I am fine with that, I only wonder if your
On 04/11/14 09:25, Michael Paquier wrote:
On Tue, Nov 4, 2014 at 5:05 PM, Andres Freund and...@2ndquadrant.com
mailto:and...@2ndquadrant.com wrote:
On 2014-11-02 19:27:25 +0100, Petr Jelinek wrote:
Well, Michael has point that the extradata is pretty much useless
currently,
On 11/4/14 3:21 PM, Alvaro Herrera wrote:
FWIW I gave this a trial run and found I needed some tweaks to test.sh
and the Makefile in order to make it work on VPATH; mainly replace ./
with `dirname $0` in a couple test.sh in a couple of places, and
something similar in the Makefile. Also you
On 04/11/14 22:20, Peter Eisentraut wrote:
On 11/3/14 5:17 PM, Petr Jelinek wrote:
Please don't name anything committs. That looks like a misspelling of
something.
There is nothing wrong with
pg_get_transaction_commit_timestamp()
If you want to reduce the length, lose the get.
I am fine
On 11/2/14 8:26 AM, Magnus Hagander wrote:
The idea is to have pg_receivexlog
fire off an external command at the end of each segment - for example
a command to gzip the file, or to archive it off into a Magic Cloud
(TM) or something like that.
A simple facility to allow gzipping after the
Andres Freund and...@2ndquadrant.com writes:
On 2014-11-04 13:51:23 -0500, Tom Lane wrote:
Not sure. The OP's point is that in a SELECT, you do get unsurprising
results, because a SELECT will acquire its execution snapshot after it's
gotten AccessShareLock on the table. Arguably COPY should
--On 4. November 2014 17:18:14 -0500 Tom Lane t...@sss.pgh.pa.us wrote:
Yeah, and I think that it's entirely reasonable for rewriting ALTER TABLEs
to update the xmin of the rewritten tuples; after all, the output data
could be arbitrarily different from what the previous transactions put
into
I wrote:
An alternative that just occurred to me is to put the no-volatile-
I/O-functions check into CREATE TYPE, but make it just WARNING not
ERROR. That would be nearly as good as an ERROR in terms of nudging
people who'd accidentally omitted a volatility marking from their
custom types.
Hi,
9.4 FINALLY added the UTC offset formatting pattern to to_char().
However, it falls a bit short in the sense that it's always the time
zone offset according to the effective TimeZone value. This has a few
issues as far as I can tell:
1) It's not truly controlled by the query which
On Tue, Nov 4, 2014 at 10:01 PM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Michael Paquier wrote:
I'm still on a -1 for that. You mentioned that there is perhaps no reason
to delay a decision on this matter, but IMO there is no reason to rush
either in doing something we may regret.
Marko Tiikkaja ma...@joh.to writes:
So I got into thinking whether it would make sense to provide a new
function, say, to_char_at_timezone() to solve this problem. For example:
...
Any thoughts? The patch is quite trivial.
I'm not convinced that it's all that trivial. Is the input
On 11/5/14, 12:59 AM, Tom Lane wrote:
Marko Tiikkaja ma...@joh.to writes:
So I got into thinking whether it would make sense to provide a new
function, say, to_char_at_timezone() to solve this problem. For example:
...
Any thoughts? The patch is quite trivial.
I'm not convinced that it's
On 04/11/14 09:07, Craig Ringer wrote:
On 11/04/2014 07:31 AM, Álvaro Hernández Tortosa wrote:
Thank you for your comment, Tom. However I think this behavior, as
seen from a user perspective, it's not the expected one.
That may be the case, but I think it's the SQL-standard behaviour, so
On 2014-11-05 08:57:07 +0900, Michael Paquier wrote:
On Tue, Nov 4, 2014 at 10:01 PM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Michael Paquier wrote:
I'm still on a -1 for that. You mentioned that there is perhaps no reason
to delay a decision on this matter, but IMO there is
Hi all,
MemSet is an internal macro faster than the system memset for zeroing small
word-aligned structures defined in src/include/c.h. Both are being used
here and there with no real preference.
An example of that is that in many code paths we have for example nulls and
values used to build
Michael Paquier michael.paqu...@gmail.com writes:
MemSet is an internal macro faster than the system memset for zeroing small
word-aligned structures defined in src/include/c.h. Both are being used
here and there with no real preference.
An example of that is that in many code paths we have
Hello,
I would like to transform the query plan (output of the planner,
debug_print_plan) into an sql query.
I know that there are pieces of the query plan that might be machine
dependent (in var for example).
So I wanted to have your suggestions or thoughts before I put efforts into
it.
On Fri, Oct 31, 2014 at 11:27 AM, Michael Paquier michael.paqu...@gmail.com
wrote:
So, what I think is missing is really a friendly interface to manipulate
JsonbContainers directly, and I think that we are not far from it with
something like this set, roughly:
- Initialization of an empty
Thanks for the tests.
On Wed, Nov 5, 2014 at 5:21 AM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Michael Paquier wrote:
On Mon, Jul 14, 2014 at 6:14 PM, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp wrote:
Although I doubt necessity of the flexibility seeing the current
On Wed, Nov 5, 2014 at 6:29 AM, Peter Eisentraut pete...@gmx.net wrote:
On 11/4/14 3:21 PM, Alvaro Herrera wrote:
FWIW I gave this a trial run and found I needed some tweaks to test.sh
and the Makefile in order to make it work on VPATH; mainly replace ./
with `dirname $0` in a couple
May be you want to check how it's done in Postgres-XC. Postgres-XC works on
plans being created by PostgreSQL and reverse-engineers queries (for
parts of the plans which are shippable.) The notions of shippability
may not be of interest to you, but the code to reverse-engineer most of
the plan
On Tue, Nov 04, 2014 at 08:30:21AM +, Laurenz Albe wrote:
David Fetter wrote:
On Tue, Nov 04, 2014 at 07:51:06AM +0900, Tatsuo Ishii wrote:
Just out of curiosity, why is Oracle's NUMBER (I assume you are
talking about this) so fast?
I suspect that what happens is that NUMBER is
On 11/3/14, 2:36 PM, Alvaro Herrera wrote:
Jim Nasby wrote:
On 11/1/14, 8:41 AM, Petr Jelinek wrote:
Well this is not BDR specific thing, the idea is that with logical replication,
commit timestamp is not enough for conflict handling, you also need to have
additional info in order to
On Wed, Oct 22, 2014 at 11:32:41AM -0400, Tom Lane wrote:
I don't have a strong opinion about which of the above things to do ...
what's your preference?
I think it's better for the future if me make a clean cut. Yes, the option
keeps compatability a little bit higher, but that doesn't matter
On Tue, Nov 4, 2014 at 10:03 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 10/30/2014 06:02 PM, Andres Freund wrote:
On 2014-10-29 10:24:20 +0200, Heikki Linnakangas wrote:
On 10/06/2014 02:29 PM, Andres Freund wrote:
On 2014-10-06 14:19:39 +0300, Heikki Linnakangas wrote:
mariem mariem.benfad...@gmail.com wrote:
Hello,
I would like to transform the query plan (output of the planner,
debug_print_plan) into an sql query.
I don't think SQL can express the information the plan contains. For example,
join methods (hash, nest loop, merge).
--
Antonin Houska
81 matches
Mail list logo
