Sorry, I've missed sending copy to list, so I quoted off-list discussion.
> On Aug 5, 2011, at 7:59 PM, Shigeru Hanada
wrote:
>
>> 2011/8/6 Robert Haas:
>>> Done.
>>
>> Thanks!
>>
>>> Incidentally, I notice that if you do:
>>>
>>> \d some_foreign_table
>>>
>>> ...the table-level options are not di
I noticed that psql document wrongly says that \d+ command shows
per-table FDW options of a foreign table, but in fact, per-table FDW
options are shown only in the result of \det+ command. Attached patch
removes this wrong description.
This fix should be applied to 9.1 too.
Regards,
--
Shigeru
Thanks Josh,
I like the ability to bail out on PQTRANS_INERROR, and I think it's a small
enough fix to be appropriate to include in this patch.
I did consider it before but did not implement it because I am still new to
pgsql-hackers and did not know how off-the-cuff.
So thanks for the big improvem
On 08/07/2011 07:06 PM, Tim Bunce wrote:
After a little digging and some discussion on the #p5p channel [thanks
to ilmari++ leont++ and sorear++ for their help] it seems that local(%SIG)
doesn't do what you might expect. The %SIG does become empty but the OS
level handlers, even those installe
[I've included a summary of the thread and Bcc'd this to perl5-porters
for a sanity check. Please trim heavily when replying.]
On Thu, Aug 04, 2011 at 09:42:31AM -0400, Andrew Dunstan wrote:
>
> So doesn't this look like a bug in the perl module that sets the
> signal handler and doesn't restore
On Sun, Aug 7, 2011 at 3:54 AM, Tim wrote:
>
> Excerpts from Josh's message On Sun, Aug 7, 2011 at 2:36 AM:
>>
>> could we figure out what that limit should be based on
>> max_locks_per_transaction?
>
> It would be nice to implement via "-l max" instead of making users do it
> manually or somethin
Hi!
There is last version of patch. There is the list of most significant
changes in comparison with your version of patch:
1) Reference counting of path items was added. It should helps against
possible accumulation of path items.
2) Neighbor relocation was added.
3) Subtree prefetching was added
I suspected $SUBJECT from the beginning, and I've now put in enough work
to be able to prove it. The attached test program reliably fails within
a few minutes of being started, when run with 8 worker processes on an
8-core PPC machine. It's a pretty simple "token passing ring" protocol,
and at so
Kohei KaiGai writes:
> I'm under implementation of this code according to the suggestion.
> However, I'm not sure whether it is really portable way (at least, GCC
> accepts),
> and whether the interface is simpler than as Robert suggested at first.
> #define get_object_property_attnum_name(objty
Hi all, does anybody work on this TODO item?
http://wiki.postgresql.org/wiki/Todo#PL.2FpgSQL
I didn't find any related posting/bug report.
w.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hack
On Aug 7, 2011, at 11:01 AM, Simon Riggs wrote:
> On Sun, Aug 7, 2011 at 8:57 AM, Hannu Krosing wrote:
>> In 9.0 (as in earlier versions) a former standby host has to do a full
>> checkpoint before becoming available as an independent database instance
>> in either switchover or failover scenari
On Sat, Aug 6, 2011 at 7:29 PM, Dimitri Fontaine wrote:
> Tom Lane writes:
>> I think we'll be a lot better off with the framework discussed last
>> year: build a generic plan, as well as custom plans for the first few
>> sets of parameter values, and then observe whether there's a significant
>>
On lör, 2011-08-06 at 12:58 +0100, Dean Rasheed wrote:
> Right now \d gives:
>
> Table "public.foo"
> Column | Type | Modifiers
> +-+---
> a | integer | not null
> b | integer |
> c | integer |
> Check constraints:
> "foo_b_check" CHECK (b IS
On Sun, 2011-08-07 at 11:15 +0200, Hannu Krosing wrote:
> On Wed, 2011-08-03 at 15:19 -0400, Tom Lane wrote:
> > Hm, you mean reverse-engineering the parameterization of the query?
>
> Yes, basically re-generate the query after (or while) parsing, replacing
> constants and arguments with another
On Wed, 2011-08-03 at 15:19 -0400, Tom Lane wrote:
> Robert Haas writes:
> > This seems like a good design. Now what would be really cool is if
> > you could observe a stream of queries like this:
>
> > SELECT a, b FROM foo WHERE c = 123
> > SELECT a, b FROM foo WHERE c = 97
> > SELECT a, b FROM
On Sun, Aug 7, 2011 at 8:57 AM, Hannu Krosing wrote:
> In 9.0 (as in earlier versions) a former standby host has to do a full
> checkpoint before becoming available as an independent database instance
> in either switchover or failover scenarios.
>
> For most combinations of of bigger than minimal
Excerpts from Peter's message On Sun, Aug 7, 2011 at 3:49 AM:
> Please put the new option 'l' in some sensible order in the code and the
> help output (normally alphabetical). Also, there should probably be
> some update to the documentation.
>
I have alphabetized the help output, and one piece
>>> So add a bunch of macros on top for the two or three (five?) most common
>>> cases -- say those that occur 3 times or more.
>>
>> I could go for that.
>>
> OK, I'll try to implement according to the idea.
>
I'm under implementation of this code according to the suggestion.
However, I'm not sure
In 9.0 (as in earlier versions) a former standby host has to do a full
checkpoint before becoming available as an independent database instance
in either switchover or failover scenarios.
For most combinations of of bigger than minimal shared buffers and
non-memory-speed disks this can take from
Excerpts from Josh's message On Sun, Aug 7, 2011 at 2:36 AM:
> could we figure out what that limit should be based on
> max_locks_per_transaction?
It would be nice to implement via "-l max" instead of making users do it
manually or something like this "-l $(grep "max_locks_per_transaction.*="
po
On sön, 2011-08-07 at 00:41 -0400, Tim wrote:
> Thanks for help. Attached is a patch including changes suggested in your
> comments.
Please put the new option 'l' in some sensible order in the code and the
help output (normally alphabetical). Also, there should probably be
some update to the docu
21 matches
Mail list logo
