Hi Joshua,
I think the RSS feed is a great Idea! (I personally use InfoRss with
Mozilla) Though it would be nice to reduce the amount of text before
the description (I barely get by the revision number to see the
description) maybe formatted "CMP:R##: Description..." Though
I have no idea ho
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Heads up - I have seen 2 regression hangs. I am checking further. Has
> anyone else run the regression suite with any version of this patch?
Hm, anyone else? It's pretty hard to see how the patch could break
the regression tests, because they don't ex
And the patch that was applied gives the same result.
What is more, I am not seeing the reported speedup - in fact I am seeing
no speedup worth mentioning.
This is on XP-Pro, with default postgres settings. The test sets were
somewhat larger than thos Magnus used - basically TPC-H lineitems
I failed to mention that I also tend to type CONTROL-C when I forget that
putty acts like an xterm, and doesn't need CONTROL-C to copy text into the
clipboard. In that case, aborting the pager, and leaving the terminal
trashed requiring me to exit psql, stty sane, and start up psql again is
really
Andrew - Supernews wrote:
> On 2005-10-19, Kevin Brown <[EMAIL PROTECTED]> wrote:
> > Making assumptions about what the pager will do upon receipt of SIGINT
> > is folly as well.
> >
> > Setting up SIGINT to be ignored may be the right answer (I don't
> > believe it is -- see below), but if so then
If you send a recent version of vim a CONTROL-C, and you're just sitting
there at a prompt, it gives you a hint:
Type :quit to exit Vim
Any reason not to just trap the CONTROL-C in psql when paging and offer a
hint? Especially since we don't really know that the user really wanted to
type CONT
[EMAIL PROTECTED] wrote:
> On Thu, Oct 20, 2005 at 03:42:10PM -0700, Kevin Brown wrote:
> > Martijn van Oosterhout wrote:
> > > You can't do a pclose in a signal handler, it's not one of the
> > > "reeentrant safe" functions and could lead to deadlocks. The signal
> > > manpage documents the ones y
Heads up - I have seen 2 regression hangs. I am checking further. Has
anyone else run the regression suite with any version of this patch?
cheers
andrew
Tom Lane wrote:
I wrote:
BTW, expanding on Andrew's comment, ISTM we could move the kernel call
out of the macro, ie make it look lik
Neil Conway <[EMAIL PROTECTED]> writes:
> LWLocks certainly do protect shared data, and if the compiler rearranged
> loads and stores around LWLocks acquire/release, it would result in
> corruption. Tom was arguing it is unlikely the compiler will actually do
> this (because LWLockAcquire is an out
I wrote:
> BTW, expanding on Andrew's comment, ISTM we could move the kernel call
> out of the macro, ie make it look like ...
I've applied the attached version of Qingqing's revised patch. I'm not
in a position to test it, and am about to go out for the evening, but if
anyone can check the commi
On Mon, 2005-17-10 at 16:48 -0500, Jim C. Nasby wrote:
> Sorry if I'm just confused here, but don't LWLocks protect data
> structures susceptible to corruption? And if that's the case don't we
> need to be sure that the compiler can't optimize around them?
LWLocks certainly do protect shared data,
Simon Riggs <[EMAIL PROTECTED]> writes:
> Certainly there is a lack of ideas as to how to fix it, as you mention
> in (3). This shows to me that the solution lies in one of two areas: a)
> the solution has not yet been considered or b) the solution has already
> been thought of and for whatever rea
BTW, expanding on Andrew's comment, ISTM we could move the kernel call
out of the macro, ie make it look like
#define CHECK_FOR_INTERRUPTS() \
do { \
if (UNBLOCKED_SIGNAL_QUEUE()) \
pgwin32_check_queued_signals(); \
if (InterruptPending) \
ProcessInterrupts(); \
} while(0)
>
> Also, I have a small style question - why use a nested if instead of
> just saying
>
> if (UNBLOCKED_SIGNAL_QUEUE() &&
> WaitForSingleObjectEx(pgwin32_signal_event,0,TRUE) == WAIT_OBJECT_0)
>
Yeah, this works but IMHO that style states things clearer,
Regards,
Qingqing
--
> QQ: Can you fix the patch? I'm done till Monday.
>
Sure, thanks for testing it. Below is the revised version.
Regards,
Qingqing
---
Index: backend/port/win32/signal.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/port/win3
On Fri, 2005-10-21 at 09:52 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > It would be good right now to have a multi-process test harness that
> > would allow us to test out different spin lock code without the rest of
> > PostgreSQL getting in the way of testing. If we can i
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> Was that with the volatile attribute or not?
I doubt volatile would make any visible performance difference --- the
CHECK_FOR_INTERRUPTS calls that are performance-critical are in places
where the compiler couldn't try to optimize away the fetches an
>
> Wow, that's just great!
>
> Was that with the volatile attribute or not?
>
> //Magnus
not. However (I'm assuming) this should not greatly impact things.
Good work. QQ: Can you fix the patch? I'm done till Monday.
Merlin
---(end of broadcast)-
On Fri, 21 Oct 2005, Merlin Moncure wrote:
> > "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > Hm, what were the tests exactly? Offhand I'd expect something like a
> > SELECT COUNT(*) on a large but not-too-wide table to show noticeable
> > improvement.
> >
> > regards, tom
> > Hm, what were the tests exactly? Offhand I'd expect
> something like a
> > SELECT COUNT(*) on a large but not-too-wide table to show
> noticeable
> > improvement.
> >
> > regards, tom lane
> I STAND CORRECTED! My tests were high volume record by
> record iterators, e
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> I STAND CORRECTED! My tests were high volume record by record
> iterators, etc. Read and drool, gentlemen.
Looks good to me ;-) ...
If I recall the bidding correctly, the original patch needs DLLIMPORT
qualifiers attached to both of the variables,
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> Hm, what were the tests exactly? Offhand I'd expect something like a
> SELECT COUNT(*) on a large but not-too-wide table to show noticeable
> improvement.
>
> regards, tom lane
I STAND CORRECTED! My tests were high volume rec
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
>> Will have performance #s up in a bit.
> I have a couple of cpu-bound performance tests that I just ran with and
> without the patch. Everything is ran with n=1 until volatile issue is
> sorted out but so far I am not seeing any performance
> improve
On Fri, 21 Oct 2005, Magnus Hagander wrote:
> > > Shall we add "volatile" quanlifier to at least pg_signal_queue?
> >
> > If that's changed by a separate thread, "volatile" seems essential.
> > What about the mask variable?
>
> Yes, that does seem right. Previously it would never be concurrently
> > > I can't get the postgres to link with the patch...
> > > Am I missing something?
> > > Merlin
> > >
> > False alarm. I had to rerun configure which copies win32.h in
various
> > places, as Qingqing noted.
> >
> Not false alarm :) Only with DLLIMPORT can I link all the libraries.
> Will have
> > Shall we add "volatile" quanlifier to at least pg_signal_queue?
>
> If that's changed by a separate thread, "volatile" seems essential.
> What about the mask variable?
Yes, that does seem right. Previously it would never be concurrently
modified, because it was always locked by the critical s
Qingqing Zhou wrote:
"Tom Lane" <[EMAIL PROTECTED]> wrote
... so definitely worth fixing for 8.1 if we can convince ourselves
it's correct.
Despite the performance, there is one thing I am not exactly sure. Shall we
add "volatile" quanlifier to at least pg_signal_queue? The danger
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> Shall we add "volatile" quanlifier to at least pg_signal_queue?
If that's changed by a separate thread, "volatile" seems essential.
What about the mask variable?
regards, tom lane
---(end of broadcast)-
> > I can't get the postgres to link with the patch...
> > Am I missing something?
> > Merlin
> >
> False alarm. I had to rerun configure which copies win32.h in various
> places, as Qingqing noted.
>
Not false alarm :) Only with DLLIMPORT can I link all the libraries.
Will have performance #s u
> I can't get the postgres to link with the patch...
> Am I missing something?
> Merlin
>
False alarm. I had to rerun configure which copies win32.h in various
places, as Qingqing noted.
Merlin
---(end of broadcast)---
TIP 6: explain analyze is yo
"Tom Lane" <[EMAIL PROTECTED]> wrote
>
> ... so definitely worth fixing for 8.1 if we can convince ourselves
> it's correct.
>
Despite the performance, there is one thing I am not exactly sure. Shall we
add "volatile" quanlifier to at least pg_signal_queue? The dangerous place
is PGSemaphoreLoc
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> I can't get the postgres to link with the patch...
> Am I missing something?
Probably those variables need "extern DLLIMPORT".
regards, tom lane
---(end of broadcast)---
TIP 1:
I can't get the postgres to link with the patch...
Am I missing something?
Merlin
Info: resolving _pg_signal_mask by linking to __imp__pg_signal_mask
(auto-import)
Info: resolving _pg_signal_queue by linking to __imp__pg_signal_queue
(auto-import)
fu01.o(.idata$3+0xc): undefined reference to
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> Do you have any numbers on how much performance increases with it?
A rough estimate is that it would cost more than half as much as EXPLAIN
ANALYZE does: that imposes two extra syscalls per ExecProcNode, while
this adds one. There are other high-fre
> > This patch improves the win32 CHECK_FOR_INTERRUPTS() performance by
> > testing if any unblocked signals are queued before check
> > pgwin32_signal_event. This avoids an unnecessary system call.
>
> http://archives.postgresql.org/pgsql-patches/2005-10/msg00191.php
>
> This looks to me like
Qingqing Zhou <[EMAIL PROTECTED]> writes:
> This patch improves the win32 CHECK_FOR_INTERRUPTS() performance by
> testing if any unblocked signals are queued before check
> pgwin32_signal_event. This avoids an unnecessary system call.
http://archives.postgresql.org/pgsql-patches/2005-10/msg00191.p
Other than Windows I guess. Sometimes the system call restart behaviour
is annoying, but you can work around that using sigaction. But can that
be relied apon?
Thanks in advance,
--
Martijn van Oosterhout http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A
Remember the suggestion I made that PostgreSQL add the capability
to define named caches and bind specific objects to those caches?
One of the reasons Sybase recommends using such named caches
(per their performance tuning documentation) is to reduce spinlock
contention.
I don't know whether Postg
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Szima Gábor wrote:
>> At system crash or poweroff the autovacuum statistics will be lost,
> I don't remember why it was that we made the stat file be dropped on
> crash recovery, but there was a reason.
The fact that it's not WAL-backed and hence could
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Tom, I also notice that the link I put in ages ago to Kornacker's thesis
> is now defunct :(
> A quick search of Google Scholar finds it hosted on Oleg & Teodor's site.
Fixed, thanks.
regards, tom lane
---
Simon Riggs <[EMAIL PROTECTED]> writes:
> It would be good right now to have a multi-process test harness that
> would allow us to test out different spin lock code without the rest of
> PostgreSQL getting in the way of testing. If we can isolate the issue
> outside of PostgreSQL it will be much ea
Szima Gábor wrote:
> At system crash or poweroff the autovacuum statistics will be lost,
> because this statistics only stored in RAM and saved/restored at
> service shutdown/startup.
> I think it should be saved periodically and not to be deleted after
> crash.
I don't remember why it was that w
On Fri, Oct 21, 2005 at 08:48:31AM -0400, [EMAIL PROTECTED] wrote:
> Which other ones? I can't think of one. The ones that don't handle
> SIGINT, or that are not designed for this scenario certainly don't count -
> as that is how psql works right now without the patch. Of the remaining
> programs t
I wonder how widespread the MicroSoft behavior is Sybase ASE,
for example, gives this result set:
30 5 30 5
That seems more appropriate to me.
-Kevin
> "Dann Corbit" <[EMAIL PROTECTED]> writes:
> > I guess that additional ambiguity arises if you add addit
"Dann Corbit" <[EMAIL PROTECTED]> wrote on 10/20/2005 04:24:26 PM:
> > -Original Message-
> > From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, October 20, 2005 2:12 PM
> > To: Tom Lane
> > Cc: Chris Travers; Dann Corbit; Greg Stark; josh@agliodbs.com; pgsql-
> > [E
[Removed all the non-list addresses]
Dann Corbit wrote:
Let me make something clear:
When we are talking about padding here it is only in the context of a
comparison operator and NOT having anything to do with storage.
Given two strings of different in a comparison, most database systems
(by d
I will happily reiterate that I am the troll who started this mess by
whining about how *Oracle* handles this. Tom's explanation that CHAR is
has a PAD collation and VARCHAR has a NO PAD collation have restored my
faith that there is goodness in the world. My whining was out of
ignorance. I woul
On Fri, Oct 21, 2005 at 01:53:32PM +0200, Martijn van Oosterhout wrote:
> On Thu, Oct 20, 2005 at 08:11:14PM -0400, [EMAIL PROTECTED] wrote:
> > I disagree that psql should make *any* assumptions about what SIGINT
> > means to the child process. Consider less again, and Control-C used
> > to abort
Title: RES: [HACKERS] Key violation. ERROR: type "lo" does not exist.
I do not know. How I make this? How I verify if this installed?
At.
Fernando C. Figueiredo
CRC Vivo - Goiânia
Fone: (62) 3238-3441 / 9978-9857
-Mensagem original-
De: Douglas McNaught [mailto:[EMAIL PROTECT
Richard Huxton wrote:
Dann Corbit wrote:
I can see plenty of harm and absolutely no return. We are talking about
blank padding before comparison. Do you really want 'Danniel '
considered distinct from 'Danniel ' in a comparison? In real life,
what does that buy you?
100% YES!
If two va
At 05:33 PM 10/19/2005 -0700, Dann Corbit wrote:
If there is a significant performance benefit to not expanding text
columns in comparison operations, then it seems it should be OK.
I probably read the standard wrong, but it seems to me that varchar, char,
and bpchar columns should all behave
Tom Lane <[EMAIL PROTECTED]> wrote on 10/20/2005 03:11:23 PM:
> The hard part would be in figuring out how
> the output routine could know how many spaces to add back.
The length is in the metadata for the column, or am I being dense?
>
> regards, tom lane
--
On Thu, 2005-10-20 at 16:54 -0600, Robert Creager wrote:
> On Thu, 20 Oct 2005 23:28:21 +0100
> Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> > If the CS is the same, then it will tell us that the issue is not data
> > dependent. If the CS drops, it tells us that it is an activity performed
> > on t
On Thu, Oct 20, 2005 at 08:11:14PM -0400, [EMAIL PROTECTED] wrote:
> I disagree that psql should make *any* assumptions about what SIGINT
> means to the child process. Consider less again, and Control-C used
> to abort a search. You are suggesting that Control-C should not only
> abort the search,
Dann Corbit wrote:
>> -Original Message-
>> From: Tom Lane [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, October 20, 2005 2:54 PM
>> To: Dann Corbit
>> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; pgsql-
>> [EMAIL PROTECTED] Subject: Re: [GENERAL] [HACKERS] 'a' == 'a '
>>
>> "Dann Corbit" <[EM
> > I'm not actually particularly worried about the startup
> time. What's
> > bothering me right at the moment, given the new-found knowledge that
> > strftime() is slow on Linux, is that we're using it in
> elog(). At the
> > time that code was written, we did it deliberately to
> ensure t
56 matches
Mail list logo
