Hello
2011/11/21 Josh Berkus :
> All,
>
> When I present to people about the features of 9.1, one of the most
> frequent questions is when we will get writeable FDWs for data sources
> where it is appropriate. Is anyone working on this?
just note - it is relative complex feature - and need 2PC
>> On 22.11.2011 06:55, Pavel Stehule wrote:
>>> I know so dblink is "deprecated" interface - but it has necessary
>>> functionality still - it support a writable statements.
>
> So, "dblink on FDW connection" seems to be a possible solution.
> We pass a query as a form of a plain text.
>
> --
it
I wrote:
> For the range-type support functions, it would be simple enough to check
> call permission at range-type definition time. But I really don't want
> to put in a run-time check, because there doesn't seem to be a very
> practical way to do it less often than every call, and besides that i
Florian Pflug writes:
> More formally, let there be two arbitrary ranges
> a,b,i_a,i_b
> c,d,i_c,i_d
> where the first two parameters are the lower respectively upper bound, and
> the last two are booleans saying whether the lower respectively upper bound
> is inclusive (true) or exclusive (fa
On 21 November 2011 22:55, Robert Haas wrote:
> Results on my machine, for what they're worth:
I was curious as to how much of an improvement I'd made to sorting in
isolation. I've adding simple sort timing instrumentation to the code
in a revised patch, attached, for the convenience of reviewers
On Tue, Nov 22, 2011 at 11:40 PM, Simon Riggs wrote:
>> I think this is unsafe for shared catalogs.
>
> I think so too. Thats why it uses IsMVCCSnapshot() to confirm when it
> is safe to do so.
>
Ah, you mean access to shared catalogs using MVCC snapshots.
Fixed.
--
Simon Riggs
Peter Eisentraut writes:
> One thing that isn't so nice about all this is that it embeds the
> personal directory structure of the builder of the binary into the
> shipped product. But gcc's cpp doesn't like redefining __FILE__, so the
> only way to get around that altogether would be to use some
Oliver Jowett writes:
> On 23 November 2011 10:47, Mikko Tiihonen
> wrote:
>> Here is a patch that adds a new flag to the protocol that is set when all
>> elements of the array are of same fixed size.
> How does a client detect that this feature is supported?
The only way that anything like thi
On 23 November 2011 10:47, Mikko Tiihonen
wrote:
> Here is a patch that adds a new flag to the protocol that is set when all
> elements of the array are of same fixed size.
> When the bit is set the 4 byte length is only sent once and not for each
> element. Another restriction is that the flag
>
On Tue, Nov 22, 2011 at 9:21 PM, Robert Haas wrote:
> On Tue, Nov 22, 2011 at 3:23 PM, Simon Riggs wrote:
>> Some time ago, I changed GetOldestXmin() to ignore procs in other
>> databases resulting in a potentially later xmin.
>>
>> GetSnapshotData() was not touched when that happened, even thoug
It strikes me that we are rather lacking in $SUBJECT. There are a
couple of distinct issues:
1. Since no permissions checks are applied at runtime, a nefarious
person could bypass ACL_EXECUTE checks for any function that happens
to match the signature for a subtype_diff function. Just create a
r
Peter Eisentraut wrote:
> On tis, 2011-11-22 at 15:42 -0500, Bruce Momjian wrote:
> > Peter Eisentraut wrote:
> > > I thought these were fixed a while ago, but I'm still seeing these when
> > > upgrading from master to self (using testing script sent in a while
> > > ago). This is completely repr
On Tue, Nov 22, 2011 at 3:47 PM, Mikko Tiihonen
wrote:
> Hi,
>
> During conversion of the jdbc driver to use binary encoding when receiving
> array objects from postgres it was noticed
> that for example for int[] arrays the binary encoding is normally 30% to
> 200% larger in bytes than the text e
Robert Haas wrote:
> Updated patches attached.
I've gotten through several days of performance tests for this pair
of related patches, with results posted on a separate thread. I'll
link those in to the CF application shortly. To summarize the other
(fairly long) thread on benchmarks, it see
On Tue, Nov 22, 2011 at 11:47:22PM +0200, Mikko Tiihonen wrote:
> Hi,
>
> During conversion of the jdbc driver to use binary encoding when receiving
> array objects from postgres it was noticed
> that for example for int[] arrays the binary encoding is normally 30% to 200%
> larger in bytes than
On tis, 2011-11-22 at 15:42 -0500, Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > I thought these were fixed a while ago, but I'm still seeing these when
> > upgrading from master to self (using testing script sent in a while
> > ago). This is completely reproducible. What's happening?
> >
Hi,
During conversion of the jdbc driver to use binary encoding when receiving
array objects from postgres it was noticed
that for example for int[] arrays the binary encoding is normally 30% to 200%
larger in bytes than the text encoding.
This was of concern to some users with slower links to
On Tue, Nov 22, 2011 at 3:23 PM, Simon Riggs wrote:
> Some time ago, I changed GetOldestXmin() to ignore procs in other
> databases resulting in a potentially later xmin.
>
> GetSnapshotData() was not touched when that happened, even though the
> comments say "...This is the same computation done
On Mon, Nov 21, 2011 at 6:38 AM, Albe Laurenz wrote:
> Kohei KaiGai wrote:
>> The attached patch is a revised version.
>> It fixed up this bug, and revised test cases to ensure permission
>> check error shall be raised due to the new table.
>
> Thanks.
> The second patch seems fine to me, I'll mar
Peter Eisentraut wrote:
> I thought these were fixed a while ago, but I'm still seeing these when
> upgrading from master to self (using testing script sent in a while
> ago). This is completely reproducible. What's happening?
>
> ...
> Restoring user relation files
> /home/peter/devel/postgr
Some time ago, I changed GetOldestXmin() to ignore procs in other
databases resulting in a potentially later xmin.
GetSnapshotData() was not touched when that happened, even though the
comments say "...This is the same computation done by
GetOldestXmin(true, true)." The transam/README file says it
I thought these were fixed a while ago, but I'm still seeing these when
upgrading from master to self (using testing script sent in a while
ago). This is completely reproducible. What's happening?
...
Restoring user relation files
/home/peter/devel/postgresql/git/postgresql/contrib/pg_upgra
M
Excerpts from Peter Eisentraut's message of mar nov 22 16:22:15 -0300 2011:
> One thing that isn't so nice about all this is that it embeds the
> personal directory structure of the builder of the binary into the
> shipped product. But gcc's cpp doesn't like redefining __FILE__, so the
> only wa
Hackers,
WIP patch with index support for regexp search for pg_trgm contrib is
attached.
In spite of techniques which extracts continuous text parts from regexp,
this patch presents technique of automatum transformation. That allows more
comprehensive trigrams extraction.
A little example of poss
On fre, 2011-11-18 at 09:44 -0500, Tom Lane wrote:
> It wouldn't be that hard for elog.c to do strrchr(fname, '/') or
> something like that, but the idea that there are hundreds of full-path
> strings embedded in the executable is a bit annoying. I guess we
> could
> hope that the compiler is brig
Pavan Deolasee wrote:
> The numbers are not that bad, but definitely not as good as we saw
> on some other platforms.
Well, this machine is definitely designed to hold up under high
concurrency. As I understand it, each core is the memory manager
for two 4GB DIMMs, with two channels to them,
On Tue, Nov 22, 2011 at 4:40 AM, Kevin Grittner
wrote:
> Pavan Deolasee wrote:
>
>> It will be a great help if you could spare few minutes to also
>> test the patch to take out the frequently accessed PGPROC members
>> to a different array. We are seeing good improvements on HPUX IA
>> platform a
Jeff Davis writes:
> It's a little strange that we allow people to define functions with one
> argument and the same name as a type if such functions are confusing.
As long as your mental model is that such a function is a cast,
everything is fine. The trouble with the range constructors is that
Excerpts from Tom Lane's message of mar nov 22 01:14:33 -0300 2011:
> Alvaro Herrera writes:
> > ERROR: left link changed unexpectedly in block 3378 of index "index_name"
> > CONTEXT: automatic vacuum of table "table_name"
>
> > This was reported not once, but several dozens of times, by eac
On Tue, 2011-11-22 at 09:07 -0500, Robert Haas wrote:
> I honestly don't know what function names people will pick, and I
> don't care. Someone might like singleton(x), which would be
> impractical as a built-in because there could be more than one range
> type over the same base type, but if the
Robert Haas writes:
> On Mon, Nov 21, 2011 at 8:54 PM, Tom Lane wrote:
>> We could eliminate some annoying tree-copy steps if we could institute
>> the policy that parse analysis doesn't scribble on the raw parse tree,
>> rewriter doesn't modify parse analysis output, and planner doesn't
>> modif
On Mon, Nov 21, 2011 at 8:54 PM, Tom Lane wrote:
> Robert Haas writes:
>> ... Maybe we could find a way to reduce the size of the parse
>> tree (i.e. fewer nodes), or the number of times that it has to be
>> walked/copied.
>
> We could eliminate some annoying tree-copy steps if we could institute
On Mon, Nov 21, 2011 at 9:55 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Nov 20, 2011, at 10:24 PM, Jeff Davis wrote:
>>> Well, if there were a good shorter notation, then probably so. But it
>>> doesn't look like we have a good idea, so I'm fine with dropping it.
>
>> We should also keep in
2011/11/22 Albe Laurenz :
> I tried to look at the patch, but it does not apply to current master,
> probably because of bit rot.
>
> Can you submit an updated version?
>
> The patch contains docs and regression tests and is context diff.
> I'll mark it "waiting for author".
please wait, I plan to
On 22/11/11 10:26, Kevin Grittner wrote:
Rudyar wrote:
what tool you recommend for measure the query "real" query
execution time?
The -hackers list is for discussion to coordinate development of the
PostgreSQL database product. For user questions like this, please
pick a more appropriate li
Rudyar wrote:
> what tool you recommend for measure the query "real" query
> execution time?
The -hackers list is for discussion to coordinate development of the
PostgreSQL database product. For user questions like this, please
pick a more appropriate list based on the descriptions here:
ht
I tried to look at the patch, but it does not apply to current master,
probably because of bit rot.
Can you submit an updated version?
The patch contains docs and regression tests and is context diff.
I'll mark it "waiting for author".
Yours,
Laurenz Albe
--
Sent via pgsql-hackers mailing list
On 22/11/11 02:58, Kevin Grittner wrote:
Rudyar wrote:
I try to get the execution time of a query workload. I try using
explain analyze but this time is allways higher than the execution
time of a query across a client like pgadmin3
what is the reason about that difference?
It's the "observ
On Tue, Nov 22, 2011 at 20:09, Heikki Linnakangas
wrote:
> It would be nice to add support for SQL/MED "passthrough mode"... That would
> allow you to do any queries/updates to foreign servers. It wouldn't sound
> very difficult at first glance, though I'm not sure what it would mean to
> our pars
On 22.11.2011 06:55, Pavel Stehule wrote:
I know so dblink is "deprecated" interface - but it has necessary
functionality still - it support a writable statements.
It would be nice to add support for SQL/MED "passthrough mode"... That
would allow you to do any queries/updates to foreign serve
Hello,
At Fri, 11 Nov 2011 11:29:30 +0200, Heikki Linnakangas wrote
> You could use the resource owner mechanism to track
> them. Register a callback function with
> RegisterResourceReleaseCallback().
Thank you for letting me know about it. I have dug up a message
in pg-hackers refering to the me
On Tue, Nov 22, 2011 at 2:32 AM, Tom Lane wrote:
> I wrote:
>> Simon Riggs writes:
>>> Avoid marking buffer dirty when VACUUM has no work to do.
>>> When wal_level = 'hot_standby' we touched the last page of the
>>> relation during a VACUUM, even if nothing else had happened.
>>> That would alter
On Fri, Nov 18, 2011 at 3:18 PM, Tom Lane wrote:
>> So the correct number of WAL records is emitted and I see no bug there.
>
> What Thom's complaining about is that the buffer may be marked dirty
> unnecessarily, ie when there has been no actual data change.
Based upon both your feedback, I mad
43 matches
Mail list logo
