On sön, 2009-08-23 at 09:37 -0400, Robert Haas wrote:
> To some degree, what this boils down to is that you can have
> time-based releases or feature-based releases, but not both.
Sure. But some people are trying to introduce another subvariant: The
conference-circuit-based releases. ;-) It soun
Tom Lane píše v so 22. 08. 2009 v 09:56 -0400:
> Zdenek Kotala writes:
> > There are most important records from yesterdays issues.
> > Messages:
> > -
> > Aug 20 11:14:54 genunix: [ID 470503 kern.warning] WARNING: Sorry, no swap
> > space to grow stack for pid 507 (postgres)
>
> Hmm,
Zdenek Kotala píše v po 24. 08. 2009 v 13:47 +0200:
> I tested Alvaro's patch and it works, because it does not lead to stack
> consumption, but it shows another bug in StartAutovacuumWorker() code.
> When fork fails bn structure is freed but
> ReleasePostmasterChildSlot() should be called as we
Last night I had to deal with a puzzled user of version 8.4 who found
postgres refused to start but didn't log any error. It turned out that
there was an error in the pg_hba.conf file, and the client was running
in silent mode (the SUSE default).
This seems like a bug, and it's certainly n
On Mon, Aug 24, 2009 at 14:39, Andrew Dunstan wrote:
>
> Last night I had to deal with a puzzled user of version 8.4 who found
> postgres refused to start but didn't log any error. It turned out that
> there was an error in the pg_hba.conf file, and the client was running in
> silent mode (the SU
This is to go with the hypot() patch I posted the other day.
As other code, such as found in adt/float.c and adt/numeric.c, simply
assumes that isnan() exists, despite it being a C99 function, I have
assumed the same.
The below code should be placed into a file called src/port/hypot.c.
Unfortuna
On mån, 2009-08-24 at 00:42 +0100, Grzegorz Jaskiewicz wrote:
> --enable-cassert, enabled, and also added exit_* in pg_dump to list
> of functions that never return.
A few more functions to mark noreturn: DateTimeParseError(), and
die_horribly() in pg_dump
--
Sent via pgsql-hackers mailing l
On Mon, Aug 24, 2009 at 7:39 AM, Peter Eisentraut wrote:
> On sön, 2009-08-23 at 09:37 -0400, Robert Haas wrote:
>> To some degree, what this boils down to is that you can have
>> time-based releases or feature-based releases, but not both.
>
> Sure. But some people are trying to introduce another
On Mon, Aug 24, 2009 at 11:14:19PM +1000, Paul Matthews wrote:
> This is to go with the hypot() patch I posted the other day.
>
> As other code, such as found in adt/float.c and adt/numeric.c, simply
> assumes that isnan() exists, despite it being a C99 function, I have
> assumed the same.
>
> Th
Magnus Hagander wrote:
(Maybe there's a good case for deprecating silent mode. I'm not sure why
Suse uses it. Other distros don't seem to feel the need.)
Could be, but even with silent_mode=off that would be a problem, no?
as in, the log wouldn't go where you'd expect it to go.
It
On Mon, Aug 24, 2009 at 02:57:02PM +0200, Magnus Hagander wrote:
> On Mon, Aug 24, 2009 at 14:39, Andrew Dunstan wrote:
> >
> > Last night I had to deal with a puzzled user of version 8.4 who found
> > postgres refused to start but didn't log any error. It turned out that
> > there was an error i
Andrew Dunstan writes:
> (Maybe there's a good case for deprecating silent mode.
+1. The only reason to use it is that an init-script writer is too
lazy to deal with things properly --- the thing in question here being
exactly to think of a place for early failure messages to go.
You can *not*
Andrew Dunstan writes:
> Tom Lane wrote:
>> It might be that a reasonable solution on our end would be for
>> pmdaemonize to point stdout/stderr someplace other than /dev/null,
>> perhaps "$PGDATA/postmaster.log"? Of course, it's not clear what
>> we're supposed to do if that open() fails ...
>
Tom Lane wrote:
It might be that a reasonable solution on our end would be for
pmdaemonize to point stdout/stderr someplace other than /dev/null,
perhaps "$PGDATA/postmaster.log"? Of course, it's not clear what
we're supposed to do if that open() fails ...
Well, yes, but
Bruce Momjian wrote:
> > Ultimately, why not allow:
> >
> > DELETE h, tn
> > FROM history AS h
> > INNER JOIN term_node AS tn ON (h.nid = tn.nid)
> > INNER JOIN term_data AS td ON (td.tid = tn.tid)
> > WHERE h.uid = 2067 AND td.vid = 2
> >
> > IMHO this would improve compliance towards other
Zdenek Kotala writes:
> ... We can see there that AVlauncher really wait 100ms, but it is not enough
> when system is under stress.
OK, thanks for checking that.
> I think that Alvaro's patch is good and it fix a crash problem. I also
> think that AVlauncher could wait little bit more then 100ms
Zdenek Kotala wrote:
> Just a confirmation that Alvaro's patch+ReleasePostmasterChildSlot() fix
> solves the problem and PostgreSQL survives well during a memory
> shortages.
So this patch would do it.
I think this stuff about postmaster child slots is later than
launcher/worker split. I don't
Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > > Ultimately, why not allow:
> > >
> > > DELETE h, tn
> > > FROM history AS h
> > > INNER JOIN term_node AS tn ON (h.nid = tn.nid)
> > > INNER JOIN term_data AS td ON (td.tid = tn.tid)
> > > WHERE h.uid = 2067 AND td.vid = 2
> > >
> > > IMHO
Folks,
While debugging an error with Aziz (postgres_newbie) Sharief in the
#postgresql IRC channel, I found a major POLA violation:
$ psql
Welcome to psql 8.3.7, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> >
> > > > Ultimately, why not allow:
> > > >
> > > > DELETE h, tn
> > > > FROM history AS h
> > > > INNER JOIN term_node AS tn ON (h.nid = tn.nid)
> > > > INNER JOIN term_data AS td ON (td.tid = tn.tid)
> > > > WHERE h.uid
Zdenek Kotala writes:
> I attached conservative version of patch which only reorder #define to
> avoid cross including half from readline and half from editline.
Applied, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> > > Bruce Momjian wrote:
> > >
> > > > > Ultimately, why not allow:
> > > > >
> > > > > DELETE h, tn
> > > > > FROM history AS h
> > > > > INNER JOIN term_node AS tn ON (h.nid = tn.nid)
> > > > > INNER JOIN term_data AS td
pete...@gmx.net (Peter Eisentraut) writes:
> I suggest going with four commit fests. Three is too short. We already
> started the first one early, which didn't give those involved in the
> release any time to prepare some patches for it. So with three fests
> you'd only give the major developers
Alvaro Herrera writes:
> Zdenek Kotala wrote:
>> Just a confirmation that Alvaro's patch+ReleasePostmasterChildSlot() fix
>> solves the problem and PostgreSQL survives well during a memory
>> shortages.
> So this patch would do it.
Looks good to me, but I think you should also increase the avlau
On Mon, Aug 24, 2009 at 16:31, Tom Lane wrote:
> Andrew Dunstan writes:
>> (Maybe there's a good case for deprecating silent mode.
>
> +1. The only reason to use it is that an init-script writer is too
> lazy to deal with things properly --- the thing in question here being
> exactly to think of
In response to Bruce Momjian :
> Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> >
> > > > Ultimately, why not allow:
> > > >
> > > > DELETE h, tn
> > > > FROM history AS h
> > > > INNER JOIN term_node AS tn ON (h.nid = tn.nid)
> > > > INNER JOIN term_data AS td ON (td.tid = tn.tid)
> > > >
Magnus Hagander writes:
> I don't see why we couldn't move the hba call specifically, though.
> That's a fairly common error, so it would be good if the output went
> to the place that is actually configured in postgresql.conf. It's at
> least a lot more likely than most other things that are prio
David Fetter writes:
> While debugging an error with Aziz (postgres_newbie) Sharief in the
> #postgresql IRC channel, I found a major POLA violation:
I see no bug here. There is only one '+' operator with timestamptz
as left input, and it is timestamptz plus interval, so the system
takes the unk
Alvaro Herrera writes:
> Bruce Momjian wrote:
>> So the problem is that our DELETE ... USING does not allow ANSI join
>> syntax? Can that be added?
> Not sure about that. USING is already an extension to the standard, so
> if we extend it a bit more, it can't be a problem, can it?
I don't see
On Mon, Aug 24, 2009 at 09:12:07AM -0700, David Fetter wrote:
> shac...@shackle:5432=# SELECT now() + '90';
>?column?
> ---
> 2009-09-03 19:03:43.195514-07
> (1 row)
>
> shac...@shackle:5432=# SELECT now() - '90';
> ERROR: date/time fie
Christopher Browne writes:
> I do agree that trying to force coordination with a specific conference
> in Ottawa seems like a very peculiar sort of forced scheduling.
Well, PGCon is just a convenient concrete target. The real point here
is that we're trying to get the release cycle to end with a
2009/8/24 Tom Lane :
> Alvaro Herrera writes:
>> Bruce Momjian wrote:
>>> So the problem is that our DELETE ... USING does not allow ANSI join
>>> syntax? Can that be added?
>
>> Not sure about that. USING is already an extension to the standard, so
>> if we extend it a bit more, it can't be a p
I wrote:
> ... I'm not sure why it's complaining about field overflow
> rather than syntax error when the literal is taken as a timestamp,
> but that's a pretty minor issue.
Oh, of course, it's because we allow this shorthand:
regression=# select '900102'::timestamptz;
timestamptz
--
On Mon, Aug 24, 2009 at 5:55 PM, Tom Lane wrote:
> Christopher Browne writes:
>> I do agree that trying to force coordination with a specific conference
>> in Ottawa seems like a very peculiar sort of forced scheduling.
>
> Well, PGCon is just a convenient concrete target. The real point here
> i
Tom Lane wrote:
> Alvaro Herrera writes:
> > Zdenek Kotala wrote:
> >> Just a confirmation that Alvaro's patch+ReleasePostmasterChildSlot() fix
> >> solves the problem and PostgreSQL survives well during a memory
> >> shortages.
>
> > So this patch would do it.
>
> Looks good to me, but I think
Robert Haas writes:
> 2009/8/24 Tom Lane :
>> ... Some other systems
>> allow it by letting you re-specify the target in the other clause,
>> equivalently to
>>
>> DELETE FROM target t USING t LEFT JOIN other_table ot ON ...
>>
>> but we have always considered that the target is *not* to be iden
David Fetter wrote:
> On Mon, Aug 24, 2009 at 11:14:19PM +1000, Paul Matthews wrote:
> These next two lines are a teensy bit baroque. Is there some
> significant speed increase that would justify them?
>
>> if (x == 0.0)
>> return 0.0;
>> else {
>> yx = y/x;
>>
All,
> Yeah, conference-based releases is just a proxy for time-based
> releases. It's nice to have something to be happy about at the
> conference too. And it's a convenient time to start talking about the
> next release when you're all face-to-face.
On the one hand:
I'd say that we go for the
Tom Lane wrote:
Magnus Hagander writes:
I don't see why we couldn't move the hba call specifically, though.
That's a fairly common error, so it would be good if the output went
to the place that is actually configured in postgresql.conf. It's at
least a lot more likely than most other thin
On Mon, Aug 24, 2009 at 01:41:28PM -0400, Tom Lane wrote:
> The real problem with this is that all the
> good candidates for the reserved word are things people are probably
> already using as aliases, so we'd have a large risk of breaking existing
> queries. We could avoid that with a sufficientl
On Mon, Aug 24, 2009 at 12:47:42PM -0500, Kevin Grittner wrote:
> David Fetter wrote:
> > On Mon, Aug 24, 2009 at 11:14:19PM +1000, Paul Matthews wrote:
>
> > These next two lines are a teensy bit baroque. Is there some
> > significant speed increase that would justify them?
> >
> >> if (
On Mon, Aug 24, 2009 at 01:18:46PM -0400, Tom Lane wrote:
> I wrote:
> > ... I'm not sure why it's complaining about field overflow
> > rather than syntax error when the literal is taken as a timestamp,
> > but that's a pretty minor issue.
>
> Oh, of course, it's because we allow this shorthand:
>
On Mon, Aug 24, 2009 at 07:07:13AM -0700, David Fetter wrote:
> These next two lines are a teensy bit baroque. Is there some
> significant speed increase that would justify them?
Just noticed with your revised code that the following check:
> On Mon, Aug 24, 2009 at 11:14:19PM +1000, Paul Matthe
On Mon, Aug 24, 2009 at 1:48 PM, Josh Berkus wrote:
> Therefore: I think, 3CFs, but we go all-out to get Standby/Replication
> into 8.5 in the next month. So, every committer/major hacker on this
> list should pitch in to get those features done.
>
> So, is there someone here who could be helping
On Mon, Aug 24, 2009 at 06:59:38PM +0100, Sam Mason wrote:
> > On Mon, Aug 24, 2009 at 11:14:19PM +1000, Paul Matthews wrote:
> > > if (x == 0.0)
> > > return 0.0;
> > > else {
> > > yx = y/x;
>
> is preventing a divide by zero on the line above. So it's not a
> performanc
David Fetter writes:
> On Mon, Aug 24, 2009 at 01:18:46PM -0400, Tom Lane wrote:
>> Just out of curiosity, what were you *expecting* this to do?
> The gentleman in IRC was the one who was using the construct.
Well, what did he think it would do? If it's a date it's invalid,
and if it's not a da
David Fetter writes:
> He expected '-' to subtract seconds, just as '+' added them.
Ah. Well, what it boils down to is that in a scenario like
known_type_expr operator unknown_literal
we preferentially consider unknown_literal to be of the same type
as the other operand. But there's n
Andrew Dunstan writes:
> Tom Lane wrote:
>> Oh, you mean move load_hba *down*, past the syslogger startup?
>> Yeah, that would probably be all right.
> Well, that's what I originally said, yes ;-)
> But I don't think that precludes your more general suggestion regarding
> startup errors. In par
On Mon, Aug 24, 2009 at 02:05:38PM -0400, Tom Lane wrote:
> David Fetter writes:
> > On Mon, Aug 24, 2009 at 01:18:46PM -0400, Tom Lane wrote:
> >> Just out of curiosity, what were you *expecting* this to do?
>
> > The gentleman in IRC was the one who was using the construct.
>
> Well, what did
Josh Berkus writes:
> So, is there someone here who could be helping with HS/SR and isn't?
> Why not?
You mean, other than Simon's hands-off attitude?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscri
Alvaro Herrera writes:
> Tom Lane wrote:
>> Yeah, I added that recently to try to detect postmaster children
>> that exit without cleaning up properly. I seem to have missed this
>> error case :-(. Actually it looks like fork failure for regular
>> backends gets it wrong too :-( :-( --- would yo
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> Yeah, I added that recently to try to detect postmaster children
> >> that exit without cleaning up properly. I seem to have missed this
> >> error case :-(. Actually it looks like fork failure for regular
> >> backends gets it wr
Tom Lane wrote:
Andrew Dunstan writes:
Tom Lane wrote:
Oh, you mean move load_hba *down*, past the syslogger startup?
Yeah, that would probably be all right.
Well, that's what I originally said, yes ;-)
But I don't think that precludes your more general suggest
On Mon, Aug 24, 2009 at 6:52 PM, David Fetter wrote:
> double hypot( double x, double y )
> {
> double yx;
>
> if( isinf(x) || isinf(y) )
> return get_float8_infinity();
>
> if( isnan(x) || isnan(y) )
> return get_float8_nan();
For what it's worth though, check out the code in float
On Wed, Aug 19, 2009 at 11:08 AM, Jaime
Casanova wrote:
> On Tue, Aug 18, 2009 at 6:49 AM, Heikki
> Linnakangas wrote:
>>
>> Hmm, are you sure you the right version of libpq is being loaded at
>> runtime? What does "ldd ./test-libpq" say?
>>
>
attached the results of ldd and the result of the test
Hello,
I reworked patch to respect mentioned issues. - this patch still
implement mixed notation - I am thing so this notation is really
important. All others I respect. The behave is without change, fixed
some bugs, enhanced regress tests.
Sorry for delay.
Regards
Pavel Stehule
p.s. Bernard, p
On Mon, Aug 24, 2009 at 20:51, Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>>
>> Andrew Dunstan writes:
>>
>>>
>>> Tom Lane wrote:
>>>
Oh, you mean move load_hba *down*, past the syslogger startup?
Yeah, that would probably be all right.
>>
>>
>>>
>>> Well, that's what I origin
On Mon, Aug 24, 2009 at 02:31:35PM -0400, Tom Lane wrote:
> David Fetter writes:
> > He expected '-' to subtract seconds, just as '+' added them.
>
> Ah. Well, what it boils down to is that in a scenario like
>
> known_type_expr operator unknown_literal
>
> we preferentially consider unk
Magnus Hagander writes:
> On Mon, Aug 24, 2009 at 20:51, Andrew Dunstan wrote:
>> We didn't check HBA validity at startup time before, did we? I would not be
>> surprised to get more complaints now.
Good point.
> We checked some of it, but we check it a whole lot more now.
> +1 for backpatching
On Mon, Aug 24, 2009 at 8:27 PM, David Fetter wrote:
> I'm thinking that the unknown literal here should just cause an error
> in the case of '+'. Same with '-', for what it's worth.
That would make a lot of people very unhappy. They expect things like
select date + '1 year'
to just work.
The
On fre, 2009-08-21 at 20:07 -0400, Tom Lane wrote:
> As of SQL99 it's supposed to be legal if you're grouping by a primary key
> (or some other cases where the other columns can be proved functionally
> dependent on the grouping columns, but that's the most useful one).
> We haven't got round to im
Greg Stark writes:
> I wonder if we could get around this by inventing a new type
> date_or_interval which looks at the input and decides which it is
> using fairly strict rules. date_sub would take that type and do the
> appropriate operation based on what the constant had in it.
Ick. This woul
On Mon, Aug 24, 2009 at 09:13:09PM +0100, Greg Stark wrote:
> On Mon, Aug 24, 2009 at 8:27 PM, David Fetter wrote:
> > I'm thinking that the unknown literal here should just cause an
> > error in the case of '+'. Same with '-', for what it's worth.
>
> That would make a lot of people very unhappy
Josh Berkus wrote:
> All,
>
> > Yeah, conference-based releases is just a proxy for time-based
> > releases. It's nice to have something to be happy about at the
> > conference too. And it's a convenient time to start talking about the
> > next release when you're all face-to-face.
>
> On the one
Robert Haas wrote:
> As I've said before, I am presently of the opinion that Streaming
> Replication has little chance of making it into 8.5. This opinion is
> vulnerable to contrary evidence, like a new version of the patch
> showing up that shows massive progress. But the patch was bounced
> fr
Greg Stark wrote:
> David Fetter wrote:
>> I'm thinking that the unknown literal here should just cause an
>> error in the case of '+'. Same with '-', for what it's worth.
>
> That would make a lot of people very unhappy. They expect things
> like
>
> select date + '1 year'
>
> to just work.
On Mon, Aug 24, 2009 at 4:56 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> As I've said before, I am presently of the opinion that Streaming
>> Replication has little chance of making it into 8.5. This opinion is
>> vulnerable to contrary evidence, like a new version of the patch
>> showing up
Robert Haas wrote:
> On Mon, Aug 24, 2009 at 4:56 PM, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> As I've said before, I am presently of the opinion that Streaming
> >> Replication has little chance of making it into 8.5. ?This opinion is
> >> vulnerable to contrary evidence, like a new versio
Tom Lane wrote:
> Alvaro Herrera writes:
> > Bruce Momjian wrote:
> >> So the problem is that our DELETE ... USING does not allow ANSI join
> >> syntax? Can that be added?
>
> > Not sure about that. USING is already an extension to the standard, so
> > if we extend it a bit more, it can't be a
On Monday 24 August 2009 3:51:31 pm Bruce Momjian wrote:
> > folks were expecting it in 8.4.
>
> That is a slightly alarmist. Who are we going to lose these users to?
the insane asylum?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
ht
On Mon, Aug 24, 2009 at 04:51:31PM -0400, Bruce Momjian wrote:
> Josh Berkus wrote:
> > All,
> >
> > > Yeah, conference-based releases is just a proxy for time-based
> > > releases. It's nice to have something to be happy about at the
> > > conference too. And it's a convenient time to start talki
> "Ron" == Ron Mayer writes:
>> At this point it's been 12 days since this was written and no
>> updated patch has been posted, so I think it's well past time to
>> move this to "Returned with Feedback". Accordingly I'm going to
>> make that change. Hopefully, an updated patch will be r
On ons, 2009-08-19 at 19:11 +0200, Stefan Kaltenbrunner wrote:
> Tom Lane wrote:
> > Peter Eisentraut writes:
> >> Alpha1 has been bundled and is available at
> >> http://developer.postgresql.org/~petere/alpha/
> >> Please check that it is sane.
> >
> > It looks like all the derived grammar files
Greg Stark wrote:
> Also, the question arises what should be returned for hypot(Inf,NaN)
> which your code returns Inf for. Empirically, it seems the normal
> floating point behaviour is to return NaN so I think the NaN test
> should be first.
>
>
See http://www.opengroup.org/onlinepubs/9539
"Kevin Grittner" writes:
> I realize I'm in a minority on this, but I would also prefer an error.
> I expect things like
> SELECT "date" + (INTERVAL '1' YEAR)
> to just work.
Uh, I think you're confused. That certainly works, and I didn't hear
anyone proposing to change it. The issue is abo
>> I think if we do another release without Standby/replication, we'll
>> start to lose a lot of users. People are waiting on that, and a lot of
>> folks were expecting it in 8.4.
>
> That is a slightly alarmist. Who are we going to lose these users to?
Drizzle. MySQL forks. CouchDB. Any da
Bruce Momjian writes:
> What we cannot currently do is reference test twice:
> test=> DELETE FROM test USING test;
> ERROR: table name "test" specified more than once
> test=> DELETE FROM test t USING test t;
> ERROR: table name "t" specified more than once
Hmm
Josh Berkus writes:
>> That is a slightly alarmist. Who are we going to lose these users to?
> Drizzle. MySQL forks. CouchDB. Any database which has replication
> which you don't need a professional DBA to understand. Whether or not
> it works.
You haven't explained why we'd lose such folk
Paul Matthews writes:
> Just trying to implement correct C99 behaviour here.
Around here we tend to read the Single Unix Spec before C99, and SUS
saith something different:
http://www.opengroup.org/onlinepubs/007908799/xsh/hypot.html
It would be serious folly for us to suppose that every platfo
On Mon, Aug 24, 2009 at 07:48:06PM -0400, Tom Lane wrote:
> "Kevin Grittner" writes:
> > I realize I'm in a minority on this, but I would also prefer an
> > error. I expect things like
> >
> > SELECT "date" + (INTERVAL '1' YEAR)
> >
> > to just work.
>
> Uh, I think you're confused. That certai
On Tue, Aug 25, 2009 at 1:14 AM, Tom Lane wrote:
> Paul Matthews writes:
>> Just trying to implement correct C99 behaviour here.
>
> Around here we tend to read the Single Unix Spec before C99, and SUS
> saith something different:
It doesn't seem to anticipate NaN at all.
Neither of these seems
There seems to be a bug in the visibility map in 8.4.0, introduced to
cvs on 2008-12-03. It results in tuples being called visible that
shouldn't be.
In heap_update function from heapam.c:
/*
* Note: we mustn't clear PD_ALL_VISIBLE flags before writing the WAL
* record
The following url is a patch to rework access control facilities in PostgreSQL.
http://sepgsql.googlecode.com/files/sepgsql-01-base-8.5devel-r2251.patch.gz
The current implementation does not have well separation in what
to be controled and how to be controled. For example, when we create
a new
All,
>> DELETE FROM target t USING t LEFT JOIN other_table ot ON ...
>>
>> but we have always considered that the target is *not* to be identified
>> with any member of the FROM/USING clause, so it would be a serious
>> compatibility break to change that now.
What I don't get is why this is such
On Mon, Aug 24, 2009 at 6:23 PM, Jeff Janes wrote:
> There seems to be a bug in the visibility map in 8.4.0, introduced to
> cvs on 2008-12-03. It results in tuples being called visible that
> shouldn't be.
Well, never mind. It took me a few days to track down the bug and in the
mean time I didn
On Mon, Aug 24, 2009 at 08:02:31PM -0400, Tom Lane wrote:
> Josh Berkus writes:
> >> That is a slightly alarmist. Who are we going to lose these
> >> users to?
>
> > Drizzle. MySQL forks. CouchDB. Any database which has
> > replication which you don't need a professional DBA to understand.
>
Tom,
> we preferentially consider unknown_literal to be of the same type
> as the other operand.
I can't really think of what other assumption we would make. Any time a
user doesn't specify a type, they're taking pot luck.
Me, I always use some_timestamp + INTERVAL 'value'
--
Josh Berkus
KaiGai Kohei wrote:
> The following url is a patch to rework access control facilities in
> PostgreSQL.
>
> http://sepgsql.googlecode.com/files/sepgsql-01-base-8.5devel-r2251.patch.gz
IIRC, the limitation of attachment was 40kb, so I resent it using a pointing URL
instead of attachment, sorry
Jeff Janes escribió:
> On Mon, Aug 24, 2009 at 6:23 PM, Jeff Janes wrote:
> > There seems to be a bug in the visibility map in 8.4.0, introduced to
> > cvs on 2008-12-03. It results in tuples being called visible that
> > shouldn't be.
>
> Well, never mind. It took me a few days to track down th
KaiGai Kohei wrote:
> KaiGai Kohei wrote:
> > The following url is a patch to rework access control facilities in
> > PostgreSQL.
> >
> >
> > http://sepgsql.googlecode.com/files/sepgsql-01-base-8.5devel-r2251.patch.gz
>
> IIRC, the limitation of attachment was 40kb, so I resent it using a poi
On Mon, Aug 24, 2009 at 10:15 PM, David Fetter wrote:
> On Mon, Aug 24, 2009 at 08:02:31PM -0400, Tom Lane wrote:
>> Josh Berkus writes:
>> >> That is a slightly alarmist. Who are we going to lose these
>> >> users to?
>>
>> > Drizzle. MySQL forks. CouchDB. Any database which has
>> > replicat
Jeff Janes writes:
> ... But really, I don't think such
> communication should be necessary, and the xlrec.all_visible_cleared
> and xlrec.new_all_visible_cleared fields are unneeded. Just assume
> they are true. It seems like the worst thing that can happen is that
> we call PageClearAllVisible
92 matches
Mail list logo
