Hello,
I would like to fix this bug, but it looks like it would be not one-line
patch.
Looking at the pg_dump code I see that the object names come through the
following chain:
1. pg_dump executes 'SELECT c.tableoid, c.oid, c.relname, ... ' and gets
the object_name with the encoding chosen for
Re: Tom Lane 2012-07-02 <18088.1341245...@sss.pgh.pa.us>
> Christoph Berg writes:
> > What is still puzzling me is that the customer is repeatedly reporting
> > these issues, even after rebooting the system.
>
> Hm. A server restart really ought to clear any problem in this area,
> since pg_noti
On Thu, Jul 19, 2012 at 02:24:36AM -0400, Bruce Momjian wrote:
> On Wed, Jul 18, 2012 at 01:30:34AM -0400, Tom Lane wrote:
> > I wrote:
> > > ... I'm wondering if maybe
> > > Solaris has a weird definition of struct dirent that breaks the
> > > calculation used here:
> >
> > > entrysize
Hi,
I notice that pg_basebackup has lots of messages where file names are
not in quotes. Is this okay?
There's also this one which is probably against our conventions:
#: pg_receivexlog.c:181
#, c-format
msgid "%s: segment file '%s' is incorrect size %d, skipping\n"
I also wonder about "is" vs
Bruce Momjian writes:
> On Thu, Jul 19, 2012 at 02:24:36AM -0400, Bruce Momjian wrote:
>> On Wed, Jul 18, 2012 at 01:30:34AM -0400, Tom Lane wrote:
>>> Some googling suggests that on Solaris, this calculation would actually
>>> give a result that's a little too *large* not too small, because of
>>
Alvaro Herrera writes:
> I notice that pg_basebackup has lots of messages where file names are
> not in quotes. Is this okay?
They should be in double quotes, per our message style guidelines.
> msgid "%s: segment file '%s' is incorrect size %d, skipping\n"
> I also wonder about "is" vs. "has"
Bruce Momjian writes:
> Tom suggested that load_directory() return a (char *) array, rather than
> a struct dirent array, greatly simplifying the code.
> I have done this in the attached patch, and because of the uncertainty
> of ths fix, I would like to apply this to 9.2 as well.
BTW, the patch
On Wed, Jul 25, 2012 at 04:09:42PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Thu, Jul 19, 2012 at 02:24:36AM -0400, Bruce Momjian wrote:
> >> On Wed, Jul 18, 2012 at 01:30:34AM -0400, Tom Lane wrote:
> >>> Some googling suggests that on Solaris, this calculation would actually
> >>> gi
On Wed, Jul 25, 2012 at 04:30:10PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Tom suggested that load_directory() return a (char *) array, rather than
> > a struct dirent array, greatly simplifying the code.
> > I have done this in the attached patch, and because of the uncertainty
> > of
On Fri, Jul 13, 2012 at 08:08:59PM -0430, Jose Ildefonso Camargo Tolosa wrote:
> On Fri, Jul 13, 2012 at 10:22 AM, Bruce Momjian wrote:
> > On Fri, Jul 13, 2012 at 09:12:56AM +0200, Hampus Wessman wrote:
> >> How you decide what to do with the servers on failures isn't that
> >> important here, re
On 3 March 2012 20:22, Jeff Janes wrote:
> Add it all up, and instead of pre-reading 32 consecutive 8K blocks, it
> pre-reads only about 1 or 2 consecutive ones on the final merge. Now
> some of those could be salvaged by the kernel keeping track of
> multiple interleaved read ahead opportunities
Excerpts from Tom Lane's message of mié jul 25 16:25:36 -0400 2012:
> Alvaro Herrera writes:
> > Apparently, this needs a thorough revision ...
>
> Evidently. Peter tends to see to that sort of thing while he works on
> translations, but I'm sure he wouldn't mind some help.
Here's an attempt a
Alvaro Herrera writes:
> One thing I'm not clear about is the "WAL file" vs "transaction log
> file" terminology. We use both in various error messages. Do we want
> to consistently use one? It seems to me that we're using the very
> verbose "transaction log" phrase just to avoid exposing users
Excerpts from Alvaro Herrera's message of mié jul 25 18:23:46 -0400 2012:
> Excerpts from Tom Lane's message of mié jul 25 16:25:36 -0400 2012:
> > Alvaro Herrera writes:
>
> > > Apparently, this needs a thorough revision ...
> >
> > Evidently. Peter tends to see to that sort of thing while he
Hello
we cannot actually store result of query to psql variable
I propose a new slash statement "\eset for this purpose
Syntax:
\eset variable [, variable [..]] query -- it raise exception when
more than one row is returned or when no row is returned
Usage:
\eset var1, var2 select version(),
Pavel Stehule writes:
> \eset variable [, variable [..]] query -- it raise exception when
> more than one row is returned or when no row is returned
Better would be a variant on \g, that is you type in the query and
then tell it where to put the result. We have learned the hard way
that putting
2012/7/26 Tom Lane :
> Pavel Stehule writes:
>> \eset variable [, variable [..]] query -- it raise exception when
>> more than one row is returned or when no row is returned
>
> Better would be a variant on \g, that is you type in the query and
> then tell it where to put the result. We have lea
On Thu, Jul 26, 2012 at 01:36:17AM -0400, Tom Lane wrote:
> Pavel Stehule writes:
> > \eset variable [, variable [..]] query -- it raise exception when
> > more than one row is returned or when no row is returned
>
> Better would be a variant on \g, that is you type in the query and
> then tell
2012/7/26 David Fetter :
> On Thu, Jul 26, 2012 at 01:36:17AM -0400, Tom Lane wrote:
>> Pavel Stehule writes:
>> > \eset variable [, variable [..]] query -- it raise exception when
>> > more than one row is returned or when no row is returned
>>
>> Better would be a variant on \g, that is you typ
On Thu, Jul 26, 2012 at 08:31:13AM +0200, Pavel Stehule wrote:
> 2012/7/26 David Fetter :
> > On Thu, Jul 26, 2012 at 01:36:17AM -0400, Tom Lane wrote:
> >> Pavel Stehule writes:
> >> > \eset variable [, variable [..]] query -- it raise exception when
> >> > more than one row is returned or when
2012/7/26 David Fetter :
> On Thu, Jul 26, 2012 at 08:31:13AM +0200, Pavel Stehule wrote:
>> 2012/7/26 David Fetter :
>> > On Thu, Jul 26, 2012 at 01:36:17AM -0400, Tom Lane wrote:
>> >> Pavel Stehule writes:
>> >> > \eset variable [, variable [..]] query -- it raise exception when
>> >> > more t
21 matches
Mail list logo
