Sergey Burladyan eshkin...@gmail.com writes:
Oh, now problem with simple query:
8.4.0 from Debian
explain analyze select i from t where i = 10 and i = 1;
QUERY PLAN
Andrew Dunstan wrote:
...
branch | released | curr_version | curr_date | final_date
++--++
8.4| 2009-07-01 | 8.4.0| 2009-07-01 |
8.3| 2008-02-04 | 8.3.7| 2009-03-16 |
8.2| 2006-12-05 | 8.2.13
On Tue, 2009-07-07 at 19:38 +0100, Dean Rasheed wrote:
This approach works well if the number of potential conflicts is
small.
[...]
Curing the scalability problem by spooling the queue to disk shouldn't
be too hard to do, but that doesn't address the problem that if a
significant
Hi,
It seems our makefiles fail to install fmgroids.h by make install in a
VPATH build.
The reason is that they do this (src/include/Makefile)
for dir in $(SUBDIRS); do \
cp $(srcdir)/$$dir/*.h '$(DESTDIR)$(includedir_server)'/$$dir/ || exit; \
chmod $(INSTALL_DATA_MODE)
Tom Lane t...@sss.pgh.pa.us writes:
Sergey Burladyan eshkin...@gmail.com writes:
Oh, now problem with simple query:
8.4.0 from Debian
explain analyze select i from t where i = 10 and i = 1;
QUERY PLAN
On Tue, Jul 7, 2009 at 8:12 PM, Tom Lanet...@sss.pgh.pa.us wrote:
(If nothing else, there is no point in keeping so much WAL that catching
up by scanning it would take longer than taking a fresh base backup.
My impression from recent complaints about our WAL-reading speed is that
that might be
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
Greg Stark wrote:
It would still protect against offline attacks such as against backup files.
True, but filesystem-level encryption handles that scenario with less pain.
Yes, I intended offline attacks, and also agree that
On Wed, Jul 8, 2009 at 1:49 AM, Itagaki
Takahiroitagaki.takah...@oss.ntt.co.jp wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
Greg Stark wrote:
It would still protect against offline attacks such as against backup
files.
True, but filesystem-level encryption handles
Encrypting lots of small chunks of data with the same key is a very
dangerous thing to do and it's very tricky to get right.
Using an initialization vector (IV) is the way to go, recommend using CBC or CFB
mode. Although, an IV is never supposed to be used more than once with the same
key;
Andrew Chernow wrote:
Encrypting lots of small chunks of data with the same key is a very
dangerous thing to do and it's very tricky to get right.
Using an initialization vector (IV) is the way to go, recommend using
CBC or CFB mode. Although, an IV is never supposed to be used more
Andrew Dunstan wrote:
Andrew Chernow wrote:
Encrypting lots of small chunks of data with the same key is a very
dangerous thing to do and it's very tricky to get right.
Using an initialization vector (IV) is the way to go, recommend using
CBC or CFB mode. Although, an IV is never
On Tue, Jul 7, 2009 at 6:33 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Jul 7, 2009, at 4:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
My own thought is that from_collapse_limit has more justification,
That's pretty much where I am with it, too. The
Hi,
On Wed, Jul 8, 2009 at 12:49 AM, Tom Lanet...@sss.pgh.pa.us wrote:
This design seems totally wrong to me. It's confusing the master's
pg_xlog directory with the archive. We should *not* use pg_xlog as
a long-term archive area; that's terrible from both a performance
and a reliability
Hi,
On Wed, Jul 8, 2009 at 4:00 AM, Heikki
Linnakangasheikki.linnakan...@enterprisedb.com wrote:
I would envision the slaves
connecting to the master's replication port and asking feed me WAL
beginning at LSN position thus-and-so, with no notion of WAL file
boundaries exposed anyplace.
On Thu, Jul 02, 2009 at 03:42:56PM +0100, Dave Page wrote:
On Thu, Jul 2, 2009 at 3:22 PM, Joshua Tolleyeggyk...@gmail.com wrote:
On Thu, Jul 02, 2009 at 08:41:27AM +0100, Dave Page wrote:
As far as I'm aware, there's been no code
review yet either, which would probably be a good idea.
Pgbench is a famous tool to measure postgres performance, but nowadays
it does not work well because it cannot use multiple CPUs. On the other
hand, postgres server can use CPUs very well, so the bottle-neck of
workload is *in pgbench*.
Multi-threading would be a solution. The attached patch adds
2009/7/8 Alvaro Herrera alvhe...@commandprompt.com:
By the way, if the migration of the current commitfest was an automatic
procedure, is there a chance that the old commitfests can be migrated as
well?
It wasn't really automatic as such. I used a few scripts that I saved
in case we needed
to...@tuxteam.de wrote:
As other posters have put it, I'd be very sceptical of server-side
decryption. If the server has all the necessary bits to decrypt the
data, all bets are off.
Server can access both encrypted data and its password, but we can put
them in different disk drives. We
2009/7/8 Peter Eisentraut pete...@gmx.net:
I have the following concern: Likely, this tool and the overall process will
evolve over time. To pick an example that may or may not be actually useful,
in the future we might want to change from a fixed list of patch sections to a
free list of
On Wed, Jul 8, 2009 at 6:43 AM, Itagaki
Takahiroitagaki.takah...@oss.ntt.co.jp wrote:
to...@tuxteam.de wrote:
As other posters have put it, I'd be very sceptical of server-side
decryption. If the server has all the necessary bits to decrypt the
data, all bets are off.
Server can access
101 - 120 of 120 matches
Mail list logo
