On Tue, Jun 26, 2012 at 7:06 AM, Pavel Stehule wrote:
> Hello
>
> I worked on simple patch, that enable access from server side to
> client side data. It add two new hooks to libpq - one for returning of
> local context, second for setting of local context.
>
> A motivation is integration of possi
2012/6/26 Magnus Hagander :
> On Tue, Jun 26, 2012 at 7:06 AM, Pavel Stehule
> wrote:
>> Hello
>>
>> I worked on simple patch, that enable access from server side to
>> client side data. It add two new hooks to libpq - one for returning of
>> local context, second for setting of local context.
>>
2012-06-26 06:59 keltezéssel, Alvaro Herrera írta:
I cleaned up the framework patch a bit. My version's attached. Mainly,
returning false for failure in some code paths that are only going to
have the caller elog(FATAL) is rather pointless -- it seems much better
to just have the code itself do
On Tue, Jun 26, 2012 at 9:50 AM, Pavel Stehule wrote:
> 2012/6/26 Magnus Hagander :
>> On Tue, Jun 26, 2012 at 7:06 AM, Pavel Stehule
>> wrote:
>>> Hello
>>>
>>> I worked on simple patch, that enable access from server side to
>>> client side data. It add two new hooks to libpq - one for returni
2012/6/26 Magnus Hagander :
> On Tue, Jun 26, 2012 at 9:50 AM, Pavel Stehule
> wrote:
>> 2012/6/26 Magnus Hagander :
>>> On Tue, Jun 26, 2012 at 7:06 AM, Pavel Stehule
>>> wrote:
Hello
I worked on simple patch, that enable access from server side to
client side data. It add
On Wed, Jun 20, 2012 at 2:19 AM, Tom Lane wrote:
> I've marked this patch committed, although in the end there was nothing
> left of it ;-)
>
Thank you, Dean and Tom!
I'm sorry for not participating in this thread, I've been away for the past
five weeks and have much catching up to do.
Hi Kaigai-san,
> -Original Message-
> From: Kohei KaiGai [mailto:kai...@kaigai.gr.jp]
> Sent: Monday, June 25, 2012 9:49 PM
> To: Etsuro Fujita
> Cc: Robert Haas; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] WIP Patch: Selective binary conversion of CSV file
> foreign tables
>
>
On Tue, Jun 19, 2012 at 5:39 PM, Robert Haas wrote:
> On Tue, Jun 19, 2012 at 5:33 PM, Greg Smith wrote:
>> In January of 2011 Robert committed 7f242d880b5b5d9642675517466d31373961cf98
>> to try and compact the fsync queue when clients find it full. There's no
>> visible behavior change, just a
On Tue, Jun 26, 2012 at 3:59 AM, Boszormenyi Zoltan wrote:
> Well, I can make the registration interface similar to how LWLocks
> are treated, but that doesn't avoid modification of the base_timeouts
> array in case a new internal use case arises. Say:
>
> #define USER_TIMEOUTS 4
>
> int n_t
On Monday, June 25, 2012 08:50:54 PM Kevin Grittner wrote:
> Andres Freund wrote:
> >> We most particularly *don't* want DDL to replicate automatically,
> >> because the schema changes are deployed along with related
> >> software changes, and we like to pilot any changes for at least a
> >> few d
2012-06-26 13:50 keltezéssel, Robert Haas írta:
On Tue, Jun 26, 2012 at 3:59 AM, Boszormenyi Zoltan wrote:
Well, I can make the registration interface similar to how LWLocks
are treated, but that doesn't avoid modification of the base_timeouts
array in case a new internal use case arises. Say:
Hi all,
I've modified the pg_stat_lwlocks patch to be able to work with
the latest PostgreSQL Git code.
This patch provides:
pg_stat_lwlocks New system view to show lwlock statistics.
pg_stat_get_lwlocks() New function to retrieve lwlock statistics.
pg_stat_reset_lwlocks() N
On 25 June 2012 17:42, Kevin Grittner wrote:
> This is clearly going to depend on the topology. You would
> definitely want to try to replicate the DDL for the case on which
> Simon is focused (which seems to me to be essentially physical
> replication of catalogs with logical replication of dat
On Mon, Jun 25, 2012 at 11:05 PM, Jeff Janes wrote:
> On Mon, Jun 18, 2012 at 5:42 PM, Robert Haas wrote:
>>
>> Hmm. That was actually a gloss I added on existing code to try to
>> convince myself that it was safe; I don't think that the changes I
>> made make that any more or less safe than it
On Tue, Jun 26, 2012 at 8:03 AM, Boszormenyi Zoltan wrote:
> I know, but it doesn't feel right to "register" static functionality.
We do it elsewhere. The overhead is pretty minimal compared to other
things we already do during startup, and avoiding the need for the
array to have a fixed-size se
Amit Kapila writes:
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane
>> The implementation I've wanted to see for some time is that you can
>> start a standalone backend, but it speaks FE/BE protocol to its caller
>> (preferably over pipes, so that there is no issue whatsoever o
Robert Haas writes:
> On Tue, Jun 26, 2012 at 8:03 AM, Boszormenyi Zoltan wrote:
>> I know, but it doesn't feel right to "register" static functionality.
> We do it elsewhere. The overhead is pretty minimal compared to other
> things we already do during startup, and avoiding the need for the
>
On Mon, Jun 25, 2012 at 3:17 PM, Andres Freund wrote:
>> I suppose the main reason we haven't done it already is that it
>> increases the period of time during which we're using 2X the disk
>> space.
> I find that an acceptable price if its optional. Making it such doesn't seem
> to be a problem f
Harada-san,
I checked your patch, and had an impression that includes many
improvements from the previous revision that I looked at the last
commit fest.
However, I noticed several points to be revised, or investigated.
* It seems to me expected results of the regression test is not
attached,
On Fri, Jun 22, 2012 at 12:35 PM, Andres Freund wrote:
>> Can you elaborate on that a bit? What scenarios did you play around
>> with, and what does "win" mean in this context?
> I had two machines connected locally and setup HS and my prototype between
> them (not at once obviously).
> The patch
2012/6/26 Etsuro Fujita :
> Hi Kaigai-san,
>
>> -Original Message-
>> From: Kohei KaiGai [mailto:kai...@kaigai.gr.jp]
>> Sent: Monday, June 25, 2012 9:49 PM
>> To: Etsuro Fujita
>> Cc: Robert Haas; pgsql-hackers@postgresql.org
>> Subject: Re: [HACKERS] WIP Patch: Selective binary conversion
On Tuesday, June 26, 2012 04:01:26 PM Robert Haas wrote:
> On Fri, Jun 22, 2012 at 12:35 PM, Andres Freund
wrote:
> >> Can you elaborate on that a bit? What scenarios did you play around
> >> with, and what does "win" mean in this context?
> >
> > I had two machines connected locally and setup
On Wed, Mar 28, 2012 at 10:08 AM, Fujii Masao wrote:
> On Wed, Mar 28, 2012 at 12:30 AM, Alvaro Herrera
> wrote:
>>
>> Excerpts from Fujii Masao's message of mar mar 27 06:40:34 -0300 2012:
>>
>>> Anyway, should I add this patch into the next CF? Or is anyone planning
>>> to commit the patch for
On Mon, Jun 25, 2012 at 4:25 PM, k...@rice.edu wrote:
> On Mon, Jun 25, 2012 at 09:45:26PM +0200, Florian Pflug wrote:
>> On Jun25, 2012, at 21:21 , Dimitri Fontaine wrote:
>> > Magnus Hagander writes:
>> >> Or that it takes less code/generates cleaner code...
>> >
>> > So we're talking about som
On Sun, Jun 24, 2012 at 5:33 PM, David Kerr wrote:
> Howdy,
>
> We're using NetApp's flexclone's whenever we need to move our DB between
> machines.
>
> One specific case where we do that is when we're creating a new streaming
> replication target.
>
> The basic steps we're using are:
> pg_start
On Wed, May 30, 2012 at 4:35 PM, Alexander Korotkov
wrote:
>> So, do we demote that message to a DEBUG1? Or do we make it more clear
>> what the authors of a specific picksplit are supposed to do to avoid
>> that problem? Or am I misunderstanding something?
>
>
> +1 for demote message to DEBUG1. I
On Mon, Jun 4, 2012 at 9:14 AM, chinnaobi wrote:
> Recently I was writing an application to implement automated failover with
> env: Two 2008 R2 servers, Network area storage, asynchronous replication,
> WAL archive on primary enabled.
>
> Is there any way to avoid starting standby server always f
On 26-06-2012 12:23, Robert Haas wrote:
> At the risk of making everyone laugh at me, has anyone tested pglz? I
> observe that if the compression ration and performance are good, we
> might consider using it for this purpose, too, which would avoid
> having to add dependencies. Conversely, if the
On Tue, Jun 26, 2012 at 5:24 PM, Robert Haas wrote:
> On Sun, Jun 24, 2012 at 5:33 PM, David Kerr wrote:
>> Howdy,
>>
>> We're using NetApp's flexclone's whenever we need to move our DB between
>> machines.
>>
>> One specific case where we do that is when we're creating a new streaming
>> repli
Robert Haas writes:
> On Mon, Jun 25, 2012 at 4:25 PM, k...@rice.edu wrote:
>> Here is the benchmark list from the Google lz4 page:
>>
>> NameRatio C.speed D.speed
>> LZ4 (r59) 2.084 330 915
>> LZO 2.05 1x_1 2.038 311 480
>> QuickLZ 1.5 -1 2.233 257 27
On Tue, May 22, 2012 at 11:31 PM, Joel Jacobson wrote:
> This is true, which means some users won't be able to use the feature,
> because they are using an ancient OS or have function names with slashes,
> hm, is it even possible to have function names with slashes?
Sure. If you quote the functi
On Tue, Jun 26, 2012 at 05:33:42PM +0200, Magnus Hagander wrote:
- On Tue, Jun 26, 2012 at 5:24 PM, Robert Haas wrote:
- > On Sun, Jun 24, 2012 at 5:33 PM, David Kerr wrote:
- >> Howdy,
- >>
- >> We're using NetApp's flexclone's whenever we need to move our DB between
machines.
- >>
- >> One spe
On Tue, Jun 26, 2012 at 11:33 AM, Magnus Hagander wrote:
> On Tue, Jun 26, 2012 at 5:24 PM, Robert Haas wrote:
>> On Sun, Jun 24, 2012 at 5:33 PM, David Kerr wrote:
>>> Howdy,
>>>
>>> We're using NetApp's flexclone's whenever we need to move our DB between
>>> machines.
>>>
>>> One specific cas
On Tue, May 22, 2012 at 12:15 PM, chinnaobi wrote:
> You mean when the primary which is going to switch its role to standby might
> not have sent all the WAL records to the standby and If it is switched to
> standby it has more WAL records than the standby which is now serves as
> primary. Is it ?
Excerpts from Boszormenyi Zoltan's message of mar jun 26 03:59:06 -0400 2012:
>
> 2012-06-26 06:59 keltezéssel, Alvaro Herrera írta:
> > I cleaned up the framework patch a bit. My version's attached. Mainly,
> > returning false for failure in some code paths that are only going to
> > have the c
On Thu, Jun 14, 2012 at 11:43 AM, Kohei KaiGai wrote:
> In the previous discussion, we planned to add a syntax option to
> clarify the command type to fire the RLS policy, such as FOR UPDATE.
> But current my opinion is, it is not necessary. For example, we can
> reference the contents of rows bei
2012-06-26 18:12 keltezéssel, Alvaro Herrera írta:
Excerpts from Boszormenyi Zoltan's message of mar jun 26 03:59:06 -0400 2012:
2012-06-26 06:59 keltezéssel, Alvaro Herrera írta:
I cleaned up the framework patch a bit. My version's attached. Mainly,
returning false for failure in some code p
Excerpts from Boszormenyi Zoltan's message of mar jun 26 12:43:34 -0400 2012:
> So, should I keep the enum TimeoutName? Are global variables for
> keeping dynamically assigned values preferred over the enum?
> Currently we have 5 timeout sources in total, 3 of them are used by
> regular backends,
Hi,
I am currently trying to understand what looks like really bad scalability of
9.1.3 on a 64core 512GB RAM system: the system runs OK when at 30% usr, but only
marginal amounts of additional load seem to push it to 70% and the application
becomes highly unresponsive.
My current understanding b
On Mon, Jun 11, 2012 at 11:12 AM, Robert Haas wrote:
> On Sat, Jun 9, 2012 at 11:42 AM, Dean Rasheed
> wrote:
>> Hi,
>>
>> Attached is a small patch to improve the HINT message produced by
>> CREATE OR REPLACE FUNCTION when the new function definition conflicts
>> with the old definition. With t
> To implement it, a new array can be added in the local process memory
> to hold lwlock statistics, and update counters both in the shared
> memory and the local process memory at once. Then, the session can
> retrieve 'per-session' statistics from the local process memory
> via some dedicated fu
On Tue, 2012-06-26 at 11:28 -0400, Robert Haas wrote:
> On Wed, May 30, 2012 at 4:35 PM, Alexander Korotkov
> wrote:
> >> So, do we demote that message to a DEBUG1? Or do we make it more clear
> >> what the authors of a specific picksplit are supposed to do to avoid
> >> that problem? Or am I misu
On Tue, Jun 26, 2012 at 10:12:52AM +0200, Pavel Stehule wrote:
> 2012/6/26 Magnus Hagander :
> > On Tue, Jun 26, 2012 at 9:50 AM, Pavel Stehule
> > wrote:
> >> 2012/6/26 Magnus Hagander :
> >>> On Tue, Jun 26, 2012 at 7:06 AM, Pavel Stehule
> >>> wrote:
> Hello
>
> I worked on si
On Mon, Jun 25, 2012 at 01:50:54PM -0500, Kevin Grittner wrote:
> Andres Freund wrote:
>
> > I am not sure were going to get all that into 9.3.
>
> Sure, that was more related to why I was questioning how much these
> use cases even *could* integrate -- whether it even paid to
> *consider* the
On Tue, Jun 26, 2012 at 12:02 PM, Nils Goroll wrote:
> Hi,
>
> I am currently trying to understand what looks like really bad scalability of
> 9.1.3 on a 64core 512GB RAM system: the system runs OK when at 30% usr, but
> only
> marginal amounts of additional load seem to push it to 70% and the ap
2012/6/26 David Fetter :
> On Tue, Jun 26, 2012 at 10:12:52AM +0200, Pavel Stehule wrote:
>> 2012/6/26 Magnus Hagander :
>> > On Tue, Jun 26, 2012 at 9:50 AM, Pavel Stehule
>> > wrote:
>> >> 2012/6/26 Magnus Hagander :
>> >>> On Tue, Jun 26, 2012 at 7:06 AM, Pavel Stehule
>> >>> wrote:
>>
Nils Goroll writes:
> Now that the scene is set, here's the simple question: Why all this? Why not
> simply use posix mutexes which, on modern platforms, will map to efficient
> implementations like adaptive mutexes or futexes?
(1) They do not exist everywhere.
(2) There is absolutely no evidence
Hi Merlin,
> _POSIX_THREAD_PROCESS_SHARED
sure.
> Also, it's forbidden to do things like invoke i/o in the backend while
> holding only a spinlock. As to your larger point, it's an interesting
> assertion -- some data to back it up would help.
Let's see if I can get any. ATM I've only got indic
> But if you start with "let's not support any platforms that don't have this
> feature"
This will never be my intention.
Nils
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Jun 26, 2012 at 3:05 AM, Magnus Hagander wrote:
> But with a small change to psql they could, without the need for a
> whole new type of variable. For example, psql could set all those
> variable as "psql.", which could then be accessed
> from the DO PL code just fine.
That's a really nea
2012/6/26 Merlin Moncure :
> On Tue, Jun 26, 2012 at 3:05 AM, Magnus Hagander wrote:
>> But with a small change to psql they could, without the need for a
>> whole new type of variable. For example, psql could set all those
>> variable as "psql.", which could then be accessed
>> from the DO PL cod
Robert, all:
Last I checked, we had a reasonably acceptable patch to use mostly Posix
Shared mem with a very small sysv ram partition. Is there anything
keeping this from going into 9.3? It would eliminate a major
configuration headache for our users.
--
Josh Berkus
PostgreSQL Experts Inc.
htt
On Mon, Jun 18, 2012 at 9:36 PM, Robert Haas wrote:
> On Sat, Jun 16, 2012 at 6:25 PM, Jeff Janes wrote:
>>> Well, this fell through the cracks, because I forgot to add it to the
>>> January CommitFest. Here it is again, rebased.
>>
>> This applies and builds cleanly and passes make check (under
On Fri, Jun 22, 2012 at 10:12 AM, Robert Haas wrote:
> On Tue, Jun 19, 2012 at 5:41 AM, Etsuro Fujita
> wrote:
>>> I'm confused by this remark, because surely the query planner does it this
>>> way only if there's no LIMIT. When there is a LIMIT, we choose based on
>>> the startup cost plus the
Excerpts from Josh Berkus's message of mar jun 26 15:49:59 -0400 2012:
> Robert, all:
>
> Last I checked, we had a reasonably acceptable patch to use mostly Posix
> Shared mem with a very small sysv ram partition. Is there anything
> keeping this from going into 9.3? It would eliminate a major
2012/6/26 Robert Haas :
>> Of course, here is some limitations, to keep the patch size reasonable
>> level to review.
>> - The permission to bypass RLS policy was under discussion.
>> If and when we should provide a special permission to bypass RLS
>> policy, the "OR has_superuser_privilege()" sh
On Thu, Mar 29, 2012 at 3:04 AM, Daniel Farina wrote:
> On Mon, Mar 26, 2012 at 12:14 AM, Jeff Davis wrote:
>> On Tue, 2012-03-20 at 01:38 -0700, Daniel Farina wrote:
>>> On Thu, Mar 15, 2012 at 9:39 PM, Fujii Masao wrote:
>>> > On Fri, Mar 16, 2012 at 8:14 AM, Daniel Farina wrote:
>>> >> Paral
Kohei KaiGai writes:
> 2012/6/26 Robert Haas :
>> I think you're missing the point. Everyone who has commented on this
>> issue is in favor of having some check that causes the RLS predicate
>> *not to get added in the first place*.
> Here is a simple idea to avoid the second problematic scenari
On Wed, May 2, 2012 at 9:01 PM, Josh Berkus wrote:
> On 5/2/12 10:20 AM, Jameison Martin wrote:
>> Attached are the following as per various requests:
>> * test_results.txt: the performance benchmarking results,
>>
>> * TestTrailingNull.java: the performance benchmarking code, with a f
On Sat, Mar 3, 2012 at 3:22 PM, Jeff Janes wrote:
> When sorting small tuples, the memtuples array can use a substantial
> fraction of the total per-tuple memory used. (In the case of pass by
> value, it is all of it)
>
> The way it grows leads to sub-optimal memory usage.
Greg, I see you signed
On Tue, Jun 26, 2012 at 4:29 PM, Alvaro Herrera
wrote:
> Excerpts from Josh Berkus's message of mar jun 26 15:49:59 -0400 2012:
>> Robert, all:
>>
>> Last I checked, we had a reasonably acceptable patch to use mostly Posix
>> Shared mem with a very small sysv ram partition. Is there anything
>> k
Pavel Stehule writes:
> it is not security issue - just I dislike sending complete stack, when
> just only one variable should be used.
That's a pretty darn weak argument. If I read the patch correctly, what
you're proposing involves a dynamic fetch from the client at runtime,
which is going to
On 6/26/12 2:13 PM, Robert Haas wrote:
> On Tue, Jun 26, 2012 at 4:29 PM, Alvaro Herrera
> wrote:
>> Excerpts from Josh Berkus's message of mar jun 26 15:49:59 -0400 2012:
>>> Robert, all:
>>>
>>> Last I checked, we had a reasonably acceptable patch to use mostly Posix
>>> Shared mem with a very s
Merlin Moncure writes:
> On Tue, Jun 26, 2012 at 3:05 AM, Magnus Hagander wrote:
>> But with a small change to psql they could, without the need for a
>> whole new type of variable. For example, psql could set all those
>> variable as "psql.", which could then be accessed
>> from the DO PL code j
On Tue, Jun 26, 2012 at 2:18 PM, Josh Berkus wrote:
> On 6/26/12 2:13 PM, Robert Haas wrote:
>> On Tue, Jun 26, 2012 at 4:29 PM, Alvaro Herrera
>> wrote:
>>> Excerpts from Josh Berkus's message of mar jun 26 15:49:59 -0400 2012:
Robert, all:
Last I checked, we had a reasonably acce
On Tue, Jun 26, 2012 at 5:18 PM, Josh Berkus wrote:
> On 6/26/12 2:13 PM, Robert Haas wrote:
>> On Tue, Jun 26, 2012 at 4:29 PM, Alvaro Herrera
>> wrote:
>>> Excerpts from Josh Berkus's message of mar jun 26 15:49:59 -0400 2012:
Robert, all:
Last I checked, we had a reasonably acce
> On that, I used to be of the opinion that this is a good compromise (a
> small amount of interlock space, plus mostly posix shmem), but I've
> heard since then (I think via AgentM indirectly, but I'm not sure)
> that there are cases where even the small SysV segment can cause
> problems -- notab
On Tue, Jun 26, 2012 at 01:46:06PM -0500, Merlin Moncure wrote:
> Well, that would introduce a backend dependency on pthreads, which is
> unpleasant. Also you'd need to feature test via
> _POSIX_THREAD_PROCESS_SHARED to make sure you can mutex between
> processes (and configure your mutexes as suc
On Tue, Jun 26, 2012 at 1:58 PM, Robert Haas wrote:
> On Thu, Mar 29, 2012 at 3:04 AM, Daniel Farina wrote:
>> On Mon, Mar 26, 2012 at 12:14 AM, Jeff Davis wrote:
>>> On Tue, 2012-03-20 at 01:38 -0700, Daniel Farina wrote:
On Thu, Mar 15, 2012 at 9:39 PM, Fujii Masao wrote:
> On Fri,
On Tue, Jun 26, 2012 at 5:44 PM, Josh Berkus wrote:
>
>> On that, I used to be of the opinion that this is a good compromise (a
>> small amount of interlock space, plus mostly posix shmem), but I've
>> heard since then (I think via AgentM indirectly, but I'm not sure)
>> that there are cases where
Excerpts from Daniel Farina's message of mar jun 26 17:40:16 -0400 2012:
> On that, I used to be of the opinion that this is a good compromise (a
> small amount of interlock space, plus mostly posix shmem), but I've
> heard since then (I think via AgentM indirectly, but I'm not sure)
> that there
David Fetter wrote:
> On Mon, Jun 25, 2012 at 01:50:54PM -0500, Kevin Grittner wrote:
>> One fine point regarding before and after images -- if a value
>> doesn't change in an UPDATE, there's no reason to include it in
>> both the BEFORE and AFTER tuple images, as long as we have the
>> null col
Martijn van Oosterhout writes:
> And then you have fabulous things like:
> https://git.reviewboard.kde.org/r/102145/
> (OSX defines _POSIX_THREAD_PROCESS_SHARED but does not actually support
> it.)
> Seems not very well tested in any case.
> It might be worthwhile testing futexes on Linux though
On Tue, Jun 26, 2012 at 2:53 PM, Alvaro Herrera
wrote:
>
> Excerpts from Daniel Farina's message of mar jun 26 17:40:16 -0400 2012:
>
>> On that, I used to be of the opinion that this is a good compromise (a
>> small amount of interlock space, plus mostly posix shmem), but I've
>> heard since then
On Jun 26, 2012, at 5:44 PM, Josh Berkus wrote:
>
>> On that, I used to be of the opinion that this is a good compromise (a
>> small amount of interlock space, plus mostly posix shmem), but I've
>> heard since then (I think via AgentM indirectly, but I'm not sure)
>> that there are cases where e
> This can be trivially reproduced if one runs an old (SysV shared
> memory-based) postgresql alongside a potentially newer postgresql with a
> smaller SysV segment. This can occur with applications that bundle postgresql
> as part of the app.
I'm not saying it doesn't happen at all. I'm sayi
Robert Haas writes:
> So, what about keeping a FIFO in the data directory?
Hm, does that work if the data directory is on NFS? Or some other weird
not-really-Unix file system?
> When the
> postmaster starts up, it tries to open the file with O_NONBLOCK |
> O_WRONLY (or O_NDELAY | O_WRONLY, if t
On Jun 26, 2012, at 6:12 PM, Daniel Farina wrote:
>
> (Emphasis mine).
>
> I don't think that -hackers at the time gave the zero-shmem rationale
> much weight (I also was not that happy about the safety mechanism of
> that patch), but upon more reflection (and taking into account *other*
> softw
Josh Berkus writes:
> So let's fix the 80% case with something we feel confident in, and then
> revisit the no-sysv interlock as a separate patch. That way if we can't
> fix the interlock issues, we still have a reduced-shmem version of Postgres.
Yes. Insisting that we have the whole change in
Tom Lane wrote:
> In the meantime, insisting that we solve this problem before we do
> anything is a good recipe for ensuring that nothing happens, just
> like it hasn't happened for the last half dozen years. (I see
> Alvaro just made the same point.)
And now so has Josh.
+1 from me, too.
"A.M." writes:
> This can be trivially reproduced if one runs an old (SysV shared
> memory-based) postgresql alongside a potentially newer postgresql with a
> smaller SysV segment. This can occur with applications that bundle postgresql
> as part of the app.
I don't believe that that case is a
> It's
> still unproven whether it'd be an improvement, but you could expect to
> prove it one way or the other with a well-defined amount of testing.
I've hacked the code to use adaptive pthread mutexes instead of spinlocks. see
attached patch. The patch is for the git head, but it can easily be
Excerpts from Tom Lane's message of mar jun 26 18:58:45 -0400 2012:
> Even if you actively try to configure the shmem settings to exactly
> fill shmmax (which I concede some installation scripts might do),
> it's going to be hard to do because of the 8K granularity of the main
> knob, shared_buff
Hi,
To recapitulate why I think this sort of embedded list is worthwile:
* minimal memory overhead (16 bytes for double linked list heads/nodes on
64bit systems)
* no additional memory allocation overhead
* no additional dereference to access the contents of a list element
* most modifications ar
"A.M." writes:
> On Jun 26, 2012, at 6:12 PM, Daniel Farina wrote:
>> I'm simply suggesting that for additional benefits it may be worth
>> thinking about getting around nattach and thus SysV shmem, especially
>> with regard to safety, in an open-ended way.
> I solved this via fcntl locking.
No,
Hi Steve,
On Tuesday, June 26, 2012 02:14:22 AM Steve Singer wrote:
> I planned to have some cutoff 'max_changes_in_memory_per_txn' value.
> > If it has
> > been reached for one transaction all existing changes are spilled to
> > disk. New changes again can be kept in memory till its reached again
On 06/26/2012 07:30 PM, Tom Lane wrote:
"A.M." writes:
On Jun 26, 2012, at 6:12 PM, Daniel Farina wrote:
I'm simply suggesting that for additional benefits it may be worth
thinking about getting around nattach and thus SysV shmem, especially
with regard to safety, in an open-ended way.
I so
On 06/26/2012 07:15 PM, Alvaro Herrera wrote:
Excerpts from Tom Lane's message of mar jun 26 18:58:45 -0400 2012:
Even if you actively try to configure the shmem settings to exactly
fill shmmax (which I concede some installation scripts might do),
it's going to be hard to do because of the 8K
On Tue, Jun 26, 2012 at 6:20 PM, Tom Lane wrote:
> Robert Haas writes:
>> So, what about keeping a FIFO in the data directory?
>
> Hm, does that work if the data directory is on NFS? Or some other weird
> not-really-Unix file system?
I would expect NFS to work in general. We could test that.
"A.M." writes:
> On 06/26/2012 07:30 PM, Tom Lane wrote:
>>> I solved this via fcntl locking.
>> No, you didn't, because fcntl locks aren't inherited by child processes.
>> Too bad, because they'd be a great solution otherwise.
> You claimed this last time and I replied:
> http://archives.postgr
On Tue, Jun 26, 2012 at 05:05:27PM -0500, Kevin Grittner wrote:
> David Fetter wrote:
> > On Mon, Jun 25, 2012 at 01:50:54PM -0500, Kevin Grittner wrote:
>
> >> One fine point regarding before and after images -- if a value
> >> doesn't change in an UPDATE, there's no reason to include it in
> >
I wrote:
> Reflecting on this further, it seems to me that the main remaining
> failure modes are (1) file locking doesn't work, or (2) idiot DBA
> manually removes the lock file.
Oh, wait, I just remembered the really fatal problem here: to quote from
the SUS fcntl spec,
All locks associ
Hi Kaigai-san,
> -Original Message-
> From: Kohei KaiGai [mailto:kai...@kaigai.gr.jp]
> Sent: Tuesday, June 26, 2012 11:05 PM
> To: Etsuro Fujita
> Cc: Robert Haas; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] WIP Patch: Selective binary conversion of CSV file
> foreign tables
>
On Tue, Jun 26, 2012 at 6:25 PM, Tom Lane wrote:
> Josh Berkus writes:
>> So let's fix the 80% case with something we feel confident in, and then
>> revisit the no-sysv interlock as a separate patch. That way if we can't
>> fix the interlock issues, we still have a reduced-shmem version of Postg
Hi, hackersI modified the code in add_path() a bit so that all the query
path candidates inside pathlist will not be removed and all new path will be
added into the pathlist, thus all path candidates are kept in pathlist. I then
tested a four-relation query. In 9.1.3, I can see thousands of
Hi,
> -Original Message-
> From: Robert Haas [mailto:robertmh...@gmail.com]
> Sent: Wednesday, June 27, 2012 5:09 AM
> To: Etsuro Fujita
> Cc: Ants Aasma; Jay Levitt; Tom Lane; PostgreSQL-development; Francois Deliege
> Subject: Re: [HACKERS] [PATCH] Lazy hashaggregate when no aggregation
Robert Haas writes:
> So, here's a patch. Instead of using POSIX shmem, I just took the
> expedient of using mmap() to map a block of MAP_SHARED|MAP_ANONYMOUS
> memory. The sysv shm is still allocated, but it's just a copy of
> PGShmemHeader; the "real" shared memory is the anonymous block. Thi
Qi Huang writes:
> Hi, hackersI modified the code in add_path() a bit so that all the query
> path candidates inside pathlist will not be removed and all new path will be
> added into the pathlist, thus all path candidates are kept in pathlist. I
> then tested a four-relation query. In 9.1.
> [ shrug... ] When you're not showing us exactly what you did, it's hard
> to answer that for sure. But there is some prefiltering logic in
> joinpath.c that you might have to lobotomize too if you want to keep
> known-inferior join paths.
>
> regards, tom lane
Thanks, Tom.
Below is what I did
2012/6/26 Tom Lane :
> Pavel Stehule writes:
>> it is not security issue - just I dislike sending complete stack, when
>> just only one variable should be used.
>
> That's a pretty darn weak argument. If I read the patch correctly, what
> you're proposing involves a dynamic fetch from the client
1 - 100 of 103 matches
Mail list logo
