-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hey,
While translating the plperl page from the manual, I found the following
sentence:
The %_SHARED variable and other global state within
the language is public data.
Should it be :
The %_SHARED variable and other global variables
within
On Fri, Jun 11, 2010 at 11:24 PM, Robert Haas wrote:
> I think the failover case might be OK. But if the master crashes and
> restarts, the slave might be left thinking its xlog position is ahead
> of the xlog position on the master.
Right. Unless we perform a failover in this case, the standby
On Fri, Jun 11, 2010 at 11:47 PM, Tom Lane wrote:
> Stefan Kaltenbrunner writes:
>> hmm not sure that is what fujii tried to say - I think his point was
>> that in the original case we would have serialized all the operations
>> (first write+sync on the master, network afterwards and write+sync o
On Sat, Jun 12, 2010 at 12:15 AM, Stefan Kaltenbrunner
wrote:
> hmm ok - but assuming sync rep we would end up with something like the
> following(hypotetically assuming each operation takes 1 time unit):
>
> originally:
>
> write 1
> sync 1
> network 1
> write 1
> sync 1
>
> total: 5
>
> whereas
I attached three patches for the effort.
Each patch tries to tackle one theme, so it is not unreasonable.
But the ESP security hook patch (quite tiny) depends on the DML permission
refactoring patch (relatively larger). So, Robert suggested me to reconsider
the dependency of these patches.
The at
The attached patch was a part of DML refactoring and security hook patches.
It adds makeRangeTblEntry() into makefuncs.c to keep the code more
clean. It shall be also used for the upcoming DML refactor patch.
In this refactoring, a common DML permission checker function take
a list of RangeTblEntr
The attached patch tries to rework DML permission checks.
It was mainly checked at the ExecCheckRTEPerms(), but same logic was
implemented in COPY TO/FROM statement and RI_Initial_Check().
This patch tries to consolidate these permission checks into a common
function to make access control decisi
2010/6/14 Greg Smith :
> Pavel Baros wrote:
>>
>> After each INSERT, UPDATE, DELETE statement (transaction)
>> pg_class.rellastxid would be updated. That should not be time- or memory-
>> consuming (not so much) since pg_class is cached, I guess.
>
> An update in PostgreSQL is essentially an INSERT
The attached patch tries to add one more security hook on the
initialization of PostgreSQL instance (InitPostgres()).
It gives the external security module a chance to initialize itself,
and acquire credential of the client.
I assumed the best place to initialize the module is just after the
init
Heikki Linnakangas wrote:
> On 12/06/10 04:19, Bruce Momjian wrote:
> > Robert Haas wrote:
> >>> If my streaming replication stops working, I want to know about it as
> >>> soon as possible. WARNING just doesn't cut it.
> >>>
> >>> This needs some better thought.
> >>>
> >>> If we PANIC, then surel
On Mon, Jun 14, 2010 at 12:16, Bruce Momjian wrote:
> Heikki Linnakangas wrote:
>> On 12/06/10 04:19, Bruce Momjian wrote:
>> > Robert Haas wrote:
>> >>> If my streaming replication stops working, I want to know about it as
>> >>> soon as possible. WARNING just doesn't cut it.
>> >>>
>> >>> This n
Fujii Masao writes:
> In SR, WAL files in the pg_xlog directory on the standby are recycled
> by every restartpoints. So your proposed function seems not to be helpful
> even if hot_standby = on.
Then I guess I'm at a loss here: what is the pg_archivecleanup utility
good for in a standby?
--
di
Hi,
I tend to consider it a bug that there's no known way under windows to
use the same trick as under Unix by using '/usr/bin/true' as your
archive command. And this Unix trick itself does feel like a hack.
Also I'd very much like to be able to recommend (even if not change the
official defaults
Robert Haas wrote:
> In response to a complaint from Hartmut Goebel:
>
> http://archives.postgresql.org/pgsql-bugs/2010-06/msg00018.php
>
> And per a design proposed by Tom Lane:
>
> http://archives.postgresql.org/pgsql-bugs/2010-06/msg00211.php
>
> PFA a patch to implement $SUBJECT. One inter
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> The attached patch tries to add one more security hook on the
> initialization of PostgreSQL instance (InitPostgres()).
>
> It gives the external security module a chance to initialize itself,
> and acquire credential of the client.
>
> I assumed the
On Mon, Jun 14, 2010 at 04:56, Fujii Masao wrote:
> On Fri, Jun 11, 2010 at 7:14 PM, Heikki Linnakangas
> wrote:
>> On 09/06/10 08:24, Fujii Masao wrote:
>>>
>>> On Wed, Jun 9, 2010 at 12:52 PM, Andrew Dunstan
>>> wrote:
There is precedent for .pgpass being a bit ambiguous. See the way
On Mon, Jun 14, 2010 at 4:14 AM, Fujii Masao wrote:
> On Fri, Jun 11, 2010 at 11:24 PM, Robert Haas wrote:
>> I think the failover case might be OK. But if the master crashes and
>> restarts, the slave might be left thinking its xlog position is ahead
>> of the xlog position on the master.
>
> R
Magnus Hagander wrote:
> >> Seems like we need something like WARNING that doesn't cause the process
> >> to die, but more alarming like ERROR/FATAL/PANIC. Or maybe just adding a
> >> hint to the warning will do. How about
> >>
> >> WARNING: ?invalid record length at 0/4005330
> >> HINT: An invalid
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Bruce Momjian wrote:
> > > Alvaro Herrera wrote:
> > > > Excerpts from Tom Lane's message of jue jun 10 11:46:25 -0400 2010:
> > > >
> > > > > Yes, the folks at commandprompt need to be told about this. Loudly.
> > > > > It's a serious packaging err
On Mon, Jun 14, 2010 at 6:57 AM, Bruce Momjian wrote:
> Robert Haas wrote:
>> In response to a complaint from Hartmut Goebel:
>>
>> http://archives.postgresql.org/pgsql-bugs/2010-06/msg00018.php
>>
>> And per a design proposed by Tom Lane:
>>
>> http://archives.postgresql.org/pgsql-bugs/2010-06/ms
(2010/06/14 20:01), Stephen Frost wrote:
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>> The attached patch tries to add one more security hook on the
>> initialization of PostgreSQL instance (InitPostgres()).
>>
>> It gives the external security module a chance to initialize itself,
>> and acqui
On Mon, Jun 14, 2010 at 13:11, Bruce Momjian wrote:
> Magnus Hagander wrote:
>> >> Seems like we need something like WARNING that doesn't cause the process
>> >> to die, but more alarming like ERROR/FATAL/PANIC. Or maybe just adding a
>> >> hint to the warning will do. How about
>> >>
>> >> WARNIN
On Mon, 2010-06-14 at 12:39 +0200, Dimitri Fontaine wrote:
> I tend to consider it a bug that there's no known way under windows to
> use the same trick as under Unix by using '/usr/bin/true' as your
> archive command. And this Unix trick itself does feel like a hack.
>
> Also I'd very much like
On Mon, 2010-06-14 at 12:21 +0200, Dimitri Fontaine wrote:
> Fujii Masao writes:
> > In SR, WAL files in the pg_xlog directory on the standby are recycled
> > by every restartpoints. So your proposed function seems not to be helpful
> > even if hot_standby = on.
>
> Then I guess I'm at a loss her
On Sat, 2010-06-12 at 03:29 +0200, Rafael Martinez wrote:
> What I didn't expect was such a serious consequence. Postgres crashed
> in the standby node and it refused to start until the directory needed
> by the tablespace was created also in the standby.
> I suppose there is not an easy way of fi
Magnus Hagander wrote:
> On Mon, Jun 14, 2010 at 13:11, Bruce Momjian wrote:
> > Magnus Hagander wrote:
> >> >> Seems like we need something like WARNING that doesn't cause the process
> >> >> to die, but more alarming like ERROR/FATAL/PANIC. Or maybe just adding a
> >> >> hint to the warning will
On Mon, Jun 14, 2010 at 7:18 AM, Magnus Hagander wrote:
> On Mon, Jun 14, 2010 at 13:11, Bruce Momjian wrote:
>> Magnus Hagander wrote:
>>> >> Seems like we need something like WARNING that doesn't cause the process
>>> >> to die, but more alarming like ERROR/FATAL/PANIC. Or maybe just adding a
>
On 14/06/10 13:39, Dimitri Fontaine wrote:
I tend to consider it a bug that there's no known way under windows to
use the same trick as under Unix by using '/usr/bin/true' as your
archive command. And this Unix trick itself does feel like a hack.
Also I'd very much like to be able to recommend (
On Mon, Jun 14, 2010 at 5:00 AM, Magnus Hagander wrote:
> 2010/6/14 Greg Smith :
>> Pavel Baros wrote:
>>>
>>> After each INSERT, UPDATE, DELETE statement (transaction)
>>> pg_class.rellastxid would be updated. That should not be time- or memory-
>>> consuming (not so much) since pg_class is cache
On 14/06/10 13:16, Bruce Momjian wrote:
Heikki Linnakangas wrote:
On 12/06/10 04:19, Bruce Momjian wrote:
Robert Haas wrote:
If my streaming replication stops working, I want to know about it as
soon as possible. WARNING just doesn't cut it.
This needs some better thought.
If we PANIC, then
2010/6/14 KaiGai Kohei :
> I attached three patches for the effort.
> Each patch tries to tackle one theme, so it is not unreasonable.
>
> But the ESP security hook patch (quite tiny) depends on the DML permission
> refactoring patch (relatively larger). So, Robert suggested me to reconsider
> the
On Mon, 2010-06-14 at 17:39 +0900, Fujii Masao wrote:
> On Fri, Jun 11, 2010 at 11:47 PM, Tom Lane wrote:
> > Stefan Kaltenbrunner writes:
> >> hmm not sure that is what fujii tried to say - I think his point was
> >> that in the original case we would have serialized all the operations
> >> (fir
On Mon, 2010-06-14 at 17:39 +0900, Fujii Masao wrote:
> No, currently walsender waits for fsync.
> ...
> But that change would cause the problem that Robert pointed out.
> http://archives.postgresql.org/pgsql-hackers/2010-06/msg00670.php
Presumably this means that if synchronous_commit = off on p
2010/6/14 KaiGai Kohei :
> The attached patch was a part of DML refactoring and security hook patches.
>
> It adds makeRangeTblEntry() into makefuncs.c to keep the code more
> clean. It shall be also used for the upcoming DML refactor patch.
> In this refactoring, a common DML permission checker fu
On Mon, Jun 14, 2010 at 3:48 AM, Jehan-Guillaume (ioguix) de Rorthais
wrote:
> While translating the plperl page from the manual, I found the following
> sentence:
>
> The %_SHARED variable and other global state within
> the language is public data.
>
> Should it be :
>
> The %_SHARED variable
2010/6/14 KaiGai Kohei :
> (2010/06/14 20:01), Stephen Frost wrote:
>> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>>> The attached patch tries to add one more security hook on the
>>> initialization of PostgreSQL instance (InitPostgres()).
>>>
>>> It gives the external security module a chance to
* Robert Haas (robertmh...@gmail.com) wrote:
> This is essentially the same patch that I wrote and posted several
> weeks ago, with changes to the comments and renaming of the
> identifiers. Are you trying to represent it as your own work?
Ehh, I doubt it. He had included your patch in another p
Simon Riggs writes:
> Cleaning the archive directory, not the pg_xlog directory.
Hence the choice of the directory where to act. I was slow on that,
sorry guys.
I guess my main problem here is that I still picture PostgreSQL has
being able to maintain an archive with no external script in the si
* Robert Haas (robertmh...@gmail.com) wrote:
> 2010/6/14 KaiGai Kohei :
> > It adds makeRangeTblEntry() into makefuncs.c to keep the code more
> > clean. It shall be also used for the upcoming DML refactor patch.
> > In this refactoring, a common DML permission checker function take
> > a list of R
On Mon, Jun 14, 2010 at 8:10 PM, Robert Haas wrote:
> Maybe. That sounds like a pretty enormous foot-gun to me, considering
> that we have no way of recovering from the situation where the standby
> gets ahead of the master.
No, we can do that by reconstructing the standby from the backup.
And,
Heikki Linnakangas writes:
> On 14/06/10 13:39, Dimitri Fontaine wrote:
>> I tend to consider it a bug that there's no known way under windows to
>> use the same trick as under Unix by using '/usr/bin/true' as your
>> archive command. And this Unix trick itself does feel like a hack.
>>
>> Also I'
On Mon, Jun 14, 2010 at 8:46 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> 2010/6/14 KaiGai Kohei :
>> > It adds makeRangeTblEntry() into makefuncs.c to keep the code more
>> > clean. It shall be also used for the upcoming DML refactor patch.
>> > In this refactoring,
On Mon, Jun 14, 2010 at 8:41 AM, Fujii Masao wrote:
> On Mon, Jun 14, 2010 at 8:10 PM, Robert Haas wrote:
>> Maybe. That sounds like a pretty enormous foot-gun to me, considering
>> that we have no way of recovering from the situation where the standby
>> gets ahead of the master.
>
> No, we can
Robert Haas writes:
> On Mon, Jun 14, 2010 at 6:57 AM, Bruce Momjian wrote:
>> Uh, I thought this was about quoting the identifiers. I am confused
>> about why "integer" is an issue in this case. Can you show an example?
> Sure.
INTEGER is actually a keyword in this context, not an identifier
Bruce Momjian writes:
> Magnus Hagander wrote:
>> It means that we can't prevent people from configuring their tools to
>> ignore important warning. We can't prevent them rom ignoring ERROR or
>> FATAL either...
> My point is that most tools are going to look at the tag first to
> determine the s
On Mon, Jun 14, 2010 at 10:08 AM, Tom Lane wrote:
> Bruce Momjian writes:
>> Magnus Hagander wrote:
>>> It means that we can't prevent people from configuring their tools to
>>> ignore important warning. We can't prevent them rom ignoring ERROR or
>>> FATAL either...
>
>> My point is that most to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14/06/2010 14:08, Robert Haas wrote:
> On Mon, Jun 14, 2010 at 3:48 AM, Jehan-Guillaume (ioguix) de Rorthais
> wrote:
>> While translating the plperl page from the manual, I found the following
>> sentence:
>>
>> The %_SHARED variable and other gl
Robert Haas writes:
> On Mon, Jun 14, 2010 at 10:08 AM, Tom Lane wrote:
>> The correct log level for this message is LOG. End of discussion.
> Why?
Because it's not being issued in a user's session. The only place it
can go is to the system log, and if you use a level of WARNING or less,
it's
On Mon, Jun 14, 2010 at 10:30 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jun 14, 2010 at 10:08 AM, Tom Lane wrote:
>>> The correct log level for this message is LOG. End of discussion.
>
>> Why?
>
> Because it's not being issued in a user's session. The only place it
> can go is to t
On Mon, Jun 14, 2010 at 10:18 AM, Jehan-Guillaume (ioguix) de Rorthais
wrote:
> On 14/06/2010 14:08, Robert Haas wrote:
>> On Mon, Jun 14, 2010 at 3:48 AM, Jehan-Guillaume (ioguix) de Rorthais
>> wrote:
>>> While translating the plperl page from the manual, I found the following
>>> sentence:
>>>
Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Jun 14, 2010 at 10:08 AM, Tom Lane wrote:
> >> The correct log level for this message is LOG. ?End of discussion.
>
> > Why?
>
> Because it's not being issued in a user's session. The only place it
> can go is to the system log, and if you use
Robert Haas writes:
> I'm willing to buy the above, but nobody has explained to my
> satisfaction why it's remotely sane to go into an infinite retry loop
> on an unrecoverable error.
That's a different question altogether ;-). I assume you're not
satisfied by the change Heikki committed a coupl
On Mon, Jun 14, 2010 at 10:38 AM, Tom Lane wrote:
> Robert Haas writes:
>> I'm willing to buy the above, but nobody has explained to my
>> satisfaction why it's remotely sane to go into an infinite retry loop
>> on an unrecoverable error.
>
> That's a different question altogether ;-). I assume
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
...
> what's stored in variables. Off the top of my head, I'm not sure if
> there is anything like that, but I wouldn't bet on there not being
> any...
I'm with Robert: I don't see much of a problem here. I might even
suggest removing the ref
On Mon, 2010-06-14 at 10:30 -0400, Tom Lane wrote:
> I'm totally unimpressed by the argument that log-filtering
> applications don't know enough to pay attention to LOG messages.
> There are already a lot of those that are quite important to notice.
We have a log level where 1 log entry in a mill
Robert Haas writes:
> On Mon, Jun 14, 2010 at 10:38 AM, Tom Lane wrote:
>> That's a different question altogether ;-). I assume you're not
>> satisfied by the change Heikki committed a couple hours ago?
>> It will at least try to do something to recover.
> Yeah, I'm not satisfied by that. It's
Robert Haas wrote:
Ok, so shouldn't it be
"The %_SHARED variable and other global state(s?)
within the language *are* public data"
?
It seems correct to me as-is, but I just work here.
Umm, you don't say "Joe and Mary is people." (Or I hope you don't.) So
"are" looks correct here
Fujii Masao writes:
> On Fri, Jun 11, 2010 at 11:47 PM, Tom Lane wrote:
>> Well, we're already not waiting for fsync, which is the slowest part.
> No, currently walsender waits for fsync.
No, you're mistaken.
> Walsender tries to send WAL up to xlogctl->LogwrtResult.Write. OTOH,
> xlogctl->Log
On Mon, Jun 14, 2010 at 10:57 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jun 14, 2010 at 10:38 AM, Tom Lane wrote:
>>> That's a different question altogether ;-). I assume you're not
>>> satisfied by the change Heikki committed a couple hours ago?
>>> It will at least try to do someth
Simon Riggs writes:
> Should I be downgrading Hot Standby breakages to LOG? That will
> certainly help high availability as well.
If a message is being issued in a non-user-connected session, there
is basically not a lot of point in WARNING or below. It should either
be LOG, or ERROR/FATAL/PANIC
On Mon, Jun 14, 2010 at 10:59 AM, Andrew Dunstan wrote:
> Robert Haas wrote:
>>> Ok, so shouldn't it be
>>>
>>> "The %_SHARED variable and other global state(s?)
>>> within the language *are* public data"
>>>
>>> ?
>> It seems correct to me as-is, but I just work here.
>
> Umm, you don't say "Joe
On Mon, Jun 14, 2010 at 11:09 AM, Tom Lane wrote:
> Simon Riggs writes:
>> Should I be downgrading Hot Standby breakages to LOG? That will
>> certainly help high availability as well.
>
> If a message is being issued in a non-user-connected session, there
> is basically not a lot of point in WARN
Robert Haas wrote:
> What Pavel's trying to do here is be smart about figuring out when
> an MV needs to be refreshed. I'm pretty sure this is the wrong
> way to go about it, but it seems entirely premature considering
> that we don't have a working implementation of a *manually*
> refreshed MV
Excerpts from Bruce Momjian's message of dom jun 13 10:00:16 -0400 2010:
> Why have I received no reply to this email? Do people think this is not
> a serious issue? I know it is a weekend but the problem was identified
> on Thursday, meaning there was a full workday for someone from
> CommandPr
On Mon, 2010-06-14 at 11:14 -0400, Robert Haas wrote:
> On Mon, Jun 14, 2010 at 11:09 AM, Tom Lane wrote:
> > Simon Riggs writes:
> >> Should I be downgrading Hot Standby breakages to LOG? That will
> >> certainly help high availability as well.
> >
> > If a message is being issued in a non-user-
Robert Haas writes:
> On Mon, Jun 14, 2010 at 11:09 AM, Tom Lane wrote:
>> If a message is being issued in a non-user-connected session, there
>> is basically not a lot of point in WARNING or below. It should either
>> be LOG, or ERROR/FATAL/PANIC (which are probably all about the same
>> thing
On Mon, Jun 14, 2010 at 11:34 AM, Simon Riggs wrote:
> On Mon, 2010-06-14 at 11:14 -0400, Robert Haas wrote:
>> On Mon, Jun 14, 2010 at 11:09 AM, Tom Lane wrote:
>> > Simon Riggs writes:
>> >> Should I be downgrading Hot Standby breakages to LOG? That will
>> >> certainly help high availability
On Mon, Jun 14, 2010 at 1:55 PM, Dimitri Fontaine
wrote:
> What about /usr/bin/true, or a simple archive where you cp in a given
> location (which could happen to be a remote server thanks to unix
> network file systems or windows shares), etc. It seems to me those are
> existing problem that we s
Heikki Linnakangas napsal(a):
On 12/06/10 17:18, Pavel Baros wrote:
I am curious how could I solve the problem:
During refreshing I would like to know, if MV is stale or fresh? And I
had an idea:
In fact, MV need to know if its last refresh (transaction id) is older
than any INSERT, UPDATE, DE
Bruce Momjian wrote:
Bruce Momjian wrote:
Bruce Momjian wrote:
Bruce Momjian wrote:
Alvaro Herrera wrote:
Excerpts from Tom Lane's message of jue jun 10 11:46:25 -0400 2010:
Yes, the folks at commandprompt need to be told about this. Loudly.
It's a serious packaging error.
Just notified L
Robert Haas writes:
> On Mon, Jun 14, 2010 at 11:09 AM, Tom Lane wrote:
>> Simon Riggs writes:
>>> Should I be downgrading Hot Standby breakages to LOG? That will
>>> certainly help high availability as well.
>>
>> If a message is being issued in a non-user-connected session, there
>> is basical
On sön, 2010-06-13 at 12:11 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Sat, Jun 12, 2010 at 1:45 AM, Peter Eisentraut wrote:
> >> I wrote it down now:
> >> http://wiki.postgresql.org/wiki/PostgreSQL_9.1_Development_Plan
>
> > Thanks! Looks good, except I thought our plan was to cut alp
Folks,
The PostgreSQL 9.1 Development Plan:
http://wiki.postgresql.org/wiki/PostgreSQL_9.1_Development_Plan
calls for a ReviewFest to run from the 15th of June (tomorrow) until
the start of the first CommitFest for the 9.1 release. The idea is
that those with time available to contribute bey
On Mon, 2010-06-14 at 18:11 +0200, Dimitri Fontaine wrote:
> Robert Haas writes:
> > On Mon, Jun 14, 2010 at 11:09 AM, Tom Lane wrote:
> >> Simon Riggs writes:
> >>> Should I be downgrading Hot Standby breakages to LOG? That will
> >>> certainly help high availability as well.
> >>
> >> If a mes
On Mon, Jun 14, 2010 at 12:31 PM, Simon Riggs wrote:
>> If that's the case, I guess Tom's right, once more, saying that LOG is
>> fine here. If we want to be more subtle than that, we'd need to revise
>> each and every error message and attribute it the right level, which it
>> probably have alrea
Robert Haas writes:
> Not sure I agree with this - what I think the problem is here is we
> need to make a clear distinction between recoverable errors and
> unrecoverable errors.
Um, if it's recoverable, it's not really an error ...
regards, tom lane
--
Sent via pgsql-
On Sat, Jun 12, 2010 at 1:21 PM, Tom Lane wrote:
> "David E. Wheeler" writes:
>> Which, IIRC, is new in 9.1, so could in theory be removed, especially if
>> there was an
>> hstore(text[], text[])
>
> Oh --- now that I look, both that and the hstore => text[] one are new
> in 9.0, which m
On Mon, Jun 14, 2010 at 1:00 PM, Tom Lane wrote:
> Robert Haas writes:
>> Not sure I agree with this - what I think the problem is here is we
>> need to make a clear distinction between recoverable errors and
>> unrecoverable errors.
>
> Um, if it's recoverable, it's not really an error ...
Gah.
On Mon, 2010-06-14 at 11:09 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > Should I be downgrading Hot Standby breakages to LOG? That will
> > certainly help high availability as well.
>
> If a message is being issued in a non-user-connected session, there
> is basically not a lot of point in W
A recent bug report
http://archives.postgresql.org/pgsql-admin/2010-06/msg00101.php
shows that dblink_build_sql_update and friends are really not all there
when it comes to dealing with dropped columns in the target table.
The immediate cause of the reported crash is just an internal matter,
but wh
On 06/14/2010 10:58 AM, Tom Lane wrote:
> A recent bug report
> http://archives.postgresql.org/pgsql-admin/2010-06/msg00101.php
> shows that dblink_build_sql_update and friends are really not all there
> when it comes to dealing with dropped columns in the target table.
Yup, was just looking at th
Joe Conway writes:
> On 06/14/2010 10:58 AM, Tom Lane wrote:
>> The current effective behavior of the code is that the column numbers
>> are physical numbers. Should we document it that way, or change it?
> Probably it should be changed to deal with dropped columns correctly,
> but I won't have
> At the risk of sounding obsessed, this is an area where predicate
> locks might be usefully extended, if and when the serializable patch
> makes it in.
Yes, we see your patch in 9.1-first. ;-)
--
-- Josh Berkus
PostgreSQ
Simon Riggs writes:
> LOG is already over-used and so anything said at that level is drowned.
This is nonsense.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpr
Simon Riggs wrote:
> LOG is already over-used and so anything said at that level is
> drowned. In many areas of code we cannot use a higher level
> without trauma. That is a problem since we have no way to separate
> the truly important from the barely interesting.
The fact that LOG is catego
"Kevin Grittner" writes:
> Simon Riggs wrote:
>> LOG is already over-used and so anything said at that level is
>> drowned. In many areas of code we cannot use a higher level
>> without trauma. That is a problem since we have no way to separate
>> the truly important from the barely interesting.
On 6/14/10 7:57 AM, Tom Lane wrote:
> However, I do agree that it's not helpful to loop forever. If we can
> easily make it retry once and then PANIC, I'd be for that --- otherwise
> I tend to agree that the best thing is just to PANIC immediately. There
> are many many situations where a slave r
On Mon, Jun 14, 2010 at 20:22, Tom Lane wrote:
> Simon Riggs writes:
>> LOG is already over-used and so anything said at that level is drowned.
>
> This is nonsense.
Whether it's over-used or not may be, but that doesn't make the
general issue nonsense.
But the fact is that having LOG at a high
On 06/14/2010 11:21 AM, Tom Lane wrote:
> Actually, I was working on it myself. On further reflection I think
> that logical numbers are clearly the right thing --- if we define it
> as being physical numbers then we will have headaches in the future
> when/if we support rearranging columns. Howe
Robert Haas wrote:
> On Mon, Jun 14, 2010 at 10:59 AM, Andrew Dunstan wrote:
> > Robert Haas wrote:
> >>> Ok, so shouldn't it be
> >>>
> >>> "The %_SHARED variable and other global state(s?)
> >>> within the language *are* public data"
> >>>
> >>> ?
> >> It seems correct to me as-is, but I just wo
Joe Conway writes:
> I didn't even think people were using those functions for many years
> since I never heard any complaints. I'd say better to not backpatch
> changes to logical ordering, but FWIW the attached at least fixes the
> immediate bug in head and ought to work at least a few branches.
On 06/14/2010 11:54 AM, Tom Lane wrote:
> Joe Conway writes:
>> I didn't even think people were using those functions for many years
>> since I never heard any complaints. I'd say better to not backpatch
>> changes to logical ordering, but FWIW the attached at least fixes the
>> immediate bug in h
Tom Lane wrote:
> "Kevin Grittner" writes:
>> The fact that LOG is categorized the same as INFO has led me to
>> believe that they are morally equivalent --
>
> They are not morally equivalent. INFO is for output that the user
> has explicitly requested appear on his console (eg, via VACUUM
>
> "Tom" == Tom Lane writes:
Tom> But actually, there's another issue here: hstore defines not one
Tom> but three => operators:
Tom> text => textyields hstore (with 1 element)
Tom> text[] => text[]yields hstore (with N elements)
Tom> hstore => text[]yiel
Excerpts from Marko Kreen's message of jue jun 10 18:10:50 -0400 2010:
> Jan's proposal of storing small struct into segmented files
> sounds like it could work. Can't say anything more because
> I can't imagine it as well as Jan. Would need to play with
> working implementation to say more...
Lacey Powers wrote:
> I tried to send something out Thursday about this to pgsql-performance,
> and I tried to send something out last night about this to
> pgsql-announce. Neither seem to have gotten through, or approved. =( =( =(
Yes, I suspected that might have happened.
> Thursday to the Pe
Bruce Momjian writes:
> OK, how do we properly get rid of all those buggy 8.4.4 installs? Seems
> a posting to announce is not enough, and we need to show users how to
> tell if they are running a de-buggy version.
The original thread already covered that in sufficient detail: check
debug_assert
Tom Lane wrote:
> Bruce Momjian writes:
> > OK, how do we properly get rid of all those buggy 8.4.4 installs? Seems
> > a posting to announce is not enough, and we need to show users how to
> > tell if they are running a de-buggy version.
>
> The original thread already covered that in sufficien
Bruce Momjian wrote:
Lacey Powers wrote:
I tried to send something out Thursday about this to pgsql-performance,
and I tried to send something out last night about this to
pgsql-announce. Neither seem to have gotten through, or approved. =( =( =(
Yes, I suspected that might have happened.
T
On 6/14/10 3:39 PM, Lacey Powers wrote:
> Bruce Momjian wrote:
>> Lacey Powers wrote:
>>> I tried to send something out Thursday about this to
>>> pgsql-performance, and I tried to send something out last night about
>>> this to pgsql-announce. Neither seem to have gotten through, or
>>> approved.
1 - 100 of 121 matches
Mail list logo
