On Tue, 2007-03-27 at 11:40 -0400, Andrew Dunstan wrote:
http://www.pgbuildfarm.org/cgi-bin/show_status.pl?sortby=name
http://www.pgbuildfarm.org/cgi-bin/show_status.pl?sortby=os
http://www.pgbuildfarm.org/cgi-bin/show_status.pl?sortby=compiler
Looks perfect. Many thanks.
--
Simon Riggs
On Tue, Mar 27, 2007 at 11:08:44AM -0700, David Fetter wrote:
On Sun, Mar 25, 2007 at 10:18:14PM -0400, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
I've written up a patch intended to implement this on the
non-pg_catalog tables and VIEWs, but while it builds, it doesn't
-Original Message-
From: Hannu Krosing [mailto:[EMAIL PROTECTED]
Sent: dinsdag 27 maart 2007 15:45
To: Joris Dobbelsteen
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Guarenteeing complex referencial
integrity throughcustom triggers
Ühel kenal päeval, E, 2007-03-26 kell 16:05,
On Tue, 2007-03-27 at 18:16 +0100, Heikki Linnakangas wrote:
Bruce Momjian wrote:
Yes, yes. I would like to have used it when testing the MyProc-xmin
improvements. The only thing that has held it back from being applied
was that there was no documentation/examples of how it would be used.
On Fri, 2007-02-23 at 12:07 -0800, Ron Mayer wrote:
Jim Nasby wrote:
The problem with using simple OS priority settings is you leave yourself
wide open to priority inversion.
Which is why you either
(a) note that papers studying priority inversion on RDBMS's
find that it's a non
David Fetter wrote:
It now initdb's successfully, but fails on a lot of regression tests.
Please find attached the new patch vs. CVS TIP and the regression test
output.
The regression test output is useless without seeing the regression diffs.
cheers
andrew
Simon Riggs wrote:
I would love, love, love to be able to use this syntax within pg_dump as
well, so we can create multiple indexes in parallel at restore time.
Anyone fancy adding that as well? We should be able to speed up overall
index builds by x2 using concurrent builds.
You will
On Tue, 2007-03-27 at 17:11 -0400, Andrew Dunstan wrote:
Simon Riggs wrote:
I would love, love, love to be able to use this syntax within pg_dump as
well, so we can create multiple indexes in parallel at restore time.
Anyone fancy adding that as well? We should be able to speed up overall
Simon Riggs wrote:
On Tue, 2007-03-27 at 17:11 -0400, Andrew Dunstan wrote:
Simon Riggs wrote:
I would love, love, love to be able to use this syntax within pg_dump as
well, so we can create multiple indexes in parallel at restore time.
Anyone fancy adding that as well? We should be
On Tue, 2007-03-27 at 11:52 +0900, Koichi Suzuki wrote:
Here's an update of a code to improve full page writes as proposed in
http://archives.postgresql.org/pgsql-hackers/2007-01/msg01491.php
and
http://archives.postgresql.org/pgsql-patches/2007-01/msg00607.php
Update includes some
Hiroshi,
We are doing the support including the trouble. It was thought that the
place of JPUG was preferable for the reasons why they were problems too
peculiar to Japan.
Well, some of PostgreSQL's commercial distributors have been pretty
surprised when they package PostgreSQL and find out
In CVS HEAD:
contrib/tsearch2/dict_syn.c:124: warning: 'slen' is used uninitialized
in this function
Induced by the recent pg_verifymbstr() patch.
-Neil
---(end of broadcast)---
TIP 4: Have you searched our list archives?
Hi Josh-san.
From: Josh Berkus josh@agliodbs.com
Hiroshi,
We are doing the support including the trouble. It was thought that the
place of JPUG was preferable for the reasons why they were problems too
peculiar to Japan.
Well, some of PostgreSQL's commercial distributors have been pretty
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Included is a more eloborate example, which has some webby thing at
http://www.familiedobbelsteen.nl/printer-test/ (should work).
Much too elaborate - I'm sorry, but I don't think anyone here is willing
to wade through nearly 900 lines of
Simon Riggs [EMAIL PROTECTED] writes:
It seems possible to reduce overall WAL volume by roughly 25% on common
workloads by optimising the way UPDATE statements generate WAL.
This seems a huge amount of work to optimize *one* benchmark. If it
weren't so narrowly focused on the properties of a
Simon Riggs [EMAIL PROTECTED] writes:
I would love, love, love to be able to use this syntax within pg_dump as
well, so we can create multiple indexes in parallel at restore time.
I can hardly conceive of greater folly than putting an *experimental*
psql facility into pg_dump scripts, thereby
Right now, all the patches I think are ready for review are in the patch
queue:
http://momjian.postgresql.org/cgi-bin/pgpatches
However, with feature freeze coming on Sunday, I am worried because
there are a significant number of patches that have are not ready for
review because they
Pavan Deolasee [EMAIL PROTECTED] writes:
Here is a patch which fixes this. We re-read part of the pg_index
row and update rd_index with the new data. I tested REINDEX and CIC
and both seems to work fine with the patch applied.
Tom, does this look good ?
It seems a bit brute-force. Why
Neil Conway [EMAIL PROTECTED] writes:
In CVS HEAD:
contrib/tsearch2/dict_syn.c:124: warning: 'slen' is used uninitialized
in this function
Induced by the recent pg_verifymbstr() patch.
Seems to be a genuine bug. Fixed, but I see a worse problem with this
code: random backend code should
Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
In CVS HEAD:
contrib/tsearch2/dict_syn.c:124: warning: 'slen' is used uninitialized
in this function
Induced by the recent pg_verifymbstr() patch.
Seems to be a genuine bug. Fixed, but I see a worse problem with this
code:
Simon;
Thanks a lot for your comments/advices. I'd like to write some feedback.
Simon Riggs wrote:
On Tue, 2007-03-27 at 11:52 +0900, Koichi Suzuki wrote:
Here's an update of a code to improve full page writes as proposed in
http://archives.postgresql.org/pgsql-hackers/2007-01/msg01491.php
On 3/28/07, Tom Lane [EMAIL PROTECTED] wrote:
It seems a bit brute-force. Why didn't you use SearchSysCache(INDEXRELID)
the same as RelationInitIndexAccessInfo does?
I tried that initially, but it gets into infinite recursion during initdb.
And what's the point of
the extra tuple copy
Bruce,
However, with feature freeze coming on Sunday, I am worried because
there are a significant number of patches that have are not ready for
review because they have not been completed by their authors.
Can you flag those somehow?
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
... random backend code should not, not, not be using fopen()
directly. If you lose control to an elog, which is certainly possible
seeing that this loop calls into the utils/mb subsystem, you'll leak
the file descriptor. Use
Pavan Deolasee [EMAIL PROTECTED] writes:
On 3/28/07, Tom Lane [EMAIL PROTECTED] wrote:
It seems a bit brute-force. Why didn't you use SearchSysCache(INDEXRELID)
the same as RelationInitIndexAccessInfo does?
I tried that initially, but it gets into infinite recursion during initdb.
Magnus Hagander [EMAIL PROTECTED] wrote:
IIRC, we're still waiting for performance numbers showing there exists a
win from this patch.
Here is a performance number of Direct I/O support on Windows.
There was 10%+ of performance win on pgbench (263.33 vs. 290.79) in O_DIRECT.
However, I only
On 3/27/07, Bruce Momjian [EMAIL PROTECTED] wrote:
I removed the advertising clause from all the BSD-copyrighted files from
Berkeley, namely all but */blf.*.
Their upstream is OpenBSD that still has same license.
NetBSD and FreeBSD have even worse versions with ssleay
license.
I think I need
On 3/26/07, Tom Lane [EMAIL PROTECTED] wrote:
It might be feasible to have RelationReloadClassinfo re-read the
pg_index row and apply only the updates for specific known-changeable
columns. The stuff it's worried about is the subsidiary data such
as support function fmgr lookup records, but
Ühel kenal päeval, E, 2007-03-26 kell 11:30, kirjutas Andrew Dunstan:
This feature (ability to add a message payload to a NOTIFY) is on the
TODO list and I had undertaken to implement it. However, pressure of
other work has conspired to make that difficult, and Abhijit Menon-Sen
recently
Ühel kenal päeval, T, 2007-03-27 kell 11:17, kirjutas Hannu Krosing:
Ühel kenal päeval, E, 2007-03-26 kell 11:30, kirjutas Andrew Dunstan:
This feature (ability to add a message payload to a NOTIFY) is on the
TODO list and I had undertaken to implement it. However, pressure of
other work
http://www.pgbuildfarm.org/cgi-bin/show_status.pl
Could we sort the results by System, please? At least as an option.
It's currently fairly hard to review the details to see whether a
particular release level is supported/tested. The sort order changes
over time, which isn't useful.
Build
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
... But ISTM that means we just need to pick a few strategic spots
that will call CHECK_FOR_NOTIFICATIONS() even in the middle of a
transaction and store them locally.
Minor comment --- I don't believe in having a separate
Hannu Krosing wrote:
So perhaps it Alvaros proposal can be rephrased thus:
Why have the name on each message? The names are already stored in
listen table, just reuse numeric identifier pointing to item in that
table. That gives you room for a lot more messages.
If there is no name in listen
Hannu Krosing wrote:
I find the feature very useful, and have even done some preliminary
design work for shared memory implementation, where each listener is
required to copy data to its own privat memory ASAP and notifier waits
in case there is not enough room in shared memory buffer.
Alas,
Should these designations be more generic in case there are other uses
for enabling/disabling groups of triggers?
That would be fine with me, I just wasn't able to come up with any
sensible naming scheme other than replication related. Can you?
The best I could think of would be to create
Hannu Krosing wrote:
Now that I think about it again, maybe we should NOT go for a
shared memory implementation after all, as we now have HOT updates and
thanks to the fact, that we have 1:1 correspondence between the backends
and
deleters in LISTEN/NOTIFY we can have much more exact
Simon Riggs wrote:
http://www.pgbuildfarm.org/cgi-bin/show_status.pl
Could we sort the results by System, please? At least as an option.
It's currently fairly hard to review the details to see whether a
particular release level is supported/tested. The sort order changes
over time, which
On Tue, Mar 27, 2007 at 07:33:08AM -0400, Andrew Dunstan wrote:
We can certainly provide a different view, or sort it by system name,
What about making the column headers clickable to control the sort
order?
--
Michael Fuhr
---(end of
On Tue, 2007-03-27 at 07:33 -0400, Andrew Dunstan wrote:
Simon Riggs wrote:
http://www.pgbuildfarm.org/cgi-bin/show_status.pl
Could we sort the results by System, please? At least as an option.
It's currently fairly hard to review the details to see whether a
particular release
Gregory Stark wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
and b) that there is broad agreement on the general design (i.e. to use a
circular buffer in shared memory, of configurable size, to hold the
outstanding message queue).
Would it spill out to disk and expand (and shrink
Ühel kenal päeval, T, 2007-03-27 kell 07:11, kirjutas Andrew Dunstan:
Hannu Krosing wrote:
So perhaps it Alvaros proposal can be rephrased thus:
Why have the name on each message? The names are already stored in
listen table, just reuse numeric identifier pointing to item in that
table.
Ühel kenal päeval, T, 2007-03-27 kell 16:13, kirjutas Hannu Krosing:
How else would we know how many copies to make for each backend or when
we can release the memory in case we make one copy ?
(see earlier discussion).
could you post a link to archives ?
Sorry, found it now.
I was
Would people be interested in this feature? There was some positive reaction
from users but I'm not sure how excited developers are about complicating the
logic in psql (which is already pretty tangled).
This code bitrotted severely when Tom added the cursor support to psql. I
don't mind redoing
Ühel kenal päeval, E, 2007-03-26 kell 16:05, kirjutas Joris Dobbelsteen:
Oracle has choosen to allow constraint enforcement by locking on the
parent tuple. In contrast postgres has chosen (historically, see RI
triggers) to fail on detecting conflicting newly inserted rows (the
cross-check).
Hannu Krosing [EMAIL PROTECTED] writes:
Ãhel kenal päeval, T, 2007-03-27 kell 07:11, kirjutas Andrew Dunstan:
Er, what listen table?
At least the list of which backends listen to which events should be
also in shared mem.
No, the intent is specifically that there will be *no* such global
Yes, yes. I would like to have used it when testing the MyProc-xmin
improvements. The only thing that has held it back from being applied
was that there was no documentation/examples of how it would be used.
---
Gregory
Guillaume Smet [EMAIL PROTECTED] writes:
test=# CREATE TABLE test_in (field varchar(3));
CREATE TABLE
test=# CREATE INDEX idx_test_in ON test_in(field) WHERE field IN('1', '2');
ERROR: functions in index predicate must be marked IMMUTABLE
Hmm. This is generating a coercion from varchar[] to
Andrew Dunstan [EMAIL PROTECTED] writes:
This page is a dashboard. It shows the latest state of each build system
on each branch during the last 30 days.
The advantage to sorting it by snapshot is that you can quickly see when
something broke a bunch of builds.
Yes --- I will be exceedingly
Heikki Linnakangas wrote:
Here's what's happening:
1. Client 1 issues fsync (A)
2. Clients 2-5 write their commit record, and try to fsync, but they
have to wait for fsync (A) to finish.
It contains a graph that shows that the patch works very well for this
test case. It's not very good for
Simon Riggs wrote:
We can certainly provide a different view, or sort it by system name,
but I'm not sure that will actually show you what you want. If you want
to see the history on a particular system/branch, there is a separate
page for that - just click the system's name on the dashboard
On Tue, Mar 27, 2007 at 05:43:53AM -0600, Michael Fuhr wrote:
On Tue, Mar 27, 2007 at 07:33:08AM -0400, Andrew Dunstan wrote:
We can certainly provide a different view, or sort it by system
name,
What about making the column headers clickable to control the sort
order?
There's an
Is this patch ready?
---
Greg Smith wrote:
I have a WIP patch that adds the main detail I have found I need to
properly tune checkpoint and background writer activity. I think it's
almost ready to submit (you can see
On Mon, Mar 26, 2007 at 07:31:20PM -0400, Neil Conway wrote:
Bruce Momjian wrote:
FYI, I have received permission, below, to remove the Andrew Yu
copyright. Thanks.
Can't we just remove the file outright? The last release of Ultrix
was in 1995.
Sadly, in the US, at least, and so that
David Fetter wrote:
On Mon, Mar 26, 2007 at 07:31:20PM -0400, Neil Conway wrote:
Bruce Momjian wrote:
FYI, I have received permission, below, to remove the Andrew Yu
copyright. Thanks.
Can't we just remove the file outright? The last release of Ultrix
was in 1995.
Sadly, in the US, at
Joshua D. Drake wrote:
David Fetter wrote:
Sadly, in the US, at least, and so that file, absent sweeping changes
in the law, will remain outside the public domain until slightly after
the first human-crewed starship departs our solar system.
Hardly, we will have populated at least 3 solar
David Fetter [EMAIL PROTECTED] writes:
On Mon, Mar 26, 2007 at 07:31:20PM -0400, Neil Conway wrote:
Can't we just remove the file outright? The last release of Ultrix
was in 1995.
Sadly, in the US, at least, and so that file, absent sweeping changes
in the law, will remain outside the public
I am still unclear why sigres is better than a temporary file system. I
relize your patch is faster, but what is about your patch that makes it
faster.
And if we were going to add such capability, we would name it based on
what it does, rather than on a 'sigres' mode.
Bruce Momjian wrote:
Yes, yes. I would like to have used it when testing the MyProc-xmin
improvements. The only thing that has held it back from being applied
was that there was no documentation/examples of how it would be used.
Hear hear! I had trouble writing regression tests for the
Where are we on this patch idea?
---
Koichi Suzuki wrote:
Sorry for the late responce;
Gzip can reduce the archive log size about one fourth. My point is
that it can still be large enough.Removing physical log
Would not at least some of these numbers be better presented through the
stats collector, so they can be easily monitored?
That goes along the line of my way way way away from finished attempt
earlier, perhaps a combination of these two patches?
//Magnus
Bruce Momjian wrote:
Is this patch
Magnus Hagander wrote:
Would not at least some of these numbers be better presented through the
stats collector, so they can be easily monitored?
That goes along the line of my way way way away from finished attempt
earlier, perhaps a combination of these two patches?
Yes.
On Sun, Mar 25, 2007 at 10:18:14PM -0400, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
I've written up a patch intended to implement this on the
non-pg_catalog tables and VIEWs, but while it builds, it doesn't
initdb. Enclosed are the patch and the error log.
Any hints as to
+++
We'd love this feature as it would really help us write better test cases !
Regards
Sailesh
--
Sailesh Krishnamurthy
Amalgamated Insight
[W] (650) 242-3503
[C] (650) 804-6585
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gregory Stark
Sent:
It seems possible to reduce overall WAL volume by roughly 25% on common
workloads by optimising the way UPDATE statements generate WAL. I've got
a practical proposal that looks like it can be completed in a few more
days work and fits very well with HOT UPDATEs.
This is likely to have beneficial
64 matches
Mail list logo
