Le mardi 15 octobre 2013 09:47:31 Robert Haas a écrit :
On Mon, Oct 14, 2013 at 5:24 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
And, I also want some comments from committers, not only from mine.
+1
+1
/me pokes head up. I know I'm going to annoy people with this
comment, but I
Sorry, I might call it something like primary key, instead of 'tupleid'.
Apart from whether we can uniquely identify a particular remote record with
an attribute, what FDW needs here is something to identify a remote
record. So, we were talking about same concept with different names.
Ah,
Hello Vik,
Yes, I understand you are trying to help, and I appreciate it! My
opinion, and that of others as well from the original thread, is that
this patch should either go in as is and break that one case, or not go
in at all. I'm fine with either (although clearly I would prefer it
went
On 10/16/2013 10:57 AM, Fabien COELHO wrote:
Hello Vik,
I see this is marked as rejected in the commitfest app, but I don't see
any note about who did it or why. I don't believe there is consensus
for rejection on this list. In fact I think the opposite is true.
May we have an explanation
On 2013-10-16 11:03:12 +0530, Pavan Deolasee wrote:
I think you are right. Someone who understands the replication code very
well advised us to use that log message as a way to measure how much time
it takes to send all the missing WAL to a remote standby on a slow WAN
link. While it worked
On 16-Oct-2013, at 3:45 pm, Andres Freund and...@2ndquadrant.com wrote:
On 2013-10-16 11:03:12 +0530, Pavan Deolasee wrote:
I think you are right. Someone who understands the replication code very
well advised us to use that log message as a way to measure how much time
it takes to send
From: Andres Freund and...@2ndquadrant.com
I've seen several sites shutting down because of forgotten prepared
transactions causing bloat and anti-wraparound shutdowns.
From: Magnus Hagander mag...@hagander.net
I would say *using* an external transaction manager *is* the irregular
thing. The
The following query is performed concurrently by two threads logged in
with two different users:
WITH raw_stat AS (
SELECT
host(client_addr) as client_addr,
pid ,
usename
FROM
pg_stat_activity
WHERE
usename =
On Tue, Oct 15, 2013 at 4:17 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
One reason we should support local triggers is that not all the data
source of FDW support remote trigger. It required FDW drivers to
have RDBMS as its backend, but no realistic assumption.
For example, file_fdw is
On Tue, Oct 15, 2013 at 11:17 PM, Peter Eisentraut pete...@gmx.net wrote:
On Mon, 2013-10-14 at 18:14 -0400, Robert Haas wrote:
I cleaned the semaphores on smew, but they came back. Whatever is
crashing is leaving the semaphores lying around.
Ugh. When did you do that exactly? I thought
On 2013-10-16 08:39:10 -0400, Robert Haas wrote:
On Tue, Oct 15, 2013 at 11:17 PM, Peter Eisentraut pete...@gmx.net wrote:
On Mon, 2013-10-14 at 18:14 -0400, Robert Haas wrote:
I cleaned the semaphores on smew, but they came back. Whatever is
crashing is leaving the semaphores lying
On Tue, Oct 15, 2013 at 4:02 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
Hmm. It probably allows to clean-up smaller fraction of data structure
constructed on dynamic shared memory segment, if we map / unmap
for each transactions.
I think the primary use of dynamic shared memory will be for
On Wed, Oct 16, 2013 at 8:54 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-10-16 08:39:10 -0400, Robert Haas wrote:
On Tue, Oct 15, 2013 at 11:17 PM, Peter Eisentraut pete...@gmx.net wrote:
On Mon, 2013-10-14 at 18:14 -0400, Robert Haas wrote:
I cleaned the semaphores on smew, but
On Wed, Oct 16, 2013 at 01:42:34PM +0900, KONDO Mitsumasa wrote:
(2013/10/15 22:01), k...@rice.edu wrote:
Google's lz4 is also a very nice algorithm with 33% better compression
performance than snappy and 2X the decompression performance in some
benchmarks also with a bsd license:
On Wed, Oct 16, 2013 at 9:37 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-10-16 09:35:46 -0400, Robert Haas wrote:
Gah. I fixed one instance of that problem in test_config_settings(),
but missed the other.
Maybe it'd be better to default to none, just as max_connections
defaults
On 2013-10-16 09:44:32 -0400, Robert Haas wrote:
On Wed, Oct 16, 2013 at 9:37 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-10-16 09:35:46 -0400, Robert Haas wrote:
Gah. I fixed one instance of that problem in test_config_settings(),
but missed the other.
Maybe it'd be better
* Vik Fearing (vik.fear...@dalibo.com) wrote:
I don't know if that's enough of a consensus to commit it, but I do
think it's not nearly enough of a consensus to reject it.
This is actually a problem that I think we have today- the expectation
that *everyone* has to shoot down an idea for it to
Because of CF-2nd end, it was moved to the next commit-fest.
In my personal opinion, it probably needs a few groundwork to get RLS
commitable,
prior to RLS itself.
One is a correct handling towards the scenario that Korotkov pointed
out. (How was
it concluded?) I think it is a problem we can fix
On 2013-10-16 11:18:55 -0400, Stephen Frost wrote:
This is actually a problem that I think we have today- the expectation
that *everyone* has to shoot down an idea for it to be rejected, but
one individual saying oh, that's a good idea means it must be
committed.
But neither does a single
On Wed, Oct 16, 2013 at 11:18 AM, Stephen Frost sfr...@snowman.net wrote:
* Vik Fearing (vik.fear...@dalibo.com) wrote:
I don't know if that's enough of a consensus to commit it, but I do
think it's not nearly enough of a consensus to reject it.
This is actually a problem that I think we have
hstore_to_json used to return an empty string for empty hstores, but
that is not correct as an empty string is not valid json and calling
row_to_json() on rows which have empty hstores will generate invalid
json for the entire row. The right thing to do is to return an empty
json object.
On Tue, Oct 15, 2013 at 8:33 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-10-13 16:56:12 +0200, Tom Lane wrote:
More to the point for this specific case, it seems like our process
ought to be
(1) select a preferably-small set of gcc atomic intrinsics that we
want to use.
I
Hi everyone,
Seems that the latest patch in this series is:
http://www.postgresql.org/message-id/CAB7nPqRLWLH1b0YsvqYF-zOFjrv4FRiurQ6yqcP3wjBp=tj...@mail.gmail.com
= Applying =
Reading the threads it seems there is consensus in this happening, so
let's move in that direction.
The patch applies
On 2013-10-16 12:26:28 -0400, Robert Haas wrote:
On Tue, Oct 15, 2013 at 8:33 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-10-13 16:56:12 +0200, Tom Lane wrote:
More to the point for this specific case, it seems like our process
ought to be
(1) select a preferably-small set of
On Sat, Oct 12, 2013 at 8:46 PM, Andres Freund and...@2ndquadrant.com wrote:
I think we should remove support the following ports:
- IRIX
- UnixWare
- Tru64
According to http://en.wikipedia.org/wiki/IRIX, IRIX has been
officially retired. The last release of IRIX was in 2006 and support
will
On Tue, Oct 8, 2013 at 09:05:37AM -0400, Bruce Momjian wrote:
On Tue, Oct 8, 2013 at 05:08:17PM +0530, Rushabh Lathia wrote:
This
might be a case where throwing an error is actually better than trying
to make sense of the input.
I don't feel super-strongly about this,
On 10/16/2013 07:04 PM, Robert Haas wrote:
On Sat, Oct 12, 2013 at 8:46 PM, Andres Freund and...@2ndquadrant.com wrote:
I think we should remove support the following ports:
- IRIX
- UnixWare
- Tru64
According to http://en.wikipedia.org/wiki/IRIX, IRIX has been
officially retired. The
On 10/16/2013 08:18 AM, Stephen Frost wrote:
As it relates to this specific patch for this CF, I'd go with 'Returned
with Feedback' and encourage you to consider the arguments for and
against, and perhaps try to find existing usage which would break due to
this change and consider the impact
On 2013-10-16 13:04:23 -0400, Robert Haas wrote:
So I vote for removing IRIX and Tru64 immediately, but I'm a little
more hesitant about shooting UnixWare, since it's technically still
supported.
I think if somebody wants to have it supported they need to provide a
buildfarm member and
- sinix (s_lock support remaining)
- sun3 (I think it's just s_lock support remaining)
- natsemi 32k
Patch removing spinlock support for these three ports is attached.
This is not to say we couldn't remove more later, but these seem to be
the three spinlock implementations that are most
On 2013-10-16 13:55:20 -0400, Robert Haas wrote:
- sinix (s_lock support remaining)
- sun3 (I think it's just s_lock support remaining)
- natsemi 32k
Patch removing spinlock support for these three ports is attached.
This is not to say we couldn't remove more later, but these seem to be
On 2013-10-16 13:04:23 -0400, Robert Haas wrote:
- m86k (doesn't have a useable CAS on later iterations like coldfire)
I don't think we can desupport it just because it doesn't have CAS.
Btw, if necessary we could easily support the pre coldfire
variants. Note that e.g. debian doesn't
You can see the UTF8 case is fine because \n is considered greater
than space, but in the C locale, where \n is less than space, the
false return value shows the problem with
internal_bpchar_pattern_compare() trimming the string and first
comparing on lengths. This is exactly the
2013/10/16 Robert Haas robertmh...@gmail.com:
On Tue, Oct 15, 2013 at 4:17 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
One reason we should support local triggers is that not all the data
source of FDW support remote trigger. It required FDW drivers to
have RDBMS as its backend, but no
On Wed, Oct 16, 2013 at 1:52 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-10-16 13:04:23 -0400, Robert Haas wrote:
So I vote for removing IRIX and Tru64 immediately, but I'm a little
more hesitant about shooting UnixWare, since it's technically still
supported.
I think if somebody
I am seeing this compiler warning in git head:
rowtypes.c: In function 'record_image_cmp':
rowtypes.c:1433: warning: 'cmpresult' may be used
uninitialized in this function rowtypes.c:1433: note: 'cmpresult' was
declared here
--
Bruce Momjian br...@momjian.us
On Wed, Oct 16, 2013 at 12:52 PM, Andres Freund and...@2ndquadrant.com wrote:
Partially that only works because we sprinkle 'volatile's on lots of
places. That can actually hurt performance... it'd usually be something
like:
#define pg_atomic_load(uint32) (*(volatile uint32 *)(atomic))
Even
On Wed, Oct 16, 2013 at 2:20 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
True, but gosh, updates via file_fdw are gonna be so slow I can't
believe anybody'd use it for something real
How about another example? I have implemented a column-oriented
data store with read/write capability,
Jaime,
= Building =
In pg_basebackup we have now 2 unused functions:
escapeConnectionParameter and escape_quotes. the only use of these
functions was when that tool created the recovery.conf file so they
aren't needed anymore.
Except that we'll want 9.4's -R to do something, probably create
On Wed, Oct 16, 2013 at 1:26 PM, Josh Berkus j...@agliodbs.com wrote:
Also, as Tom pointed out, at some point we have to either say we really
support overloading or we don't.
We clearly do support overloading. I don't think that's at issue.
But as we all know, using it can cause formerly
Bruce Momjian br...@momjian.us wrote:
I am seeing this compiler warning in git head:
rowtypes.c: In function 'record_image_cmp':
rowtypes.c:1433: warning: 'cmpresult' may be used
uninitialized in this function rowtypes.c:1433: note: 'cmpresult' was
declared here
I had not
On 2013-10-16 14:30:34 -0400, Robert Haas wrote:
But _and, _or are really useful because they can be used to atomically
clear and set flag bits.
Until we have some concrete application that requires this
functionality for adequate performance, I'd be inclined not to bother.
I think we
On Sat, Oct 12, 2013 at 06:35:00PM -0700, Peter Geoghegan wrote:
- ALPHA (big pain in the ass to get right, nobody uses it anymore)
Yes, for many years now ALPHA has only been useful as a way of
illustrating how bad it's possible for CPU memory operation reordering
considerations to get. So
On Wed, Oct 16, 2013 at 11:49:13AM -0700, Kevin Grittner wrote:
Bruce Momjian br...@momjian.us wrote:
I am seeing this compiler warning in git head:
rowtypes.c: In function 'record_image_cmp':
rowtypes.c:1433: warning: 'cmpresult' may be used
uninitialized in this function
On 2013-10-16 15:49:54 -0400, Bruce Momjian wrote:
On Sat, Oct 12, 2013 at 06:35:00PM -0700, Peter Geoghegan wrote:
- ALPHA (big pain in the ass to get right, nobody uses it anymore)
Yes, for many years now ALPHA has only been useful as a way of
illustrating how bad it's possible for
On Wed, Oct 16, 2013 at 3:26 PM, Andres Freund and...@2ndquadrant.com wrote:
I don't agree with that policy. Sure, 97% of our users are probably
running Linux, Windows, MacOS X, or one of the fairly-popular BSD
variants. But I think a part of the appeal of PostgreSQL is that it is
On 10/09/2013 11:06 AM, Andrew Dunstan wrote:
The assumption that each connection won't use lots of work_mem is also
false, I think, especially in these days of connection poolers.
Andres has just been politely pointing out to me that my knowledge of
memory allocators is a little out
On Wed, Oct 16, 2013 at 04:25:37PM -0400, Andrew Dunstan wrote:
On 10/09/2013 11:06 AM, Andrew Dunstan wrote:
The assumption that each connection won't use lots of work_mem is
also false, I think, especially in these days of connection
poolers.
Andres has just been politely
Robert Haas robertmh...@gmail.com wrote:
Anyone who actually wants this in their environment can
add the overloaded function in their environment with a one-line SQL
function: pg_sleep(interval) as proposed here is just
pg_sleep(extract(epoch from now() + $1) - extract(epoch from now())).
On 2013-10-16 16:10:18 -0400, Robert Haas wrote:
On the other hand, I'm not convinced that we don't need to give any
thought to UNIX vendors that are still pushing their proprietary
compilers. Many of the old players are dead, but IBM's ICC and HP's
aCC definitely aren't, and I wouldn't be
Andres Freund and...@2ndquadrant.com writes:
On 2013-10-16 14:30:34 -0400, Robert Haas wrote:
But _and, _or are really useful because they can be used to atomically
clear and set flag bits.
Until we have some concrete application that requires this
functionality for adequate performance, I'd
On Wed, Oct 16, 2013 at 5:30 PM, Bruce Momjian br...@momjian.us wrote:
On Wed, Oct 16, 2013 at 04:25:37PM -0400, Andrew Dunstan wrote:
On 10/09/2013 11:06 AM, Andrew Dunstan wrote:
The assumption that each connection won't use lots of work_mem is
also false, I think, especially in these
On 2013-10-16 22:39:07 +0200, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-10-16 14:30:34 -0400, Robert Haas wrote:
But _and, _or are really useful because they can be used to atomically
clear and set flag bits.
Until we have some concrete application that
On 2013-10-16 16:10:18 -0400, Robert Haas wrote:
(though I don't see the code you're talking about wrt/32bitv9
sparc)
v9 sparc doesn't support compare-and-swap like operations, that's the
background.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
On 10/16/2013 01:25 PM, Andrew Dunstan wrote:
Andres has just been politely pointing out to me that my knowledge of
memory allocators is a little out of date (i.e. by a decade or two), and
that this memory is not in fact likely to be held for a long time, at
least on most modern systems. That
On 10/16/13 2:40 PM, Robert Haas wrote:
On Wed, Oct 16, 2013 at 1:26 PM, Josh Berkus j...@agliodbs.com wrote:
Also, as Tom pointed out, at some point we have to either say we really
support overloading or we don't.
We clearly do support overloading. I don't think that's at issue.
But as we
Hi,
I've been experimenting with the new reworked FDW API to get familiar
with it. The postgres_fdw is a great source of knowledge (huge thanks to
Shigeru Hanada, KaiGai Kohei and everyone else who made this happen),
but in the end I had to draw some flow charts in Dia, to understand how
exactly
On Wed, Oct 16, 2013 at 8:35 PM, Tomas Vondra t...@fuzzy.cz wrote:
[...]
Attached is the set of flow charts, showing the sequence of callbacks
for all the supported commands (i.e. SELECT, INSERT, UPDATE, DELETE,
ANALYZE).
Thank you very much... this flow charts will help many people,
On Wed, Oct 16, 2013 at 4:34 PM, Kevin Grittner kgri...@ymail.com wrote:
Robert Haas robertmh...@gmail.com wrote:
Anyone who actually wants this in their environment can
add the overloaded function in their environment with a one-line SQL
function: pg_sleep(interval) as proposed here is just
I wonder whether it was ever consciously decided what the dependency
relationship between libpgport and libpgcommon would be. When I added
asprintf(), I had intuitively figured that libpgport would be the lower
layer, and so psprintf() in libpgcommon depends on vasprintf() in
libpgport. I still
On Tue, 2013-09-24 at 15:07 +, Albe Laurenz wrote:
--- 3511,3534
}
/*
! * Perform an explicit anonymous bind.
! * This is not necessary in principle, but we want to set a timeout
! * of PGLDAP_TIMEOUT seconds and return 2 if the connection fails.
!
On Wed, Oct 16, 2013 at 09:41:20PM -0400, Peter Eisentraut wrote:
I wonder whether it was ever consciously decided what the dependency
relationship between libpgport and libpgcommon would be. When I added
asprintf(), I had intuitively figured that libpgport would be the lower
layer, and so
Tomas Vondra wrote:
Attached is the set of flow charts, showing the sequence of callbacks
for all the supported commands (i.e. SELECT, INSERT, UPDATE, DELETE,
ANALYZE). Wouldn't it be useful to put something like this into the
docs? I mean, the FDW API is not going to get any simpler, and for
On Mon, 2013-07-08 at 16:04 +, Dean Rasheed wrote:
There was concern that pg_relation_is_updatable() would end up opening
every relation in the database, hammering performance. I now realise
that these tab-complete queries have a limit (1000 by default) so I
don't think this is such an
Hey All,
I had missed these emails, sorry.
The search+bind mode issue is one of documentation location, I have fixed
it by moving the section to the applied to both list. As the patch is to do
with post-auth response this is correct.
As far as the issue when something other than 0 or 1 is set I
On Wed, Oct 16, 2013 at 4:30 AM, Gibheer gibh...@zero-knowledge.org wrote:
On Mon, 14 Oct 2013 11:52:57 +0530
Amit Kapila amit.kapil...@gmail.com wrote:
On Sun, Oct 13, 2013 at 2:08 PM, Gibheer gibh...@zero-knowledge.org
wrote:
On Sun, 13 Oct 2013 11:38:17 +0530
Amit Kapila
Alvaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Tomas Vondra wrote:
Attached is the set of flow charts, showing the sequence of callbacks
for all the supported commands (i.e. SELECT, INSERT, UPDATE, DELETE,
ANALYZE). Wouldn't it be useful to put something like this into the
On Wed, Oct 16, 2013 at 10:04:29PM +0200, Andres Freund wrote:
On 2013-10-16 15:49:54 -0400, Bruce Momjian wrote:
On Sat, Oct 12, 2013 at 06:35:00PM -0700, Peter Geoghegan wrote:
- ALPHA (big pain in the ass to get right, nobody uses it anymore)
Yes, for many years now ALPHA has only
68 matches
Mail list logo
