On Sun, 2007-04-08 at 11:08 +0300, Marko Kreen wrote:
> I think implicit ABORT would annoy various tools that
> partially parse user sql and expect to know what transaction
> state currently is. For them a new tranaction control statement
> would be nuisance.
That's not the only alternative: we c
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> I manually merged your patch on top of my own. This is the result.
> Please have a look at whether the new code is correct and behaves sanely
> (I haven't tested it).
The patch seems to be broken -- the latter half is lost.
Regards,
---
ITAGAKI Taka
I don't fully understand what "transaction log" means. If it means
"archived WAL", the current (8.2) code handle WAL as follows:
1) If full_page_writes=off, then no full page writes will be written to
WAL, except for those during onlie backup (between pg_start_backup and
pg_stop_backup). T
The score below was taken based on 8.2 code, not 8.3 code. So I don't
think the below measure is introduced only in 8.3 code.
Tom Lane wrote:
> Koichi Suzuki <[EMAIL PROTECTED]> writes:
>> For more information, when checkpoint interval is one hour, the amount
>> of the archived log size was as fo
This patch replace _ftime() by QueryPerformanceCounter() to measure durations
in psql \timing on Windows. It had only 15ms~ of time resolusion. I brought
the codes from src/include/executor/instrument.h .
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
psql_timing_on_windows.patch
ITAGAKI Takahiro wrote:
> > > >Yes, that's correct. Per previous discussion, what I actually wanted to
> > > >do was to create a GUC setting to simplify the whole thing, something
> > > >like "autovacuum_max_mb_per_second" or "autovacuum_max_io_per_second".
> > > >Then, have each worker use up to
Koichi Suzuki <[EMAIL PROTECTED]> writes:
> For more information, when checkpoint interval is one hour, the amount
> of the archived log size was as follows:
> cp: 3.1GB
> gzip: 1.5GB
> pg_compresslog: 0.3GB
The notion that 90% of the WAL could be backup blocks even at very l
NikhilS wrote:
> Hi,
>
> On 4/10/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> >
> >
> > Added to TODO:
> >
> > o Have WITH CONSTRAINTS also create constraint indexes
> >
> > http://archives.postgresql.org/pgsql-patches/2007-04/msg00149.php
>
>
> Trevor's patch does add unique/primary i
Thanks, that was a distinction I didn't know. TODO updated:
o Allow single-byte header storage for array elements
---
Gregory Stark wrote:
>
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> > Added to TODO:
> >
Gurjeet Singh wrote:
> The interface etc. may not be beautiful, but it isn't ugly either! It is
> a lot better than manually creating pg_index records and inserting them into
> cache; we use index_create() API to create the index (build is deferred),
> and then 'rollback to savepoint' to undo t
I noticed that when psql accepts input from stdin or -f (but not -c),
and timing is set to on in .psqlrc, timing results are printed out to
stdout even when -q (quiet) is passed in.
This may not be the perfect solution, but it fixes the problem (I'm
having problems with bash scripts that are bork
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> My first thought is that the cycle_ctr just adds extra complexity. The
> canceled-flag really is the key in Takahiro-san's patch, so we don't
> need the cycle_ctr anymore.
We don't have to have it in the sense of the code not working without it,
b
Hi,
As per discussion on -hackers, a patch which allows updates to use
subselects is attached with this mail.
As per discussion with Tom, I have adopted the following approach:
* Introduce ROWEXPR_SUBLINK type for subqueries that allows multiple column
outputs.
* Populate the targetList with PA
On 4/11/07, Tom Lane <[EMAIL PROTECTED]> wrote:
[ itch... ] The problem is with time-extended execution of
GetSnapshotData; what happens if the other guy lost the CPU for a good
long time while in the middle of GetSnapshotData? He might set his
xmin based on info you saw as long gone.
You mi
Tom Lane wrote:
I wrote:
Actually, on second look I think the key idea here is Takahiro-san's
introduction of a cancellation flag in the hashtable entries, to
replace the cases where AbsorbFsyncRequests can try to delete entries.
What that means is mdsync() doesn't need an outer retry loop at al
I've been looking at this, and my feeling is that we should drop the
PROARGMODE_TABLE business and just define RETURNS TABLE(x int, y int)
as exactly equivalent to RETURNS SETOF RECORD with x and y treated as
OUT parameters. There isn't any advantage to distinguishing the cases
that outweighs b
I've been looking at this, and my feeling is that we should drop the
PROARGMODE_TABLE business and just define RETURNS TABLE(x int, y int)
as exactly equivalent to RETURNS SETOF RECORD with x and y treated as
OUT parameters. There isn't any advantage to distinguishing the cases
that outweighs b
17 matches
Mail list logo
