On 2/2/2007 4:51 AM, Simon Riggs wrote:
It sounds like if we don't put a SHARE lock on the referenced table then
we can end the transaction in an inconsistent state if the referenced
table has concurrent UPDATEs or DELETEs. BUT those operations do impose
locking rules back onto the referencing ta
On 2/3/2007 5:20 PM, Bruce Momjian wrote:
Jan Wieck wrote:
I don't have any such paper and the proof of concept will be the
implementation of the system. I do however see enough resistance against
this proposal to withdraw the commit timestamp at this time. The new
replication system will ther
Added to TODO:
* Allow custom variable classes that can restrict who can set the values
http://archives.postgresql.org/pgsql-hackers/2006-11/msg00911.php
---
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writ
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > vacuumlazy.c contains a hint "Consider compacting this relation" but
> > AFAICT,
> > there is no indication anywhere how "compacting" is supposed to be achieved.
> > I guess this means VACUUM FULL or CLUSTER, but I don't think the
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Ga
Added to TODO:
o Add \# to list command history like \s, but with line numbers
http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php
---
Joshua D. Drake wrote:
> Hello,
>
> O.k. this is my cu
The original discussion of this patch was here:
http://archives.postgresql.org/pgsql-hackers/2006-11/msg00876.php
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the Post
On 2/3/2007 5:25 PM, Joshua D. Drake wrote:
Jan Wieck wrote:
Attached is the implementation of the proposed changes as a patch for
discussion.
The chosen syntax is backward compatible and uses
ALTER TABLE ENABLE TRIGGER (fires on origin - default)
ALTER TABLE DISABLE TRIGGER (disabled)
ALT
Heikki, did this code cleanup get included in your recent btree split
fix?
---
Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > In that case, newitemleft would be false, right?
> > I'm saying the piece ma
I am writing a set returning function in C. There are cases where I can
know definitively, upfront, that this function will only return one row.
I have noticed, through happenstance of partially converted function, that
I can mark a normal, non-set returning function as returning SETOF
something,
Tatsuo Ishii wrote:
> As usual, following item in the 8.1.5 release note is pretty vague:
>
> * Efficiency improvements in hash tables and bitmap index scans(Tom)
>
> Especially I'm wondering what was actually improved in bitmap index
> scans. I see several commit messages regarding bitmap i
Added to TODO:
o Allow recovery.conf to allow the same syntax as
postgresql.conf, including quoting
http://archives.postgresql.org/pgsql-hackers/2006-12/msg00497.php
---
Simon Riggs wrot
Jan Wieck wrote:
> Attached is the implementation of the proposed changes as a patch for
> discussion.
>
> The chosen syntax is backward compatible and uses
>
> ALTER TABLE ENABLE TRIGGER (fires on origin - default)
> ALTER TABLE DISABLE TRIGGER (disabled)
> ALTER TABLE ENABLE REPLICA TRIGGE
Jan Wieck wrote:
> I don't have any such paper and the proof of concept will be the
> implementation of the system. I do however see enough resistance against
> this proposal to withdraw the commit timestamp at this time. The new
> replication system will therefore require the installation of a
On Feb 3, 2007, at 5:09 PM, Jan Wieck wrote:
On 2/3/2007 4:58 PM, Theo Schlossnagle wrote:
I don't have any such paper and the proof of concept will be the
implementation of the system. I do however see enough resistance
against this proposal to withdraw the commit timestamp at this
time
On 2/3/2007 4:58 PM, Theo Schlossnagle wrote:
On Feb 3, 2007, at 4:38 PM, Jan Wieck wrote:
On 2/3/2007 4:05 PM, Theo Schlossnagle wrote:
On Feb 3, 2007, at 3:52 PM, Jan Wieck wrote:
On 2/1/2007 11:23 PM, Jim Nasby wrote:
On Jan 25, 2007, at 6:16 PM, Jan Wieck wrote:
If a per database configu
On Feb 3, 2007, at 4:38 PM, Jan Wieck wrote:
On 2/3/2007 4:05 PM, Theo Schlossnagle wrote:
On Feb 3, 2007, at 3:52 PM, Jan Wieck wrote:
On 2/1/2007 11:23 PM, Jim Nasby wrote:
On Jan 25, 2007, at 6:16 PM, Jan Wieck wrote:
If a per database configurable tslog_priority is given, the
timesta
Attached is the implementation of the proposed changes as a patch for
discussion.
The chosen syntax is backward compatible and uses
ALTER TABLE ENABLE TRIGGER (fires on origin - default)
ALTER TABLE DISABLE TRIGGER (disabled)
ALTER TABLE ENABLE REPLICA TRIGGER (fires on replica only)
ALTE
On 2/3/2007 4:05 PM, Theo Schlossnagle wrote:
On Feb 3, 2007, at 3:52 PM, Jan Wieck wrote:
On 2/1/2007 11:23 PM, Jim Nasby wrote:
On Jan 25, 2007, at 6:16 PM, Jan Wieck wrote:
If a per database configurable tslog_priority is given, the
timestamp will be truncated to milliseconds and the inc
Matthias Luedtke wrote:
> And while we are at it, how about some CFLAGS="-DOPTIMIZER_DEBUG"
> sweetness for the debugging section in the Dev FAQ?
Most of the debugging macros are not documented because their purpose
only arises out of the source code.
--
Peter Eisentraut
http://developer.postgr
On Feb 3, 2007, at 3:52 PM, Jan Wieck wrote:
On 2/1/2007 11:23 PM, Jim Nasby wrote:
On Jan 25, 2007, at 6:16 PM, Jan Wieck wrote:
If a per database configurable tslog_priority is given, the
timestamp will be truncated to milliseconds and the increment
logic is done on milliseconds. The p
On 2/1/2007 11:23 PM, Jim Nasby wrote:
On Jan 25, 2007, at 6:16 PM, Jan Wieck wrote:
If a per database configurable tslog_priority is given, the
timestamp will be truncated to milliseconds and the increment logic
is done on milliseconds. The priority is added to the timestamp.
This guarante
Michael Fuhr wrote:
On Sat, Feb 03, 2007 at 10:52:29AM -0600, Andrew Dunstan wrote:
I'd say fix psql. Not sure how far back we should backpatch it. It's
interesting that this has been there since 8.0 and is only now discovered.
The problem is new in 8.2 because COPY (query) doesn't s
Hi all,
Magnus Hagander wrote:
Personally, in my development tree I use a Makefile.custom containing
# back off optimization unless profiling
ifeq ($(PROFILE),)
CFLAGS:= $(patsubst -O2,-O1,$(CFLAGS))
endif
-O1 still generates "uninitialized variable" warnings but the code is a
lot saner to
On Sat, 3 Feb 2007, Simon Riggs wrote:
> On Fri, 2007-02-02 at 16:50 -0500, Tom Lane wrote:
> > No, I don't. I think knowledge of which columns are in a PK is quite a
> > few levels away from the semantics of row locking. To point out just
> > one problem, what happens when you add or drop a PK?
On Sat, Feb 03, 2007 at 10:52:29AM -0600, Andrew Dunstan wrote:
> I'd say fix psql. Not sure how far back we should backpatch it. It's
> interesting that this has been there since 8.0 and is only now discovered.
The problem is new in 8.2 because COPY (query) doesn't support USING
DELIMITERS. COPY
Michael Fuhr wrote:
> psql's \copy (query) with a delimiter yields a syntax error:
>
> test=> \copy foo to foo.txt delimiter '|'
> (works)
>
> test=> \copy (select * from foo) to foo.txt
> (works)
>
> test=> \copy (select * from foo) to foo.txt delimiter '|'
> ERROR: syntax error at or
On Fri, 2007-02-02 at 16:50 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > On Fri, 2007-02-02 at 15:57 -0500, Tom Lane wrote:
> >> , and it doesn't scale to
> >> more than two holders, and I don't think it works for combinations of
> >> share and exclusive lock. Also, what
psql's \copy (query) with a delimiter yields a syntax error:
test=> \copy foo to foo.txt delimiter '|'
(works)
test=> \copy (select * from foo) to foo.txt
(works)
test=> \copy (select * from foo) to foo.txt delimiter '|'
ERROR: syntax error at or near "USING"
LINE 1: COPY ( select
29 matches
Mail list logo
