(2010/11/14 11:19), Robert Haas wrote:
2010/11/12 KaiGai Kohei:
The attached patch allows the security label provider to switch
security label of the client during execution of certain functions.
I named it as "label switcher function"; also called as "trusted-
procedure" in SELinux community.
David Fetter wrote:
For the past couple of years, I've been hearing from the PostGIS
people among others that our type system just isn't flexible enough
for their needs. It's really starting to show its age, or possibly
design compromises that seemed reasonable a decade or more ago, but
are less
On Sat, Nov 13, 2010 at 9:17 PM, Greg Stark wrote:
> On Sun, Nov 14, 2010 at 1:15 AM, Tom Lane wrote:
>> Cleanup at first connection is something we've been avoiding for years,
>> but maybe it's time to bite the bullet and do that?
>
> Another alternative is to initialize the unlogged tables when
2010/11/12 KaiGai Kohei :
> The attached patch allows the security label provider to switch
> security label of the client during execution of certain functions.
> I named it as "label switcher function"; also called as "trusted-
> procedure" in SELinux community.
>
> This feature is quite similar
On Sun, Nov 14, 2010 at 1:15 AM, Tom Lane wrote:
> Cleanup at first connection is something we've been avoiding for years,
> but maybe it's time to bite the bullet and do that?
>
Another alternative is to initialize the unlogged tables when you
first access them. If you try to open a table and th
On Sat, Nov 13, 2010 at 8:15 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Nov 13, 2010 at 7:41 PM, Tom Lane wrote:
>>> That seems pretty gross. If you're going to have to take a special
>>> action at startup anyway, why wouldn't it take the form of "truncate,
>>> then if it's an index,
On Sat, Nov 13, 2010 at 7:59 PM, Tom Lane wrote:
> Robert Haas writes:
>> Here is a series of three patches related to unlogged tables.
>> 1. The first one (relpersistence-v1) is a mostly mechanical patch that
>> replaces pg_class.relistemp (a Boolean) with pg_class.relpersistence
>> (a character
Magnus Hagander wrote:
> On Fri, Nov 12, 2010 at 15:02, Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Bruce Momjian writes:
> >> > I have developed the attached patch to report whether IPv4 or IPv6 are
> >> > being used.
> >>
> >> What's the use of that exactly? ?It doesn't really respond to Pete
Robert Haas writes:
> On Sat, Nov 13, 2010 at 7:41 PM, Tom Lane wrote:
>> That seems pretty gross. If you're going to have to take a special
>> action at startup anyway, why wouldn't it take the form of "truncate,
>> then if it's an index, call the appropriate ambuild function"?
> We've been ov
On 11/13/2010 07:59 PM, Tom Lane wrote:
I would also argue that temp-ness is a distinct
concept from logged-ness.
I agree.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-ha
"A.M." writes:
> The goal of this work is to address all of the shortcomings of previous POSIX
> shared memory patches as pointed out mostly by Tom Lane.
It seems like you've failed to understand the main shortcoming of this
whole idea, which is the loss of ability to detect pre-existing backend
Robert Haas writes:
> Here is a series of three patches related to unlogged tables.
> 1. The first one (relpersistence-v1) is a mostly mechanical patch that
> replaces pg_class.relistemp (a Boolean) with pg_class.relpersistence
> (a character), so that we can support more than two values. BE SURE
On Sat, Nov 13, 2010 at 7:41 PM, Tom Lane wrote:
> Robert Haas writes:
>> 2. The second one (unlogged-tables-v1) adds support for unlogged
>> tables by adding a new supported value for relpersistence. I made this
>> work by having backend that creates an unlogged relation write out an
>> "init" f
The goal of this work is to address all of the shortcomings of previous POSIX
shared memory patches as pointed out mostly by Tom Lane.
Branch:
http://git.postgresql.org/gitweb?p=users/agentm/postgresql.git;a=shortlog;h=refs/heads/posix_shmem
Main file:
http://git.postgresql.org/gitweb?p=users/a
Robert Haas writes:
> 2. The second one (unlogged-tables-v1) adds support for unlogged
> tables by adding a new supported value for relpersistence. I made this
> work by having backend that creates an unlogged relation write out an
> "init" fork for that relation. The main fork is nuked and repla
On 11/13/2010 11:07 PM, Tom Lane wrote:
Stefan Kaltenbrunner writes:
On 11/13/2010 06:58 PM, Tom Lane wrote:
Just looking at it, I think that the logic in canAcceptConnections got
broken by somebody in 8.4, and then broken some more in 9.0: in some
cases it will return an "okay to proceed" sta
On Sat, Nov 13, 2010 at 12:30 PM, Peter Eisentraut wrote:
> On fre, 2010-11-12 at 17:19 -0500, Robert Haas wrote:
>> If we allow users to name objects, we ought to make every effort to
>> also allow renaming them. In my mind, the only way renaming is too
>> marginal to be useful is if the feature
On Sat, Nov 13, 2010 at 12:13 PM, Tom Lane wrote:
> Hannu Krosing writes:
>> On Sat, 2010-11-13 at 10:51 -0500, Tom Lane wrote:
>>> If a table has no indexes, we will always decide that any same-page
>>> update operation is a HOT update, since obviously it isn't modifying
>>> any indexed columns.
On Fri, Nov 12, 2010 at 10:55 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> FYI, I always wondered if the rare use of mergejoins justified the extra
>> planning time of carrying around all those joinpaths.
>
> They're hardly rare.
They fairly rare in the sorts of queries I normally issue, but I
On Sat, Nov 13, 2010 at 10:07 AM, Tom Lane wrote:
> Robert Haas writes:
>> One idea I've had is that we might want to think about defining an
>> operation that is effectively "store, with a memory barrier". For
>> example, on x86, this could be implemented using xchg. I think if you
>> have a s
Stefan Kaltenbrunner writes:
> On 11/13/2010 06:58 PM, Tom Lane wrote:
>> Just looking at it, I think that the logic in canAcceptConnections got
>> broken by somebody in 8.4, and then broken some more in 9.0: in some
>> cases it will return an "okay to proceed" status without having checked
>> for
On 11/13/2010 06:58 PM, Tom Lane wrote:
Alvaro Herrera writes:
Stefan Kaltenbrunner reported a problem in postmaster via IM to me. I
thought I had nailed down the bug, but after more careful reading of the
code, turns out I was wrong.
The reported problem is that postmaster shuts itself dow
Peter Eisentraut writes:
> Well, it looks like $(eval) is pretty broken in 3.80, so either we
> require 3.81 or we abandon this line of thought.
[ emerges from some grubbing about in the gmake sources... ]
It looks to me like the bug in 3.80 is only triggered when "eval"
expands to a long enough
Circumstances have conspired to leave me with very little time to
work on the SSI patch during the last few weeks. I'm still convinced
that the work mentioned in this post is necessary to have a
commit-quality patch:
http://archives.postgresql.org/pgsql-hackers/2010-10/msg01754.php
I also thin
On lör, 2010-11-13 at 20:07 +0200, Peter Eisentraut wrote:
> On lör, 2010-11-13 at 12:20 -0500, Tom Lane wrote:
> > Peter Eisentraut writes:
> > > On lör, 2010-11-13 at 11:12 -0500, Tom Lane wrote:
> > >> It looks like all the unhappy critters are getting the same "virtual
> > >> memory exhausted"
Alvaro Herrera writes:
> It's not that straighforward though, in that the producer could stop a
> bit ahead of what the consumer reads, due to there being a buffer in the
> middle. Witness this simple example
Yeah, another example where the analogy fails for us.
--
Dimitri Fontaine
http://2ndQu
On Sat, Nov 13, 2010 at 03:23:42PM +0100, Yeb Havinga wrote:
> On 2010-11-13 14:41, David Fetter wrote:
> >On Sat, Nov 13, 2010 at 02:28:35PM +0100, Yeb Havinga wrote:
> >>1) the name "Common Table Expression" suggests that t must be
> >>regarded as an expression, hence syntactically / proof theore
On Sat, Nov 13, 2010 at 05:23:34PM +0200, Marko Tiikkaja wrote:
> On 2010-11-13 5:08 PM +0200, Tom Lane wrote:
> >Marko Tiikkaja writes:
> >>On 13 Nov 2010, at 15:41, David Fetter wrote:
> >>>Similarly, if a normal CTE called a data-changing function but
> >>>was nevertheless not referred to, it
Hannu Krosing writes:
> On Sat, 2010-11-13 at 12:13 -0500, Tom Lane wrote:
>> AFAICS we do: heap_update marks the page as prunable whether it's a HOT
>> update or not. The only difference between treating the update as HOT vs
>> not-HOT is that if there was more than one HOT update, the intermedi
On Sat, 2010-11-13 at 12:13 -0500, Tom Lane wrote:
> Hannu Krosing writes:
> > On Sat, 2010-11-13 at 10:51 -0500, Tom Lane wrote:
> >> If a table has no indexes, we will always decide that any same-page
> >> update operation is a HOT update, since obviously it isn't modifying
> >> any indexed colu
On lör, 2010-11-13 at 12:20 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > On lör, 2010-11-13 at 11:12 -0500, Tom Lane wrote:
> >> It looks like all the unhappy critters are getting the same "virtual
> >> memory exhausted" error. I wonder whether they are all using make
> >> 3.80 ...
>
>
Alvaro Herrera writes:
> Stefan Kaltenbrunner reported a problem in postmaster via IM to me. I
> thought I had nailed down the bug, but after more careful reading of the
> code, turns out I was wrong.
> The reported problem is that postmaster shuts itself down with this
> error message:
> 2010-
On Sat, November 13, 2010 18:15, Peter Eisentraut wrote:
> On lör, 2010-11-13 at 11:12 -0500, Tom Lane wrote:
>> It looks like all the unhappy critters are getting the same "virtual
>> memory exhausted" error. I wonder whether they are all using make
>> 3.80 ...
>
> It turns out that there is an
On fre, 2010-11-12 at 17:19 -0500, Robert Haas wrote:
> If we allow users to name objects, we ought to make every effort to
> also allow renaming them. In my mind, the only way renaming is too
> marginal to be useful is if the feature itself is too marginal to be
> useful.
The bottom line is, any
Peter Eisentraut writes:
> On lör, 2010-11-13 at 11:12 -0500, Tom Lane wrote:
>> It looks like all the unhappy critters are getting the same "virtual
>> memory exhausted" error. I wonder whether they are all using make
>> 3.80 ...
> It turns out that there is an unrelated bug in 3.80 that some
On lör, 2010-11-13 at 11:23 -0500, Tom Lane wrote:
> Consulting stdout shows that indeed it's launched this series of jobs:
>
> make -C backend/utils/mb/conversion_procs all
> make -C ascii_and_mic all
> gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
> -Wdeclaration-after-statement -Wendif-lab
On lör, 2010-11-13 at 11:12 -0500, Tom Lane wrote:
> It looks like all the unhappy critters are getting the same "virtual
> memory exhausted" error. I wonder whether they are all using make
> 3.80 ...
It turns out that there is an unrelated bug in 3.80 that some Linux
distributions have patched a
On lör, 2010-11-13 at 11:06 -0500, Andrew Dunstan wrote:
> But I don't feel we need to squeeze every last pip out of
> the build system.
Probably not on the buildfarm, but when you are developing, saving 20
seconds or 2 minutes per cycle can lead to hours saved.
--
Sent via pgsql-hackers maili
Hannu Krosing writes:
> On Sat, 2010-11-13 at 10:51 -0500, Tom Lane wrote:
>> If a table has no indexes, we will always decide that any same-page
>> update operation is a HOT update, since obviously it isn't modifying
>> any indexed columns. But is there any benefit to doing so?
> If we do the
On Sat, 2010-11-13 at 10:51 -0500, Tom Lane wrote:
> If a table has no indexes, we will always decide that any same-page
> update operation is a HOT update, since obviously it isn't modifying
> any indexed columns. But is there any benefit to doing so?
If we do the in-page "mini vacuum" even wit
On Sat, Nov 13, 2010 at 4:12 PM, Tom Lane wrote:
> It looks like all the unhappy critters are getting the same "virtual
> memory exhausted" error. I wonder whether they are all using make 3.80
Both my Sparc and Intel Solaris critters have 3.80.
--
Dave Page
Blog: http://pgsnake.blogspot.com
On 11/13/2010 11:12 AM, Tom Lane wrote:
It looks like all the unhappy critters are getting the same "virtual
memory exhausted" error. I wonder whether they are all using make 3.80
...
Maybe we need to put back make version logging. Interestingly, narwhal,
the mingw machine that has reported
BTW, there's another problem here: "make -j2" on my Mac blows up with
this on stderr:
ld: file not found: ../../../../../../src/backend/postgres
collect2: ld returned 1 exit status
make[3]: *** [ascii_and_mic.so] Error 1
make[2]: *** [all-ascii_and_mic-recursive] Error 2
make[1]: *** [all-backend/
Andrew Dunstan writes:
> I'm curious to know how much all this buys us.
It *would* be nice if "make -k" worked better. I frequently run into
the fact that (with the pre-existing setup) a compile error in the
backend prevented make from proceeding with builds of interfaces/,
bin/, etc, meaning th
On 11/12/2010 11:25 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 11/12/2010 03:16 PM, Peter Eisentraut wrote:
Improved parallel make support
Looks like this patch has pretty comprehensively broken the MSVC build
system. I'll see what I can recover from the wreckage.
There are also at leas
If a table has no indexes, we will always decide that any same-page
update operation is a HOT update, since obviously it isn't modifying
any indexed columns. But is there any benefit to doing so? I don't
see one offhand, and it has a downside: we're very likely to
encounter broken HOT chains if a
On 2010-11-13 5:36 PM +0200, Clark C. Evans wrote:
On Sat, 13 Nov 2010 17:23 +0200, "Marko Tiikkaja" wrote:
So these queries would behave differently?
WITH t AS (DELETE FROM foo RETURNING *)
SELECT 1 WHERE false;
WITH t AS (DELETE FROM foo RETURNING *)
SELECT 1 FROM t LIMIT 0;
I'm still tryi
On Sat, 13 Nov 2010 17:23 +0200, "Marko Tiikkaja" wrote:
> So these queries would behave differently?
>
> WITH t AS (DELETE FROM foo RETURNING *)
> SELECT 1 WHERE false;
>
> WITH t AS (DELETE FROM foo RETURNING *)
> SELECT 1 FROM t LIMIT 0;
I'm still trying to wrap my head around this
new mechani
On 2010-11-13 5:08 PM +0200, Tom Lane wrote:
Marko Tiikkaja writes:
On 13 Nov 2010, at 15:41, David Fetter wrote:
Similarly, if a normal CTE called a data-changing function but was
nevertheless not referred to, it would still run.
Actually, it wouldn't.
Indeed, and that was considered a
Marko Tiikkaja writes:
> On 13 Nov 2010, at 15:41, David Fetter wrote:
>> Similarly, if a normal CTE called a data-changing function but was
>> nevertheless not referred to, it would still run.
> Actually, it wouldn't.
Indeed, and that was considered a feature when we did it. I think
that havi
Robert Haas writes:
> One idea I've had is that we might want to think about defining an
> operation that is effectively "store, with a memory barrier". For
> example, on x86, this could be implemented using xchg. I think if you
> have a single-word variable in shared memory that is always updat
On 13 Nov 2010, at 15:41, David Fetter wrote:
On Sat, Nov 13, 2010 at 02:28:35PM +0100, Yeb Havinga wrote:
On 2010-11-12 16:51, David Fetter wrote:
On Fri, Nov 12, 2010 at 10:25:51AM -0500, Tom Lane wrote:
Yeah, that's another interesting question: should we somehow force
unreferenced CTEs
On 2010-11-13 14:41, David Fetter wrote:
On Sat, Nov 13, 2010 at 02:28:35PM +0100, Yeb Havinga wrote:
1) the name "Common Table Expression" suggests that t must be
regarded as an expression, hence syntactically / proof theoretic and
not as a table, set of rows / model theoretic. I.e. it is not a
On Fri, Nov 12, 2010 at 11:27 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> Right. I propose that we set max_wal_senders to unlimited when
>> wal_level = hot_standby.
>
> It's a memory allocation parameter ... you can't just set it to
> "unlimited", at least not without a nontrivial amount of w
On Sat, Nov 13, 2010 at 02:28:35PM +0100, Yeb Havinga wrote:
> On 2010-11-12 16:51, David Fetter wrote:
> >On Fri, Nov 12, 2010 at 10:25:51AM -0500, Tom Lane wrote:
> >>
> >>Yeah, that's another interesting question: should we somehow force
> >>unreferenced CTEs to be evaluated anyhow?
> >Yes.
> Af
On Fri, Nov 12, 2010 at 15:02, Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian writes:
>> > I have developed the attached patch to report whether IPv4 or IPv6 are
>> > being used.
>>
>> What's the use of that exactly? It doesn't really respond to Peter's
>> concern, I think.
>
> Peter li
On 2010-11-12 16:51, David Fetter wrote:
On Fri, Nov 12, 2010 at 10:25:51AM -0500, Tom Lane wrote:
Yeah, that's another interesting question: should we somehow force
unreferenced CTEs to be evaluated anyhow?
Yes.
After a night's sleep I'm still thinking no. Arguments:
1) the name "Common Tabl
57 matches
Mail list logo