On Sat, Nov 21, 2009 at 16:07, David E. Wheeler da...@kineticode.com wrote:
On Nov 22, 2009, at 7:49 AM, Tom Lane wrote:
I'm thinking maybe we should remove -w. Comments?
Have you tried it on the existing tests to see what happens?
For me there I get:
*the breaking in create_cast
*various
On Tue, Nov 17, 2009 at 03:54, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
Also, after reading through the previous threads; it was not
immediately obvious that you dealt with
http://archives.postgresql.org/pgsql-hackers/2009-10/msg00566.php by
only allowing selects or values at the
On Thu, Nov 12, 2009 at 11:56, Bernd Helmle maili...@oopsware.de wrote:
I've just started looking into this and wonder how this should look like.
IIRC another motivation for moving them into pg_constraint was we
could then give them names as required by the spec (unless I got mixed
up with
On Mon, Nov 16, 2009 at 11:45, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com writes:
FYI defaults have the same problem. Would it be awkward would it be
to use pg_constraint for the book keeping as well? [ and by that I
really mean ALTER TABLE ADD CONSTRAINT my_default
While looking over the writable cte patch I noticed queries.sgml has
lots of things in the form literalFROM/. I tried various
googles to see if / is some kind of sgml/xml shorthand for close the
last opened tag. But alas, nothing found. Bad google foo?
Should we change those to be the right
On Mon, Nov 16, 2009 at 20:41, Tom Lane t...@sss.pgh.pa.us wrote:
Apparently --- it's perfectly legal in SGML. (I think not in XML.)
Cool. Thanks!
BTW anyone know how to escape and for google? I tried searching
for it-- but ran into a chick and egg situation. So the I tried
various forms
On Sun, Nov 15, 2009 at 14:27, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
I wrote:
Attached is the latest version of this patch.
Find attached a incremental diff with the following changes:
-get rid of operation argument to InitResultRelInfo, its unused now
-add some asserts to make
the connection, which means that we'll be checking
for a NOTIFY every time we have new data.
That just doesn't make sense.
--
Alex
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Nov 12, 2009 at 13:55, Tom Lane t...@sss.pgh.pa.us wrote:
I'd go for the first of those, for sure. Testing attnotnull is
significantly cheaper than enforcing a generic constraint expression,
and NOT NULL is a sufficiently common case to be worth worrying about
optimizing it.
When I
. The example I gave involved removing Distinct and pushing
Limit through a join)
--
Alex Brasetvik
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Aug 27, 2009 at 06:39, Grzegorz Jaskiewiczg...@pointblue.com.pl wrote:
heh, sorry folks for the noise again :/
There was a fair amount of false positives there - due to nature of Assert()
macro. Mainly, since assert_enabled is a runtime variable, not a macro
(which I sadly
On Fri, Aug 7, 2009 at 10:10, Todd A. Cooktc...@blackducksoftware.com wrote:
Alex Hunsaker wrote:
With double the number of files maybe something
simple like turning on dir_index if you are ext3 will help?
Thanks for the tip. Doing tune2fs -O +dir_index didn't seem to make
a difference
On Thu, Aug 6, 2009 at 11:32, Todd A. Cooktc...@blackducksoftware.com wrote:
Tom Lane wrote:
I took a look through the CVS history and verified that there were
no post-8.4 commits that looked like they'd affect performance in
this area. So I think it's got to be a platform difference not a
support more worthwhile.
--
Alex Brasetvik
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Dec 8, 2008 at 06:56, Pavan Deolaseepavan.deola...@gmail.com wrote:
Here is a patch which implements this. The PD_ALL_VISIBLE flag is set if all
tuples in the page are visible to all transactions and there are no DEAD
line pointers in the page. The second check is required so that
On Mon, May 11, 2009 at 21:18, Tom Lane t...@sss.pgh.pa.us wrote:
However, he can do that anyway via ALTER TABLE, which
will happily take out AccessExclusiveLock before it checks any
permissions. So I'm not seeing the point of risking unsafe behavior
in LOCK TABLE.
I would rather fix ALTER
On Tue, May 12, 2009 at 14:40, Alex Hunsaker bada...@gmail.com wrote:
Hrm on second thought I think your right. They only get the lock
until the permission check, and I have a hard time seeing how someone
can take real advantage of that. The owner that is trying to lock
table should get
On Tue, May 12, 2009 at 12:10, Alex Hunsaker bada...@gmail.com wrote:
On Mon, May 11, 2009 at 21:18, Tom Lane t...@sss.pgh.pa.us wrote:
However, he can do that anyway via ALTER TABLE, which
will happily take out AccessExclusiveLock before it checks any
permissions. So I'm not seeing
On Mon, Jan 19, 2009 at 15:26, Brendan Jurd dire...@gmail.com wrote:
From the better-late-than-never department, comes a patch to improve
the handling of AM/PM and AD/BC markers in to_timestamp(), and up the
ante on error reporting for various kinds of invalid input.
Ok cool I tried this out
Sitnikov, not the pg_stat_statement author, Alex
Hunsaker, so I am just checking.
I assume you mean Itagaki-san not me :)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Jan 6, 2009 at 06:43, Bruce Momjian br...@momjian.us wrote:
Alex Hunsaker wrote:
This patch lets you control 3 pg_lzcompress knobs on a per table basis
(note requires reloptions.patch)
I think we need to live with the TOAST changes for at least one release
before we know what knobs
On Tue, Jan 6, 2009 at 12:57, Stephen R. van den Berg s...@cuci.nl wrote:
Peter Eisentraut wrote:
(1) Compress everything within reason by default, causing slower retrieval, do
not offer substr optimization. [= 8.3]
(2) Compress only up to 1 MB, causing faster retrieval, supporting substr
On Sun, Jan 4, 2009 at 15:01, Alvaro Herrera alvhe...@commandprompt.com wrote:
Alvaro Herrera wrote:
Okay, it was basically fine except for the attached minor correction.
Warning: I intend to commit this patch fairly soon!
This is the patch in its final form. I have included a few macros to
This patch lets you control 3 pg_lzcompress knobs on a per table basis
(note requires reloptions.patch)
compress_max_size: Controls the maximum size to be considered for
TOAST compression.
compress_min_rate: Minimum compression rate (0-100%) required for
TOAST compression to be used.
On Sat, Jan 3, 2009 at 09:37, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
... This doesn't actually work in the current system.
I have a solution for this, I think. I propose that guc.c only allow
custom PGC_POSTMASTER variables to be created during
process_shared_preload_libraries().
On Fri, Jan 2, 2009 at 20:20, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
* the startup/shutdown hooks will be installed in the postmaster
process, but the patch expects them to be executed in a child process.
I think nothing will happen.
OK, I figured out what is happening there: the patch
On Fri, Jan 2, 2009 at 16:11, Stephen Frost sfr...@snowman.net wrote:
* Stephen Frost (sfr...@snowman.net) wrote:
Please find attached an updated patch for column-level privileges
which incorporates Alvaro's suggested changes and is updated to the
latest CVS HEAD.
Hi!
This gives me
On Sat, Jan 3, 2009 at 20:47, Philip Warner p...@rhyme.com.au wrote:
Tom Lane wrote:
It would be fairly easy, I think, to add some reloption fields that
would let these parameters be controlled on a per-table level.
Per-column would be much more painful; do we really need that?
Another +1
On Sat, Jan 3, 2009 at 21:56, Philip Warner p...@rhyme.com.au wrote:
Alex Hunsaker wrote:
For the record I just imported a production database that sits at
about ~20G right now with *zero* size increase (rounding to the
nearest gigabyte). That's with basically the exact same schema just
;
$ ./pgbench -T60 -n -f q.sql
8.4: 1532.327546
8.3: 21.295657
Thats with 8.4 as a --enable-debug --enable-cassert build! (8.3 just
has --enable-debug)
I'm not entirely convinced by Alex' analysis anyway; the only way
those 39 large values explain the size difference
On Fri, Jan 2, 2009 at 10:44, Robert Haas robertmh...@gmail.com wrote:
Here, we have a case where the space savings are potentially much
larger, and the only argument against it is that someone might be
disappointed in the performance of substring operations, if they
happen to do any. What if
to INT_MAX, then
re-load the table with the modified backend (or you could even
just do CREATE TABLE foo AS SELECT * FROM existing_table and
then compare sizes). If that puts the toast table size back where
it had been, then Alex correctly diagnosed the cause.
And the toast file size is *drum
On Fri, Jan 2, 2009 at 17:22, Tom Lane t...@sss.pgh.pa.us wrote:
A couple of other possibilities that seem a bit saner:
1. Use a self-organizing list: any time an entry is referenced,
move it to front, and when you need a new entry take the oldest
one off the back. I don't see a way to do
On Fri, Jan 2, 2009 at 18:23, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com writes:
Its seems to me a linear list would make the common case where the
query is already in the list but we need to update the stats slow.
No, the hashtable is still there for lookups
On Fri, Jan 2, 2009 at 03:13, Magnus Hagander mag...@hagander.net wrote:
Andrew Chernow wrote:
Yes, the homedir variable is used again later in the function. homedir
could be invalid since pqGetHomeDirectory might not get called. Maybe
something like below would do the trick:
How about
On Fri, Jan 2, 2009 at 18:30, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com writes:
On Fri, Jan 2, 2009 at 11:44, Tom Lane t...@sss.pgh.pa.us wrote:
An easy way to prove or disprove the point would be to go into
src/backend/utils/adt/pg_lzcompress.c, and change the second
On Fri, Jan 2, 2009 at 20:30, Tom Lane t...@sss.pgh.pa.us wrote:
One point that nobody seems to have focused on is whether Alex's
less-compressed table is faster or slower to access than the original.
I dunno if he has any easy way of investigating that for his typical
query mix, but it's
On Fri, Jan 2, 2009 at 18:46, Tom Lane t...@sss.pgh.pa.us wrote:
It would be fairly easy, I think, to add some reloption fields that
would let these parameters be controlled on a per-table level.
+1
Or something easier that just lets you use PGLZ_Strategy strategy_always_data.
ALTER TABLE
On Thu, Jan 1, 2009 at 17:28, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com writes:
... So Im going to mark it as
ready for commmiter.
Has this patch been tested on Windows? (Or more generally, with
EXEC_BACKEND?)
I was under the impression thats where Itagaki-san
On Thu, Jan 1, 2009 at 19:59, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
* in an EXEC_BACKEND situation, we re-execute
process_shared_preload_libraries() when starting a fresh backend
(but not in other kinds of child processes, which is why the other
problem is a problem). This means
I just did a fresh import of my alpha database into 8.4 and noticed
that the size of the database had increased significantly:
8.4: 6.3G
8.3: 4.9G
Tracking it down the main difference seems to a toast tables namely this one:
ls -ltrh 8.3/base/16516/430156
-rw--- 1 postgres postgres 145M
On Thu, Jan 1, 2009 at 21:30, Alex Hunsaker bada...@gmail.com wrote:
http://git.postgresql.org/?p=postgresql.git;a=commit;h=3b6942b3f2fe733572c05a71cb2d12e5ece60cdbits
... typoed that its
http://git.postgresql.org/?p=postgresql.git;a=commit;h=3b6942b3f2fe733572c05a71cb2d12e5ece60cd
--
Sent
On Thu, Jan 1, 2009 at 21:30, Alex Hunsaker bada...@gmail.com wrote:
My hunch is its related to
http://git.postgresql.org/?p=postgresql.git;a=commit;h=3b6942b3f2fe733572c05a71cb2d12e5ece60cd
or for the CVS inclined
http::/archives.postgresql.org/pgsql-committers/2008-03/msg00121.php
On Thu, Jan 1, 2009 at 22:44, Alex Hunsaker bada...@gmail.com wrote:
Looking at the patch we dont compress things 1M anymore so I thought
maybe I was hitting that. But no luck there are only 39 rows where
the row size 1M... With those 39 being about 22M each.
Oh my... 25 * 40 = 1000M
So
On Mon, Dec 29, 2008 at 15:46, Alex Hunsaker bada...@gmail.com wrote:
On Thu, Dec 25, 2008 at 23:04, ITAGAKI Takahiro
itagaki.takah...@oss.ntt.co.jp wrote:
Here is an updated version of contrib/pg_stat_statements patch.
Im going to do some more testing, give the typedef Chunk stuff another
On Sat, Dec 27, 2008 at 11:50, Andrew Chernow a...@esilo.com wrote:
Why does pqGetHomeDirectory have to succeed to use conn-sslrootcert. Maybe
this should be an OR of the two since sslrootcert is not dependent on
homedir?
around line 970 src/interfaces/libpq/fe-secure.c
if (conn-sslrootcert
On Thu, Dec 25, 2008 at 23:04, ITAGAKI Takahiro
itagaki.takah...@oss.ntt.co.jp wrote:
Here is an updated version of contrib/pg_stat_statements patch.
Im going to do some more testing, give the typedef Chunk stuff another
look (you did fix the race/not protected by a spinlock you found
earlier
On Mon, Dec 22, 2008 at 00:44, ITAGAKI Takahiro
itagaki.takah...@oss.ntt.co.jp wrote:
Alex Hunsaker bada...@gmail.com wrote:
A few comments:
Is there a reason you add sourceText to QueryDesc? AFAICT you can do
ActivePortal-sourceText and it will always be populated correctly.
That's
On Tue, Dec 9, 2008 at 01:20, Greg Smith [EMAIL PROTECTED] wrote:
On Sun, 7 Dec 2008, Alex Hunsaker wrote:
(dual core machine, --enable-debug, --enable-cassert build)
pgbench -c 2 -T60 -n -f test.sql
HEAD: tps = 9.674423
PATCH: tps = 9.695784
Two general suggestions here, not specific
On Mon, Dec 8, 2008 at 23:28, ITAGAKI Takahiro
[EMAIL PROTECTED] wrote:
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
On Sun, Dec 7, 2008 at 19:13, Alex Hunsaker [EMAIL PROTECTED] wrote:
On Tue, Dec 2, 2008 at 02:35, ITAGAKI Takahiro
[EMAIL PROTECTED] wrote:
Here is an update version of contrib/pg_stat_statements.
Hello again!
I was assigned to review this.
... Some other things I accidentally left out
On Tue, Dec 2, 2008 at 02:35, ITAGAKI Takahiro
[EMAIL PROTECTED] wrote:
Here is an update version of contrib/pg_stat_statements.
Hello again!
I was assigned to review this.
Submission review:
Is the patch in standard form? Yes
Does it apply cleanly to current HEAD? Yes (with fuzz)
Does it
On Fri, Dec 5, 2008 at 13:58, Andrew Chernow [EMAIL PROTECTED] wrote:
Who anyone be opposed to ssldir = path as a connection option? Currently,
there is no way to change the homedir method ~/.postgresql ... or am I
missing something? I am willing to supply a patch.
You mean something like the
On Fri, Dec 5, 2008 at 14:22, Andrew Chernow [EMAIL PROTECTED] wrote:
Alex Hunsaker wrote:
On Fri, Dec 5, 2008 at 13:58, Andrew Chernow [EMAIL PROTECTED] wrote:
Who anyone be opposed to ssldir = path as a connection option?
Currently,
there is no way to change the homedir method
On Fri, Aug 1, 2008 at 13:31, Alvaro Herrera [EMAIL PROTECTED] wrote:
Something that's bothering me is that PGSSLKEY is inconsistent with the
sslkey conninfo parameter. PGSSLKEY specifies an engine (basically a
driver for specialized hardware AFAICT) from which the key is to be
loaded, but
On Thu, Nov 20, 2008 at 21:45, Philip Warner [EMAIL PROTECTED] wrote:
Sounds somewhat evil, I know, but I was wondering if it was even
remotely possible with the current design?
The reason: we are contemplating using pg_standy to create a
warm-standby. It would be a bonus if we would run
On Mon, Nov 17, 2008 at 01:01, Magnus Hagander [EMAIL PROTECTED] wrote:
On 16 nov 2008, at 01.00, Alex Hunsaker [EMAIL PROTECTED] wrote:
Would cncert be a better auth_method name? As later we might have
different types of ssl client cert authentication??
If/when I'd rather still call it cert
On Mon, Nov 17, 2008 at 05:31, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Magnus Hagander escribió:
On 16 nov 2008, at 01.00, Alex Hunsaker [EMAIL PROTECTED] wrote:
My only concern is there is no way to specify the USER_CERT_FILE for
libpq. So if for example I have two users that I want to use
On Mon, Nov 17, 2008 at 03:04, Magnus Hagander [EMAIL PROTECTED] wrote:
Alex Hunsaker wrote:
On Sat, Nov 15, 2008 at 17:39, Tom Lane [EMAIL PROTECTED] wrote:
2. Root cert file present but we fail to load it: FATAL is probably okay
here, but not with that hint message.
Err, I was just trying
On Thu, Oct 23, 2008 at 08:51, Magnus Hagander [EMAIL PROTECTED] wrote:
Magnus Hagander wrote:
This patch adds a configuration option to pg_hba.conf for clientcert.
This makes it possible to have different client certificate requirements
on different connections. It also makes sure that if you
On Sat, Nov 15, 2008 at 15:20, Alex Hunsaker [EMAIL PROTECTED] wrote:
we do something like:
+ if (access(ROOT_CERT_FILE, R_OK))
+ {
+ ssl_loaded_verify_locations = false;
+
+ /*
+ * If root certificate file simply not found. Don't log
On Thu, Nov 13, 2008 at 05:31, Magnus Hagander [EMAIL PROTECTED] wrote:
Attached patch implements client certificate authentication.
I kept this sitting in my tree without sending it in before the
commitfest because it is entirely dependent on the
not-yet-reviewed-and-applied patch for how to
On Sat, Nov 15, 2008 at 17:39, Tom Lane [EMAIL PROTECTED] wrote:
Alex Hunsaker [EMAIL PROTECTED] writes:
Err that really should be ereport(FATAL,
I don't think that's a particularly user-friendly design.
The behavior I'd expect to see is
1. Root cert file not there: issue existing LOG
On Thu, Nov 13, 2008 at 01:05, Magnus Hagander [EMAIL PROTECTED] wrote:
It means I will go ahead and apply it once I have looked it over once more.
Thanks for review+testing!
You may now move on to the next ssl patch if you're interested ;)
Sure thing probably wont get to it till tomorrow...
)
Type help for help.
postgres=# \q
$ ./psql postgres -h 127.0.0.1
psql: server common name 'bahdushka' does not match hostname
'127.0.0.1'FATAL: no pg_hba.conf entry for host 127.0.0.1, user
alex, database postgres, SSL off
$ PGHOSTADDR=127.0.0.1 ./psql postgres -h 127.0.0.1
psql: verified SSL
(8.4devel)
SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)
Type help for help.
junk=#
$ SSLVERIFY=cn ./psql junk -h 192.168.0.2
psql: server common name 'bahdushka' does not match hostname
'192.168.0.2'FATAL: no pg_hba.conf entry for host 192.168.0.2, user
alex, database junk, SSL off
On Tue, Nov 11, 2008 at 06:16, Magnus Hagander [EMAIL PROTECTED] wrote:
Alex Hunsaker wrote:
On Mon, Oct 20, 2008 at 05:50, Magnus Hagander [EMAIL PROTECTED] wrote:
$ SSLVERIFY=cn ./psql junk -h 192.168.0.2
psql: server common name 'bahdushka' does not match hostname
'192.168.0.2'FATAL
On Wed, Nov 5, 2008 at 16:00, Kevin Grittner
[EMAIL PROTECTED] wrote:
An idea for a possible enhancement to PostgreSQL: allow creation of a
temporary table without generating any disk I/O. (Creating and
dropping a three-column temporary table within a database transaction
currently generates
On Fri, Oct 31, 2008 at 07:48, David Fetter [EMAIL PROTECTED] wrote:
Please find attached a patch which works in PL/Perl, the work having
been done by Andrew (RhodiumToad) Gierth. It's not clear to me how
this would be generally surface-able to SQL, though. Any ideas?
I was assigned to
On Thu, Oct 30, 2008 at 05:16, Tom Lane [EMAIL PROTECTED] wrote:
David Fetter [EMAIL PROTECTED] writes:
On Wed, Oct 29, 2008 at 10:23:36PM -0400, Tom Lane wrote:
I would argue that it's already designed wrong if there's need for
PL-specific implementation effort.
I'm not sure how else to do
On Thu, Oct 9, 2008 at 03:06, ITAGAKI Takahiro
[EMAIL PROTECTED] wrote:
Thanks for your reviewing, Alex.
I applied your comments to my patch.
Sorry for the late reply! Somehow I missed this, saw it on the commit
fest wiki :)
*custom_guc_flags-0828.patch
My only other concern is the changes
On Wed, Aug 27, 2008 at 8:54 PM, ITAGAKI Takahiro
[EMAIL PROTECTED] wrote:
Here is a contrib version of auto-explain.
I'd like to add it the next commit-fest in September.
Here is my review:
*custom_guc_flags-0828.patch
It seems to be windows newline damaged? lots of ^M at the end of the
On Fri, Sep 26, 2008 at 11:25 AM, Brendan Jurd [EMAIL PROTECTED] wrote:
One way to tidy this up would be to re-implement the meridiem markers
using the seq_search functions, i.e., make it work like the day and
month names. This would make it easy to accept any flavour of marker,
and the error
On Sun, Sep 21, 2008 at 11:09 AM, Tom Lane [EMAIL PROTECTED] wrote:
A possible objection to this plan is that if the column-level privileges
patch doesn't get in, then we're left with a useless column in
pg_attribute. But an always-null column doesn't cost much of anything,
and we know that
On Mon, Sep 8, 2008 at 2:24 AM, Brendan Jurd [EMAIL PROTECTED] wrote:
HEAD actually gets this one wrong; in defiance of the documentation it
returns 2000-09-07. So, it seems to me that the patch shifts the
behaviour in the right direction.
Barring actually teaching the code that some nodes
On Tue, Sep 9, 2008 at 6:46 AM, Brendan Jurd [EMAIL PROTECTED] wrote:
On Tue, Sep 9, 2008 at 9:04 PM, Brendan Jurd [EMAIL PROTECTED] wrote:
On Tue, Sep 9, 2008 at 7:29 PM, Martijn van Oosterhout
[EMAIL PROTECTED] wrote:
The use of palloc/pfree in this routine seems excessive. Does len have
On Thu, Sep 4, 2008 at 12:01 PM, Tom Lane [EMAIL PROTECTED] wrote:
I think what the hash index patch really needs is some performance
testing. I'm willing to take responsibility for the code being okay
or not, but I haven't got any production-grade hardware to do realistic
performance tests
On Fri, Aug 29, 2008 at 1:16 PM, Tom Lane [EMAIL PROTECTED] wrote:
In theory the above implementation of newNode should be a clear win,
so I'm thinking this result must be an artifact of some kind. I'm
going to go try it on PPC and HPPA machines next; does anyone want to
try it on something
On Thu, Jul 3, 2008 at 10:58 AM, Dean Rasheed [EMAIL PROTECTED] wrote:
Here is an updated version of the patch, with a debug_explain_min_duration
parameter to allow explaining of just slow-running queries. I've also
incorporated
a couple of Simon Riggs' suggestions for formatting the output
On Thu, Jul 3, 2008 at 12:44 PM, Dave Page [EMAIL PROTECTED] wrote:
it concerns me that despite it being day 3 of the July commit fest,
people are still being advised to add new items to the wiki page.
To make the idea work, we need to stick to the rules we defined when
we came up with the
On Mon, Jun 30, 2008 at 6:34 AM, Dean Rasheed [EMAIL PROTECTED] wrote:
Hi,
This is a small patch I posted a few months back, and then kinda forgot
about / got distracted with other things.
Is there any interest in this? If so I am willing to put more work into
it, if people like it or have
On Mon, Jun 23, 2008 at 4:51 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
I would like to get do this without adding a new --use-statement-timeout
flag. Is anyone going to want to honor statement_timeout during
pg_dump/pg_restore? I thought we were just going to disable it.
I believe so. This
On Tue, May 27, 2008 at 10:20 AM, Tom Lane [EMAIL PROTECTED] wrote:
I am wondering if it's a good idea to hide the redundant entries
to reduce clutter in the pg_settings display. (We could do this
by adding a hidden boolean to struct config_enum_entry.)
Thoughts?
+1
On Tue, May 27, 2008 at 12:05 PM, Magnus Hagander [EMAIL PROTECTED] wrote:
Alex Hunsaker wrote:
On Tue, May 27, 2008 at 10:20 AM, Tom Lane [EMAIL PROTECTED] wrote:
I am wondering if it's a good idea to hide the redundant entries
to reduce clutter in the pg_settings display. (We could do
On Fri, May 9, 2008 at 5:37 PM, Tom Lane [EMAIL PROTECTED] wrote:
Alex Hunsaker [EMAIL PROTECTED] writes:
[ patch to change inherited-check-constraint behavior ]
Applied after rather heavy editorializations. You didn't do very well on
getting it to work in multiple-inheritance scenarios
On Wed, May 7, 2008 at 12:20 AM, Alex Hunsaker [EMAIL PROTECTED] wrote:
Find attached a diff from v4-v5, and a full patch.
src/backend/commands/tablecmds.c | 242
+++-
src/backend/utils/cache/syscache.c | 12 --
src/include/catalog/indexing.h
On Wed, May 7, 2008 at 8:28 AM, Bruce Momjian [EMAIL PROTECTED] wrote:
Brendan Jurd wrote:
On Thu, May 8, 2008 at 12:17 AM, Tom Lane [EMAIL PROTECTED] wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I think it would be helpful for us to provide an infrastructure where
people who
On Wed, May 7, 2008 at 9:03 AM, Bruce Momjian [EMAIL PROTECTED] wrote:
Alex Hunsaker wrote:
Plus it seems awkward to move a discussion thats taking place on
-hackers over to patches... Granted I could post to patches first,
wait an hour then send an email to hackers/reviewer and say hey
On Wed, May 7, 2008 at 2:13 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
David Fetter wrote:
This would make it a little tougher on me as far as maintaining the
patches section of the PostgreSQL Weekly News, but I'll deal with it
if I need to :)
Yes, it is going to make scooping patches
On Tue, May 6, 2008 at 7:57 PM, Tom Lane [EMAIL PROTECTED] wrote:
Alex Hunsaker [EMAIL PROTECTED] writes:
[ patch to fix behavior of inherited constraints ]
Looking over this patch, I see that it introduces a syscache on
pg_constraint (conrelid, conname), which requires a unique index
On Wed, Apr 16, 2008 at 4:32 PM, Joshua D. Drake [EMAIL PROTECTED] wrote:
On Wed, 16 Apr 2008 15:22:31 -0700
Joshua D. Drake [EMAIL PROTECTED] wrote:
On Wed, 16 Apr 2008 22:17:30 -
Greg Sabino Mullane [EMAIL PROTECTED] wrote:
I don't think it's fair to simply discard the use
On Wed, Apr 16, 2008 at 4:54 PM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Joshua D. Drake escribió:
That is an interesting idea. Something like:
pg_restore -E SET STATEMENT_TIMEOUT=0; SET MAINTENANCE_WORK_MEM=1G ?
We already have it -- it's called PGOPTIONS.
Ok but is not the purpose
On Mon, Mar 31, 2008 at 2:36 AM, NikhilS [EMAIL PROTECTED] wrote:
Hi Alex,
I was taking a look at this patch to add the pg_dump related changes. Just
wanted to give you a heads up as this patch crashes if we run make
installcheck. Seems there is an issue introduced in the CREATE TABLE
On Fri, Mar 28, 2008 at 4:07 AM, NikhilS [EMAIL PROTECTED] wrote:
Hi Alex,
On Fri, Mar 28, 2008 at 4:58 AM, Alex Hunsaker [EMAIL PROTECTED] wrote:
Attached is a WIP patch I have been playing with in my spare time. It
should take care of the first 2. It does nothing for pg_dump or set
BTW, anybody following the GIT mirror, the REL8_3_STABLE branch has been
re-wound, you you'll probably have to force update it (git fetch -f) if
you only accept fast forward updates on fetches (the default).
Thanks! now i can ditch the git.or.cz mirror
And if you have patches based on
On Thu, Mar 27, 2008 at 5:34 PM, Alex Hunsaker [EMAIL PROTECTED] wrote:
BTW, anybody following the GIT mirror, the REL8_3_STABLE branch has been
re-wound, you you'll probably have to force update it (git fetch -f) if
you only accept fast forward updates on fetches (the default
tables - for the table in question it very well may ~20 disk
seeks per webpage view, so very high cache hit rate (ideally 100%) has to be
assured.
So - will the 'mlock' hack work? Or any other ideas for pinning a table in
memory?
- Alex
Heikki Linnakangas [EMAIL PROTECTED] wrote:
adrobj
. Or am I totally wrong?
Alex.
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
On Tue, 13 Feb 2007, Marc Munro wrote:
On Mon, 2007-12-02 at 00:10 -0500, Tom Lane wrote:
Marc Munro [EMAIL PROTECTED] writes:
Consider a table C containing 2 child records C1 and C2, of parent P.
If transaction T1 updates C1 and C2, the locking order of the the
records will be C1, P,
The situation is like that:
[19:24] Press_Enter Who can help with file system level backup?
[19:24] KL Press_Enter: shut down postgres, tar the data dir
[19:25] KL Press_Enter: apparently filesystem snapshots might work as well
[19:25] KL Press_Enter: you're supposed to use pg_dumpall
[19:25]
401 - 500 of 627 matches
Mail list logo
