Tom Lane escribió:
> Alvaro Herrera writes:
> > Please see my reply to Robert. My proposal (in form of a patch) is
> > while operating on tuple (0,2) in table "foo": updating tuple
> > Would this work for you?
>
> It's pretty lousy from a readability standpoint, even in English;
> I shudder to
2014-03-18 20:49 GMT+01:00 Petr Jelinek :
>
> On 18/03/14 20:45, Pavel Stehule wrote:
>
>
>
> 2014-03-18 20:44 GMT+01:00 Petr Jelinek :
>
>>
>> On 18/03/14 20:36, Pavel Stehule wrote:
>>
>>>
>>>
>>> +To aid the user in finding instances of simple but common problems
>>> before
>>> +the
On 03/18/2014 12:35 PM, Andres Freund wrote:
> I still think a rewriting noop ALTER TABLE ... ALTER COLUMN col TYPE
> old_type USING (col); is the only real thing to do.
Then why wouldn't VACUUM FULL work?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers m
On 2014-03-18 12:52:49 -0700, Josh Berkus wrote:
> On 03/18/2014 12:35 PM, Andres Freund wrote:
> > I still think a rewriting noop ALTER TABLE ... ALTER COLUMN col TYPE
> > old_type USING (col); is the only real thing to do.
>
> Then why wouldn't VACUUM FULL work?
Please read the referenced messa
On 03/18/2014 12:55 PM, Andres Freund wrote:
> On 2014-03-18 12:52:49 -0700, Josh Berkus wrote:
>> On 03/18/2014 12:35 PM, Andres Freund wrote:
>>> I still think a rewriting noop ALTER TABLE ... ALTER COLUMN col TYPE
>>> old_type USING (col); is the only real thing to do.
>>
>> Then why wouldn't VA
On Mon, Mar 17, 2014 at 3:14 AM, Joshua Yanovski wrote:
> Here's a SQL script that (1) demonstrates the new index only scan
> functionality, and (2) at least on my machine, has a consistently
> higher planning time for the version with my change than without it.
I'm glad you're looking at this, b
On Tue, Mar 18, 2014 at 4:48 PM, Merlin Moncure wrote:
> > That alone could improve things considerably, and statistical info could
> be
> > propagated along expressions to make it possible to model uncertainty in
> > complex expressions as well.
>
> But how would that work? I see no solution ad
Folks:
So another question, which I've already received from the field, is how
can you detect this kind of corruption in the first place, if it's not
causing a user-visible error?
Got that question from someone who failed over between master and
replica on 9.3.2 last weekend. They're not seeing
Robert Haas writes:
> On Tue, Mar 18, 2014 at 12:15 PM, Tom Lane wrote:
>> Meh. I think you're putting a bit too much faith in your ability to
>> predict the locus of bugs that you think aren't there.
> Well, I'm open to suggestions.
As a suggestion: it'd be worth explicitly testing zero-byte
> I'm glad you're looking at this, but we're in the final throws of
> nailing down 9.4 and I don't have anticipate I'll have time to look at
> it in the near future. You should add it here so we don't forget
> about it:
>
> https://commitfest.postgresql.org/action/commitfest_view/open
Yeah, no wor
Andres Freund writes:
> On 2014-03-18 19:28:53 +, Greg Stark wrote:
>> It would be nice to be able to tell people that if they vacuum, then
>> reindex and check all their foreign key constraints then they should
>> be ok.
> I don't think so:
> http://archives.postgresql.org/message-id/2014031
On 2014-03-18 16:19:01 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-03-18 19:28:53 +, Greg Stark wrote:
> >> It would be nice to be able to tell people that if they vacuum, then
> >> reindex and check all their foreign key constraints then they should
> >> be ok.
>
> > I don't t
On Tue, Mar 18, 2014 at 4:18 PM, Joshua Yanovski wrote:
>> I'm glad you're looking at this, but we're in the final throws of
>> nailing down 9.4 and I don't have anticipate I'll have time to look at
>> it in the near future. You should add it here so we don't forget
>> about it:
>>
>> https://com
Andres Freund wrote:
> On 2014-03-18 16:19:01 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > On 2014-03-18 19:28:53 +, Greg Stark wrote:
> > >> It would be nice to be able to tell people that if they vacuum, then
> > >> reindex and check all their foreign key constraints then they shou
On 02/06/2014 01:54 AM, Peter Geoghegan wrote:
On Thu, Jan 23, 2014 at 1:36 PM, Peter Geoghegan wrote:
So while post-recovery callbacks no longer exist for any
rmgr-managed-resource, 100% of remaining startup and cleanup callbacks
concern the simple management of memory of AM-specific recovery
On 2014-03-18 17:34:34 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > On 2014-03-18 16:19:01 -0400, Tom Lane wrote:
> > > Andres Freund writes:
> > > > On 2014-03-18 19:28:53 +, Greg Stark wrote:
> > > >> It would be nice to be able to tell people that if they vacuum, then
> > > >> re
Heikki Linnakangas writes:
> Yeah, it's a bit silly that each resource manager has to do that on
> their own. It would be useful to have a memory context that was
> automatically reset between each WAL record. In fact that should
> probably be the default memory context you run the WAL redo rou
Wim Dumon wrote:
> 9.3.1 is the version that failed for me, MSVS 2012, Windows 7.
It's pretty clear that we will never be able to keep this working unless
somebody sets up a buildfarm animal that tests this stuff directly.
If you're up to the task, please see here:
https://wiki.postgresql.org/wiki
On Tue, Mar 18, 2014 at 9:29 PM, Petr Jelinek wrote:
> Attached V4 uses "shadowed-variables" instead of "shadow".
I think that should be "shadowed_variables" for consistency; GUC
values usually have underscores, not dashes. (e.g.
intervalstyle=sql_standard, backslash_quote=safe_encoding,
synchron
On 03/18/2014 04:39 PM, Andres Freund wrote:
Mail that's CC/TOed to me onlist, is automatically marked as read by a
sieve script so I don't have to mark it as read twice. It seems
something went wrong there for a couple of messages...
Why not just turn on eliminatecc on the majordomo server
On 18 March 2014 20:52, Marti Raudsepp wrote:
> On Tue, Mar 18, 2014 at 9:29 PM, Petr Jelinek wrote:
>> Attached V4 uses "shadowed-variables" instead of "shadow".
>
> I think that should be "shadowed_variables" for consistency; GUC
> values usually have underscores, not dashes. (e.g.
> intervalst
Hi Petr,
On 3/18/14, 8:38 PM, I wrote:
I did one small change (that I think was agreed anyway) from Marko's
original patch in that warnings are only emitted during function
creation, no runtime warnings and no warnings for inline (DO) plpgsql
code either as I really don't think these optional wa
On Tue, Mar 18, 2014 at 10:39:03AM +, Simon Riggs wrote:
> On 8 March 2014 11:14, Simon Riggs wrote:
> > Implemented in attached patch, v22
> > I commend this patch to you for final review; I would like to commit
> > this in a few days.
>
> I'm planning to commit this today at 1500UTC barrin
All,
Updated per feedback. CC'd to Advocacy now for additional corrections.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
The PostgreSQL Global Development Group has released an update to all supported version of the database system, including versions 9.3.4, 9.2.8, 9.1.13, 9.0.1
Josh Berkus writes:
> Updated per feedback. CC'd to Advocacy now for additional corrections.
A few thoughts:
> The PostgreSQL Global Development Group has released an update to all
> supported version of the database system, including versions 9.3.4, 9.2.8,
> 9.1.13, 9.0.19, and 8.4.20.
By my
Peter Eisentraut writes:
> On 3/17/14, 10:55 PM, Tom Lane wrote:
>> It doesn't pass the regression tests. Do you need more of a bug report
>> than that?
> It does pass the tests for me and others. If you are seeing something
> different, then we need to see some details, like what platform, wha
Josh Berkus writes:
> On 03/17/2014 05:49 PM, Josh Berkus wrote:
>> https://wiki.postgresql.org/wiki/20140320UpdateIssues
> Anyone? We're going public with this in 36 hours, so I'd love for it to
> actually be correct.
I did a bit more hacking on this page. Could use another look from Alvaro
a
It seems two exactly same sql sessions are repeated in
logicaldecoding.sgml. Is this intended?
postgres=# -- You can also peek ahead in the change stream without consuming
changes
postgres=# SELECT * FROM pg_logical_slot_peek_changes('regression_slot', NULL,
NULL);
location | xid |
Hi all,
Some of you may remember me from last year: I had applied to implement the
k-medoids clustering method in MADlib, a Postgres and GreenPlum library.
As this project could not be selected last year, I'm trying again now!
You can find my application at this address:
https://github.com/viodle
On Tue, Mar 18, 2014 at 09:13:28PM +0200, Heikki Linnakangas wrote:
> On 03/18/2014 09:04 PM, Simon Riggs wrote:
> >On 18 March 2014 18:55, Alvaro Herrera wrote:
> >
> >>That said, I don't find comma expression to be particularly "not
> >>simple".
> >
> >Maybe, but we've not used it before anywher
Hello!
Here is the text of my proposal which I've applied to GSoC.
(and link
https://docs.google.com/document/d/1s-Q4rzEysPxo-dINsk_eKFJOBoVjNYDrQ-Oh75gtYEM/edit?usp=sharing)
Any suggestions and comments are welcome.
*
PostgreSQL GSoC 2014 proposal
Project name
Rewrite (add) pg_dump and pg_
On Friday, 14 March 2014 2:42 PM, Amit Kapila wrote:
>On Wed, Mar 12, 2014 at 12:22 PM, Haribabu Kommi
>wrote:
>> On Tue, Mar 11, 2014 at 2:59 PM, Amit Kapila wrote:
>>
>>> By the way have you checked if FreeSpaceMapVacuum() can serve your
>>> purpose, because this call already traverses FSM i
Bruce Momjian writes:
> Would people accept?
> for (errno = 0; (dirent = readdir(dir)) != NULL; errno = 0)
It's a bit weird looking, but I agree that there's value in only needing
the errno-zeroing in precisely one place.
regards, tom lane
--
Sent via pgsql-hack
On Friday, Mar 14, 2014 at 9:33 PM, Maganus Hagander
mailto:mag...@hagander.net> > wrote:
>>Hi,
>>In connection to my previous proposal about "providing catalog view to
>>pg_hba.conf file contents" , I have developed the attached patch .
>> [Current situation]
>>Currently, to view the pg_hba.
>
>> > That's precisely what risk estimation was about.
>>
>> Yeah. I would like to see the planner's cost estimates extended to
>> include some sort of uncertainty estimate, whereupon risk-averse people
>> could ask it to prefer low-uncertainty plans over high-uncertainty ones
>> (the plans we ty
On Tue, Mar 18, 2014 at 4:42 PM, Heikki Linnakangas
wrote:
> When inserting into a B-tree index, all the pages are read-locked when
> descending the tree. When we reach the leaf page, the read-lock is exchanged
> for a write-lock.
>
> There's nothing wrong with that, but why don't we just directly
101 - 136 of 136 matches
Mail list logo