> 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. Th
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 ge
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 no
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
> > > achie
"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 m
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 th
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
confusin
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 suppo
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.
htt
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 "localhos
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
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 saf
"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 t
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 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 case there
could
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 AccessEx
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 w
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-unsaf
Martijn van Oosterhout 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 for Linux, and p
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 agr
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
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 agree
"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 wh
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 stateme
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 w
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"
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/
>> 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
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?
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 reall
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
On Mon, Feb 05, 2007 at 11:34:23AM -0500, Tom Lane wrote:
> Martijn van Oosterhout 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
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
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 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 fa
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
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 co
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 libpq, particularly
>PQescapeByteaConn,
>PQescapeBytea,
>PQunescapeBytea,
>and PQnotifies.
>It is needed by Microsoft Windows, which cannot free memory across
>DLLs, unless multithreaded DLL
Bruce Momjian wrote:
OK, text trimmed down to a hint:
Environment variables on Windows are set as a property of My
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 *if* we wan
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 connectio
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 m
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. M
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 ta
"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 concurren
"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 othe
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 multi-line
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
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
> mul
Josh Berkus 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 applications with e
"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
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 conforming
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, B
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 co
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 ke
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
>
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 conf
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 sy
63 matches
Mail list logo
