Hi all,
Sorry for arriving so late into the discussion.
I don't know if it's possible but it could be useful to have the text
of the query which required the creation of the temporary files as an
additional DETAIL line. At least, if it's possible to have it in this
part of the code.
Thoughts?
On Thu, Jan 11, 2007 at 11:10:38PM +, Simon Riggs wrote:
> On Thu, 2007-01-11 at 17:06 +, Gregory Stark wrote:
> > Having a CRC in WAL but not in the heap seems kind of pointless.
>
> Yes...
>
> > If your
> > hardware is unreliable the corruption could anywhere.
>
> Agreed.
I thought
Per discussion on -hackers, the attached patch introduces an optional
parameter to pg_dumpall's -g (--globals-only) option to allow roles or
tablespaces to be dumped on their own.
eg.
pg_dumpall -g -- Dump roles and tablespaces per current behaviour
pg_dumpall -gr -- Dump roles only (or users an
Dave Page <[EMAIL PROTECTED]> writes:
> pg_dumpall -g -- Dump roles and tablespaces per current behaviour
> pg_dumpall -gr -- Dump roles only (or users and groups)
> pg_dumpall -gt -- Dump tablespaces only
This seems a bit ugly, mainly because (1) it doesn't have a natural
translation to long-for
Tom Lane wrote:
Dave Page <[EMAIL PROTECTED]> writes:
pg_dumpall -g -- Dump roles and tablespaces per current behaviour
pg_dumpall -gr -- Dump roles only (or users and groups)
pg_dumpall -gt -- Dump tablespaces only
This seems a bit ugly, mainly because (1) it doesn't have a natural
t
On Thu, Jan 11, 2007 at 10:36:11PM +0100, Magnus Hagander wrote:
> The attached patch changes vcbuild so the project and solution files are
> only regenerated if they are actually changed. This helps when you're
> developing in the Visual Studio GUI, because updating the files (even to
> the same c
Andrew Dunstan wrote:
> Tom Lane wrote:
>> Dave Page <[EMAIL PROTECTED]> writes:
>>
>>> pg_dumpall -g -- Dump roles and tablespaces per current behaviour
>>> pg_dumpall -gr -- Dump roles only (or users and groups)
>>> pg_dumpall -gt -- Dump tablespaces only
>>>
>>
>> This seems a bit ugly,
Am Freitag, 12. Januar 2007 15:08 schrieb Dave Page:
> pg_dumpall -g -- Dump roles and tablespaces per current behaviour
> pg_dumpall -gr -- Dump roles only (or users and groups)
> pg_dumpall -gt -- Dump tablespaces only
Also note that optional argument specifications in getopt like "g::" are not
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Maybe we could forcibly activate the freeze mode on a template database?
>
> Might not be a bad idea. And even more to the point, forcibly disable
> analyze.
Patch implementing this (albeit untested!) attached. I'll try to
reprod
Simon Riggs wrote:
> On Thu, 2007-01-11 at 12:37 -0500, Bruce Momjian wrote:
>
> > The trace probe was incorrect
>
> Yes, incomplete, no doubt. On that point you were 100% right to reject.
>
> > and kind of at an odd place. I don't
> > think we want to go down the road of throwing trace in eve
On Fri, 2007-01-12 at 11:44 -0500, Bruce Momjian wrote:
> I think the right approach is to look at our existing code and come up
> with places we want them, and add them in one shot. Doing thing
> in small parts doesn't work too well with a project this size.
Will do.
--
Simon Riggs
Guillaume Smet wrote:
> Hi all,
>
> Sorry for arriving so late into the discussion.
>
> I don't know if it's possible but it could be useful to have the text
> of the query which required the creation of the temporary files as an
> additional DETAIL line. At least, if it's possible to have it in
Hi Bruce,
Thanks for your answer.
On 1/12/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
We have the ability to conditionally print statements based on error
level, but LOG isn't a valid level for log_min_error_statement.
We could add a parameter that few people would use, but the right way to
d
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> That's not what I had in mind. I was asking if the text of the query
> was available when logging the temp file usage. If so it could be good
> to add a DETAIL line with it directly and systematically when logging
> the temp file usage.
(1) you could
Guillaume Smet wrote:
> Hi Bruce,
>
> Thanks for your answer.
>
> On 1/12/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > We have the ability to conditionally print statements based on error
> > level, but LOG isn't a valid level for log_min_error_statement.
> >
> > We could add a parameter that
On 1/12/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> That's not what I had in mind. I was asking if the text of the query
> was available when logging the temp file usage. If so it could be good
> to add a DETAIL line with it directly and systematically w
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> On 1/12/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> (2) there is already a generalized solution to this, it's called
>> log_min_error_statement.
> I didn't think of that when posting my message but Bruce seems to say
> that we can't use it in this case
Guillaume Smet wrote:
> On 1/12/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > Usually people don't want th query unless they ask for it. One nify
> > trick would be to print the query as DETAIL unless they are already
> > logging queries, but that just seems too complex. If you want the
> > qu
On 1/12/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Usually people don't want th query unless they ask for it. One nify
trick would be to print the query as DETAIL unless they are already
logging queries, but that just seems too complex. If you want the
query, why not just log them all?
Beca
Alvaro Herrera wrote:
> Tom Lane wrote:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
>
> > > Maybe we could forcibly activate the freeze mode on a template database?
> >
> > Might not be a bad idea. And even more to the point, forcibly disable
> > analyze.
>
> Patch implementing this (albeit
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Ok, it does what it's intended to do. But in testing it I also
> confirmed that a database-wide vacuum creates a pgstat entry for it and
> for all tables in it. Is this something we want to prevent?
That's odd, because I didn't see any such thing when
Tom Lane wrote:
> "Guillaume Smet" <[EMAIL PROTECTED]> writes:
> > On 1/12/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> (2) there is already a generalized solution to this, it's called
> >> log_min_error_statement.
>
> > I didn't think of that when posting my message but Bruce seems to say
> > tha
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Ok, it does what it's intended to do. But in testing it I also
> > confirmed that a database-wide vacuum creates a pgstat entry for it and
> > for all tables in it. Is this something we want to prevent?
>
> That's odd, because I di
In response to "Guillaume Smet" <[EMAIL PROTECTED]>:
> On 1/12/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > Usually people don't want th query unless they ask for it. One nify
> > trick would be to print the query as DETAIL unless they are already
> > logging queries, but that just seems too
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>>> Ok, it does what it's intended to do. But in testing it I also
>>> confirmed that a database-wide vacuum creates a pgstat entry for it and
>>> for all tables in it. Is this something we
On Thu, 2007-01-11 at 21:04 -0500, Neil Conway wrote:
> Comments? I'll write up a doc patch, barring any objections.
I'll apply the attached doc patch to CVS tomorrow, barring any
objections.
-Neil
Index: doc/src/sgml/datatype.sgml
26 matches
Mail list logo
