2013/2/3 Tom Lane :
> Alvaro Herrera writes:
>> [ pgsql-v9.3-alter-reworks.3-rename.v10.patch.gz ]
>
> Say ... I hadn't been paying too close attention to this patch, but
> is there any particularly principled reason for it having unified
> only 14 of the 29 object types handled by ExecRenameStmt(
On Wed, Jan 30, 2013 at 11:37:41PM +0530, Pavan Deolasee wrote:
> On Wed, Jan 30, 2013 at 7:34 AM, Noah Misch wrote:
> > On Mon, Jan 28, 2013 at 07:24:04PM +0530, Pavan Deolasee wrote:
> >> On Wed, Jan 23, 2013 at 10:05 AM, Noah Misch wrote:
> >>
> >> > You're the second commentator to be skittis
On 1.2.2013 17:19, Alvaro Herrera wrote:
> Tomas Vondra wrote:
>
>> diff --git a/src/backend/postmaster/pgstat.c
>> b/src/backend/postmaster/pgstat.c
>> index be3adf1..4ec485e 100644
>> --- a/src/backend/postmaster/pgstat.c
>> +++ b/src/backend/postmaster/pgstat.c
>> @@ -64,10 +64,14 @@
>>
>>
On 02/03/2013 08:20 PM, Robert Haas wrote:
On Fri, Feb 1, 2013 at 6:03 PM, Tom Lane wrote:
Daniel Farina writes:
On Fri, Feb 1, 2013 at 2:08 PM, Robert Haas wrote:
I think it's smarter for us to ship functions, and let users wrap them
in operators if they so choose. It's not difficult for
On Fri, Feb 1, 2013 at 6:03 PM, Tom Lane wrote:
> Daniel Farina writes:
>> On Fri, Feb 1, 2013 at 2:08 PM, Robert Haas wrote:
>>> I think it's smarter for us to ship functions, and let users wrap them
>>> in operators if they so choose. It's not difficult for people who
>
>> The problem being:
On Fri, Feb 1, 2013 at 5:13 PM, Peter Eisentraut wrote:
>> I wonder whether it'd not be a better idea to forbid specifying
>> pg_catalog as the target schema for relocatable extensions.
>
> But that would be important, I think.
I understand the temptation to forbid pg_catalog as the target schema
On 3.2.2013 21:54, Jeff Janes wrote:
> On Sat, Feb 2, 2013 at 2:33 PM, Jeff Janes wrote:
>> On Sat, Jan 5, 2013 at 8:03 PM, Tomas Vondra wrote:
>>> On 3.1.2013 20:33, Magnus Hagander wrote:
Yeah, +1 for a separate directory not in global.
>>>
>>> OK, I moved the files from "global/stat"
On 2.2.2013 23:33, Jeff Janes wrote:
> On Sat, Jan 5, 2013 at 8:03 PM, Tomas Vondra wrote:
>> On 3.1.2013 20:33, Magnus Hagander wrote:
>>>
>>> Yeah, +1 for a separate directory not in global.
>>
>> OK, I moved the files from "global/stat" to "stat".
>
> This has a warning:
>
> pgstat.c:5132: wa
On 3.2.2013 20:46, Jeff Janes wrote:
> On Sat, Jan 5, 2013 at 8:03 PM, Tomas Vondra wrote:
>> On 3.1.2013 20:33, Magnus Hagander wrote:
>>>
>>> Yeah, +1 for a separate directory not in global.
>>
>> OK, I moved the files from "global/stat" to "stat".
>
> Why "stat" rather than "pg_stat"?
>
> The
On Sun, Feb 3, 2013 at 9:25 AM, Kevin Grittner wrote:
>
> I was able to confirm two cases where this was a consequence of the
> lazy truncate logic which Jan recently fixed, but there are clearly
> other problems which I didn't have much of a grasp on prior to this
> thread. The only thing I knew
On 3 February 2013 17:53, Tom Lane wrote:
> I think what we need to do in the short run is to fix GetOldestXmin per
> my proposal and shut off on-the-fly changes of vacuum_defer_cleanup_age.
> That will at least fix bug #7819 for cases not involving hot-standby
> feedback. Simon seems to think i
There is a bug in hot_standby_feedback that causes the xmin of the
walsender process to not be reset when hot_standby_feedback is turned
off after it had previously sent at least one feedback message.
Clearly, that is a bad thing and deserves backpatching to 9.1, unless
I hear otherwise real soon.
Alvaro Herrera writes:
> [ pgsql-v9.3-alter-reworks.3-rename.v10.patch.gz ]
Say ... I hadn't been paying too close attention to this patch, but
is there any particularly principled reason for it having unified
only 14 of the 29 object types handled by ExecRenameStmt()?
If so, how to tell which ob
On 2013-02-03 13:26:25 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-02-03 11:17:42 -0500, Tom Lane wrote:
> >> -1 on using txids here. If memory serves, we have had exactly this
> >> discussion before and rejected spreading those into other parts
> >> of the system. That gets rid o
"Marko Tiikkaja" writes:
> Here's the third version of this patch, hopefully this time without any
> problems. I looked through the patch and it looked OK, but I did that
> last time too so I wouldn't trust myself on that one.
Applied with corrections.
The xml expected output was still wron
On Sat, Feb 2, 2013 at 2:33 PM, Jeff Janes wrote:
> On Sat, Jan 5, 2013 at 8:03 PM, Tomas Vondra wrote:
>> On 3.1.2013 20:33, Magnus Hagander wrote:
>>>
>>> Yeah, +1 for a separate directory not in global.
>>
>> OK, I moved the files from "global/stat" to "stat".
>
> This has a warning:
>
> pgsta
I'm hoping that someone familiar with sepgsql can review this
portion of the materialized view patch and comment on whether it is
the best approach for dealing with the integration of these two
features. Basically, the patch as it stands treats a materialized
view as a table for purposes of sepgsq
On Sat, Jan 5, 2013 at 8:03 PM, Tomas Vondra wrote:
> On 3.1.2013 20:33, Magnus Hagander wrote:
>>
>> Yeah, +1 for a separate directory not in global.
>
> OK, I moved the files from "global/stat" to "stat".
Why "stat" rather than "pg_stat"?
The existence of "global" and "base" as exceptions alre
2013/2/3 Tom Lane :
> Pavel Stehule writes:
>> now missing variables is replaced by variable's name. We can implement
>> some pset option - some like define what do with missing variable
>
>> \pset missing_variable (use_name | use_null | error )
>
> No, it isn't "replaced by variable's name". Wha
Pavel Stehule writes:
> now missing variables is replaced by variable's name. We can implement
> some pset option - some like define what do with missing variable
> \pset missing_variable (use_name | use_null | error )
No, it isn't "replaced by variable's name". What actually happens is we
don'
Andres Freund writes:
> On 2013-02-03 11:17:42 -0500, Tom Lane wrote:
>> -1 on using txids here. If memory serves, we have had exactly this
>> discussion before and rejected spreading those into other parts
>> of the system. That gets rid of three of your problems right there,
>> as well as a lo
2013/2/2 Tom Lane :
> Shigeru Hanada writes:
>> On Sat, Feb 2, 2013 at 7:30 PM, Pavel Stehule
>> wrote:
>>> possible variants
>>>
>>> a) don't store NULL values - and remove existing variable when NULL
>>> be assigned - it is probably best, but should be confusing for users
>>> b) implement fla
Robert Haas writes:
> On Sat, Feb 2, 2013 at 1:55 PM, Simon Riggs wrote:
>> Mark vacuum_defer_cleanup_age as PGC_POSTMASTER.
>> Following bug analysis of #7819 by Tom Lane
> This has barely been discussed, let alone agreed.
Well, we have a bug, and I believe everybody agrees that it can be
fixe
Andres Freund wrote:
> On 2013-02-01 15:09:34 -0800, Jeff Janes wrote:
>> Since freeze_min_age was mistakenly being used, the limit
>> would be 50 million in the past (rather than 150 million) under
>> defaults. But since the last full-table vacuum, whenever that was,
>> used freeze_min_age for
On 2013-02-03 11:17:42 -0500, Tom Lane wrote:
> Andres Freund writes:
> > It obviously needs more polish:
>
> > - I opted for using the 64bit representation of xids, seems to be better
> > in a log which very well might be looked at only after some
> > wraparounds
> > - exporting 'txid' from
Andres Freund writes:
> It obviously needs more polish:
> - I opted for using the 64bit representation of xids, seems to be better
> in a log which very well might be looked at only after some
> wraparounds
> - exporting 'txid' from adt/txid.c is pretty ugly. I don't like the
> invention of
On 29 January 2013 15:34, Ali Dar wrote:
> Please find attached the complete patch for alter rename rule. I have
> followed all the suggestions.
This looks good. I've tested it, and it appears to work as intended.
I'm happy with the code, and the new docs and regression tests look
OK.
I have a c
27 matches
Mail list logo
