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 AL
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 th
On Wed, Oct 16, 2013 at 4:30 AM, Gibheer wrote:
> On Mon, 14 Oct 2013 11:52:57 +0530
> Amit Kapila wrote:
>
>> On Sun, Oct 13, 2013 at 2:08 PM, Gibheer
>> wrote:
>> > On Sun, 13 Oct 2013 11:38:17 +0530
>> > Amit Kapila wrote:
>> >
>> >> On Thu, Oct 10, 2013 at 3:17 AM, Gibheer
>> >> wrote:
>>
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 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
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
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
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.
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 t
On Wed, Oct 16, 2013 at 4:34 PM, Kevin Grittner wrote:
> Robert Haas 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
On Wed, Oct 16, 2013 at 8:35 PM, 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).
Thank you very much... this flow charts will help many people, including me
;
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 d
On 10/16/13 2:40 PM, Robert Haas wrote:
> On Wed, Oct 16, 2013 at 1:26 PM, Josh Berkus 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,
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. Th
On 2013-10-16 16:10:18 -0400, Robert Haas wrote:
> (though I don't see the code you're talking about wrt/32bit 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 2013-10-16 22:39:07 +0200, Tom Lane wrote:
> Andres Freund 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
On Wed, Oct 16, 2013 at 5:30 PM, Bruce Momjian 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 th
Andres Freund 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 be inclined
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
Robert Haas 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())).
You're making it sou
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 j
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 3:26 PM, Andres Freund 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
>> cross-platform, and doesn'
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 possib
On Wed, Oct 16, 2013 at 11:49:13AM -0700, Kevin Grittner wrote:
> Bruce Momjian 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 rowt
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 ge
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 thin
Bruce Momjian 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 gotten a warning
On Wed, Oct 16, 2013 at 1:26 PM, Josh Berkus 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 unambiguous queries t
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 c
On Wed, Oct 16, 2013 at 2:20 PM, Kohei KaiGai 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, using FDW APIs.
On Wed, Oct 16, 2013 at 12:52 PM, Andres Freund 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 if not needed in
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 http://momjian.us
On Wed, Oct 16, 2013 at 1:52 PM, Andres Freund 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 wants to have
2013/10/16 Robert Haas :
> On Tue, Oct 15, 2013 at 4:17 PM, Kohei KaiGai 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, fil
> > 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 t
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 sup
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
>> - 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 s
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 proba
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 impac
On 10/16/2013 07:04 PM, Robert Haas wrote:
> On Sat, Oct 12, 2013 at 8:46 PM, Andres Freund 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
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 a
On Sat, Oct 12, 2013 at 8:46 PM, Andres Freund 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 end in December of
On 2013-10-16 12:26:28 -0400, Robert Haas wrote:
> On Tue, Oct 15, 2013 at 8:33 AM, Andres Freund 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
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 a
On Tue, Oct 15, 2013 at 8:33 AM, Andres Freund 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 suggest:
> * pg_at
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.
Signed-o
On Wed, Oct 16, 2013 at 11:18 AM, Stephen Frost 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 today- the
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 singl
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
* 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
On 2013-10-16 09:44:32 -0400, Robert Haas wrote:
> On Wed, Oct 16, 2013 at 9:37 AM, Andres Freund 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 defaul
On Wed, Oct 16, 2013 at 9:37 AM, Andres Freund 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 to 1 and shared
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 8:54 AM, Andres Freund wrote:
> On 2013-10-16 08:39:10 -0400, Robert Haas wrote:
>> On Tue, Oct 15, 2013 at 11:17 PM, Peter Eisentraut wrote:
>> > On Mon, 2013-10-14 at 18:14 -0400, Robert Haas wrote:
>> >> > I cleaned the semaphores on smew, but they came back. Whatever
On Tue, Oct 15, 2013 at 4:02 PM, Kohei KaiGai 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 segments
that get c
On 2013-10-16 08:39:10 -0400, Robert Haas wrote:
> On Tue, Oct 15, 2013 at 11:17 PM, Peter Eisentraut 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.
>
On Tue, Oct 15, 2013 at 11:17 PM, Peter Eisentraut 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 I fix
On Tue, Oct 15, 2013 at 4:17 PM, Kohei KaiGai 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 unavailable to impleme
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 = curr
From: "Andres Freund"
I've seen several sites shutting down because of forgotten prepared
transactions causing bloat and anti-wraparound shutdowns.
From: "Magnus Hagander"
I would say *using* an external transaction manager *is* the irregular
thing. The current default *is* friendly for norm
> On 16-Oct-2013, at 3:45 pm, Andres Freund 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 all the missin
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 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
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 i
66 matches
Mail list logo
