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
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.
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
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
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.
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
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
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
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
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
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
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 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
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
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
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
(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
(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
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
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
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
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
"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
"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
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
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 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
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
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
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,
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
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
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
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
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
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
* 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
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
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.
>
* 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 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
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.
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, 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
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 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
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
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);*
*
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.
>
>
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
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
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);*
*
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
* 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
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
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, 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.
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
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,
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
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
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
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
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
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
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
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
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
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
> 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
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
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 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 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
> (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
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
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
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 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
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
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.
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
96 matches
Mail list logo
