-- Crossposting to pgsql-hackers --
Jan Wieck wrote:
For the record,
Slony-I uses a pg_listener entry as a locking mechanism to prevent
multiple concurrent slon processes serving the same node. The function
Async_Unlisten() is used in a backend function that is called during
slon startup
Sean Utt wrote:
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 :quitEnter 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
On 22/10/05 3:45 am, Tom Lane [EMAIL PROTECTED] wrote:
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
I just found this Forum thread on nabble.com, very nice what you are talking about. Whithout Nabble i would never got in contact with such interesting stuff, like database development. So far i have only had experi.cese with Access, and some aspects off your discussions are quite hard to
On Fri, Oct 21, 2005 at 06:09:00PM -0400, Tom Lane wrote:
BTW, we may be perfectly safe on architectures like PPC, where
S_UNLOCK includes an __asm__ __volatile__ section for a hardware-level
optimization fence instruction. I wonder though if it'd be a good idea
to be marking those fence
Hi all,
I am new to postgres developement. Want some help.
Can we run nested query in postgres?
Means, can I do like -
When somequery is being executed (say create database) it goes through
exec_simple_query():backend/tcop/postgres.c (if I am not wrong) then can
I call exec_simple_query() from
On Fri, Oct 21, 2005 at 05:28:49PM -0700, Kevin Brown wrote:
When a pager is being used, we check for the flag immediately after
doing a write()/fwrite() to the pipe. If it's set, we pclose(), clear
the flag, and then manually invoke the non-pager signal handler.
SIGINT should cause the
On Sat, Oct 22, 2005 at 03:41:07PM +0530, Paresh Bafna wrote:
Hi all,
I am new to postgres developement. Want some help.
Can we run nested query in postgres?
The answer is yes, although you generally need to use the SPI interface
to do it. Among other things it sets up everything to work
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 exercise
control-C response time.
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
Magnus Hagander wrote:
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 -
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
Magnus Hagander [EMAIL PROTECTED] writes:
I can unfortunatly conform that I'm also seeing this :-( I'm seeing it
in some kind of tight loop in the plpgsql regression test. Either that,
or it's just doing something *really* slowly. Doing some poking at it
with procexp I see it always being
I can unfortunatly conform that I'm also seeing this :-(
I'm seeing it
in some kind of tight loop in the plpgsql regression test. Either
that, or it's just doing something *really* slowly. Doing
some poking
at it with procexp I see it always being somewhere in a callstack
that's
PL/Java has gone through a series of stability improvements over the
last couple of weeks. Now it's time to perhaps improve things even more
but that requires a little help from PostgreSQL itself (nothing related
to threads though ;-) )
PL/Java has various wrapper objects for PostgreSQL
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
I can unfortunatly conform that I'm also seeing this :-( I'm seeing it
in some kind of tight loop in the plpgsql regression test. Either that,
or it's just doing something *really* slowly. Doing some poking at it
with procexp I see
Magnus Hagander [EMAIL PROTECTED] writes:
Agreed. I definitly vote for backing out the patch so we don't block the
release. If we find the problem we put it back in before release, but if
it takes a while we just wait for 8.2.
After digging in the Microsoft documentation a little bit, I think
I've been doing some test imports of UNICODE databases into Postgres
8.1beta3. The only problem I've seen is that some data from 8.0
databases will not import.
I've generated dumps using pg_dump from 8.0 and 8.1. Attempting to
restore these results in
Invalid UNICODE byte sequence detected
On Sat, Oct 22, 2005 at 01:49:16PM +0200, Thomas Hallgren wrote:
PL/Java has gone through a series of stability improvements over the
last couple of weeks. Now it's time to perhaps improve things even more
but that requires a little help from PostgreSQL itself (nothing related
to threads
I wrote:
Isn't there some way we can get the timer completion routine to be run
by the signal thread instead? This coding seems pretty unreliable to me
even without QQ's patch.
After further thought it seems like the right thing to do is to redesign
port/win32/timer.c so that it sets up a
Andrew Dunstan [EMAIL PROTECTED] writes:
I could make the whole dataset available, but tarred and zipped it's
about 300Mb. The reason I used this dataset was that I wanted to see a
test that took many seconds, and Merlin's did not - I wanted to see how
any performance gain scaled.
Well,
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I could make the whole dataset available, but tarred and zipped it's
about 300Mb. The reason I used this dataset was that I wanted to see a
test that took many seconds, and Merlin's did not - I wanted to see how
any performance
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Well, you tried to scale into a domain where the performance is going
to be disk-I/O-limited, so I'm not sure it proves anything.
Good point. I took a 5% random extract from the lineitems table and saw
the expected improvement.
Tom Lane wrote:
After further thought it seems like the right thing to do is to redesign
port/win32/timer.c so that it sets up a separate thread whose
responsibility is to wait for timeouts and deliver a SIGALRM signal back
to the main thread when they happen. It's probably a bit late to
Andrew Dunstan [EMAIL PROTECTED] writes:
The hard part looks to be cancelling/changing the timer, which means
that we can't just create a set and forget listener thread for a given
timeout. Otherwise that seems to me the straightforward approach.
Yeah. I think probably the cleanest way is
On Sun, Oct 16, 2005 at 03:25:49PM +0200, Martijn van Oosterhout wrote:
This behaviour has been around so long that I've gotten used to it but
I've always considered it a bug. Yet it has never been fixed so I'm
going to ask if anybody else has issues with this behaviour.
I've posted a patch to
Martijn van Oosterhout wrote:
On Sat, Oct 22, 2005 at 01:49:16PM +0200, Thomas Hallgren wrote:
PL/Java has gone through a series of stability improvements over the
last couple of weeks. Now it's time to perhaps improve things even more
but that requires a little help from PostgreSQL itself
Hi
I am trying to implement Query Progress estimator in postgres for
queries with long run time.I am looking for info regarding the number of
tuples already processsed by a running query .
I would be very thankful if someone can suggest where can i find it or
the data structure that holds the
Hi
I am trying to implement Query Progress estimator in postgres for
queries with long run time.I am looking for info regarding the number of
tuples already processsed by a running query .
I would be very thankful if someone can suggest where can i find it or
the data structure that holds the
On Sat, Oct 22, 2005 at 09:46:32PM +0200, Martijn van Oosterhout wrote:
I've posted a patch to -patches which fixes all the memory leak and
file descriptor leak issues and well as making psql handle ^C more
gracefully in general. It doesn't address this particular issue though,
thats for
On Sat, Oct 22, 2005 at 10:09:12PM +0200, Thomas Hallgren wrote:
I guess some of my questions originate in lack of knowledge about the
rules you mention. I haven't been able to find documentation that
explains them thoroughly and I haven't been able to fully deduct it from
looking at the
On Sun, Oct 23, 2005 at 02:04:02AM +0530, Anuj Tripathi wrote:
Hi
I am trying to implement Query Progress estimator in postgres for
queries with long run time.I am looking for info regarding the number of
tuples already processsed by a running query .
I would be very thankful if someone can
It won't work properly that way. SIGINT gets sent to all the members
of the process group, not just the child. Psql isn't responsible for
sending ctrl-c through to the child.
Except that if I am in less, and I do CONTROL-C, it doesn't do anything at
all.
It doesn't exit.
If I send a
Martijn,
Thanks a lot. Your insights and pointers will help me a great deal. The
answer to your question where I get HeapTupleHeader's from is that
that's what a call-handler receive when you declare a function that
takes complex parameters.
Kind Regards,
Thomas Hallgren
Andrew Dunstan [EMAIL PROTECTED] writes:
The hard part looks to be cancelling/changing the timer, which means
that we can't just create a set and forget listener thread for a given
timeout. Otherwise that seems to me the straightforward approach.
Yeah. I think probably the cleanest way
Well, first, have you tested it with make check? I am not sure if
there's any great value in supporting a non null old value param.
Second, please note that the PostgreSQL community convention is for
patches as context diffs, not unidiffs.
I guess there are several ways to skin this cat -
On Sat, 22 Oct 2005, Andrew Dunstan wrote:
Well, first, have you tested it with make check? I am not sure if
there's any great value in supporting a non null old value param.
Yeah, I've managed to install in my slow windows box and tested it.
Supporting ovalue is just the by-product. If it
On Fri, Oct 21, 2005 at 05:06:45PM -0700, Kevin Brown 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, but
With the recent changes that have been made, we figured a quick Beta 4
would be wise before the RC ... so, its built, and should be available on
the various mirrors shortly ... I'll do a more general announce tomorrow
...
The hope is that this is the last beta, with an RC1 for this coming
Here is the full patch of the timer implemenation with threading safty
added. Basic test is by several rounds of make check and threading
safty test is by a SQL file with many lines of set statement_timeout =
x. I don't know if there are any corner cases that I should consider, if
any, let me
40 matches
Mail list logo
