Bruce Momjian wrote:
Lacey Powers wrote:
I tried to send something out Thursday about this to pgsql-performance,
and I tried to send something out last night about this to
pgsql-announce. Neither seem to have gotten through, or approved. =( =( =(
Yes, I suspected that might have happened.
On 6/14/10 3:39 PM, Lacey Powers wrote:
Bruce Momjian wrote:
Lacey Powers wrote:
I tried to send something out Thursday about this to
pgsql-performance, and I tried to send something out last night about
this to pgsql-announce. Neither seem to have gotten through, or
approved. =( =( =(
Lacey Powers wrote:
Do any of the other minor releases made at the same time have this
problem, or just 8.4.4?
The only ones affected were 8.4.4 for CentOS 5 x86_64 and i386.
That also covers RHEL5 x86_64/i386, no? I assume you use the same RPMs
for both.
cheers
andrew
--
Sent via
Andrew Dunstan wrote:
Lacey Powers wrote:
Do any of the other minor releases made at the same time have this
problem, or just 8.4.4?
The only ones affected were 8.4.4 for CentOS 5 x86_64 and i386.
That also covers RHEL5 x86_64/i386, no? I assume you use the same RPMs
for both.
Josh Berkus wrote:
On 6/14/10 3:39 PM, Lacey Powers wrote:
Bruce Momjian wrote:
Lacey Powers wrote:
I tried to send something out Thursday about this to
pgsql-performance, and I tried to send something out last night about
this to pgsql-announce. Neither seem to have gotten through, or
(2010/06/14 21:15), Robert Haas wrote:
2010/6/14 KaiGai Koheikai...@kaigai.gr.jp:
(2010/06/14 20:01), Stephen Frost wrote:
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
The attached patch tries to add one more security hook on the
initialization of PostgreSQL instance (InitPostgres()).
It
(2010/06/14 22:11), Robert Haas wrote:
On Mon, Jun 14, 2010 at 8:46 AM, Stephen Frostsfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
2010/6/14 KaiGai Koheikai...@ak.jp.nec.com:
It adds makeRangeTblEntry() into makefuncs.c to keep the code more
clean. It shall be also
(2010/06/14 21:35), Stephen Frost wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
This is essentially the same patch that I wrote and posted several
weeks ago, with changes to the comments and renaming of the
identifiers. Are you trying to represent it as your own work?
Ehh, I doubt
2010/6/14 KaiGai Kohei kai...@ak.jp.nec.com:
On the hook, I'd like to obtain security context of the client process
which connected to the PostgreSQL instance. It is not available at the
_PG_init() phase, because clients don't connect yet.
Can't you just call getpeercon() the first time you
(2010/06/15 9:22), Robert Haas wrote:
2010/6/14 KaiGai Koheikai...@ak.jp.nec.com:
On the hook, I'd like to obtain security context of the client process
which connected to the PostgreSQL instance. It is not available at the
_PG_init() phase, because clients don't connect yet.
Can't you just
2010/6/14 KaiGai Kohei kai...@ak.jp.nec.com:
(2010/06/15 9:22), Robert Haas wrote:
2010/6/14 KaiGai Koheikai...@ak.jp.nec.com:
On the hook, I'd like to obtain security context of the client process
which connected to the PostgreSQL instance. It is not available at the
_PG_init() phase,
(2010/06/15 10:12), Robert Haas wrote:
2010/6/14 KaiGai Koheikai...@ak.jp.nec.com:
(2010/06/15 9:22), Robert Haas wrote:
2010/6/14 KaiGai Koheikai...@ak.jp.nec.com:
On the hook, I'd like to obtain security context of the client process
which connected to the PostgreSQL instance. It is not
On Tue, Jun 15, 2010 at 12:09 AM, Robert Haas robertmh...@gmail.com wrote:
The testing that I have been doing while we've been discussing this
reveals that you are correct. I set up an HS/SR master and slave
(running on the same machine), ran pgbench on the master, and then
started randomly
KaiGai Kohei kai...@ak.jp.nec.com writes:
The attached patch tries to add one more security hook on the
initialization of PostgreSQL instance (InitPostgres()).
Yeah, but so what? Stephen's point is still valid.
On the hook, I'd like to obtain security context of the client process
which
On Mon, Jun 14, 2010 at 10:35 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Jun 15, 2010 at 12:09 AM, Robert Haas robertmh...@gmail.com wrote:
The testing that I have been doing while we've been discussing this
reveals that you are correct. I set up an HS/SR master and slave
(running
(2010/06/15 12:28), Tom Lane wrote:
KaiGai Koheikai...@ak.jp.nec.com writes:
The attached patch tries to add one more security hook on the
initialization of PostgreSQL instance (InitPostgres()).
Yeah, but so what? Stephen's point is still valid.
On the hook, I'd like to obtain security
On Mon, Jun 14, 2010 at 10:13 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jun 14, 2010 at 8:41 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Jun 14, 2010 at 8:10 PM, Robert Haas robertmh...@gmail.com wrote:
Maybe. That sounds like a pretty enormous foot-gun to me, considering
On Tue, Jun 15, 2010 at 12:02 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
On Fri, Jun 11, 2010 at 11:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, we're already not waiting for fsync, which is the slowest part.
No, currently walsender waits for fsync.
On 15/06/10 07:47, Fujii Masao wrote:
On Tue, Jun 15, 2010 at 12:02 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Fujii Masaomasao.fu...@gmail.com writes:
Walsender tries to send WAL up to xlogctl-LogwrtResult.Write. OTOH,
xlogctl-LogwrtResult.Write is updated after XLogWrite() performs fsync.
On Thu, Jun 10, 2010 at 11:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Even then, we wouldn't need to start from the beginning of the WAL
segment AFAICS. The point is to start from the Redo pointer, not from
the checkpoint record,
On 15/06/10 08:23, Fujii Masao wrote:
On Thu, Jun 10, 2010 at 11:06 PM, Tom Lanet...@sss.pgh.pa.us wrote:
I'm not sure if it's worth the trouble, or even a particularly smart
idea, to force the output of the status function to be monotonic
regardless of what happens underneath. I think
101 - 121 of 121 matches
Mail list logo