On 26.01.2012 21:37, Peter Geoghegan wrote:
On 26 January 2012 16:48, Heikki Linnakangas
wrote:
Ok, committed with some further cleanup.
Do you think the docs need to be updated for this, and if so,
where? The only place I found in the docs that speak about how the
bgwriter works is in config
Thank you for the comment,
> First, my priority is one-the-fly result processing,
> not the allocation optimizing. And this patch seems to make
> it possible, I can process results row-by-row, without the
> need to buffer all of them in PQresult. Which is great!
>
> But the current API seems cl
On 27 January 2012 03:32, Robert Haas wrote:
> But if we want to put it on a diet, the first thing I'd probably be
> inclined to lose is the float4 specialization. Some members of the
> audience will recall that I take dim view of floating point arithmetic
> generally, but I'll concede that there
At 2012-01-15 11:08:05 -0500, and...@dunslane.net wrote:
>
> Here's an update that adds row_to_json, plus a bit more cleanup.
I've started reviewing this patch, but it'll take me a bit longer to go
through json.c properly. Here are a few preliminary notes:
1. The patch has a lot of whitespace err
On Thu, Jan 26, 2012 at 5:10 PM, Peter Geoghegan wrote:
> Alright, so while I agree with everything you've asked for, the fact
> is that there is a controversy in relation to binary bloat, and that's
> the blocker here. How can we satisfactorily resolve that, or is that
> question adequately addre
Peter Eisentraut writes:
> On mån, 2012-01-09 at 14:04 -0500, Tom Lane wrote:
>> #ifdef CATALOG_VARLEN /* variable-length fields start here
>> */
>>
>> to be even clearer.
>>
>> What would be appropriate to add instead of those inconsistently-used
>> comments is explicit comments abou
A reminder, there are three days left to get in before the deadline…
PGCon 2012 will be held 17-18 May 2012, in Ottawa at the University of
Ottawa. It will be preceded by two days of tutorials on 15-16 May 2012.
We are now accepting proposals for talks. Proposals can be quite
simple. We do not
Some other comments on the checksum patch:
I'm not sure why you moved the checksum calculation (PageSetVerificationInfo)
to mdwrite() rather than smgrwrite(). If there were every another storage
backend, it would have to duplicate the checksum check, right? Is there a
disadvantage to putting
On Jan 26, 2012, at 9:40 AM, Dimitri Fontaine wrote:
> So I'm going to prepare the next version of the patch with this design:
>
> - in catalog extension scripts for inline extension
>
> pg_extension_script(extoid, oldversion, version, script)
>
> oldversion is null when create extension is
Robert Haas writes:
> ... In an ideal world, I'd like the amount of effort we spend
> planning to be somehow tied to the savings we can expect to get, and
> deploy optimizations like this only in cases where we have a
> reasonable expectation of that effort being repaid.
BTW, so far as that goes:
Alright, so while I agree with everything you've asked for, the fact
is that there is a controversy in relation to binary bloat, and that's
the blocker here. How can we satisfactorily resolve that, or is that
question adequately addressed by the benchmark that I produced?
What if third party modul
Dimitri Fontaine writes:
>> Really I think there is not any single point where you can put the
>> command-trigger hook and be done. In almost every case, the right
>> place is going to be buried somewhere within the execution of the
>> command.
>
> I'm finally realizing it. I already introduced a
On Thu, Jan 26, 2012 at 4:09 PM, Peter Geoghegan wrote:
> On 26 January 2012 19:45, Robert Haas wrote:
>> The patch came out about 28% faster than master. Admittedly, that's
>> with no client overhead, but still: not bad.
>
> Thanks. There was a 28% reduction in the time it took to execute the
>
On 26 January 2012 19:45, Robert Haas wrote:
> The patch came out about 28% faster than master. Admittedly, that's
> with no client overhead, but still: not bad.
Thanks. There was a 28% reduction in the time it took to execute the
query, but there would have also been a larger reduction in the t
On Wed, Jan 11, 2012 at 10:12:31PM +, Simon Riggs wrote:
> v7
This patch uses FPIs to guard against torn hint writes, even when the
checksums are disabled. One could not simply condition them on the
page_checksums setting, though. Suppose page_checksums=off and we're hinting
a page previousl
On Thu, Jan 26, 2012 at 2:27 PM, Tom Lane wrote:
> Robert Haas writes:
Is there a guard in here against joining a parameterized path to an
intermediate relation when no SJ is involved? In other words, if
we're joining a parameterized path on A to a path on B, then either
the
On Thu, Jan 19, 2012 at 1:47 PM, Peter Geoghegan wrote:
> Thoughts?
I generated some random data using this query:
create table nodups (g) as select (g%10)*1000+g/10 from
generate_series(1,1) g;
And then used pgbench to repeatedly sort it using this query:
select * from nodups order by g o
On 26 January 2012 16:48, Heikki Linnakangas
wrote:
> Ok, committed with some further cleanup.
>
> Do you think the docs need to be updated for this, and if so, where? The
> only place I found in the docs that speak about how the bgwriter works is in
> config.sgml, where bgwriter_delay is describe
Robert Haas writes:
>>> Is there a guard in here against joining a parameterized path to an
>>> intermediate relation when no SJ is involved? In other words, if
>>> we're joining a parameterized path on A to a path on B, then either
>>> the join to B should satisfy at least part of the parameteri
On Thu, Jan 26, 2012 at 2:07 PM, Kohei KaiGai wrote:
> 2012/1/26 Robert Haas :
>> I'm wondering if a function would be a better fit than a GUC. I don't
>> think you can really restrict the ability to revert a GUC change -
>> i.e. if someone does a SET and then a RESET, you pretty much have to
>>
Hi Robert,
On Thu, Jan 26, 2012 at 7:59 PM, Robert Haas wrote:
> On Thu, Jan 26, 2012 at 1:13 PM, Vik Reykja wrote:
>> On Thu, Jan 26, 2012 at 18:47, Robert Haas wrote:
>>>
>>> OK, committed with that further change.
thank you for the fast fix and Vik for the base patch ;)
>> Just a small nit
2012/1/26 Robert Haas :
> I'm wondering if a function would be a better fit than a GUC. I don't
> think you can really restrict the ability to revert a GUC change -
> i.e. if someone does a SET and then a RESET, you pretty much have to
> allow that. I think. But if you expose a function then it
Excerpts from Alvaro Herrera's message of mar ene 24 15:47:16 -0300 2012:
> Need more code changes for the following:
> * export FOR KEY UPDATE lock mode in SQL
While doing this, I realized that there's an open item here regarding a
transaction that locks a tuple, and then in an aborted savepoi
On Thu, Jan 26, 2012 at 1:13 PM, Vik Reykja wrote:
> On Thu, Jan 26, 2012 at 18:47, Robert Haas wrote:
>>
>> OK, committed with that further change.
>
> Thank you, Robert! My first real contribution, even if tiny :-)
>
> Just a small nit to pick, though: Giuseppe Sucameli contributed to this
> p
On 26.01.2012 17:31, Tom Lane wrote:
Heikki Linnakangas writes:
The thing is, there's currently no encoding conversion happening, so if
you have one database in LATIN1 encoding and another in UTF-8, for
example, whatever you put in your postgresql.conf is going to be wrong
for one database. I'm
On Thu, Jan 26, 2012 at 18:47, Robert Haas wrote:
> OK, committed with that further change.
Thank you, Robert! My first real contribution, even if tiny :-)
Just a small nit to pick, though: Giuseppe Sucameli contributed to this
patch but was not credited in the commit log.
On mån, 2012-01-09 at 14:04 -0500, Tom Lane wrote:
> #ifdef CATALOG_VARLEN /* variable-length fields start here
> */
>
> to be even clearer.
>
> What would be appropriate to add instead of those inconsistently-used
> comments is explicit comments about the exception cases such as
> proa
On Wed, Jan 25, 2012 at 7:06 AM, Tareq Aljabban
wrote:
> Hi,
> I'm doing some development on the storage manager module of Postgres.
>
> I have added few source files already to the smgr folder, and I was able to
> have the Make system includes them by adding their names to the OBJS list in
> the
On tor, 2012-01-26 at 10:34 +0200, Heikki Linnakangas wrote:
> For postgresql.conf I think we could make a rule that it's always in
> UTF-8. We haven't had to take a stance on the encoding used in
> postgresql.conf before, but IMHO UTF-8 only would be quite reasonable.
We have so far violently r
On Wed, Jan 25, 2012 at 2:49 PM, Benjamin Johnson
wrote:
> PG Gurus,
>
> I have a table like this:
>
> CREATE TABLE filemods (
> guid BIGINT NOT NULL UNIQUE,
> filepath_guid BIGINT NOT NULL,
> createtime TIMESTAMP WITH TIME ZONE DEFAULT NULL,
> writetime
On Thu, Jan 26, 2012 at 12:02 PM, Vik Reykja wrote:
> On Thu, Jan 26, 2012 at 17:58, Robert Haas wrote:
>>
>> On Thu, Jan 26, 2012 at 11:29 AM, Tom Lane wrote:
>> > This looks reasonable to me, except that possibly the new error message
>> > text could do with a bit more thought. It seems rando
On Fri, Jan 27, 2012 at 12:50 AM, Magnus Hagander wrote:
>> One idea; starting archive recovery with standby_mode=on meets your needs?
>
> I haven't tested, but probably, yes. But in that case, why do we need
> the pause_at_recovery_target *at all*? It's basically overloaded
> functionality alread
Robert Haas writes:
> On Mon, Jan 23, 2012 at 7:59 PM, Daniel Farina wrote:
>> Things are still a bit ugly in the more complex cases: consider
>> PostGIS's linkage against libproj and other libraries. In order to
After thinking about that for a while I think we should not include the
shared mod
On Thu, Jan 26, 2012 at 10:59 AM, Robert Haas wrote:
> On Thu, Jan 26, 2012 at 11:41 AM, Merlin Moncure wrote:
>> On Thu, Jan 26, 2012 at 8:18 AM, Abhijit Menon-Sen wrote:
>>> This is just to confirm that the patch applies and builds and works
>>> fine (though of course it does take a long time…
On Tue, Jan 10, 2012 at 6:28 AM, Kohei KaiGai wrote:
> This patch adds a new GUC "sepgsql.client_label" that allows client
> process to switch its privileges into another one, as long as the
> system security policy admits this transition.
> Because of this feature, I ported two permissions from "
On Thu, Jan 26, 2012 at 17:58, Robert Haas wrote:
> On Thu, Jan 26, 2012 at 11:29 AM, Tom Lane wrote:
> > This looks reasonable to me, except that possibly the new error message
> > text could do with a bit more thought. It seems randomly unlike the
> > normal message, and I also have a bit of
On Thu, Jan 26, 2012 at 11:54 AM, Robert Haas wrote:
> AFAICS, such queries aren't going to benefit from this optimization,
> so ideally we'd like them to not have to pay little or nothing for it.
There are a few too many negations in that sentence.
Let me try again:
AFAICS, such queries aren't
On Thu, Jan 26, 2012 at 11:41 AM, Merlin Moncure wrote:
> On Thu, Jan 26, 2012 at 8:18 AM, Abhijit Menon-Sen wrote:
>> This is just to confirm that the patch applies and builds and works
>> fine (though of course it does take a long time… pity there doesn't
>> seem to be any easy way to add progr
On Thu, Jan 26, 2012 at 11:29 AM, Tom Lane wrote:
> Robert Haas writes:
>> However, I think we ought to handle
>> renaming a column symmetrically to adding one.
>
> Yeah, I was thinking the same.
>
>> So here's a revised version of your patch that does that.
>
> This looks reasonable to me, excep
On Thu, Jan 26, 2012 at 11:04 AM, Tom Lane wrote:
> Robert Haas writes:
>> Is there a guard in here against joining a parameterized path to an
>> intermediate relation when no SJ is involved? In other words, if
>> we're joining a parameterized path on A to a path on B, then either
>> the join to
On 17.01.2012 14:38, Peter Geoghegan wrote:
On 17 January 2012 11:24, Heikki Linnakangas
wrote:
In the patch I sent, I did rearrange the sleeping logic. I think it's more
readable the way it is now.
I have no objection to either your refinement of the sleeping logic,
nor that you moved some
At 2012-01-17 13:43:11 -0800, dan...@heroku.com wrote:
>
> > See the attached patch. It has a detailed cover letter/comment at
> > the top of the file.
The patch looks good, but the resetxlog and controldata Makefile hunks
didn't apply. I don't know why, but I've attached updated versions of
thos
On Thu, Jan 26, 2012 at 8:18 AM, Abhijit Menon-Sen wrote:
> This is just to confirm that the patch applies and builds and works
> fine (though of course it does take a long time… pity there doesn't
> seem to be any easy way to add progress indication like -i has).
On any non server grade hardware
Robert Haas writes:
> However, I think we ought to handle
> renaming a column symmetrically to adding one.
Yeah, I was thinking the same.
> So here's a revised version of your patch that does that.
This looks reasonable to me, except that possibly the new error message
text could do with a bit
At 2012-01-09 20:23:59 +0200, pete...@gmx.net wrote:
>
> Nobody had a better idea, so here is the final patch. I adjusted the
> regression tests a bit to avoid bloat from the now-visible owner
> privileges.
Patch applies, builds, and passes tests (and does report EXECUTE
privileges on a newly-cre
Robert Haas writes:
> Is there a guard in here against joining a parameterized path to an
> intermediate relation when no SJ is involved? In other words, if
> we're joining a parameterized path on A to a path on B, then either
> the join to B should satisfy at least part of the parameterization
>
At 2011-12-21 18:24:17 +0200, ma...@juffo.org wrote:
>
> > I think the least invasive fix, as proposed by Jeroen, is to fail only
> > when ERANGE is set *and* the return value is 0.0 or +/-HUGE_VAL.
> > Reading relevant specifications, this seems to be a fairly safe
> > assumption. That's what the
On Thu, Jan 26, 2012 at 08:42, Fujii Masao wrote:
> On Wed, Dec 28, 2011 at 7:27 PM, Simon Riggs wrote:
>> On Thu, Dec 22, 2011 at 6:16 AM, Simon Riggs wrote:
>>
>>> I can see a reason to do this now. I've written patch and will commit
>>> on Friday. Nudge me if I don't.
>>
>> It's hard to write
At 2012-01-11 22:05:34 +0200, pete...@gmx.net wrote:
>
> I propose to add two functions to the result object:
>
> .colnames() returns a list of column names (strings)
> .coltypes() returns a list of type OIDs (integers) […]
>
> Patch attached. Comments welcome.
Applies, builds, passes tests. Co
Heikki Linnakangas writes:
> The thing is, there's currently no encoding conversion happening, so if
> you have one database in LATIN1 encoding and another in UTF-8, for
> example, whatever you put in your postgresql.conf is going to be wrong
> for one database. I'm happy to just document the i
At 2011-11-24 17:44:16 +0100, pavel.steh...@gmail.com wrote:
>
> patch is relative long, but almost all are changes in regress tests.
> Changes in plpgsql are 5 lines
The change looks good in principle. The patch applies to HEAD with a bit
of fuzz and builds fine… but it fails tests, because it's
On Tue, Jan 24, 2012 at 6:27 PM, Vik Reykja wrote:
> I took my first stab at hacking the sources to fix the bug reported here:
>
> http://archives.postgresql.org/pgsql-bugs/2012-01/msg00152.php
>
> It's such a simple patch but it took me several hours with Google and IRC
> and I'm sure I did many
On Sun, Jan 22, 2012 at 19:35, Jaime Casanova wrote:
> On Mon, Jan 16, 2012 at 3:19 PM, Magnus Hagander wrote:
>> Attached patch adds a counter for number of deadlocks in a database to
>> pg_stat_database.
>>
>
> A little review:
>
> - it applies with a few hunks
> - the oid you have chosen for t
On Wed, Jan 25, 2012 at 10:39:56PM -0500, Noah Misch wrote:
> In any event, the patch needed a rebase, so I've attached it rebased and with
> that comment edited to reference ri_GenerateQualCollation(), that being the
> most-relevant source for the assumption in question.
Commit 9d35116611e6a1fc10
On Mon, Jan 23, 2012 at 5:28 PM, Dominik Bylica wrote:
> Hello.
>
> It's probably not the right place to write, but I guess you are there to
> take care of it.
>
> When I was creating a trigger with command like:
> create trigger asdf before update on beginninOfTheNameOfMyTable...
> I hit tab and
On Tue, Jan 24, 2012 at 4:39 AM, Thomas Ogrisegg
wrote:
> While testing a backup script, I noticed that pg_basebackup exits with
> 0, even if it had errors while writing the backup to disk when the
> backup file is to be sent to stdout. The attached patch should fix this
> problem (and some specia
On Thu, Jan 26, 2012 at 7:27 AM, Kohei KaiGai wrote:
> It seems to me reasonable design.
> The attached patch is rebased one according to your perform-deletion patch.
That looks pretty sensible. But I don't think this is true any more:
+Please note that it shall not be checked on the object
On Wed, Jan 25, 2012 at 11:24 AM, Tom Lane wrote:
> I wrote:
>> Attached is a WIP patch for parameterized paths, along the
>> lines we have discussed before: ...
>
> I've made considerable progress on the TODO items I listed: indxpath.c
> has been ripped apart and restructured, and I have it consi
At 2012-01-12 12:31:20 +, si...@2ndquadrant.com wrote:
>
> The following patch adds a pgbench option -I to load data using
> INSERTs
This is just to confirm that the patch applies and builds and works
fine (though of course it does take a long time… pity there doesn't
seem to be any easy way t
On 26 Leden 2012, 14:44, Magnus Hagander wrote:
> On Sat, Jan 21, 2012 at 20:12, Tomas Vondra wrote:
>> On 21 Leden 2012, 18:13, Magnus Hagander wrote:
>>> On Sat, Jan 21, 2012 at 18:02, Tomas Vondra wrote:
>>> Though I just looked at the tabstat code again, and we already split
>>> that message
On Sat, Jan 21, 2012 at 20:12, Tomas Vondra wrote:
> On 21 Leden 2012, 18:13, Magnus Hagander wrote:
>> On Sat, Jan 21, 2012 at 18:02, Tomas Vondra wrote:
>> Though I just looked at the tabstat code again, and we already split
>> that message up at regular intervals. Which would make it quite wei
At 2012-01-14 14:23:49 +0200, pete...@gmx.net wrote:
>
> Inspired by this question http://stackoverflow.com/questions/6857265 I
> have implemented a way to set the psql record and field separators to
> a zero byte (ASCII NUL character).
Since this patch is in the commitfest, I had a look at it.
I
On Thu, Jan 26, 2012 at 6:55 AM, Noah Misch wrote:
> On Wed, Jan 25, 2012 at 11:53:10PM -0500, Tom Lane wrote:
>> Not only is that code spectacularly unreadable, but has nobody noticed
>> that this commit broke the buildfarm?
>
> Thanks for reporting the problem. This arose because the new test c
On Wed, Jan 25, 2012 at 11:53:10PM -0500, Tom Lane wrote:
> Not only is that code spectacularly unreadable, but has nobody noticed
> that this commit broke the buildfarm?
Thanks for reporting the problem. This arose because the new test case
temporarily sets client_min_messages=DEBUG1. The defau
On Sun, Jan 22, 2012 at 1:13 AM, Euler Taveira de Oliveira
wrote:
> On 23-12-2011 12:05, Tom Lane wrote:
>> I too think a datatype is overkill, if we're only planning on providing
>> one function. Just emit the values as numeric and have done.
>>
> Here it is. Output changed to numeric.
Thanks!
>> To be clear, I'd love to have this feature. But if there is a choice
>> between reducing planning time significantly for everyone and NOT
>> getting this feature, and increasing planning time significantly for
>> everyone and getting this feature, I think we will make more people
>> happy by do
--On 15. Januar 2012 02:50:00 -0500 Jaime Casanova
wrote:
Attached is a patch thats implements a pg_stat_recovery view that
keeps counters about processed wal records. I just notice that it
still lacks documentation but i will add it during the week.
Hi Jaime,
do you have an updated patc
On 25.01.2012 15:29, Jim Mlodgenski wrote:
On Tue, Jan 24, 2012 at 7:38 AM, Heikki Linnakangas
wrote:
There's one little problem remaining with this, which is what to do if the
message is in a different encoding than used by the client? That's not a new
problem, we have the same problem with a
68 matches
Mail list logo
