Hi,
In 2 of 3 pq_setkeepalives* functions we have the #DEFINE involving
even this conditional:
"""
if (port == NULL || IS_AF_UNIX(port->laddr.addr.ss_family))
return STATUS_OK;
"""
but in pq_setkeepalivesinterval() the #DEFINE is after the
conditional, doesn't seems to affect anything
Where are we in getting to beta1? I know people are looking to me for
9.0 release notes and I will have them done in about a week, but what
about open issues? I don't see many on the main 9.0 open items page:
http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items#Bugs
The list has be
Steve Atkins wrote:
>
> On Mar 12, 2010, at 5:18 PM, Tom Lane wrote:
>
> > Bruce Momjian writes:
> >> Well, I think the big question is whether we need to honor RFC 5322
> >> (http://www.rfc-editor.org/rfc/rfc5322.txt). Wikipedia says these are
> >> all valid characters:
> >
> >>http://en.w
Tom Lane wrote:
> Bruce Momjian writes:
> > OK, I can add '+' using Teodor's patch as a guide, and document which
> > characters we support, and that we don't support all of them. What
> > about the binary upgrade issue? I am now worried that maybe we should
> > back out the patch and just docum
Bruce Momjian writes:
> OK, I can add '+' using Teodor's patch as a guide, and document which
> characters we support, and that we don't support all of them. What
> about the binary upgrade issue? I am now worried that maybe we should
> back out the patch and just document our restrictions.
The
On Mar 12, 2010, at 5:18 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> Well, I think the big question is whether we need to honor RFC 5322
>> (http://www.rfc-editor.org/rfc/rfc5322.txt). Wikipedia says these are
>> all valid characters:
>
>>http://en.wikipedia.org/wiki/E-mail_address
>
>>
Tom Lane wrote:
> Bruce Momjian writes:
> > Well, I think the big question is whether we need to honor RFC 5322
> > (http://www.rfc-editor.org/rfc/rfc5322.txt). Wikipedia says these are
> > all valid characters:
>
> > http://en.wikipedia.org/wiki/E-mail_address
>
> > * Uppercase and lowe
Bruce Momjian writes:
> Well, I think the big question is whether we need to honor RFC 5322
> (http://www.rfc-editor.org/rfc/rfc5322.txt). Wikipedia says these are
> all valid characters:
> http://en.wikipedia.org/wiki/E-mail_address
> * Uppercase and lowercase English letters (a-z, A-Z)
Alvaro Herrera wrote:
>
> Upon seeing this patch I considered that I use addresses such as
> alvherre+st...@something.org and wondered how could this thing support
> that. I don't think we want extra parser stuff just to add whatever
> random junk we want to support in email addresses ...
Well,
2010/3/11 KaiGai Kohei :
> (2010/03/11 23:55), Robert Haas wrote:
>> 2010/3/10 KaiGai Kohei:
>>> Indeed, it is useful to allow renaming attribute of composite types.
>>>
>>> However, it is also useless to allow to rename attribute of sequences,
>>> but harmless, like renames on indexes. It seems to
Upon seeing this patch I considered that I use addresses such as
alvherre+st...@something.org and wondered how could this thing support
that. I don't think we want extra parser stuff just to add whatever
random junk we want to support in email addresses ...
--
Alvaro Herrera
Teodor Sigaev wrote:
> > Oleg, Teodor, can you look at this? I tried to fix it in wparser_def.c,
> > but couldn't figure out how. Thanks.
> >>
> >> select distinct token as email
> >> from ts_parse('default', ' first_l...@yahoo.com ' )
> >> where tokid = 4
>
> Patch in attachment, it allows un
> Tatsuo Ishii writes:
> >> Tatsuo Ishii writes:
> >>> It seems between 8.4 and CVS HEAD backend responses 'E' packet
> >>> (error/fatal message) if a startup packet sent with wrong user and/or
> >>> database. Before backend responses 'R' packet first followd by 'E'
> >>> packet.
>
> > I now und
Alvaro Herrera writes:
> Since the warning comes from the launcher and not the worker, I wonder
> if this is a red herring.
It's all speculation at the moment. So far there's not really enough
evidence to refute the idea that the system was just under heavy load
at that point --- except that eve
Tom Lane wrote:
> Alvaro Herrera writes:
> > I also think the autovacuum worker minimum timestamp may be playing
> > games with the retry logic too. Maybe a worker is requesting a new file
> > continuously because pgstat is not able to provide one before the
> > deadline is past, and thus overlo
On Fri, Mar 12, 2010 at 4:24 PM, Boszormenyi Zoltan wrote:
> Merlin Moncure írta:
>> On Fri, Mar 12, 2010 at 3:01 PM, Boszormenyi Zoltan wrote:
>>
>>> What's wrong with "UPDATE foo SET (foo) = (NEW);" ?
>>>
>>>
>>
>> amen brother! :-)
>>
>> I say though, since you can do:
>> SELECT foo FROM foo;
Tatsuo Ishii writes:
>> Tatsuo Ishii writes:
>>> It seems between 8.4 and CVS HEAD backend responses 'E' packet
>>> (error/fatal message) if a startup packet sent with wrong user and/or
>>> database. Before backend responses 'R' packet first followd by 'E'
>>> packet.
> I now understand that tho
Alvaro Herrera writes:
> Tom Lane wrote:
>> Still meditating on this ... and it strikes me that the pgstat.c code
>> is really uncommunicative about problems. In particular,
>> pgstat_read_statsfile_timestamp and pgstat_read_statsfile don't complain
>> at all about being unable to read a stats f
> Tatsuo Ishii writes:
> > It seems between 8.4 and CVS HEAD backend responses 'E' packet
> > (error/fatal message) if a startup packet sent with wrong user and/or
> > database. Before backend responses 'R' packet first followd by 'E'
> > packet.
>
> > Does anybody know why this change made?
>
>
Tom Lane wrote:
> I wrote:
> > Anyway it's only a guess. It could well be that that machine was simply
> > so heavily loaded that the stats collector couldn't respond fast enough.
> > I'm just wondering whether there's an unrecognized bug lurking here.
>
> Still meditating on this ... and it stri
Merlin Moncure írta:
> On Fri, Mar 12, 2010 at 3:01 PM, Boszormenyi Zoltan wrote:
>
>> What's wrong with "UPDATE foo SET (foo) = (NEW);" ?
>>
>>
>
> amen brother! :-)
>
> I say though, since you can do:
> SELECT foo FROM foo;
> why not
> UPDATE foo SET foo = new;?
>
I just tried this:
I wrote:
> Anyway it's only a guess. It could well be that that machine was simply
> so heavily loaded that the stats collector couldn't respond fast enough.
> I'm just wondering whether there's an unrecognized bug lurking here.
Still meditating on this ... and it strikes me that the pgstat.c cod
On Fri, Mar 12, 2010 at 3:01 PM, Boszormenyi Zoltan wrote:
>
> What's wrong with "UPDATE foo SET (foo) = (NEW);" ?
>
amen brother! :-)
I say though, since you can do:
SELECT foo FROM foo;
why not
UPDATE foo SET foo = new;?
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
strk írta:
> On Fri, Mar 12, 2010 at 10:47:45AM -0800, David Fetter wrote:
>
>> On Fri, Mar 12, 2010 at 07:35:41PM +0100, Pavel Stehule wrote:
>>
>>> 2010/3/12 David Fetter :
>>>
This is, by the way, an excellent argument for including hstore in
core in 9.1. :)
I wrote:
> OK, I'm going to double-check that and then back-patch the current
> tzcode files.
Oh, wait, belay that. If we do that, we will be retroactively breaking
the no-working-64-bit-integer-type support in the older branches.
Probably not a good thing to do in minor releases. I guess we'll
Heikki Linnakangas writes:
> Tom Lane wrote:
>> It strikes me that maybe we are putting ourselves at risk by blithely
>> pushing tzdata updates into back branches without also pushing tzcode
>> updates.
> I believe they're designed to be compatible both ways, I remember that
> the 64-bit changes
2010/3/12 strk :
> On Fri, Mar 12, 2010 at 10:47:45AM -0800, David Fetter wrote:
>> On Fri, Mar 12, 2010 at 07:35:41PM +0100, Pavel Stehule wrote:
>> > 2010/3/12 David Fetter :
>> > >
>> > > This is, by the way, an excellent argument for including hstore in
>> > > core in 9.1. :)
>> >
>> > I like i
Jeevan Chalke writes:
> In summary, following are the steps to re-produce:
> - Add above three lines at the beginning of the pg_tzset() function
> - make install
> - mv install/share/postgresql/timezone/posixrules
> install/share/postgresql/timezoneposixrules_a (or remove it)
> - start the se
On Fri, Mar 12, 2010 at 10:47:45AM -0800, David Fetter wrote:
> On Fri, Mar 12, 2010 at 07:35:41PM +0100, Pavel Stehule wrote:
> > 2010/3/12 David Fetter :
> > >
> > > This is, by the way, an excellent argument for including hstore in
> > > core in 9.1. :)
> >
> > I like it - but it looking little
On Fri, Mar 12, 2010 at 07:35:41PM +0100, Pavel Stehule wrote:
> 2010/3/12 David Fetter :
> >
> > This is, by the way, an excellent argument for including hstore in
> > core in 9.1. :)
>
> I like it - but it looking little bit strange - I thinking we need
> only one function (maybe with some speci
2010/3/12 David Fetter :
> On Wed, Mar 10, 2010 at 07:50:16AM -0500, Andrew Dunstan wrote:
>> hubert depesz lubaczewski wrote:
>> >On Tue, Mar 09, 2010 at 06:59:31PM +0100, Pavel Stehule wrote:
>> >>2010/3/9 strk :
>> >>>How can a pl/pgsql trigger change the
>> >>>values of dynamic fields in NEW re
Tatsuo Ishii writes:
> It seems between 8.4 and CVS HEAD backend responses 'E' packet
> (error/fatal message) if a startup packet sent with wrong user and/or
> database. Before backend responses 'R' packet first followd by 'E'
> packet.
> Does anybody know why this change made?
It's a side effec
Takahiro Itagaki wrote:
>
> Bruce Momjian wrote:
>
> > OK, I have created a new function, win32_wchar_to_db_encoding(), to
> > share the conversion from wide characters to the database encoding.
> > New patch attached.
>
> Since 9.0 has GetPlatformEncoding() for the purpose, we could simplify
>
On Mar 11, 2010, at 6:00 PM, Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>> I was looking at this recent nonrepeatable buildfarm failure:
>> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=polecat&dt=2010-03-11%2021:45:10
>> which has several instances of the known "pgstat wait timeout"
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
> > + /* If it was 'invalid authorization', add .pgpass mention */
> > + if (conn->dot_pgpass_used && conn->password_needed && conn->result &&
> > + /* only works with >= 9.0 servers */
> > + strcmp(PQresultErrorField(conn->
On Wed, Mar 10, 2010 at 07:50:16AM -0500, Andrew Dunstan wrote:
> hubert depesz lubaczewski wrote:
> >On Tue, Mar 09, 2010 at 06:59:31PM +0100, Pavel Stehule wrote:
> >>2010/3/9 strk :
> >>>How can a pl/pgsql trigger change the
> >>>values of dynamic fields in NEW record ?
> >>>
> >>>By "dynamic" I
Tom Lane wrote:
Robert Creager writes:
Is there any value in setting "keep_error_builds => 0,"? I know Andrew was
able to get the complete log file.
The data is all uploaded to the buildfarm server, so as long as EDB
doesn't holler uncle about the amount of storage that's taking,
Robert Creager writes:
> Is there any value in setting "keep_error_builds => 0,"? I know Andrew was
> able to get the complete log file.
The data is all uploaded to the buildfarm server, so as long as EDB
doesn't holler uncle about the amount of storage that's taking, I don't
think you need to
Robert Creager wrote:
On Mar 11, 2010, at 6:00 PM, Andrew Dunstan wrote:
Tom Lane wrote:
I was looking at this recent nonrepeatable buildfarm failure:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=polecat&dt=2010-03-11%2021:45:10
which has several instances of the known "pgs
Alvaro Herrera writes:
> Tom Lane wrote:
>> Most of the "pgstat wait timeout" gripes are coming from the backend
>> running the "vacuum" regression test, but there are two that came from
>> process dcc0, which is shown by other log entries to be the autovacuum
>> launcher. So now I'm wondering if
Gurjeet Singh writes:
> It seems this commit never made it to the release notes. A customer came
> asking for the fix to this very problem, and although we know that the issue
> has been fixed, we could not refer him to the release notes. All we could
> suggest was to do the minor upgrade.
We som
Tom Lane wrote:
Now, the log_text field in our build_status_log table is text, so it's
on insertion to the database that it gets truncated. I'm thinking that I
should just escape nulls with a regex ( 's/\x00/\\0/g' or similar)
before inserting the data.
Works for me.
Tom Lane wrote:
> Most of the "pgstat wait timeout" gripes are coming from the backend
> running the "vacuum" regression test, but there are two that came from
> process dcc0, which is shown by other log entries to be the autovacuum
> launcher. So now I'm wondering if there could be some issue th
Hannu Krosing wrote:
On Mon, 2010-03-08 at 21:52 -0500, Andrew Dunstan wrote:
Tom Lane wrote:
Hannu Krosing writes:
So SPI interface should also be fixed, either from perl side, or maybe
from inside SPI ?
SPI has every right to assume that data it's given is
Andrew Dunstan writes:
> Tom Lane wrote:
>> I was looking at this recent nonrepeatable buildfarm failure:
>> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=polecat&dt=2010-03-11%2021:45:10
> Well, the good news is that we actually have the data on the server, in
> a temp file that will b
On Mon, 2010-03-08 at 21:52 -0500, Andrew Dunstan wrote:
>
> Tom Lane wrote:
> > Hannu Krosing writes:
> >
> >> So SPI interface should also be fixed, either from perl side, or maybe
> >> from inside SPI ?
> >>
> >
> > SPI has every right to assume that data it's given is already in the
>
On Thu, Mar 11, 2010 at 11:24 PM, Alvaro Herrera
wrote:
> Merlin Moncure escribió:
>
>
>> (small aside: the other biggie would be able to push a composite type
>> in to an update statement...something like 'update foo set foo =
>> new'). This is really great...some variant of this question is
>>
On Wed, Mar 10, 2010 at 10:09, Fujii Masao wrote:
> Hi,
>
> http://archives.postgresql.org/pgsql-hackers/2010-01/msg01672.php
> On win32, the blocking libpq functions like PQconnectdb() and
> PQexec() are uninterruptible since they use the vanilla select()
> instead of our signal emulation layer c
2010/3/12 Dag-Erling Smørgrav :
> Tom Lane writes:
>> Any such platform would already be contending with plpgsql not working,
>> encoding conversion not working, etc etc. It's barely conceivable that
>> a client-only installation would be useful.
>
> Uh, I don't understand why it's so hard to con
Tom Lane writes:
> Any such platform would already be contending with plpgsql not working,
> encoding conversion not working, etc etc. It's barely conceivable that
> a client-only installation would be useful.
Uh, I don't understand why it's so hard to conceive that someone might
need the client
Hi Tom,
On Thu, Mar 11, 2010 at 8:29 PM, Tom Lane wrote:
> Jeevan Chalke writes:
> > While setting timezone using SET command (say GMT+3:30), postgres
> sometimes
> > crashes randomly.
>
> I can't reproduce that:
>
> regression=# SET TimeZone = 'GMT+3:30';
> SET
> regression=# SELECT '1969-12-3
On Thu, 2010-03-11 at 11:29 +0200, Heikki Linnakangas wrote:
> I'm still not any wiser on what's causing that, but I've fixed the bug
> in KnownAssignedXidsMany() now.
Yeh, I've been mulling this over for a few days now and I can't see a
way that could have happened either.
I agree with your fix
52 matches
Mail list logo
