> -Original Message-
> From: Christopher Kings-Lynne [mailto:[EMAIL PROTECTED]
> Sent: 05 July 2005 02:39
> To: Robert Treat
> Cc: Bruce Momjian; Dave Page; Tom Lane; Dawid Kuroczko;
> Andreas Pflug; PostgreSQL-patches; PostgreSQL-development
> Subject: Re: [HACKERS] [PATCHES] Dbsize b
Bruce Momjian wrote:
I am not sure what to do with this patch. It is missing dump
capability, there is no clause to disable all triggers on a table, and
it uses a table owner check when a super user check is required (because
of referential integrity).
From a user's view, a trigger implement
On Tue, Jul 05, 2005 at 10:20:17AM +1000, Neil Conway wrote:
> Bruce Momjian wrote:
> >Your patch has been added to the PostgreSQL unapplied patches list
>
> That is not the latest version of Marko's patch.
Bruce got v3, thats indeed the latest.
Also, http://momjian.postgresql.org/cgi-bin/pgpatc
Several libpqxx users have been reporting odd problems with certain error
messages generated by libpq. One of them was the inclusion of garbage
data.
As it turns out, src/interfaces/libpq/fe-misc.c contains several instances
of this construct:
printfPQExpBuffer(&conn->ErrorMessage,
libpq_g
Here's another one similar to what I described in my previous message. In
libpq's pqsecure_read(), if SSL_read() returns -1 and sets an error of
SSL_ERROR_SYSCALL, errno may be polluted by libpq_gettext() before a
human-readable string is derived from it. Also, pqReadData() will see the
wrong err
On Mon, Jul 04, 2005 at 03:04:51PM -0400, Bruce Momjian wrote:
>
> Patch applied. Thanks.
>
> Gerrit van Dyk wrote:
> >
> > This patch allows the PL/Python module to do (SRF) functions.
Does this patch work? The test_setof() function in sql/plpython_setof.sql
gives me the following:
SELECT *
This patch updates the DDL for contrib/pgcrypto to create all
functions as STRICT, and all functions except gen_salt() as IMMUTABLE.
gen_salt() is VOLATILE.
Although the functions are now STRICT, I left their PG_ARGISNULL()
checks in place as a protective measure for users who install the
new code
[EMAIL PROTECTED] writes:
> Another approach would have been to make libpq_gettext() preserve errno.
That seems like a far easier, cleaner, and more robust fix than this.
Moreover I don't believe that this approach works either, as the result
of strerror() is not guaranteed still usable after an
[EMAIL PROTECTED] writes:
> Here's another one similar to what I described in my previous message.
More or less proves my point, no? Even if you manage to fix every
occurence of this issue now, it'll keep popping up as people change
the code. This approach is just not maintainable.
On Tue, Jul 05, 2005 at 04:23:42PM +0200, Gerrit van Dyk wrote:
>
> Ok, I just looked at the code again and the results I am getting, is
> what you expect.
>
> 2 rows every time returning 1 and 2.
>
> What version of postgres are you running, I am running 8.0.3
I'm running HEAD (8.1devel), whi
BTW, I read at
http://www.gnu.org/software/libc/manual/html_node/Translation-with-gettext.html
The gettext function does not modify the value of the global errno
variable. This is necessary to make it possible to write something like
printf (gettext ("Operation failed: %m\n
Michael Fuhr <[EMAIL PROTECTED]> writes:
> I'm running HEAD (8.1devel), which is where the patch was committed.
> Could somebody else test HEAD and see what they get?
Same as you --- ie, this patch is utterly broken.
> I don't see the setof functionality in the regression tests,
> presumably beca
[EMAIL PROTECTED] writes:
> Attached is a patch (by Gavin Sherry, fixed up to apply to 8.1 by me) that
> implements INSERT ... RETURNING functionality.
> It does work for the common case of RETURNING the value of a serial/sequence
> column, but gets confused when returning results out-of-order (CR
"Matthew T. O'Connor" writes:
>>> Hmm. Yes, this patch doesn't handle Xid wraparound. This should be
>>> easy to add though. Anyway, I was thinking that we could add a "last
>>> vacuum Xid" to pg_autovacuum, and handle Xid wraparound for each table
>>> separately -- this means you don't have to
Tom Lane wrote:
"Matthew T. O'Connor" writes:
The current implementation of XID wraparound requires that the vacuum
command be run against the entire database, you can not run it on a per
table basis and have it work. At least that is my understanding,
No, you're wrong. VACUUMing o
"Matthew T. O'Connor" writes:
> Tom Lane wrote:
>> No, you're wrong. VACUUMing of individual tables is perfectly good
>> enough as far as XID wrap protection goes, it's just that we chose to
>> track whether it had been done at the database level. If we tracked it
>> in, say, a new pg_class colu
Michael Fuhr <[EMAIL PROTECTED]> writes:
>> This patch allows the PL/Python module to do (SRF) functions.
> Does this patch work?
Aside from minor problems like being broken and undocumented, there is a
more serious question here: is this even the functionality we want?
The proposed test case is
On Tue, Jul 05, 2005 at 01:00:50PM -0400, Tom Lane wrote:
> "Matthew T. O'Connor" writes:
> > Tom Lane wrote:
> >> No, you're wrong. VACUUMing of individual tables is perfectly good
> >> enough as far as XID wrap protection goes, it's just that we chose to
> >> track whether it had been done at t
On Tue, Jul 05, 2005 at 01:14:25PM -0400, Tom Lane wrote:
>
> Aside from minor problems like being broken and undocumented, there is a
> more serious question here: is this even the functionality we want?
I'd rather see something akin to PL/pgSQL's RETURN NEXT or PL/Perl's
return_next.
--
Micha
Michael Fuhr wrote:
On Tue, Jul 05, 2005 at 01:14:25PM -0400, Tom Lane wrote:
Aside from minor problems like being broken and undocumented, there is a
more serious question here: is this even the functionality we want?
I'd rather see something akin to PL/pgSQL's RETURN NEXT or PL/Pe
OK, patch backed out, new and regression file removed.
---
Andrew Dunstan wrote:
>
>
> Michael Fuhr wrote:
>
> >On Tue, Jul 05, 2005 at 01:14:25PM -0400, Tom Lane wrote:
> >
> >
> >>Aside from minor problems like being
TODO item?
---
Alvaro Herrera wrote:
> On Tue, Jul 05, 2005 at 01:00:50PM -0400, Tom Lane wrote:
> > "Matthew T. O'Connor" writes:
> > > Tom Lane wrote:
> > >> No, you're wrong. VACUUMing of individual tables is perfectly
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I attach a patch to implement dependencies on shared objects.
> As some of you may remember, the purpose of this patch is to record
> dependencies on shared objects, such as roles and tablespaces, from
> regular database objects. This is done on a new s
I think so. Something like: Improve autovacuum xid wraparound detection
by moving to a pertable solution rather than per database.
Matt
Bruce Momjian wrote:
TODO item?
---(end of broadcast)---
TIP 2: you can get off all lists at once wi
Matthew T. O'Connor wrote:
> I think so. Something like: Improve autovacuum xid wraparound detection
> by moving to a pertable solution rather than per database.
Thanks, added.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610)
On Tue, Jul 05, 2005 at 02:47:15PM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I attach a patch to implement dependencies on shared objects.
> > As some of you may remember, the purpose of this patch is to record
> > dependencies on shared objects, such as roles and tabl
While we are at it (assuming the autovacuum patch gets included in 8.1)
we have a few autovacuum related todo items.
These are the ones I can think of right now:
* XID Wraparound improvement, moving to per-table vacuuming rather than
per database. (8.2)
* Alter table commands to set per table
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Tue, Jul 05, 2005 at 02:47:15PM -0400, Tom Lane wrote:
>> Although I don't have any particular objection to the OWNER/NORMAL
>> distinction, your explanation doesn't seem to make sense. Don't you
>> have to poke the Acl anyway, if it's non-null? Els
Another question about this: why bother with dependencies on
tablespaces? That seems to me to be isomorphic with dependencies on
databases --- we don't need those either, because in both cases we
count on the filesystem to provide ground truth about which objects
live inside a database/tablespace.
On Tue, Jul 05, 2005 at 04:32:22PM -0400, Tom Lane wrote:
> Another question about this: why bother with dependencies on
> tablespaces? That seems to me to be isomorphic with dependencies on
> databases --- we don't need those either, because in both cases we
> count on the filesystem to provide g
Dave Page wrote:
> > >>You are into the cycle we were in. We discussed pg_object size (too
> > >>vague) and pg_index_size (needs pg_toast_size too, and maybe toast
> > >>indexes; too many functions).
> > >
> > > Yeah, I read those discussions, and think you were better
> > off then than you
> >
Bruce Momjian wrote:
> This also adds a full_page_writes GUC to turn off page writes to WAL.
> Some people might not want full_page_writes.
Fsync linkage removed, patch attached and applied.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us
Bruce Momjian writes:
> If we go pg_table_size() and pg_relation_size(), which is object-only
> and which is heap + index + toast? I think ideally we want
> pg_relation_size to be the combined one, but then we have pg_table_size
> that works on indexes and toast too, and that is confusing, and we
Bruce Momjian wrote:
> I am not sure what to do with this patch. It is missing dump
> capability, there is no clause to disable all triggers on a table, and
> it uses a table owner check when a super user check is required (because
> of referential integrity).
>
> Satoshi, are you still working o
Tom Lane wrote:
> Bruce Momjian writes:
> > If we go pg_table_size() and pg_relation_size(), which is object-only
> > and which is heap + index + toast? I think ideally we want
> > pg_relation_size to be the combined one, but then we have pg_table_size
> > that works on indexes and toast too, and
Bruce Momjian writes:
> Tom Lane wrote:
>> I could live with that. Or "pg_total_relation_size".
> The problem with "total", to me, is that it already is the total size of
> the heap/index/toast. Complete has the idea of adding additional
> pieces, which I think fits best.
[ shrug ] I don't ca
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> I could live with that. Or "pg_total_relation_size".
>
> > The problem with "total", to me, is that it already is the total size of
> > the heap/index/toast. Complete has the idea of adding additional
> > pieces, which I think fit
Greg Sabino Mullane wrote:
>
> http://archives.postgresql.org/pgsql-patches/2005-05/msg00197.php
Applied.
---
Attached is a patch that enhances the "\h" capability in psql. I often
find myself typing a command and then want
Satoshi Nagayasu wrote:
> Bruce Momjian wrote:
> > I am not sure what to do with this patch. It is missing dump
> > capability, there is no clause to disable all triggers on a table, and
> > it uses a table owner check when a super user check is required (because
> > of referential integrity).
> >
Tom Lane wrote:
> [EMAIL PROTECTED] writes:
>> Another approach would have been to make libpq_gettext() preserve errno.
>
> That seems like a far easier, cleaner, and more robust fix than this.
Provided that either:
(a) the C standard has added a sequence point between the arguments in a
function
40 matches
Mail list logo
