On Fri, Mar 12, 2010 at 8:13 PM, Magnus Hagander mag...@hagander.net wrote:
On Wed, Mar 10, 2010 at 10:09, Fujii Masao masao.fu...@gmail.com wrote:
Hi,
http://archives.postgresql.org/pgsql-hackers/2010-01/msg01672.php
On win32, the blocking libpq functions like PQconnectdb() and
PQexec() are
On Sat, Mar 13, 2010 at 12:28 PM, Bruce Momjian br...@momjian.us wrote:
Where are we in getting to beta1? I know people are looking to me for
9.0 release notes and I will have them done in about a week, but what
about open issues? I don't see many on the main 9.0 open items page:
On Mon, Mar 15, 2010 at 10:14, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, Mar 12, 2010 at 8:13 PM, Magnus Hagander mag...@hagander.net wrote:
On Wed, Mar 10, 2010 at 10:09, Fujii Masao masao.fu...@gmail.com wrote:
Hi,
http://archives.postgresql.org/pgsql-hackers/2010-01/msg01672.php
On
David E. Wheeler da...@kineticode.com writes:
On Mar 14, 2010, at 3:38 PM, Josh Berkus wrote:
I'm planning on writing a Guide to HS SR for the beta. Originally I
planned to put this in the main docs, but I couldn't figure out how to
fit it in there structurally. Plus, it needs more
On Mon, Mar 15, 2010 at 6:42 PM, Magnus Hagander mag...@hagander.net wrote:
Perhaps we can factor out most of this
into functions in backend/port/win32 so that we can re-use it fro
there?
Sorry. I couldn't get your point. Could you explain it in detail?
What I'm referring to is the part
Dimitri Fontaine wrote:
Maybe some more admin level tutorial would be great to have too, such as
how to find what's locking, how to monitor table and index usage to
determine which indexes to drop, which to create, how to monitor
things (slaves lag, hitratio, transactions, I/U/D activity, you
Greg Smith g...@2ndquadrant.com writes:
Dimitri Fontaine wrote:
Maybe some more admin level tutorial would be great to have too, such as
how to find what's locking, how to monitor table and index usage to
determine which indexes to drop, which to create, how to monitor
things (slaves lag,
On Sat, Mar 13, 2010 at 1:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wonder if it could work to treat the result of a record-fieldname
operator as being of UNKNOWN type initially, and resolve its actual
type in the parser in the same way we do for undecorated literals
and parameters, to wit
Merlin Moncure wrote:
record-fieldname takes a string (possibly a variable)?
If it doesn't we have a communication problem. :-)
If so, his would nail the problem.
Not quite, but close. We also need a nice way of querying for field
names (at least) at run time. I've seen that requested
Dimitri Fontaine dfonta...@hi-media.com writes:
A lot of things are described in the manual and provided in munin or
nagios plugins already, but still the Tutorial looks like a good place
to give the recipes, ready-to-go queries etc.
This sounds like a pretty horrid idea. The tutorial is
Tom Lane t...@sss.pgh.pa.us writes:
This sounds like a pretty horrid idea. The tutorial is meant to be read
first, so it cannot depend on having already read any of the main
documentation. If we try to fill it with hints and tricks then either
it will be completely unintelligible to newbies,
On Mon, Mar 15, 2010 at 10:02 AM, Andrew Dunstan and...@dunslane.net wrote:
Not quite, but close. We also need a nice way of querying for field names
(at least) at run time. I've seen that requested several times.
ok. just making sure we were on the same page. wasn't there a
technical objection
Fujii Masao wrote:
On Mon, Mar 15, 2010 at 6:42 PM, Magnus Hagander mag...@hagander.net wrote:
I think we need to look at this as a single problem needing to be
solved, and then have the same solution applied to dblink and
walreceiver.
Agreed.
Something like libpq_select() which waits for
Merlin Moncure mmonc...@gmail.com writes:
On Mon, Mar 15, 2010 at 10:02 AM, Andrew Dunstan and...@dunslane.net wrote:
Not quite, but close. We also need a nice way of querying for field names
(at least) at run time. I've seen that requested several times.
does the parse/plan objection still
Just noticed a problem popping up sometimes with the new multi-threaded
pgbench. This is on a Linux RPM build (the alpha4 set) compiled with
'--disable-thread-safety'. Still trying to nail down whether that's a
requirement for this problem to appear or not. I did most of my review
of this
On 03/15/2010 02:42 AM, Magnus Hagander wrote:
I think we need to look at this as a single problem needing to be
solved, and then have the same solution applied to dblink and
walreceiver.
+1
Joe
signature.asc
Description: OpenPGP digital signature
Greg Smith wrote:
Just noticed a problem popping up sometimes with the new
multi-threaded pgbench. This is on a Linux RPM build (the alpha4 set)
compiled with '--disable-thread-safety'. Still trying to nail down
whether that's a requirement for this problem to appear or not. I did
most
Greg Smith g...@2ndquadrant.com writes:
Looks like sometimes a client is only getting part of its line written
out before getting stomped on by the next one. I think one of the
assumptions being made about how to safely write to this log file may be
broken by the multi-process
On Mon, Mar 15, 2010 at 11:37 AM, Tom Lane t...@sss.pgh.pa.us wrote:
If we make the implementation be such that (rec-field)::foo forces
a runtime cast to foo (rather than throwing an error if it's not type
foo already)
yeah...explicit cast should always do 'best effort'
The cost of looking up
Merlin Moncure mmonc...@gmail.com writes:
On Mon, Mar 15, 2010 at 11:37 AM, Tom Lane t...@sss.pgh.pa.us wrote:
If we make the implementation be such that (rec-field)::foo forces
a runtime cast to foo (rather than throwing an error if it's not type
foo already)
yeah...explicit cast should
On Mon, Mar 15, 2010 at 12:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Mon, Mar 15, 2010 at 11:37 AM, Tom Lane t...@sss.pgh.pa.us wrote:
If we make the implementation be such that (rec-field)::foo forces
a runtime cast to foo (rather than throwing an
Hello,
this patch significantly reduces memory usage of ispell dictionaries.
without patch (Czech dictionary, 64bit linux):
cspell: 48816784 total in 5930 blocks; 89496 free (1587 chunks); 48727288 used
Ispell dictionary init context: 19226672 total in 12 blocks; 1742624
free (34 chunks);
On 3/15/10 5:47 AM, Dimitri Fontaine wrote:
Maybe it's time to start another thread if people want to follow-up on
expanding our tutorial.
Yes, and on pgsql-docs rather than on this mailing list.
Or ... J.F.D.I (Just F Do It). That is, if someone contributed a
whole buncha new text to the
Josh Berkus wrote:
Devs,
Also, I would like to have a Beta or at least a new alpha release before
April 3 for the test-fest, so that our volunteers aren't testing bugs
which are already patched.
We can easily create another alpha by April 3. I think the big question
is whether we can put
On Sun, 2010-03-14 at 06:50 -0700, Sergej Galkin wrote:
1) For example - can I delete entry in my picksplit procedure ?
No, entries are automatically removed by postgres; and only when the
underlying tuples in the table are removed (or they no longer match the
predicate of a partial index).
2)
On 3/15/10 8:41 AM, Greg Smith wrote:
Just noticed a problem popping up sometimes with the new multi-threaded
pgbench. This is on a Linux RPM build (the alpha4 set) compiled with
'--disable-thread-safety'. Still trying to nail down whether that's a
requirement for this problem to appear or
It's DST transition season again, and that means that we're getting the
usual quota of questions from people who don't quite understand how
DST-related timestamp arithmetic works, and whose incorrect code seems
to work until exercised during a transition interval. We've got this
one from a guy
On Mon, Mar 15, 2010 at 4:24 PM, Bruce Momjian br...@momjian.us wrote:
We can easily create another alpha by April 3. I think the big question
is whether we can put out beta1 while we still have open HS/SR issues.
My guess is no. My other guess is that we will still have open HS/SR
issues on
Greg Smith g...@2ndquadrant.com wrote:
It looks like the switch between clients running on separate workers can
lead to a mix of their respective lines showing up though.
Oops. There might be two solutions for the issue:
1. Use explicit locks. The lock primitive will be pthread_mutex for
On Mon, Mar 15, 2010 at 9:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Mar 15, 2010 at 7:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm starting to think that maybe we should throw error in these cases
instead of silently doing something that's got
On Tue, Mar 16, 2010 at 12:32 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Something like libpq_select() which waits for the socket to become
ready would be required for walreceiver and dblink. But it's necessary
for walreceiver on not only win32 but also the other, ...
Robert Haas robertmh...@gmail.com writes:
On Mon, Mar 15, 2010 at 9:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The current code behavior seems to me to be on par with, for example,
trying to intuit MM-DD versus DD-MM field orders. We used to try to
do that, too, and gave it up as a bad idea.
Takahiro Itagaki wrote:
1. Use explicit locks. The lock primitive will be pthread_mutex for
multi-threaded implementations or semaphore for multi-threaded ones.
2. Use per-thread log files.
File names would be pgbench_log.main-process-id.thread-id.
I'm concerned that the
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp writes:
Greg Smith g...@2ndquadrant.com wrote:
It looks like the switch between clients running on separate workers can
lead to a mix of their respective lines showing up though.
Oops. There might be two solutions for the issue:
1. Use
Tom Lane t...@sss.pgh.pa.us wrote:
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp writes:
Oops. There might be two solutions for the issue:
1. Use explicit locks. The lock primitive will be pthread_mutex for
multi-threaded implementations or semaphore for multi-threaded ones.
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp wrote:
2. Use per-thread log files.
File names would be pgbench_log.main-process-id.thread-id.
Here is a patch to implement per-thread log files for pgbench -l.
The log filenames are pgbench_log.main-process-id.thread-serial-number
Robert Haas robertmh...@gmail.com writes:
On Mon, Mar 15, 2010 at 7:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm starting to think that maybe we should throw error in these cases
instead of silently doing something that's got a 50-50 chance of being
wrong. I'm not sure if the assume standard
37 matches
Mail list logo
