2011/7/2 Tom Lane :
> Kohei KaiGai writes:
>> The origin of matter is, as you mentioned, collation to be used for system
>> catalog scan when we reference it via syscache.
>> So, the following chunk should be added, as I did in the userspace access
>> vector patch - part.1.
>
>> @@ -934,8 +935,7
[ I'm a bit late to the party on this thread, but anyway: ]
Robert Haas writes:
> On Fri, Jun 24, 2011 at 7:51 PM, Greg Smith wrote:
>> On 06/24/2011 03:28 PM, Christopher Browne wrote:
>>> I expect that the correlation between commit and [various parties] is
>>> something that will need to take
Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > On m?n, 2011-06-27 at 14:34 -0400, Bruce Momjian wrote:
> > > Bruce Momjian wrote:
> > > > Robert Haas wrote:
> > > > > It's easier to read the patches if you do separate changes in separate
> > > > > patches. Anyway, I'm a bit nervous about this
Heikki Linnakangas writes:
> I couldn't resist looking into this, and came up with the attached
> patch. I tested this with:
> CREATE TABLE words (word text);
> COPY words FROM '/usr/share/dict/words';
> CREATE INDEX i_words ON words USING gist (word gist_trgm_ops);
> And then ran "REINDEX INDE
Magnus Hagander writes:
> On Fri, Jul 1, 2011 at 03:36, Alvaro Herrera
> wrote:
>> I don't understand why it is so much a deal that 9.1 has a different CSV
>> table definition than 9.0 anyway (or any two release combination).
> I don't see that as a big problem either. A file header would make
On 1 July 2011 23:57, David Fetter wrote:
> Folks,
>
> Now that there's a (very minor) crypto fix and a new DST ruleset, when
> can we get the next set of minor revs out the door?
Do we know how many identified bugs are still outstanding? There's at
least the SSPI issue for which a patch has bee
Folks,
Now that there's a (very minor) crypto fix and a new DST ruleset, when
can we get the next set of minor revs out the door?
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.com
iCal:
Robert Haas writes:
> On Wed, Jun 29, 2011 at 8:53 PM, David Fetter wrote:
>> How about this?
>>
>> PostgreSQL grants some types of objects some default privileges to
>> PUBLIC. Tables, columns, schemas and tablespaces grant no privileges
>> to PUBLIC by default. For other types, the default p
Kohei KaiGai writes:
> The origin of matter is, as you mentioned, collation to be used for system
> catalog scan when we reference it via syscache.
> So, the following chunk should be added, as I did in the userspace access
> vector patch - part.1.
> @@ -934,8 +935,7 @@ CatalogCacheInitializeCa
Alvaro Herrera writes:
> This simple patch moves two struct declarations (Trigger and
> TriggerDesc) from rel.h into a new file, reltrigger.h. The benefit is
> that execnodes.h only needs to include the latter. Since execnodes.h is
> very widely included, this change means there are less files t
Robert,
> That sounds reasonable to me. I'll be on vacation then, but (1) I'm
> not really involved in pushing the release out the door and (2) I
> should have Internet access if push comes to shove.
We seem to still have some blockers ...
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexper
On Thu, Jun 30, 2011 at 16:35, Stephen Frost wrote:
> I do want to rework the logging infrastructure (as discussed in the dev
> meeting), but I see that whole thing as rather orthogonal to this
> change.
*Shrug* Fine by me, im not going to argue that you should or shouldn't
rework the logging in
Stephen Frost writes:
> * Alex Hunsaker (bada...@gmail.com) wrote:
>> I think if Stephen was proposing 10 fields, or if there was a list of
>> fields we were planning on adding in the next release or 3, it might
>> be worth re-factoring.
>
> I know of at least one person (in an earlier piece of
On Fri, Jul 1, 2011 at 10:32 AM, Robert Haas wrote:
> On Fri, Jul 1, 2011 at 8:06 AM, Amit Khandekar
> wrote:
>> In 9.1, if a table is created using an explicit pg_temp qualification,
>> the pg_class.relpersistence is marked 'p', not 't'.
>
> That's a bug. Thanks for the report.
OK, so I think
2011/6/2 Noah Misch :
> On Wed, Jun 01, 2011 at 10:26:34PM -0400, Josh Kupershmidt wrote:
>> On Wed, Jun 1, 2011 at 5:55 PM, Noah Misch wrote:
>> > On Sun, May 29, 2011 at 10:56:02AM -0400, Josh Kupershmidt wrote:
>> >> Looking around, I see there were real problems[1] with sending SIGTERM
>> >> t
Simon Riggs writes:
> On Fri, Jul 1, 2011 at 2:42 PM, Erik Rijkers wrote:
>
>> Two questions:
>>
>> 1. How to query a session to make absolutely sure that replication is
>> actually synchronous?
>
> Check synchronous_standby_names and synchronous commit for appropriate values.
>
also check pg_
On Fri, Jul 1, 2011 at 2:42 PM, Erik Rijkers wrote:
> Two questions:
>
> 1. How to query a session to make absolutely sure that replication is
> actually synchronous?
Check synchronous_standby_names and synchronous commit for appropriate values.
> 2. Does sync-repl really need synchronous_stan
On Fri, Jul 1, 2011 at 8:06 AM, Amit Khandekar
wrote:
> In 9.1, if a table is created using an explicit pg_temp qualification,
> the pg_class.relpersistence is marked 'p', not 't'.
>
> postgres=# CREATE TABLE pg_temp.temptable (i int4);
> CREATE TABLE
>
> postgres=# select relpersistence from pg_c
I'm testing synchronous replication on 9.2devel - both instances are on a
single machine.
The primary shows synchronous_commit = on
and synchronous_standby_names = ''.
The standby receives updates fine.
Now, does the 'synchronous_commit = on' absolutely mean that the session is
sync-replicatin
In 9.1, if a table is created using an explicit pg_temp qualification,
the pg_class.relpersistence is marked 'p', not 't'.
postgres=# CREATE TABLE pg_temp.temptable (i int4);
CREATE TABLE
postgres=# select relpersistence from pg_class where relname = 'temptable';
relpersistence
>
>
> http://archives.postgresql.org/pgsql-hackers/2008-12/msg01335.php
> According to the above thread, this issue seems to exist for a few years,
> and be unsolved yet. Could you provide a self-contained test case?
I can try ...
In related to this, after the failover we got several other worry
2011/6/30 Alvaro Herrera :
> Excerpts from 花田 茂's message of jue jun 30 06:00:23 -0400 2011:
>
>> I attached a patch which fixes file_fdw to check required option
>> (filename) in its validator function. I think that such requirement
>> should be checked again in PlanForeignScan(), as it had been
New version of patch. Now, it seems that all code is covered by comments.
Also I'm going to write readme with general description of algorithm. Some
bugs were fixed.
More options were added. Options description is below.
1) fastbuild - whether to fast build algorithm. Default is true.
2) levelstep
On Fri, Jul 1, 2011 at 6:54 AM, Fujii Masao wrote:
> http://archives.postgresql.org/pgsql-hackers/2008-12/msg01335.php
> According to the above thread, this issue seems to exist for a few years,
> and be unsolved yet. Could you provide a self-contained test case?
I'll add some more logging to he
In fdwhandler.sgml, chapter fdwhandler has only one subsection
(fdw-routines).
If there is only one subsection, no table of contents is generated in
the chapter.
That means that people who navigate to the chapter from the main table
of contents
will not see that there is a subsection.
I know too
25 matches
Mail list logo
