Log Message:
---
Add and use interface to deleting function cache entries.
Use this in the validator to be sure to grab the new function the next time
around. While a more appropriate solution would handle the general case that the
function cache exists in, this is useful as it will be sur
Log Message:
---
Use snprintf instead of asprintf.
snprintf is likely to be more portable than asprintf, and the string is actually
simple enough that calculating the resulting size is trivial. Also, it can then
print right to the palloc'd memory instead of pstrdup'ing, saving a malloc/fre
Chris, do you have a set-up to test out the blob behaviour? If your
using them in production you'll spot any further slip-ups; they weren't
intentionally ignored in the original patch.
No sorry - my PostgreSQL contribution these days primary consists of
"whining" :D
I usually just do this:
c
Simon Riggs <[EMAIL PROTECTED]> writes:
>> Just do a couple of lo_imports into a test database, dump, look at
>> pg_restore's output to see if it's sane ...
> Tests pass. BEGIN/COMMIT in correct places in log files (included).
Applied, thanks.
regards, tom lane
-
Log Message:
---
Repair --single-transaction patch so it handles blobs correctly.
Simon Riggs
Modified Files:
--
pgsql/src/bin/pg_dump:
pg_backup_archiver.c (r1.124 -> r1.125)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_dump/pg_backup_archi
Log Message:
---
Updated version number to 2.0.13
Modified Files:
--
bizgres/loader/src/com/deepgreen/loader:
DGLoaderProperties.java (r1.11 -> r1.12)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/bizgres/bizgres/loader/src/com/deepgreen/loader/DGLoaderPrope
On Tue, 2006-02-14 at 12:32 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Just put an if test around that blob-handling behaviour. The code looks
> > very simple, so patch enclosed to augment the already-applied patch.
>
> Isn't the end-restore test backwards?
Corrected in
Simon Riggs <[EMAIL PROTECTED]> writes:
> Perhaps if vacuum_delay_point() contained a timer check, we'd be able to
> see if any gap between vacuum delays was more than the actual delay
> itself. It would be nice to know they are all gone, forever.
vacuum_delay_point is intended to be cheap enough
On Tue, 2006-02-14 at 15:55 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Tue, 2006-02-14 at 13:20 -0400, Tom Lane wrote:
> >> add missing vacuum_delay_point() call in btvacuumcleanup.
>
> > Cool and Interesting. That might explain some pretty dire performance
> > numbers
On Tue, 2006-02-14 at 12:32 -0500, Tom Lane wrote:
> Just do a couple of lo_imports into a test database, dump, look at
> pg_restore's output to see if it's sane ...
Thats interesting. My testing shows there is a problem with HEAD that
goes back a few versions, but works with 8.1.1. Tracing it no
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Tue, 2006-02-14 at 13:20 -0400, Tom Lane wrote:
>> add missing vacuum_delay_point() call in btvacuumcleanup.
> Cool and Interesting. That might explain some pretty dire performance
> numbers from last week while running auto vacuum. Performance was
> fl
On Tue, 2006-02-14 at 13:20 -0400, Tom Lane wrote:
> Log Message:
> ---
> Move btbulkdelete's vacuum_delay_point() call to a place in the loop where
> we are not holding a buffer content lock; where it was, InterruptHoldoffCount
> is positive and so we'd not respond to cancel signals as int
On Tue, 2006-02-14 at 12:32 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Just put an if test around that blob-handling behaviour. The code looks
> > very simple, so patch enclosed to augment the already-applied patch.
>
> Isn't the end-restore test backwards?
Yup
> > Ch
Simon Riggs <[EMAIL PROTECTED]> writes:
> Just put an if test around that blob-handling behaviour. The code looks
> very simple, so patch enclosed to augment the already-applied patch.
Isn't the end-restore test backwards?
> Chris, do you have a set-up to test out the blob behaviour?
Just do a c
Log Message:
---
Move btbulkdelete's vacuum_delay_point() call to a place in the loop where
we are not holding a buffer content lock; where it was, InterruptHoldoffCount
is positive and so we'd not respond to cancel signals as intended. Also
add missing vacuum_delay_point() call in btvacuu
Log Message:
---
Move btbulkdelete's vacuum_delay_point() call to a place in the loop where
we are not holding a buffer content lock; where it was, InterruptHoldoffCount
is positive and so we'd not respond to cancel signals as intended. Also
add missing vacuum_delay_point() call in btvacuu
Log Message:
---
Move btbulkdelete's vacuum_delay_point() call to a place in the loop where
we are not holding a buffer content lock; where it was, InterruptHoldoffCount
is positive and so we'd not respond to cancel signals as intended. Also
add missing vacuum_delay_point() call in btvacuu
Simon Riggs <[EMAIL PROTECTED]> writes:
> [It's a shame we don't support nested BEGINs, for use in nested function
> calls. I guess we took that out infavour of SAVEPOINTs? I seem to
> remember some idiot (me wasn't it?) suggesting we should do that.]
I still think that was probably the right move
Log Message:
---
Add some missing vacuum_delay_point calls in GIST vacuuming.
Tags:
REL8_1_STABLE
Modified Files:
--
pgsql/src/backend/access/gist:
gistvacuum.c (r1.9 -> r1.9.2.1)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/gi
Log Message:
---
Add some missing vacuum_delay_point calls in GIST vacuuming.
Modified Files:
--
pgsql/src/backend/access/gist:
gistvacuum.c (r1.14 -> r1.15)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/gist/gistvacuum.c.diff?r1=1.14
On Tue, 2006-02-14 at 09:57 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > How should it work?
>
> > 1. Remove the BEGIN and COMMIT around blobs?
> > 2. Use SAVEPOINT ?
>
> > Presumably (1).
>
> Yeah, there is no need for the per-blob begin/commit if we've got one
> around
Log Message:
---
Correction of Dialog font.
(windows japan)
Tags:
REL-07_03_ENHANCED
Modified Files:
--
psqlodbc:
psqlodbc.rc (r1.43.2.5 -> r1.43.2.6)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/psqlodbc/psqlodbc/psqlodbc.rc.diff?r1=1.43.2.5&r2=1.43.
On Tue, 2006-02-14 at 23:01 +0800, Christopher Kings-Lynne wrote:
> > Perhaps you can explain further? My understanding was that the desired
> > functionality was that any failure would cause all aspects of the load
> > to fail also, so I don't see any problem with that; clearly I need to
> > liste
Log Message:
---
AllocSetStats should probably be using unsigned format to show space totals.
Modified Files:
--
pgsql/src/backend/utils/mmgr:
aset.c (r1.64 -> r1.65)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/mmgr/aset.c.diff?r1=1.
Log Message:
---
Need a DLLIMPORT for MaxFSMPages, per buildfarm failure on snake.
Modified Files:
--
pgsql/contrib/pg_freespacemap:
pg_freespacemap.c (r1.1 -> r1.2)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/contrib/pg_freespacemap/pg_freespacemap.c
Perhaps you can explain further? My understanding was that the desired
functionality was that any failure would cause all aspects of the load
to fail also, so I don't see any problem with that; clearly I need to
listen to your thoughts.
Maybe we're not talking about the same thing? I was talkin
Simon Riggs <[EMAIL PROTECTED]> writes:
> How should it work?
> 1. Remove the BEGIN and COMMIT around blobs?
> 2. Use SAVEPOINT ?
> Presumably (1).
Yeah, there is no need for the per-blob begin/commit if we've got one
around the whole restore.
One thing to be careful of is not to suppress BEGIN
On Tue, 2006-02-14 at 09:35 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Tue, 2006-02-14 at 16:55 +0800, Christopher Kings-Lynne wrote:
> >> Huh? But it'll cause a total failure of dump restore?
>
> > Perhaps you can explain further?
>
> As the code stands, a restore i
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Tue, 2006-02-14 at 16:55 +0800, Christopher Kings-Lynne wrote:
>> Huh? But it'll cause a total failure of dump restore?
> Perhaps you can explain further?
As the code stands, a restore involving blobs plus --single-transaction
produces
BEGIN;
Update of /cvsroot/npgsql/Npgsql2
In directory pgfoundry.org:/tmp/cvs-serv81945
Log Message:
2006-02-14 Francisco Figueiredo Jr. <[EMAIL PROTECTED]>
* Added Npgsql2 for .Net 2.0 module
Status:
Vendor Tag: v2_0
Release Tags: v2_0_0
N Npgsql2/src/Npgsql/NpgsqlCo
On Mon, 2006-02-13 at 16:02 -0500, Tom Lane wrote:
> Isn't this patch emitting the BEGIN at the wrong place?
> That's not what I would call guaranteeing that all the commands execute
> successfully. What if the client encoding is unrecognized, for
> instance?
Please let me know if you are going
On Tue, 2006-02-14 at 16:55 +0800, Christopher Kings-Lynne wrote:
> >> Or...it could create and release a particular savepoint I suppose...I
> >> don't know if there's much point in that though.
> >
> > Didn't seem much point trying to remove it,
>
> Huh? But it'll cause a total failure of dump
Or...it could create and release a particular savepoint I suppose...I
don't know if there's much point in that though.
Didn't seem much point trying to remove it,
Huh? But it'll cause a total failure of dump restore?
Chris
---(end of broadcast)--
On Mon, 2006-02-13 at 16:02 -0500, Tom Lane wrote:
> Isn't this patch emitting the BEGIN at the wrong place?
>
> --
> -- PostgreSQL database dump
> --
>
> SET client_encoding = 'SQL_ASCII';
> SET check_function_bodies = false;
> SET client_min_messages = warning;
>
> BEGIN;
>
> --
> -- Name: SC
On Tue, 2006-02-14 at 12:21 +0800, Christopher Kings-Lynne wrote:
> >> Good question ... right offhand it looks like there are some broken
> >> things there (try grepping bin/pg_dump/ for BEGIN).
> >
> > I suggest you just suppress the begin/commit for each LOB if
> > --single-transaction is spec
Log Message:
---
Version 3.0.1
Modified Files:
--
pgpool:
ChangeLog (r1.14 -> r1.15)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgpool/pgpool/ChangeLog.diff?r1=1.14&r2=1.15)
NEWS (r1.15 -> r1.16)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.c
Log Message:
---
Fix master/slave mode breakage in 2.7.2
Fix bug with master/slave mode and prepared query
Modified Files:
--
pgpool:
pool.h (r1.7 -> r1.8)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgpool/pgpool/pool.h.diff?r1=1.7&r2=1.8)
pool_p
37 matches
Mail list logo
