Robert Haas writes:
> On Mon, Mar 15, 2010 at 7:50 PM, Tom Lane 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 time" rule is standardized,
>>
Takahiro Itagaki wrote:
> > > 2. Use per-thread log files.
> > > File names would be "pgbench_log..".
Here is a patch to implement per-thread log files for pgbench -l.
The log filenames are "pgbench_log.."
for each thread, but the first thread (including single-threaded) still uses
"pgb
Tom Lane wrote:
> Takahiro Itagaki 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.
> > 2. Use per-thread log files.
> > Fi
Takahiro Itagaki writes:
> Greg Smith 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 pthrea
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..".
I'm concerned that the locking itself will turn int
Robert Haas writes:
> On Mon, Mar 15, 2010 at 9:12 PM, Tom Lane 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.
> I suppose it's topologically eq
On Tue, Mar 16, 2010 at 12:32 AM, Heikki Linnakangas
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, ...
>
> Really, why? I thought this i
On Mon, Mar 15, 2010 at 9:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Mar 15, 2010 at 7:50 PM, Tom Lane 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
Greg Smith 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
multi-threaded
On Mon, Mar 15, 2010 at 4:24 PM, Bruce Momjian 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 April 3. So
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 who
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 o
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
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 p
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 th
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); 1748
On Mon, Mar 15, 2010 at 12:19 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Mon, Mar 15, 2010 at 11:37 AM, Tom Lane 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)
>
>
Merlin Moncure writes:
> On Mon, Mar 15, 2010 at 11:37 AM, Tom Lane 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'
Prob
On Mon, Mar 15, 2010 at 11:37 AM, Tom Lane 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 the ever-chang
Greg Smith 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 implementation, which is what
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 of
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
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 fe
Merlin Moncure writes:
> On Mon, Mar 15, 2010 at 10:02 AM, Andrew Dunstan 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 hold?
Yeah. Providing the field
Fujii Masao wrote:
> On Mon, Mar 15, 2010 at 6:42 PM, 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.
Agreed.
> Something like libpq_select() which waits for the socket to
On Mon, Mar 15, 2010 at 10:02 AM, Andrew Dunstan 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 to querying the f
Tom Lane 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, or there wil
Dimitri Fontaine 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 meant to be read
first,
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
On Sat, Mar 13, 2010 at 1:38 PM, Tom Lane 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
> * yo
Greg Smith 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
>> (slaves lag, hitratio, transactio
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
(slaves lag, hitratio, transactions, I/U/D activity, you name
it).
On Mon, Mar 15, 2010 at 6:42 PM, Magnus Hagander 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 that Hei
"David E. Wheeler" 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 examples, outpu
On Mon, Mar 15, 2010 at 10:14, Fujii Masao wrote:
> On Fri, Mar 12, 2010 at 8:13 PM, Magnus Hagander wrote:
>> On Wed, Mar 10, 2010 at 10:09, Fujii Masao wrote:
>>> Hi,
>>>
>>> http://archives.postgresql.org/pgsql-hackers/2010-01/msg01672.php
>>> On win32, the blocking libpq functions like PQcon
On Sat, Mar 13, 2010 at 12:28 PM, Bruce Momjian 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:
>
> http://wiki.pos
On Fri, Mar 12, 2010 at 8:13 PM, Magnus Hagander wrote:
> On Wed, Mar 10, 2010 at 10:09, Fujii Masao wrote:
>> Hi,
>>
>> http://archives.postgresql.org/pgsql-hackers/2010-01/msg01672.php
>> On win32, the blocking libpq functions like PQconnectdb() and
>> PQexec() are uninterruptible since they us
37 matches
Mail list logo
