pg 9.2 git master
AMD 8120 (8-core) / 6 GB memory / Centos 6.2
I have experimented a bit with dropping a table from master, then querying that
table from a
sync-rep slave. It is a little worrying that this, the first test I tried,
crashes the slave.
There are two instance on one machine,
On 25 May 2012 17:34, Tom Lane t...@sss.pgh.pa.us wrote:
Sandro Santilli s...@keybit.net writes:
I ended up providing an explicit mechanism to request interruption of
whatever the library is doing, and experimented (successfully so far)
requesting the interruption from a SIGINT handler.
Do
On May26, 2012, at 12:40 , Simon Riggs wrote:
On 25 May 2012 17:34, Tom Lane t...@sss.pgh.pa.us wrote:
I assume that the geos::util::Interrupt::request() call sets a flag
somewhere that's going to be periodically checked in long-running
loops. Would it be possible for the periodic checks to
On Fri, May 25, 2012 at 10:30 AM, Merlin Moncure mmonc...@gmail.com wrote:
I think what's happening here is that the buffer partitions don't help
(in fact, they hurt) in the presence of multiple concurrent scans that
are operating on approximately the same data. Sooner or later the
scans line
On Sat, 26 May 2012, Robert Haas wrote:
This theory is seeming fairly plausible - how can we test it?
How about trying it with synchronize_seqscans = off? If the
synchronized-seqscan logic is causing contention on the buf mapping
locks and individual buffer locks, that should fix it.
Turning
* Sergey Koposov (kopo...@ast.cam.ac.uk) wrote:
Turning off synch seq scans doesn't help either. 18 sec
multithreaded run vs 7 sec single threaded.
Alright, can you just time 'cat' when they're started a few seconds or
whatever apart from each other? I can't imagine it being affected in
the
On Sat, 26 May 2012, Stephen Frost wrote:
Alright, can you just time 'cat' when they're started a few seconds or
whatever apart from each other? I can't imagine it being affected in
the same way as these, but seems like it wouldn't hurt to check.
I've tryed cat'ting a created in advance 8gig
On Fri, May 25, 2012 at 07:02:42PM -0400, Tom Lane wrote:
However, the remaining processes trying to
compute new init files would still have to complete the process, so I'd
expect there to be a diminishing effect --- the ones that were stalling
shouldn't all release exactly together. Unless
Hello
I proposed new psql's format shell. This format is optimized for
processing returned result in shell:
postgres=# select * from foo;
a | b | c
--++
Hello, World | 10 | 2012-05-26
Ahoj, Svete | 20 | 2012-06-15
(2 rows)
postgres=# \pset format
On 26-05-2012 01:45, Fujii Masao wrote:
Ouch! But removing pg_size_pretty(numeric) causes another usability
issue, e.g., pg_size_pretty(pg_xlog_location_diff(...)) fails. So how about
removing pg_size_pretty(bigint) to resolve those two issues?
I guess pg_size_pretty(numeric) is a bit slower
On Sat, May 26, 2012 at 05:39:23PM +0200, Pavel Stehule wrote:
Hello
I proposed new psql's format shell. This format is optimized for
processing returned result in shell:
postgres=# select * from foo;
a | b | c
--++
Hello, World | 10 |
Greg Sabino Mullane g...@endpoint.com writes:
On Fri, May 25, 2012 at 07:02:42PM -0400, Tom Lane wrote:
pg_attribute just enough smaller to avoid the scenario. Not sure about
Greg's case, but he should be able to tell us the size of pg_attribute
and his shared_buffers setting ...
Fujii Masao masao.fu...@gmail.com writes:
On Sat, May 26, 2012 at 9:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The argument for adding pg_size_pretty(numeric) was pretty darn thin in
the first place, IMHO; it does not seem to me that it justified this
loss of usability.
Ouch! But removing
On Sat, May 26, 2012 at 12:17:04PM -0400, Tom Lane wrote:
If you see any block numbers above about 20 then maybe the triggering
condition is a row relocation after all.
Highest was 13.
--
Greg Sabino Mullane g...@endpoint.com
End Point Corporation
PGP Key: 0x14964AC8
pgpa6XGTGTEIZ.pgp
2012/5/26 Bruce Momjian br...@momjian.us:
On Sat, May 26, 2012 at 05:39:23PM +0200, Pavel Stehule wrote:
Hello
I proposed new psql's format shell. This format is optimized for
processing returned result in shell:
postgres=# select * from foo;
a | b | c
Bruce Momjian br...@momjian.us writes:
On Sat, May 26, 2012 at 05:39:23PM +0200, Pavel Stehule wrote:
I proposed new psql's format shell. This format is optimized for
processing returned result in shell:
I am unclear exactly how this relates to shells.
What I'm unclear on is why we'd want to
2012/5/26 Tom Lane t...@sss.pgh.pa.us:
Bruce Momjian br...@momjian.us writes:
On Sat, May 26, 2012 at 05:39:23PM +0200, Pavel Stehule wrote:
I proposed new psql's format shell. This format is optimized for
processing returned result in shell:
I am unclear exactly how this relates to shells.
On Sat, May 26, 2012 at 12:43:40PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Sat, May 26, 2012 at 05:39:23PM +0200, Pavel Stehule wrote:
I proposed new psql's format shell. This format is optimized for
processing returned result in shell:
I am unclear exactly how
Greg Sabino Mullane g...@endpoint.com writes:
On Sat, May 26, 2012 at 12:17:04PM -0400, Tom Lane wrote:
If you see any block numbers above about 20 then maybe the triggering
condition is a row relocation after all.
Highest was 13.
Hm ... but wait, you said you'd done a VACUUM FULL on the
On Sat, May 26, 2012 at 01:25:29PM -0400, Tom Lane wrote:
Greg Sabino Mullane g...@endpoint.com writes:
On Sat, May 26, 2012 at 12:17:04PM -0400, Tom Lane wrote:
If you see any block numbers above about 20 then maybe the triggering
condition is a row relocation after all.
Highest was
Hi!
On Sat, 2012-05-26 17:39:23 +0200, Pavel Stehule pavel.steh...@gmail.com
wrote:
postgres=# select * from foo;
[...]
postgres=# \pset format shell
Output format is shell.
postgres=# select * from foo;
a b c
Hello,\ World 10 2012-05-26
Ahoj,\ Svete 20 2012-06-15
[...]
I like that idea!
I've been poking at Jeff Frost's and Greg Mullane's recent reports of
high load due to many processes getting stuck in relcache init file
rebuild operations. I can reproduce a similar behavior here by creating
a database containing a whole lot of many-column views, thereby bloating
pg_attribute
A gripe today in pgsql-novice made me realize that configure's
--disable-shared option has been useless since 9.0, because it prevents
plpgsql.so from being built, which causes initdb to fail now that
plpgsql is installed by default --- which actually seems to mean
you don't have any choice about
2012/5/26 Bruce Momjian br...@momjian.us:
On Sat, May 26, 2012 at 12:43:40PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Sat, May 26, 2012 at 05:39:23PM +0200, Pavel Stehule wrote:
I proposed new psql's format shell. This format is optimized for
processing returned
2012/5/26 Jan-Benedict Glaw jbg...@lug-owl.de:
Hi!
On Sat, 2012-05-26 17:39:23 +0200, Pavel Stehule pavel.steh...@gmail.com
wrote:
postgres=# select * from foo;
[...]
postgres=# \pset format shell
Output format is shell.
postgres=# select * from foo;
a b c
Hello,\ World 10 2012-05-26
On Sat, May 26, 2012 at 11:50 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2012/5/26 Tom Lane t...@sss.pgh.pa.us:
Bruce Momjian br...@momjian.us writes:
On Sat, May 26, 2012 at 05:39:23PM +0200, Pavel Stehule wrote:
I proposed new psql's format shell. This format is optimized for
bash isn't everywhere (on UNIX)...
it is true - but first format - space is used as separator and space
is escaped should be processed on every shell.
Regards
Pavel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
27 matches
Mail list logo
