2010/1/12 Takahiro Itagaki :
> Hi, I'm reviewing OPEN FOR EXECUTE USING patch and have a couple of
> trivial comments.
>
> Pavel Stehule wrote:
>
>> this small patch add missing USING clause to OPEN FOR EXECUTE statement
>> + cleaning part of exec_stmt_open function
>
> - Can we use read_sql_expre
Michael Meskes írta:
> On Sun, Jan 10, 2010 at 07:16:59PM +0100, Boszormenyi Zoltan wrote:
>
>> As would ecpg_dynamic_type(), then. :-(
>>
>
> My guess is that this function is fine when returning InvalidOid = 0. AFAICT
> it
> is supposed to fill an integer with the SQL3 type code which se
Stefan Kaltenbrunner wrote:
so is there an actually concrete proposal of _what_ interals to expose? '
The pieces are coming together...summary:
-Status quo: really bad, but could probably ship anyway because
existing PITR is no better and people manage to use it
-Add slave pg_current_xlog_lo
Thanks for your advice!
On Wed, Jan 13, 2010 at 3:37 AM, Magnus Hagander wrote:
>> This change which moves walreceiver process into a dynamically loaded
>> module caused the following compile error on my MinGW environment.
>
> That sounds strange - it should pick those up from the -lpostgres. Any
Jaime Casanova írta:
> 2010/1/13 Boszormenyi Zoltan :
>
>> Tom Lane írta:
>>
>>> If this patch is touching those parts of relcache.c, it probably needs
>>> rethinking.
>>>
>>>
>> What I did there is to check the return value of LockRelationOid()
>>
>
> the hunk was because a dif
I found following strange error on gothic moth:
== pgsql.22658/src/test/regress/regression.diffs
===
***
/zfs_data/home/postgres/buildfarm/gothic_moth/HEAD/pgsql.22658/src/test/regress/expected/vacuum.out
Tue Jan 12 22:06:13 2010
---
/zfs_data/home/postgres/bu
Fujii Masao wrote:
> Done. Currently there is no new libpq function for replication. The
> walreceiver uses only existing functions like PQconnectdb, PQexec,
> PQgetCopyData, etc.
>
> git://git.postgresql.org/git/users/fujii/postgres.git
> branch: replication
Thanks!
I'm afraid we haven't qu
On Tue, Jan 12, 2010 at 07:06:59PM -0500, Robert Haas wrote:
> On Sun, Jan 10, 2010 at 4:35 PM, Robert Haas wrote:
> >>> I would strongly suggest to Tim that he rip the portions of this patch
> >>> that are related to this feature out and submit them separately so
> >>> that we can commit the unco
Our documentation suggests that you can take a base backup of a warm
standby server while it's running:
> If we take a backup of the standby server's data directory while it is
> processing logs shipped from the primary, we will be able to reload that data
> and restart the standby's recovery pr
On Wed, Jan 13, 2010 at 8:36 PM, Heikki Linnakangas
wrote:
> Our documentation suggests that you can take a base backup of a warm
> standby server while it's running:
>
>> If we take a backup of the standby server's data directory while it is
>> processing logs shipped from the primary, we will b
Jaime Casanova írta:
> 2010/1/13 Boszormenyi Zoltan :
>
>> Tom Lane írta:
>>
>>> If this patch is touching those parts of relcache.c, it probably needs
>>> rethinking.
>>>
>>>
>> What I did there is to check the return value of LockRelationOid()
>>
>
> the hunk was because a dif
Fujii Masao wrote:
> On Wed, Jan 13, 2010 at 8:36 PM, Heikki Linnakangas
> wrote:
>> I wonder if it would be enough to document that pg_control must be
>> backed up first?
>
> Probably No. The archive recovery from such base backup would always
> fail at the end of recovery because there is no ba
per/lower is more beautiful since
two have same length but start/end is used since it was introduced.
Comments?
Regards,
--
Hitoshi Harada
more_frame_options.20100113.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hans,
nce Jaime already asked for a use case, just a few small comments from
me.
> @@ -4,6 +4,7 @@
> #include "postgres_fe.h"
>
> #include
> +#include
This is not portable. You don't want to include this header.
Did I see this right that you use the statement cache for auto-prepared
stateme
On Wed, Jan 13, 2010 at 09:22:28AM +0100, Boszormenyi Zoltan wrote:
> I think it's best to assume a string. ecpg_set_{compat,native}_sqlda()
> uses the defailt case in that meaning anyway.
Okay, applied as you send it.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot
On Sun, 2010-01-03 at 11:55 +0100, Martijn van Oosterhout wrote:
> On Fri, Jan 01, 2010 at 03:31:58PM -0500, Kris Jurka wrote:
> > The JDBC driver does want "cancel if active" behavior. The JDBC API
> > specifies Statement.cancel() where Statement is running one particular
> > backend query.
README.bloom:
contrib/bloom provides signature file based index.
Authors: Teodor Sigaev (teo...@sigaev.ru) and Oleg Bartunov (o...@sai.msu.su)
Notes: This is a *working* prototype, which can be finishing up to production
in case of interest. Particularly, it misses wal support, because of
commo
2010/1/13 Boszormenyi Zoltan :
>>
>> well, i actually think that PANIC is too high for this...
>>
>
> Well, it tries to lock and then open a critical system index.
> Failure to open it has PANIC, it seemed appropriate to use
> the same error level if the lock failure case.
>
if you try to open a c
Boszormenyi Zoltan writes:
> Tom Lane írta:
>> If this patch is touching those parts of relcache.c, it probably needs
>> rethinking.
> What I did there is to check the return value of LockRelationOid()
> and also elog(PANIC) if the lock wasn't available.
> Does it need rethinking?
Yes. What you
2010/1/13 Teodor Sigaev :
> CREATE INDEX bloomidx ON tbloom(i1,i2,i3)
> WITH (length=5, col1=2, col2=2, col3=4);
>
> Here, we create bloom index with signature length 80 bits and attributes
> i1, i2 mapped to 2 bits, attribute i3 - to 4 bits.
This is pretty darn slick. I haven't looked at
This is pretty darn slick. I haven't looked at the code yet, but the
It's just a prototype and/or proof of concept
functionality sounds very cool, and I hope this is something we'll be
able to have as part of PG in the future (though more than likely not
for 8.5, I suspect).
Of course
--
Te
> (4) In conclusion, I hope that PostgreSQL will keep xml2
> or something similar even when the XSLT and speculative parsing
> issues have been addressed.
Given your interest in XML2, would you like to be come a maintainer of
the module?
--Josh Berkus
--
Sent via pgsql-hackers mailing list (pg
On Tue, 2010-01-12 at 20:06 -0800, Josh Berkus wrote:
> > So it seems to me that the threshold question for this patch is - do
> > we think it's a good idea to maintain two implementations of PL/python
> > in core?
>
> Not really, no. This is why we need PGAN ;-)
>
> If the new implementation is
On ons, 2010-01-13 at 09:47 -0800, Joshua D. Drake wrote:
> I think it is important to remember that the current version of
> PL/python is pretty weak compared to its counter parts (Specifically
> PL/Perl).
How so?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
On Thu, 2010-01-07 at 18:34 +0900, Fujii Masao wrote:
> On Thu, Jan 7, 2010 at 6:09 PM, Joshua Tolley wrote:
> > Having concluded I really need to start playing with hot standby, I started
> > looking for documentation on the subject. I found what I was looking for; I
> > also found this page[1],
On Wed, 2010-01-13 at 19:53 +0200, Peter Eisentraut wrote:
> On ons, 2010-01-13 at 09:47 -0800, Joshua D. Drake wrote:
> > I think it is important to remember that the current version of
> > PL/python is pretty weak compared to its counter parts (Specifically
> > PL/Perl).
>
> How so?
O.k. you ma
> My argument would be now, what is the benefit of the James Pye version
> over our version. James can you illustrate succinctly why we should be
> supporting a new version?
>
> If there is, I am still all for it, but I am a python bigot.
Yeah, it's just my viewpoint that we don't want 2 python
I wrote:
> Peter Eisentraut writes:
>> On mån, 2010-01-11 at 12:54 -0500, Tom Lane wrote:
>>> -- Name: binary_coercible(oid, oid); Type: FUNCTION; Schema: public; Owner:
>>> postgres
>> Um, that tag is the "name", and if you change that, the name in CREATE
>> FUNCTION also changes.
> So?
Actu
On Mon, Jan 11, 2010 at 8:27 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Sun, Jan 10, 2010 at 4:54 PM, Tom Lane wrote:
>> > Robert Haas writes:
>> >> I have looked this over a little bit and I guess I don't see why the
>> >> lack of a grand plan for how to organize all of our permissions
We've been chewing around query cancel on Hot Standby and I think things
have got fairly confusing, hence a new thread.
I enclose a patch that includes all the things that we all agree on so
far, in my understanding
* Recovery conflict processing uses SIGUSR1 rather than shmem per Tom,
while hol
Robert Haas writes:
> On Mon, Jan 11, 2010 at 8:27 PM, Bruce Momjian wrote:
>> I agree. Why are arbitrary restrictions being placed on code
>> improvements? If code has no purpose, why not remove it, or at least
>> mark it as NOT_USED.
> So, where do we go from here? Any other opinions? I'm
Robert Haas wrote:
> So, where do we go from here? Any other opinions?
It seems that we often have people cleaning up redundant or
unreachable code to improve code clarity. I'm not in a position
right now to confirm that this code is redundant, but if that has
been firmly established, I have
Hello all,
I am a student-magister and I'm writting my magister work. I realized gist
index TPR tree - it is like a simple R tree but moving :)
Everything is compiling ok, I creating table and index, but after whese code
- DB is restarting :(((
*
*
*set enable_seqscan = false
select * from table_o
On Wed, Jan 13, 2010 at 1:15 PM, Robert Haas wrote:
>
> So, where do we go from here? Any other opinions?
if it's not broken, then it doesn't need a fix...
if that code is causing a hole in security then i said remove it, if
not... what's the problem in let it be until we know exactly what the
p
I want to add than I have a piece of my code that looks very strange
Datum gist_mov_penalty(PG_FUNCTION_ARGS)
{
GISTENTRY *origentry = (GISTENTRY *) PG_GETARG_POINTER(0);
GISTENTRY *newentry = (GISTENTRY *) PG_GETARG_POINTER(1);
float * result = (float *) PG_GETARG_POINTER(2);
* m
Hi Simon,
On Wednesday 13 January 2010 19:24:22 Simon Riggs wrote:
> We've been chewing around query cancel on Hot Standby and I think things
> have got fairly confusing, hence a new thread.
Good idea.
> I enclose a patch that includes all the things that we all agree on so
> far, in my understan
January 13, 2010
PostgreSQL Conference East, The PostgreSQL Conference for Decision
Makers, End Users and Developers, is being held at the Radisson Plaza,
Warwick Hotel in Philadelphia on March 25th through 28th.
This is the second call for papers for this conference. You can review
the skeletal
Sergej,
> I can not understand why DB is restarting ? It is restarting when SQL
> begins use index :(((
> Can anybody help me , I would by appretiate every people who downloads
> my sources, try to deploy index and maybe solve where is the problem.
It would help if you gave people a link.
Also,
Tom Lane írta:
> Boszormenyi Zoltan writes:
>
>> Tom Lane írta:
>>
>>> If this patch is touching those parts of relcache.c, it probably needs
>>> rethinking.
>>>
>
>
>> What I did there is to check the return value of LockRelationOid()
>> and also elog(PANIC) if the lock wasn't a
On Wed, Jan 13, 2010 at 1:16 PM, Josh Berkus wrote:
>
>> My argument would be now, what is the benefit of the James Pye version
>> over our version. James can you illustrate succinctly why we should be
>> supporting a new version?
>>
>> If there is, I am still all for it, but I am a python bigot.
On Wed, Jan 13, 2010 at 1:42 PM, Sergej Galkin wrote:
> I can not understand why DB is restarting ? It is restarting when SQL begins
> use index :(((
> Can anybody help me , I would by appretiate every people who downloads my
> sources, try to deploy index and maybe solve where is the problem.
Yo
On Wed, 2010-01-13 at 19:58 +0100, Andres Freund wrote:
> > I am still testing patch, so should be confident to commit tomorrow
> > barring issues.
> I have only looked at briefly because right now I dont have the time (going
> to
> eat at a friends place...) but I think I spotted an issue:
> Th
* Jaime Casanova (jcasa...@systemguards.com.ec) wrote:
> if it's not broken, then it doesn't need a fix...
> if that code is causing a hole in security then i said remove it, if
> not... what's the problem in let it be until we know exactly what the
> plan is?
The chances of getting concensus on a
Zdenek Kotala writes:
> I found following strange error on gothic moth:
>VACUUM FULL pg_class;
> + ERROR: deadlock detected
> + DETAIL: Process 5913 waits for AccessExclusiveLock on relation 2662
> of database 16384; blocked by process 5915.
> + Process 5915 waits for AccessShareLock on re
I debugged index with gdb and found that it is segmentation fault in my
procedure named *gist_mov_consistent* it is only 7 lines. So I think it is
worth to publish it to public,
*
* *Datum gist_mov_consistent(PG_FUNCTION_ARGS)*
*{*
*GISTENTRY *entry = (GISTENTRY *)PG_GETARG_POINTER(0);*
*
This is the first of the patches to be split out from the former 'plperl
feature patch 1'.
Changes in this patch:
- Added utility functions: quote_literal, quote_nullable, quote_ident,
encode_bytea, decode_bytea, looks_like_number,
encode_array_literal, encode_array_constructor.
- Stored
And
*int obj_contains(moving_object *a, BOX *b)
{
if (b->low.x > a->x_low)
return 0;
if (b->low.y > a->y_low)
return 0;
if (b->high.x < a->x_high)
return 0;
if (b->high.y < a->y_high)
return 0;
return 1;
}*
this is the procedure obj contains
On
On Wed, Jan 13, 2010 at 1:34 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jan 11, 2010 at 8:27 PM, Bruce Momjian wrote:
>>> I agree. Why are arbitrary restrictions being placed on code
>>> improvements? If code has no purpose, why not remove it, or at least
>>> mark it as NOT_USED.
>
>
I am realizing gist index and get a bug, that crashes DB. I' debugged my
program as Robert(thanks !) advised me and I know which procedure crashed.
*Datum gist_mov_consistent(PG_FUNCTION_ARGS)*
*{*
*GISTENTRY *entry = (GISTENTRY *)PG_GETARG_POINTER(0);*
*BOX *query = PG_GETARG_BOX_P(1);*
*
Robert Haas writes:
> On Wed, Jan 13, 2010 at 1:34 PM, Tom Lane wrote:
>> If I thought this patch represented incremental movement in the
>> direction of a better security-check factorization, I'd be fine with it,
>> but that's not clear either. The argument for it is that these checks
>> are re
On Jan 13, 2010, at 11:08 AM, Joshua D. Drake wrote:
> My argument would be now, what is the benefit of the James Pye version
> over our version. James can you illustrate succinctly why we should be
> supporting a new version?
Doing so, succinctly, is unfortunately difficult.
It is primarily a ma
On Wed, 2010-01-13 at 13:06 -0700, James William Pye wrote:
> On Jan 13, 2010, at 11:08 AM, Joshua D. Drake wrote:
> > My argument would be now, what is the benefit of the James Pye version
> > over our version. James can you illustrate succinctly why we should be
> > supporting a new version?
>
>
On Wed, 13 Jan 2010, Robert Haas wrote:
2010/1/13 Teodor Sigaev :
CREATE INDEX bloomidx ON tbloom(i1,i2,i3)
WITH (length=5, col1=2, col2=2, col3=4);
Here, we create bloom index with signature length 80 bits and attributes
i1, i2 mapped to 2 bits, attribute i3 - to 4 bits.
This is pret
robertmh...@gmail.com (Robert Haas) writes:
> On Fri, Jan 8, 2010 at 10:12 AM, Dave Page wrote:
>>> I have long spoken against making Windows a second class citizen. But I
>>> don't think David is going to do that (and I'll hound him if he does). But
>>> that doesn't mean it has to be fully suppor
On Wed, Jan 13, 2010 at 12:54, Tom Lane wrote:
> I'm a little worried by Stephen's plan, mainly because I'm concerned
> that it would lead to ALTER TABLE taking exclusive lock on a table long
> before it gets around to checking permissions. Still, that's just
> extending a window that exists now.
On Wed, Jan 13, 2010 at 13:46, Alex Hunsaker wrote:
> Im of the opinion if we are going to be meddling with the permission
> checks [...]
Specifically:
http://archives.postgresql.org/pgsql-hackers/2009-05/msg00566.php
Sounds like most solutions would put us back to exactly what you were
trying t
* Alex Hunsaker (bada...@gmail.com) wrote:
> On Wed, Jan 13, 2010 at 12:54, Tom Lane wrote:
> > I'm a little worried by Stephen's plan, mainly because I'm concerned
> > that it would lead to ALTER TABLE taking exclusive lock on a table long
> > before it gets around to checking permissions. Still
On ons, 2010-01-13 at 12:12 -0800, Joshua D. Drake wrote:
> On Wed, 2010-01-13 at 13:06 -0700, James William Pye wrote:
> > Function Modules:
> > - Does away with the need for GD/SD (more natural Python environment).
> > - Allows tracebacks (tracebacks are useful, right?) to implemented easily.
>
Boszormenyi Zoltan írta:
> Tom Lane írta:
>
>> Boszormenyi Zoltan writes:
>>
>>
>>> Tom Lane írta:
>>>
>>>
If this patch is touching those parts of relcache.c, it probably needs
rethinking.
>>
>>
>>> What I did there is to check th
* Alex Hunsaker (bada...@gmail.com) wrote:
> On Wed, Jan 13, 2010 at 13:46, Alex Hunsaker wrote:
> > Im of the opinion if we are going to be meddling with the permission
> > checks [...]
>
> Specifically:
> http://archives.postgresql.org/pgsql-hackers/2009-05/msg00566.php
>
> Sounds like most so
Alex Hunsaker writes:
> Im of the opinion if we are going to be meddling with the permission
> checks in this area one of the goals should be close or at least
> tighten up that window. So you cant lock a table you dont have
> permission to (either via LOCK or ALTER TABLE). (Ignoring the issues
Michael Meskes wrote:
Hans,
nce Jaime already asked for a use case, just a few small comments from
me.
@@ -4,6 +4,7 @@
#include "postgres_fe.h"
#include
+#include
This is not portable. You don't want to include this header.
Did I see this right that you use the statement cache
On Wed, 2010-01-13 at 23:27 +0200, Peter Eisentraut wrote:
> The problem I'm having with this discussion is that every time someone
> asks what the supposed advantages of this new Python PL are, a feature
> list like the above is dumped, 75% of which is subjective and tends to
> use semi-buzzwords
When you look at a table definition with psql \d, one of the arguably
most important pieces of information -- the primary key -- is hidden
somewhere below under "indexes":
Table "public.test2"
Column | Type | Modifiers
+-+---
a | integer | not null
b | i
Hans-Juergen Schoenig writes:
> Michael Meskes wrote:
>> Before looking into it in detail I think we should first figure out if this
>> feature really has a benefit.
> the use cases for this thing are quite simple: we are currently porting
> hundreds (!) of complex Informix terminal applications
On ons, 2010-01-13 at 13:33 -0800, Joshua D. Drake wrote:
> The only thing I am currently looking for is an objective review of the
> patch based on the benefits it provides.
Right, but I was opining that such a vague feature listing is not
adequate for that.
> I can tell you that if the Pye
> pa
Peter Eisentraut writes:
> I think we could easily improve that by having it look something like
> this instead:
> Table "public.test2"
> Column | Type | Modifiers
> +-+---
> a | integer | PK
> b | integer | PK
> Indexes:
> "test2_pkey" PRIMARY KEY,
I was surprised/annoyed to find out that there is no way to have
per-user pg_service.conf, something like ~/.pg_service.conf (well,
except by export PGSYSCONFDIR). That would be easy to add. Comments?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Robert Haas wrote:
> Nope, you're on target. Although - if I were you - I would post
> the ACCESS EXCLUSIVE lock version of the patch for feedback. I
> can't speak for anyone else, but I'll read it.
Here you go! :-)
This is the milestone of having full serializable behavior, albeit
with h
On Wed, Jan 13, 2010 at 4:47 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> I think we could easily improve that by having it look something like
>> this instead:
>
>> Table "public.test2"
>> Column | Type | Modifiers
>> +-+---
>> a | integer | PK
>> b
On Wed, Jan 13, 2010 at 4:42 PM, Tom Lane wrote:
> Hans-Juergen Schoenig writes:
>> Michael Meskes wrote:
>>> Before looking into it in detail I think we should first figure out if this
>>> feature really has a benefit.
>
>> the use cases for this thing are quite simple: we are currently porting
On Wed, Jan 13, 2010 at 9:34 PM, Heikki Linnakangas
wrote:
> No, that's not an issue. We only wait for the backup-end record if we
> haven't seen yet since we started recovery from the base backup.
> Assuming the standby had reached that point already before the new
> backup from the standby start
"Kevin Grittner" wrote:
> Here you go! :-)
Hmmm... I just got a write skew example to show a snapshot
isolation anomaly, so I've got something wrong still. :-(
Will continue to work on it. Sorry.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
"Kevin Grittner" wrote:
> This is the milestone of having full serializable behavior, albeit
> with horrible performance, using the simplest implementation
> possible.
A tad too simple, as it turns out. It did it's main job of
providing a simple milestone to identify code organization and loc
Peter Eisentraut writes:
> I was surprised/annoyed to find out that there is no way to have
> per-user pg_service.conf, something like ~/.pg_service.conf (well,
> except by export PGSYSCONFDIR). That would be easy to add. Comments?
+1.
I'll use it the day it exists.
--
dim
--
Sent via pgsql
On Wed, Jan 13, 2010 at 11:49:59PM +0200, Peter Eisentraut wrote:
> I was surprised/annoyed to find out that there is no way to have
> per-user pg_service.conf, something like ~/.pg_service.conf (well,
> except by export PGSYSCONFDIR). That would be easy to add. Comments?
+1 from me. I was simil
Patch authors, please make sure your patches are listed on
commitfest.postgresql.org.
https://commitfest.postgresql.org/action/commitfest_view/open
All, we still need reviewers for the following patches.
New XLOG record indicating WAL-skipping
Fix large object support in pg_dump
knngist (WIP)
pl
Pavel Stehule wrote:
> ok, I accept all comments.
> revised version are attached.
Good. This patch is ready to commit. I'll do it soon if no objections.
BTW, I found inconsistent parameter dumps in the codes. Some of them
add '$', but others does not. Are they intentional? Or, should we
adjust
(2010/01/14 4:54), Tom Lane wrote:
Robert Haas writes:
On Wed, Jan 13, 2010 at 1:34 PM, Tom Lane wrote:
If I thought this patch represented incremental movement in the
direction of a better security-check factorization, I'd be fine with it,
but that's not clear either. �The argument for it is
(2010/01/14 4:27), Stephen Frost wrote:
> * Jaime Casanova (jcasa...@systemguards.com.ec) wrote:
>> if it's not broken, then it doesn't need a fix...
>> if that code is causing a hole in security then i said remove it, if
>> not... what's the problem in let it be until we know exactly what the
>> p
I noticed odd stuff showing up when I fired up an 8.3 psql after using psql in
HEAD. It shows up in .psql_history as well:
deci...@platter.1[20:32]~:5%tail -n 2 .psql_history
\134df+\040tools.raise_exception
\df+ tools.raise_exception
deci...@platter.1[20:35]~:6%
(last entry is from the 8.3 psql
Hi,
We support several methods for logging server messages. The "native" methods
(stderr, csvlogs) has poor management. We can't compress logs, send them to
another location/server, or just remove old ones. Another problem is that we
can't remove (automatically) old logs based on the number of exi
Jim Nasby writes:
> I noticed odd stuff showing up when I fired up an 8.3 psql after using psql
> in HEAD. It shows up in .psql_history as well:
Platform? readline version?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Euler Taveira de Oliveira writes:
> I want to propose a new command to be execute after the log file is
> rotated.
(1) Windows compatibility?
(2) What happens if the command takes a significant amount of time to
execute? We can't afford to have the log collector blocked.
(3) What do you intend
The similar matter can be reproduced with ALTER TABLE ... TYPE statement,
not only RENAME TO option.
postgres=# CREATE TABLE t1 (a int);
CREATE TABLE
postgres=# CREATE TABLE s1 (a int);
CREATE TABLE
postgres=# CREATE TABLE ts (b int) inherits (t1, s1);
NOTICE: merging multiple inheri
Euler Taveira de Oliveira wrote:
> other log management softwares have a way to do that so why our logger doesn't
> have such capability?
>
> I want to propose a new command to be execute after the log file is rotated. A
> GUC parameter log_after_rotation_command that takes a (set of) command(s
Takahiro Itagaki writes:
> The attached patch eliminates unneeded parentheses by using
> pg_get_triggerdef(pretty = true) in psql.
Is this patch reversed? It seems so but the listed file timestamps
don't match that idea ...
regards, tom lane
--
Sent via pgsql-hackers m
On Jan 13, 2010, at 2:27 PM, Peter Eisentraut wrote:
> The problem I'm having with this discussion is that every time someone
> asks what the supposed advantages of this new Python PL are, a feature
> list like the above is dumped,
I agree that this is unfortunate, but how else can we to discuss t
On Jan 13, 2010, at 12:15 PM, Robert Haas wrote:
> 1. It's not just a rewrite, it's an incompatible rewrite that will
> present significant user-visible behavioral differences. So replacing
> the current implementation wholesale would produce massive breakage
> for anyone actually using PL/python
Tom Lane wrote:
> Takahiro Itagaki writes:
> > The attached patch eliminates unneeded parentheses by using
> > pg_get_triggerdef(pretty = true) in psql.
>
> Is this patch reversed? It seems so but the listed file timestamps
> don't match that idea ...
Sorry, I cannot understand what you mean
Takahiro Itagaki writes:
> Tom Lane wrote:
>> Is this patch reversed? It seems so but the listed file timestamps
>> don't match that idea ...
> Sorry, I cannot understand what you mean...
The patch looks like it removes, rather than adds, your intended
changes.
regards
KaiGai Kohei wrote:
(2010/01/14 4:54), Tom Lane wrote:
Robert Haas writes:
On Wed, Jan 13, 2010 at 1:34 PM, Tom Lane wrote:
If I thought this patch represented incremental movement in the
direction of a better security-check factorization, I'd be fine
with it,
but that's not clear either.
The attached patch fixes bugs when we try to rename (and change type) on
a column inherited from the different origin and merged.
This patch adds:
List *find_column_origin(Oid relOid, const char *colName)
It returns the list of relation OIDs which originally defines the given
column. In most c
James William Pye wrote:
On Jan 13, 2010, at 2:27 PM, Peter Eisentraut wrote:
The problem I'm having with this discussion is that every time someone
asks what the supposed advantages of this new Python PL are, a feature
list like the above is dumped,
I agree that this is unfortunate, b
2010/1/14 Takahiro Itagaki :
>
> Pavel Stehule wrote:
>
>> ok, I accept all comments.
>> revised version are attached.
>
> Good. This patch is ready to commit. I'll do it soon if no objections.
>
> BTW, I found inconsistent parameter dumps in the codes. Some of them
> add '$', but others does not.
Hi,
3) A nice set of SQL queries to return message, parts, threads,
folders based on $criteria (search, id, folder, etc)
I guess Matteo's working on that…
Right, but this is where I want to see the AOX schema "imporove"... In
ways like adding persistant tables for threading, which are up
96 matches
Mail list logo
