One concept is to have a univeral clock that ticks forward (like
every second) and each node orders all their transactions inside the
second-granular tick. Then each commit would be like: {node,
clocksecond, txn#} and each time the clock ticks forward, txn# is
reset to zero. This
On Sun, 2007-02-04 at 14:15 -0500, Tom Lane wrote:
Markus Schiltknecht [EMAIL PROTECTED] writes:
is there a good reason to print the database system is ready message
in StartupXLOG() in xact.c? It has a) nothing to do with xlog and b)
opens a small race condition: the message gets
On Sat, 2007-02-03 at 15:51 -0800, Jeremy Drake wrote:
I am writing a set returning function in C. There are cases where I can
know definitively, upfront, that this function will only return one row.
I have noticed, through happenstance of partially converted function, that
I can mark a
On Sat, 2007-02-03 at 22:11 -0500, Bruce Momjian wrote:
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
vacuumlazy.c contains a hint Consider compacting this relation but
AFAICT,
there is no indication anywhere how compacting is supposed to be
achieved.
I guess this
Simon Riggs [EMAIL PROTECTED] writes:
My suggestions would be
1. Database system has completed recovery and
2. Database system is ready to accept connections
The second was in fact the wording I had in mind, sorry for not being
clear. As to the first, the question is whether a log message at
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
On Sun, Jan 28, 2007 at 02:05:41PM +0100, Magnus Hagander wrote:
Anyway. We hard-code thread-safety to on for Win32, because win32 is a
threaded platform in general - almost everything can be exposed to
threading even if they
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
The consequence will be, though, that psql will accept a syntax for
\copy (query) ... that the corresponding backend command would
reject were we not transforming it. That strikes me as potentially
confusing.
Hi,
I would like to know why the test stats on pgbuildfarm/cardinal fails?
Regards,
Gevik
xml ... ok
test stats... FAILED
test tablespace ... ok
---(end of broadcast)---
TIP 7: You can help
Gevik Babakhani wrote:
Hi,
I would like to know why the test stats on pgbuildfarm/cardinal fails?
Regards,
Gevik
xml ... ok
test stats... FAILED
test tablespace ... ok
If you look in the log it tells you. This looks like pilot error.
Gevik Babakhani [EMAIL PROTECTED] writes:
I would like to know why the test stats on pgbuildfarm/cardinal fails?
Looks like DNS and/or /etc/hosts misconfiguration to me:
== pgsql.10164/src/test/regress/log/postmaster.log
===
LOG: could not resolve localhost:
On Thu, Feb 01, 2007 at 11:57:41PM -0600, Jim Nasby wrote:
Has anyone actually measured the performance overhead of storing
visibility info in indexes? I know the space overhead sounds
daunting, but even if it doubled the size of the index in many cases
that'd still be a huge win over
Bruce Momjian wrote:
Added to TODO:
o Add \# to list command history like \s, but with line numbers
http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php
Humm, this is not what we agreed.
Bruce Momjian [EMAIL PROTECTED] writes:
Martijn van Oosterhout wrote:
It'd be nice if we could do the same for some Unix platofrms like
Linux. The C library uses threads internally, and there's no actual
downside to enabling thread safety there, except removing a few failure
modes.
I was
Douglas McNaught [EMAIL PROTECTED] writes:
Bruce Momjian [EMAIL PROTECTED] writes:
Martijn van Oosterhout wrote:
It'd be nice if we could do the same for some Unix platofrms like
Linux. The C library uses threads internally, and there's no actual
downside to enabling thread safety there,
Douglas McNaught [EMAIL PROTECTED] writes:
It uses threads at least for the POSIX AIO calls--I'm not sure what
else.
On that tangent, is that still true or is it only for older kernels that it's
true? I was under the impression newer kernels implemented the aio interface
but others seem to
On Mon, Jan 29, 2007 at 01:38:02PM +, Gregory Stark wrote:
Instead I suggest we create one type of reentrant node, which memoizes its
output. It would be a kind of on-demand Materialize. It would be paired with a
second node type which would be the only type of node which can invoke it.
Martijn van Oosterhout kleptog@svana.org writes:
However, I don't know it matters. You only need to cost the plan if
there are alternate paths and given the plan structure is strongly
constrained, I'm not sure how much it matters.
It does, since the whole thing could be a subquery, in which
Heikki Linnakangas wrote:
Bruce Momjian wrote:
Heikki, did this code cleanup get included in your recent btree split
fix?
No.
OK, would you please send a patch to remove the unused code. Thanks.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+
On Sat, 3 Feb 2007, Simon Riggs wrote:
There are issues, yes. Dropping PKs is a very irregular occurrence nor
is it likely to be part of a complex transaction. It wouldn't bother me
to say that if a transaction already holds a RowExclusiveLock or a
RowShareLock it cannot upgrade to an
Patch already applied by Tom. Removed from queue.
---
Simon Riggs wrote:
On Tue, 2006-12-05 at 17:26 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2006-12-05 at 16:24 -0500, Tom Lane wrote:
On Mon, Feb 05, 2007 at 11:09:06AM -0500, Tom Lane wrote:
I think the real point is that you get the same C library whether you
ask for thread safety or not, and it does internal locking to protect
itself against multi threads anyway. So arguably there's no point in
building a thread-unsafe
Martijn van Oosterhout kleptog@svana.org writes:
That's true, but I think it would be worthwhile to invert the switch to
be --disable-thread-safety, since the number of people who don't
understand the problem far outweigh the cost of the switch.
I'd vote against that unless it were done only
Alvaro Herrera wrote:
Bruce Momjian wrote:
Added to TODO:
o Add \# to list command history like \s, but with line numbers
http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php
Humm, this is not what we agreed.
Actually to be fair, there was no agreement.
On Fri, 2007-02-02 at 15:11 -0500, Tom Lane wrote:
2. Fix TOAST_TUPLE_THRESHOLD and TOAST_TUPLE_TARGET to be correctly
calculated (properly allowing for line pointers) and to be MAXALIGN
multiples. The threshold value should be exactly the size of the
largest tuple that you can put four of
Alvaro Herrera wrote:
Bruce Momjian wrote:
Added to TODO:
o Add \# to list command history like \s, but with line numbers
http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php
Humm, this is not what we agreed.
Are you saying the URL is wrong or the
Joshua D. Drake wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Added to TODO:
o Add \# to list command history like \s, but with line numbers
http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php
Humm, this is not what we agreed.
Actually to be
Simon Riggs [EMAIL PROTECTED] writes:
Sounds like a good time to suggest making these values configurable,
within certain reasonable bounds to avoid bad behaviour.
Actually, given what we've just learned --- namely that choosing these
values at random is a bad idea --- I'd want to see a whole
On Sun, 2007-02-04 at 09:38 +, Simon Riggs wrote:
The TODO I was requesting you consider was this:
Develop non-conflicting locking scheme to allow RI checks to co-exist
peacefully with non-PK UPDATEs on the referenced table.
That is, IMHO, a general statement of an important
Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Added to TODO:
o Add \# to list command history like \s, but with line numbers
http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php
Humm, this is not what we agreed.
Are
Simon Riggs wrote:
On Sat, 2007-02-03 at 22:11 -0500, Bruce Momjian wrote:
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
vacuumlazy.c contains a hint Consider compacting this relation but
AFAICT,
there is no indication anywhere how compacting is supposed to be
Alvaro Herrera wrote:
Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Added to TODO:
o Add \# to list command history like \s, but with line numbers
http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php
Humm,
I am not going to be spending my time on it and I doubt anyone else will.
Really, I thought there were a number of people who liked it. New text
is:
o Add \# to list and execute command history
Are you sure you want it removed?
Well let me put it this way. I think my idea
Joshua D. Drake wrote:
I am not going to be spending my time on it and I doubt anyone else will.
Really, I thought there were a number of people who liked it. New text
is:
o Add \# to list and execute command history
Are you sure you want it removed?
Well let me
Jim Nasby wrote:
There was also mention of having a means to tell pg_dump not to dump
extensions...
What's the use case for that? What will we do if there are db objects
that depend on some extensions? Given that there will be some uninstall
support, this one seems less necessary.
I
On Mon, 2007-02-05 at 11:52 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Sounds like a good time to suggest making these values configurable,
within certain reasonable bounds to avoid bad behaviour.
Actually, given what we've just learned --- namely that choosing these
On Mon, Feb 05, 2007 at 11:34:23AM -0500, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
That's true, but I think it would be worthwhile to invert the switch to
be --disable-thread-safety, since the number of people who don't
understand the problem far outweigh the cost of
On Mon, Feb 05, 2007 at 12:19:51PM -0500, Andrew Dunstan wrote:
Jim Nasby wrote:
There was also mention of having a means to tell pg_dump not to dump
extensions...
What's the use case for that? What will we do if there are db objects
that depend on some extensions? Given that there will
Martijn van Oosterhout wrote:
On Mon, Feb 05, 2007 at 12:19:51PM -0500, Andrew Dunstan wrote:
Jim Nasby wrote:
There was also mention of having a means to tell pg_dump not to dump
extensions...
What's the use case for that? What will we do if there are db objects
that depend on
Martijn van Oosterhout wrote:
On Mon, Feb 05, 2007 at 11:34:23AM -0500, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
That's true, but I think it would be worthwhile to invert the switch to
be --disable-thread-safety, since the number of people who don't
understand the
On 2/5/07, Andrew Dunstan [EMAIL PROTECTED] wrote:
[...]
I would suggest we start with what is (I think) simplest and clearest:
. catalog support via a simple extension-schema(s) map
. initdb installs standard extensions if it finds them, unless told not to
. support for adjusting search path.
On Jan 26, 2:38 pm, [EMAIL PROTECTED] (Tom Lane) wrote:
Rick Gigger [EMAIL PROTECTED] writes:
I thought that the following todo item just barely missed 8.2:
Allow a warm standby system to also allow read-only statements [pitr]
No, it's a someday-wishlist item; the work involved is not
Simon Riggs wrote:
It occurs to me that if we had visibility in unique indexes, this would
allow the index rows to be separately lockable to the main row. That's
exactly what we need here.
I've implemented a work-around using this principle, utilising RULEs and
a duplicated PK
Magnus Hagander wrote:
Bruce Momjian wrote:
Log Message:
---
Add documentation for Windows on how to set an environment variable.
Backpatch to 8.2.X.
Modified Files:
--
pgsql/doc/src/sgml:
libpq.sgml (r1.224 - r1.225)
Magnus Hagander wrote:
have this about PQfreemem():
Frees memory allocated by applicationlibpq/, particularly
functionPQescapeByteaConn/function,
functionPQescapeBytea/function,
functionPQunescapeBytea/function,
and functionPQnotifies/function.
It is needed by Microsoft
Bruce Momjian wrote:
OK, text trimmed down to a hint:
Environment variables on Windows are set as a property of literalMy
Computer/.
Bottom line: do we really want to document for people how to use
Windows? I don't see us documenting how to set an environment variable
in Unix... And
On Sun, Feb 04, 2007 at 01:36:03PM -0500, Jan Wieck wrote:
For the fourth time, the clock is in the mix to allow to continue during
a network outage. All your arguments seem to assume 100% network uptime.
There will be no clusterwide clock or clusterwide increment when you
lose connection.
Andrew Dunstan [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
I think environment variables are used rarely enough on Win32 that we
should supply a hint.
I think every Windows administrator who is not totally clueless knows
how to set the environment. Maybe home users don't use it much, but
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
I think environment variables are used rarely enough on Win32 that we
should supply a hint.
I think every Windows administrator who is not totally clueless knows
how to set the environment. Maybe home users
On Mon, 5 Feb 2007, Simon Riggs wrote:
On Sun, 2007-02-04 at 09:38 +, Simon Riggs wrote:
The TODO I was requesting you consider was this:
Develop non-conflicting locking scheme to allow RI checks to co-exist
peacefully with non-PK UPDATEs on the referenced table.
That
Bruce Momjian [EMAIL PROTECTED] writes:
OK, please propose some wording so at least we can get agreement on
that.
How about something open-ended like arrange for updates that do not update
columns referenced by foreign keys from other tables to avoid being blocked by
locks from concurrent RI
Gregory Stark [EMAIL PROTECTED] writes:
Bruce Momjian [EMAIL PROTECTED] writes:
OK, please propose some wording so at least we can get agreement on
that.
How about something open-ended like arrange for updates that do not update
columns referenced by foreign keys from other tables to avoid
Hackers,
In recent versions, we've changed the logging of function executions so
that only the function call is logged, and not any of the queries which it
may execute internally. While most of the time this method is superior
for performance analysis, in applications with extensive
On 2/5/2007 11:52 AM, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Sounds like a good time to suggest making these values configurable,
within certain reasonable bounds to avoid bad behaviour.
Actually, given what we've just learned --- namely that choosing these
values at random is
Hackers,
In recent versions, we've changed the logging of function executions so
that only the function call is logged, and not any of the queries which
it may execute internally. While most of the time this method is
superior for performance analysis, in applications with extensive
Josh Berkus josh@agliodbs.com writes:
In recent versions, we've changed the logging of function executions so
that only the function call is logged, and not any of the queries which it
may execute internally. While most of the time this method is superior
for performance analysis, in
Simon Riggs [EMAIL PROTECTED] wrote:
Actually, given what we've just learned --- namely that choosing these
values at random is a bad idea --- I'd want to see a whole lot of
positive evidence before adding such a configuration knob.
3. assemble performance evidence
Step 3 is always
Hello,
Is anyone working on a period data type as described in Dr. Richard Snodgrass'
book _Developing Time-Oriented Database Applications in SQL_[1]? I did not
see a relevant project listed in the TODO. I would like to contribute
(possible funding and/or coding) the development of a
I think there's improvement to be made in how we track buffer usage
in general. Seqscans still hold the same weight as any other
operation, the freelist is of questionable value, and there's a lot
of work done to find a free buffer out of the pool, for example.
On Feb 2, 2007, at 8:08 PM,
On Feb 5, 2007, at 10:45 AM, Simon Riggs wrote:
Jan suggested to me a while back that having a configurable toast
threshold would be a useful thing, when that table is also updated
reasonably frequently.
While we're in there it probably makes sense to allow a configurable
value for when to
On 1/30/07, Bruce Momjian [EMAIL PROTECTED] wrote:
FYI, I have been working all January to process 8.3 held patches/ideas,
plus process the items arriving during the month. While I have been
able to make some progress, there are still a significant number of
items for me to address. I will
Jaime Casanova wrote:
On 1/30/07, Bruce Momjian [EMAIL PROTECTED] wrote:
FYI, I have been working all January to process 8.3 held patches/ideas,
plus process the items arriving during the month. While I have been
able to make some progress, there are still a significant number of
items
Warren,
Is anyone working on a period data type as described in Dr. Richard
Snodgrass' book _Developing Time-Oriented Database Applications in SQL_[1]?
I did not see a relevant project listed in the TODO. I would like to
contribute (possible funding and/or coding) the development of a
Hi,
Theo Schlossnagle wrote:
On Feb 4, 2007, at 1:36 PM, Jan Wieck wrote:
Obviously the counters will immediately drift apart based on the
transaction load of the nodes as soon as the network goes down. And in
order to avoid this clock confusion and wrong expectation, you'd
rather have a
63 matches
Mail list logo
