On Dec 8, 2008, at 2:46 AM, Tom Lane wrote:
Comments?
+1
If this is agreed to be a bug, should we consider
back-patching it? (I'd vote not, I think, because the behavioral
change could conceivably break some apps that work now.)
+1
Best,
David
--
Sent via pgsql-hackers mailing list
I've been looking at the signal handling part of the synchronous
replication patch. It looks OK, but one thing makes me worry.
To set or clear the flag from PGPROC, to send or handle a signal, we
have to acquire ProcArrayLock. Is that safe to do in a signal handler?
And is the performance
This came up on irc:
postgres=# show lc_ctype;
lc_ctype
-
fr_FR.UTF-8
postgres=# show server_encoding;
server_encoding
-
UTF8
(1 row)
postgres=# select E'\303\201' ILIKE E'\303\241';
?column?
--
t
(1 row)
postgres=# select E'\303\201' ~*
Does this signal multiplexing solve the out of signals problem we
have generally? I need another signal for the progress indicator too.
Or is this only useful for other users which need the same locks or
other resources?
--
Greg
On 8 Dec 2008, at 08:04, Heikki Linnakangas [EMAIL
Greg Stark wrote:
Does this signal multiplexing solve the out of signals problem we have
generally?
It's a general solution, but it relies on flags in PGPROC, so it'll only
work for backends and auxiliary processes that have a PGPROC entry.
--
Heikki Linnakangas
EnterpriseDB
How would it break any apps? They would hve to be depending on passing
arrays as anynonarray? That seems unlikely.
On the other hand I don't see much reason to backpatch. It's not like
anyone is going to run into this problem unexpectedly on a running
system. It just doesn't seem like a
Heikki Linnakangas [EMAIL PROTECTED] writes:
To set or clear the flag from PGPROC, to send or handle a signal, we
have to acquire ProcArrayLock. Is that safe to do in a signal handler?
No. If it's trying to do that then it's broken. In fact, if it's
trying to do much of anything beyond
Andrew Gierth [EMAIL PROTECTED] writes:
Obviously, this happens because the locale support functions in
backend/regex/regc_locale.c are (presumably intentionally) crippled so
as not to support non-ascii chars, despite all the code there using
wide chars for everything otherwise.
It's not so
Martijn van Oosterhout [EMAIL PROTECTED] writes:
On Mon, Dec 08, 2008 at 01:12:39PM +0200, Heikki Linnakangas wrote:
BTW, on what platforms signal doesn't interrupt sleep?
In theory, none.
In practice, they exist. In particular I can demonstrate the issue
on HPUX 10.20. I also dispute your
Hello,
I did small tests and I found so for small tables (less 1000 rows)
VACUUM based on visibility maps are slower than old implementation
it is about 5ms X 20ms
Regards
Pavel Stehule
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Pavel Stehule [EMAIL PROTECTED] writes:
Hello,
I did small tests and I found so for small tables (less 1000 rows)
VACUUM based on visibility maps are slower than old implementation
it is about 5ms X 20ms
Hm, Presumably this is on a machine where the visibility map is entirely in
cache too.
On Sun, Dec 7, 2008 at 10:17 PM, Robert Haas [EMAIL PROTECTED] wrote:
On Sun, Dec 7, 2008 at 7:57 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
Dmitry Koterov wrote:
Could you please say, if ALTER TYPE ... ADD COLUMN is planned for a future
PostgreSQL version?
It is not currently on the TODO
On Mon, Dec 8, 2008 at 11:33 AM, Pavan Deolasee [EMAIL PROTECTED]wrote:
On Sat, Dec 6, 2008 at 8:08 PM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
If you see a straightforward way, please submit a patch!
Will do that.
Here is a patch which implements this. The PD_ALL_VISIBLE flag
Merlin Moncure wrote:
On Sun, Dec 7, 2008 at 10:17 PM, Robert Haas [EMAIL PROTECTED] wrote:
On Sun, Dec 7, 2008 at 7:57 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
Dmitry Koterov wrote:
Could you please say, if ALTER TYPE ... ADD COLUMN is planned for a future
PostgreSQL
In walsender, in the main loop that waits for backend requests to send
WAL, there's this comment:
+ /*
+* Nap for the configured time or until a request arrives.
+*
+* On some platforms, signals won't interrupt the sleep. To
Greg Stark [EMAIL PROTECTED] writes:
How would it break any apps?
Well, this would change the set of possible matches for ambiguous
function calls. So it's not out of the question that you could get
ambiguous-function failures that didn't happen before.
regards, tom
On Mon, Dec 08, 2008 at 01:12:39PM +0200, Heikki Linnakangas wrote:
If a signal is received just before pq_wait call, after checking
replication_requested, pq_wait won't be interrupted and will wait up to
a second before responding to it.
BTW, on what platforms signal doesn't interrupt
I haven't testsed, but it looks to me that the recovery.conf reading
patch doesn't work in EXEC_BACKEND mode (= Windows). You'll need to add
recoveryRestoreCommand to save/read_backend_parameters in postmaster.c.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via
On Sat, 2008-12-06 at 17:55 +0900, Fujii Masao wrote:
Yeah, it's my imagination about the real situation after 8.4 release,
especially I considered about the future conjugal life of Synch Rep and
Hot Standby ;) Waiting to redo until the file fills might lead to marital
breakdown.
You're
On Mon, Dec 8, 2008 at 8:01 AM, Andrew Dunstan [EMAIL PROTECTED] wrote:
Merlin Moncure wrote:
Well, new features that have a perfectly acceptable and usable
workaround typically have a fairly low priority of fixing :-)
Since tables are basically types, I'm not sure what the difference is
On Mon, 2008-12-08 at 10:04 +0200, Heikki Linnakangas wrote:
And is the performance impact of that acceptable?
No, but I think we already agreed to change that to a separate lwlock.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via
Pavel Stehule wrote:
I did small tests and I found so for small tables (less 1000 rows)
VACUUM based on visibility maps are slower than old implementation
it is about 5ms X 20ms
How did you measure that?
I tried to reproduce that here, and indeed it seems to be much slower on
CVS HEAD than
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
To set or clear the flag from PGPROC, to send or handle a signal, we
have to acquire ProcArrayLock. Is that safe to do in a signal handler?
No. If it's trying to do that then it's broken. In fact, if it's
trying to do much of
On Mon, 2008-12-08 at 12:01 +0200, Heikki Linnakangas wrote:
I haven't testsed, but it looks to me that the recovery.conf reading
patch doesn't work in EXEC_BACKEND mode (= Windows). You'll need to add
recoveryRestoreCommand to save/read_backend_parameters in postmaster.c.
That comment has
To be honest, for me back patching would mean only that I don't have
to recompile, and resend binaries to clients, after 8.1-8.3 upgrade
(to utilize enums, and domains).
I don't think it would break any apps tho.
so in my case, obviously +1 +1 :)
--
Sent via pgsql-hackers mailing list
Well, new features that have a perfectly acceptable and usable
workaround typically have a fairly low priority of fixing :-)
Putting something in the TODO list doesn't make it a priority. But it
indicates that it's something that the community would like to see
fixed, if anyone is interested
Heikki Linnakangas escribió:
Oprofile suggests that most of the time is actually spent in
pgstat_vacuum_stat. And more precisely in pstat_collect_oids, which is
called by pgstat_vacuum_stat.
Hmm, that routine is expensive. Calling it for every vacuum is not good
:-( Fortunately,
Heikki Linnakangas [EMAIL PROTECTED] writes:
Oprofile suggests that most of the time is actually spent in
pgstat_vacuum_stat. And more precisely in pstat_collect_oids, which is
called by pgstat_vacuum_stat.
We added support for tracking call counts and elapsed runtime of
user-defined
Alvaro Herrera [EMAIL PROTECTED] writes:
In the end, it would be better if this function was not called at all
for user-invoked vacuum, and have autovacuum handle it. However, that
doesn't work for people who disable autovacuum.
A possible variant on that is to invoke it only in database-wide
Dear all,
On Mon, 8 Dec 2008, Heikki Linnakangas wrote:
Date: Mon, 08 Dec 2008 09:17:52 +0200
From: Heikki Linnakangas [EMAIL PROTECTED]
To: Tom Lane [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], Zdenek Kotala [EMAIL PROTECTED],
pgsql-hackers list pgsql-hackers@postgresql.org
Subject: Re:
Andrew Dunstan wrote:
Andrew Chernow wrote:
I think what is missing is a way to deny the execution of queries that
don't operate on an object (like a table, sequence, role, schema,
etc...), OR queries not covered by the priv system. Object-based
queries can be locked down using the
I wrote:
... In particular we should at least try to bypass the pg_proc scan when
there are *no* function stats records.
That idea, at least, looks to be trivial to implement; so I'll go do so.
regards, tom lane
--
Sent via pgsql-hackers mailing list
2008/12/8 Heikki Linnakangas [EMAIL PROTECTED]:
Pavel Stehule wrote:
I did small tests and I found so for small tables (less 1000 rows)
VACUUM based on visibility maps are slower than old implementation
it is about 5ms X 20ms
How did you measure that?
it's simple test
create table x(a
Pavel Stehule [EMAIL PROTECTED] writes:
2008/12/8 Heikki Linnakangas [EMAIL PROTECTED]:
How did you measure that?
it's simple test
create table x(a integer, b integer);
insert into x select i, i from generate_series(1,1000) g(i);
and then vacuum on 8.3.5 and vacuum on current CVS HEAD.
KaiGai Kohei [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
I assume that could just be always enabled.
It is not always enabled. When we build it with SE-PostgreSQL feature,
rest of enhanced security features (includes the row-level ACL) are
disabled automatically, as we discussed before.
[ a bit off-topic for the thread, but ... ]
Kevin Grittner [EMAIL PROTECTED] writes:
I'll attach the query and plan. You'll note that the query looks a
little odd, especially all the (1=1) tests.
FWIW, it would be better to use TRUE as a placeholder in your
generated queries. I don't suppose
Gregory Stark [EMAIL PROTECTED] writes:
But I can also see Tom's reluctance. It's a fair increase in the amount of
code to maintain in that file for a pretty narrow use case. On the other hand
it looks like it would be all in that file. The planner wouldn't have to do
anything special to set
Greg Stark [EMAIL PROTECTED] writes:
That might only be the case when the pg_statistic record is in shared
buffers.
Yeah, it seems unlikely that disabling compression is a good idea in the
bigger scheme of things.
Also I wonder if eqjoinsel and company might need to be made more
On Mon, Dec 8, 2008 at 11:56 AM, Tom Lane [EMAIL PROTECTED] wrote:
Greg Stark [EMAIL PROTECTED] writes:
That might only be the case when the pg_statistic record is in shared
buffers.
Yeah, it seems unlikely that disabling compression is a good idea in the
bigger scheme of things.
Is there
On Nov 30, 2008, at 12:04 PM, David E. Wheeler wrote:
Agreed, default values should not be a part of function signatures,
although it might be nice if ALTER FUNCTION to allow default values
to be changed.
It would be VERY nice. I routinely cut and paste an entire function
header to later
On Dec 5, 2008, at 7:50 PM, Andrew Gierth wrote:
While waiting for a large restore to complete (and investigating why
parts of it were so slow), I came across this scenario. This isn't
quite the same as some previous discussion of hint bits, but I thought
it was something that could probably be
Tom == Tom Lane [EMAIL PROTECTED] writes:
Andrew Gierth [EMAIL PROTECTED] writes:
Obviously, this happens because the locale support functions in
backend/regex/regc_locale.c are (presumably intentionally)
crippled so as not to support non-ascii chars, despite all the
code there using
[EMAIL PROTECTED] writes:
the infinite loop occurs in fsm_search_avail when called for the 32nd
time.
... which is the first time that the initial test doesn't make it fall
out immediately.
Would you add a couple more printouts, along the line of
nodeno = target;
while
Tom Lane wrote:
KaiGai Kohei [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
I assume that could just be always enabled.
It is not always enabled. When we build it with SE-PostgreSQL feature,
rest of enhanced security features (includes the row-level ACL) are
disabled automatically, as we
It's strange, when I repeat tests, I get usually times about 10 ms,
but cca cca every 5 test it is about 2ms
postgres=# VACUUM x;
VACUUM
Time: 12,093 ms
postgres=# VACUUM x;
VACUUM
Time: 1,928 ms
postgres=# VACUUM x;
VACUUM
Time: 10,743 ms
postgres=# VACUUM x;
VACUUM
Time: 1,927 ms
postgres=#
Josh Williams wrote:
Hi folks,
Was recently poked and reminded that this patch may be of interest to
the community. It was mostly done as an academic exercise, just to see
how it works, and so it has a rather hackish feel. The patch adds the
sequence owner, if available, to psql's \d
On Tue, 2008-12-09 at 03:33 +0900, KaiGai Kohei wrote:
Tom Lane wrote:
KaiGai Kohei [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
I assume that could just be always enabled.
It is not always enabled. When we build it with SE-PostgreSQL feature,
rest of enhanced security features
Pavel Stehule [EMAIL PROTECTED] writes:
It's strange, when I repeat tests, I get usually times about 10 ms,
but cca cca every 5 test it is about 2ms
Hmm. The theory I'd developed for what I see here is that the slow
timings correspond to when the pgstat code decides it needs a new stats
file
[ still catching up on back email ]
[EMAIL PROTECTED] (Magnus Hagander) writes:
Properly unregister OpenSSL callbacks when libpq is done with
it's connection. This is required for applications that unload
the libpq library (such as PHP) in which case we'd otherwise
have pointers to these
Tom Lane wrote:
[ still catching up on back email ]
[EMAIL PROTECTED] (Magnus Hagander) writes:
Properly unregister OpenSSL callbacks when libpq is done with
it's connection. This is required for applications that unload
the libpq library (such as PHP) in which case we'd otherwise
have
Hello,
I've been bit by this about a million times:
select (func()).* executes the function once per each field in the
returned tuple. See the example below:
create function foo_func() returns foo as
$$
declare f foo;
begin
raise notice '!';
return f;
end;
$$ language plpgsql;
On Tue, Dec 2, 2008 at 2:25 AM, Tom Lane [EMAIL PROTECTED] wrote:
Greg Smith [EMAIL PROTECTED] writes:
... where the Power Test seems to oscillate between degrees of good and bad
behavior seemingly at random.
Are any of the queries complicated enough to trigger GEQO planning?
Is there a
Mark Wong [EMAIL PROTECTED] writes:
On Tue, Dec 2, 2008 at 2:25 AM, Tom Lane [EMAIL PROTECTED] wrote:
Are any of the queries complicated enough to trigger GEQO planning?
Is there a debug option that we could use to see?
Well, you could set geqo=off and see if the behavior changes, but
it'd be
Simon Riggs wrote:
On Tue, 2008-12-09 at 03:33 +0900, KaiGai Kohei wrote:
Tom Lane wrote:
KaiGai Kohei [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
I assume that could just be always enabled.
It is not always enabled. When we build it with SE-PostgreSQL feature,
rest of enhanced security
Hi,
On Mon, Dec 8, 2008 at 2:54 PM, Koichi Suzuki [EMAIL PROTECTED] wrote:
I understood your point. In the case of synchronous replication,
because slave fails over when master crashes, there're no need to
leave FPW from the beginning.
In this case, only prefetch will work. Fujii's code
OK, after quite some trying I have hit a brick wall. I have been unable
to get parallel restore to work with Windows threading. No doubt I am
missing something, but I really don't know what. Unless someone can tell
me what I am doing wrong, I have these possibilities:
* run parallel
Andrew Dunstan wrote:
OK, after quite some trying I have hit a brick wall. I have been unable
to get parallel restore to work with Windows threading. No doubt I am
missing something, but I really don't know what. Unless someone can tell
me what I am doing wrong, I have these possibilities:
Hi,
On Mon, Dec 8, 2008 at 10:36 PM, Tom Lane [EMAIL PROTECTED] wrote:
Martijn van Oosterhout [EMAIL PROTECTED] writes:
On Mon, Dec 08, 2008 at 01:12:39PM +0200, Heikki Linnakangas wrote:
BTW, on what platforms signal doesn't interrupt sleep?
In theory, none.
In practice, they exist. In
Andrew Chernow wrote:
Andrew Dunstan wrote:
OK, after quite some trying I have hit a brick wall. I have been
unable to get parallel restore to work with Windows threading. No
doubt I am missing something, but I really don't know what. Unless
someone can tell me what I am doing wrong, I
HANDLE h = (HANDLE)_beginthreadex(NULL, 0, thread_start, arg, 0, NULL);
This didn't give me any more joy, unfortunately. But you're right, I
should be using it.
Are these threads sharing memory, intentionally or by mistake?
if(h)
CloseHandle(h);
Umm, even if I wait on the handle
Andrew Chernow wrote:
HANDLE h = (HANDLE)_beginthreadex(NULL, 0, thread_start, arg, 0, NULL);
This didn't give me any more joy, unfortunately. But you're right, I
should be using it.
Are these threads sharing memory, intentionally or by mistake?
Things they write, and things they
Andrew Dunstan wrote:
Andrew Chernow wrote:
HANDLE h = (HANDLE)_beginthreadex(NULL, 0, thread_start, arg, 0, NULL);
This didn't give me any more joy, unfortunately. But you're right, I
should be using it.
Are these threads sharing memory, intentionally or by mistake?
Things they
Are these threads sharing memory, intentionally or by mistake?
Things they write, and things they read but might not be stable, are
not supposed to be shared. If they are it's a mistake.
Looks like the ArchiveHandle variable 'AH' and the TocEntry
'next_work_item' are not being deep
Hi,
I saw a report at .br mailing list [1] complaining about the message's title.
I do not try to investigate it. Am I missing something?
euler=# select attname from pg_attribute where attnum 0 and attnum
ALL(select conkey from pg_constraint where conrelid = attrelid and contype =
'p');
Hi,
On Mon, Dec 8, 2008 at 11:39 PM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
To set or clear the flag from PGPROC, to send or handle a signal, we have
to acquire ProcArrayLock. Is that safe to do in a signal handler?
No. If
Alex Hunsaker [EMAIL PROTECTED] wrote:
I was assigned to review this.
Thanks for your reviewing.
I assume that the basic concepts are ok and focus of discussion is in:
- New counters in struct Instrumentation.
(buffer usage and CPU usage)
- Should EXPLAIN ANALYZE show those counters.
Vladimir Sitnikov [EMAIL PROTECTED] wrote:
2. EXPLAIN ANALYZE VERBOSE shows buffer statistics in 'actual' section.
I do not get the point of VERBOSE.
As far as I understand, explain analyze (without verbose) will anyway add
overhead for calculation of gets/hits/cpu. Why discard that
2. EXPLAIN ANALYZE VERBOSE shows buffer statistics in 'actual' section.
I do not get the point of VERBOSE.
As far as I understand, explain analyze (without verbose) will anyway add
overhead for calculation of gets/hits/cpu. Why discard that information
in
non verbose mode? Just to
68 matches
Mail list logo
