On 12/09/10 20:13, Jeff Davis wrote:
On Sun, 2010-09-12 at 12:29 -0400, Tom Lane wrote:
... why throw an ERROR there if it can't happen (or
indicates an inconsistent state when it does happen)?
Are you suggesting that an Assert would be sufficient?
I'm not too picky about whether it's Assert
On 13/09/10 08:10, Fujii Masao wrote:
On Mon, Sep 13, 2010 at 12:32 PM, Tom Lane wrote:
Huh? walsender has no business applying any per-user or per-database
settings.
Okay. I got rid of the access to pg_db_role_setting from the patch.
I attached the updated version, which makes walsender pro
On Mon, Sep 13, 2010 at 12:32 PM, Tom Lane wrote:
> Huh? walsender has no business applying any per-user or per-database
> settings.
Okay. I got rid of the access to pg_db_role_setting from the patch.
I attached the updated version, which makes walsender process the
options passed in the startup
Robert, although you suggested that only one ESP module shall be
invoked on relabeling an object before, and I agreed this design
at that time, but I noticed that we cannot implement the following
behavior correctly.
SELinux defines these permissions corresponding to table relabeling.
- db_table:{
Folks,
The Commitfest for September, 2010, will start in just a couple of
days, and you can help make it successful!
The first way is to volunteer for patch-chasing, as Selena, Stephen
and Brendan did this time last year. Kudos and huge thanks to all of
them.
Patch-chasers make sure every patch
Fujii Masao writes:
> On Fri, Sep 10, 2010 at 9:56 PM, Fujii Masao wrote:
>> BTW, this issue seems to derive from the following commit.
>> http://archives.postgresql.org/pgsql-committers/2010-04/msg00175.php
>> it was previously using an untenable assumption that template1 would
>> always be ava
On Fri, Sep 10, 2010 at 9:56 PM, Fujii Masao wrote:
> BTW, this issue seems to derive from the following commit.
> http://archives.postgresql.org/pgsql-committers/2010-04/msg00175.php
> it was previously using an untenable assumption that template1 would
> always be available to connect to
The a
On Mon, Sep 6, 2010 at 10:55 PM, Robert Haas wrote:
> 3. With respect to unlogged tables, the major obstacle seems to be
> figuring out a way for these to get automatically truncated at startup
> time. As with temporary table cleanup in general, the problem here is
> that you can't do the obvious
Robert Haas writes:
> Eh, any chance you can throw this conversion up somewhere I can look at it?
I'm working up a report now, it'll include the recipe.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subsc
On Sun, Sep 12, 2010 at 9:14 PM, Tom Lane wrote:
> Robert Haas writes:
>> ... I am not sure there is really
>> much point in keeping these ancient branches and tags. I'd argue for
>> losing all branches and tags that don't start with REL except perhaps
>> for PG95-1_01. Nobody's going to care
Robert Haas writes:
> ... I am not sure there is really
> much point in keeping these ancient branches and tags. I'd argue for
> losing all branches and tags that don't start with REL except perhaps
> for PG95-1_01. Nobody's going to care about those anyway, and in the
> very unlikely event tha
On Sun, Sep 12, 2010 at 8:41 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Sep 12, 2010 at 12:02 PM, Tom Lane wrote:
>>> There are a couple of weird-looking commits way back near the beginning
>>> of the converted Postgres history:
>>>
>>> commit 91f2ac21a1e085dfe81aae110cee2246a803f600 r
Robert Haas writes:
> On Sun, Sep 12, 2010 at 12:02 PM, Tom Lane wrote:
>> There are a couple of weird-looking commits way back near the beginning
>> of the converted Postgres history:
>>
>> commit 91f2ac21a1e085dfe81aae110cee2246a803f600 refs/tags/Release_2_0_0
>> Author: PostgreSQL Daemon
>>
On Fri, Sep 10, 2010 at 1:52 PM, Igor Gelman wrote:
> Gentlemen,
>
> I found this link in PostgreSQL 9 Documentation and we are moving to a
> different platform
>
> Could you please help me with the instruction of how to install the new
> version of PostgreSQL 9
>
> on SUSE Linux Enterprise Server
On Sun, Sep 12, 2010 at 12:02 PM, Tom Lane wrote:
> There are a couple of weird-looking commits way back near the beginning
> of the converted Postgres history:
>
>
> commit 91f2ac21a1e085dfe81aae110cee2246a803f600 refs/tags/Release_2_0_0
> Author: PostgreSQL Daemon
> Date: Sat Aug 17 06:41:11
Hello folks,
I've been playing around today a lot with sysbench, and observed that 2.6.32
kernel supplied by Ubuntu is having perf regression with PG (which does not
affect MySQL), compared to 2.6.28 builds I have.
What I observed can be seen in a paste at
http://p.defau.lt/?8_GQV82Pz3_SDZbNOdP
Gentlemen,
I found this link in PostgreSQL 9 Documentation and we are moving to a
different platform
Could you please help me with the instruction of how to install the new
version of PostgreSQL 9
on SUSE Linux Enterprise Server v.10.
Thanks,
Igor G.
On Sun, 2010-09-12 at 14:12 -0400, Tom Lane wrote:
> Uh, this is nonsense. You have to have something like these functions
> to support transferring ownership of a latch from one process to
> another, which is required at least for the walreceiver usage.
Oh, I see. It's needed to know where to se
Jeff Davis writes:
> However, that also means that the whole concept of OwnLatch/DisownLatch
> is entirely redundant, and only there for asserts because it doesn't do
> anything else. That seems a little strange to me, as well, so (at
> minimum) it should be documented that the functions really ha
On Sun, 2010-09-12 at 10:13 -0700, Jeff Davis wrote:
> I'm not too picky about whether it's Assert, ERROR, or PANIC (Asserts
> aren't available in production systems, which I assume is why elog was
> used); but we should be consistent and document that:
> (a) it shouldn't happen
> (b) that it's j
On Sun, 2010-09-12 at 12:29 -0400, Tom Lane wrote:
> > ... why throw an ERROR there if it can't happen (or
> > indicates an inconsistent state when it does happen)?
>
> Are you suggesting that an Assert would be sufficient?
>
I'm not too picky about whether it's Assert, ERROR, or PANIC (Asserts
Jeff Davis writes:
> I glanced at the code, and I see (in OwnLatch()):
> + if (latch->owner_pid != 0)
> + elog(ERROR, "latch already owned");
> + latch->owner_pid = MyProcPid;
> But it looks like there may be a race there.
Yeah, that error check is only intended to cat
On Sat, 2010-09-11 at 19:15 +0300, Heikki Linnakangas wrote:
> Committed. I'll take a look at making walreceiver respond quickly when
> WAL arrives in the standby, using latches, but that shouldn't interfere
> with what you're doing.
I glanced at the code, and I see (in OwnLatch()):
+ if
There are a couple of weird-looking commits way back near the beginning
of the converted Postgres history:
commit 91f2ac21a1e085dfe81aae110cee2246a803f600 refs/tags/Release_2_0_0
Author: PostgreSQL Daemon
Date: Sat Aug 17 06:41:11 1996 +
This commit was manufactured by cvs2svn to crea
24 matches
Mail list logo
