Tom, et al,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> A few random comments based on a very fast scan through the patch:
Thanks for the feedback!
> The RTE fields really ought to be bitmaps not integer lists. The
> list representation is expensive to store, copy, etc. You could use
> the same a
On Fri, 9 Jan 2009, D'Arcy J.M. Cain wrote:
"." is on the long list of characters to be escaped I sent out earlier.
I tried escaping the '.' but it didn't change the behaviour.
I did try that specific exapmle in Trac and it worked fine for me. Using
your test rig (which you gave the wrong
* Greg Smith [090109 18:39]:
> I was hoping it might fall out of the other work being done in that area,
> given how much that code is still being poked at right now. As Hannu
> pointed out, from a conceptual level you just need to carry along the
> same information that pg_current_xlog_loca
Alvaro Herrera wrote:
> Tom Lane wrote:
>
> > I guess I'm still wondering which part of this actually needs to be
> > hand-coded so that it can be flexible. I'm envisioning the whole
> > loop replaced by something like
> >
> > FillRelOptions((void *) rdopts, options, &constanttable);
> >
>
Tom Lane wrote:
> I guess I'm still wondering which part of this actually needs to be
> hand-coded so that it can be flexible. I'm envisioning the whole
> loop replaced by something like
>
> FillRelOptions((void *) rdopts, options, &constanttable);
>
> where the constant table contains en
On Fri, 9 Jan 2009, Aidan Van Dyk wrote:
*I* didn't see an easy way to get at the "written" size later on in the
chain (i.e. in the actual archiving), so I took the path of least
resitance.
I was hoping it might fall out of the other work being done in that area,
given how much that code is s
Heikki Linnakangas wrote:
> Alvaro Herrera wrote:
> > Tom Lane wrote:
> >> Alvaro Herrera writes:
> >>> Alvaro Herrera wrote:
> I like Teodor's proposal; I'll see about implementing that.
> >>> Attached.
> >> You missed updating the sgml docs, and personally I'd be inclined to
> >> list -l be
Bruce Momjian writes:
> Uh, is this ready to be applied?
I don't think any consensus has been reached on changing this behavior.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.post
Uh, is this ready to be applied?
---
Pavel Stehule wrote:
> I am sending patch, that adds FOUND and GET DIAGNOSTICS support for
> RETURN QUERY statement
>
> Regards
> Pavel Stehule
>
>
>
> 2008/11/10 Andrew Gierth :
> >>
Uh, do we still need this patch?
---
Charlie Savage wrote:
> Charlie Savage wrote:
> > A couple of months ago I noted that 8.3.4 doesn't compile on Vista using
> > MingW+msys under certain conditions:
> >
> > http://archiv
Tom Lane writes:
> No, I think you misunderstood me entirely. The reason that I rejected
> those parts of the patch is that I think the statistics that are
> available are wrong/useless. If the bufmgr.c counters were really good
> for something they'd have been exposed long since (and we'd prob
On Fri, 2009-01-09 at 14:29 -0600, Kenneth Marshall wrote:
> Jeff,
>
> Thanks for the review. I would not really expect any differences in hash
> index build times other than normal noise variances. The most definitive
> benchmark that I have seen was done with my original patch submission
> in Ma
Bruce Momjian wrote:
Hiroshi, is this patch still needed?
Yes though it should be slightly changed now.
*set lc_messages does not work* issue isn't directly related to this
issue.
regards,
Hiroshi Inoue
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
>>> Greg Smith wrote:
> The main use case I'm concerned about losing support for is:
>
> 1) Two systems connected by a WAN with significant transmit latency
> 2) The secondary system runs a warm standby aimed at disaster
recovery
> 3) Business requirements want the standby to never be more than
Bruce Momjian writes:
> Hiroshi, is this patch still needed?
This patch is for a problem that's entirely separate from the LC_TIME
issue, if that's what you were wondering.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
Stephen Frost writes:
> Please test, comment, etc.
A few random comments based on a very fast scan through the patch:
The RTE fields really ought to be bitmaps not integer lists. The
list representation is expensive to store, copy, etc. You could use
the same approach the HOT patch used, ie of
On Fri, 9 Jan 2009, Simon Riggs wrote:
Half-filled WAL files were necessary to honour archive_timeout. With
continuous streaming all WAL files will be 100% full before we switch,
for most purposes.
The main use case I'm concerned about losing support for is:
1) Two systems connected by a WAN
On Fri, Jan 09, 2009 at 12:04:15PM -0800, Jeff Davis wrote:
> On Mon, 2008-12-22 at 13:47 -0600, Kenneth Marshall wrote:
> > Dear PostgreSQL developers,
> >
> > I am re-sending this to keep this last change to the
> > internal hash function on the radar.
> >
>
> Hi Ken,
>
> A few comments:
>
On Mon, 2008-12-22 at 13:47 -0600, Kenneth Marshall wrote:
> Dear PostgreSQL developers,
>
> I am re-sending this to keep this last change to the
> internal hash function on the radar.
>
Hi Ken,
A few comments:
1. New patch with very minor changes attached.
2. I reverted the change you made
Hiroshi, is this patch still needed?
---
Hiroshi Inoue wrote:
> Magnus Hagander wrote:
> > On 25 nov 2008, at 05.00, Tom Lane wrote:
> >
> >> Hiroshi Inoue writes:
> >>> Tom Lane wrote:
> If that's true then this cod
On Fri, 2009-01-09 at 19:38 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > Do you want me to start using the GIT repo to make it easier to
> extract parts?
>
> It would be useful.
Thanks, this is all good.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Servic
On Fri, 2009-01-09 at 11:20 +, Simon Riggs wrote:
> On Fri, 2009-01-09 at 12:33 +0200, Heikki Linnakangas wrote:
> > Simon Riggs wrote:
> > > On Thu, 2009-01-08 at 15:50 -0500, Tom Lane wrote:
> > >> Simon Riggs writes:
> > >>> On Thu, 2009-01-08 at 22:31 +0200, Heikki Linnakangas wrote:
> >
On Fri, 2009-01-09 at 13:22 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > Yes, we could make the archiver do this, but I see no big advantage over
> > having it done externally. It's not faster, safer, easier. Not easier
> > because we would want a parameter to turn it off when not wanted.
>
>>> Tom Lane wrote:
> AFAICS, file-at-a-time WAL shipping
> is a stopgap implementation that will be dead as a doornail once the
> current efforts towards realtime replication are finished.
As long as there is a way to rsync log data to multiple targets not
running replicas, with compression be
Hiroshi Saito wrote:
>> I thought this was supposed to be driven by LC_TIME now, not
>> LC_MESSAGES.
>
> Uga, yes yes!
>
> HIROSHI=# set LC_TIME=Ja;
> SET
> HIROSHI=# select to_char(now(),'TMDay');
> to_char
> -
> 土曜日
> (1 行)
>
> Thanks:-)
Great! Thanks for testing!
//Magnus
--
Sent
On Fri, 2009-01-09 at 13:49 +0200, Heikki Linnakangas wrote:
> Thinking about this some more, I'm not too happy with those names
> either. vacuum_freeze_scan_age and autovacuum_freeze_scan_age don't mean
> quite the same thing, like vacuum_cost_delay and
> autovacuum_vacuum_cost_delay do, for ex
Simon Riggs writes:
> Yes, we could make the archiver do this, but I see no big advantage over
> having it done externally. It's not faster, safer, easier. Not easier
> because we would want a parameter to turn it off when not wanted.
And the other question to ask is how much effort and code shou
Aidan Van Dyk wrote:
> * Richard Huxton [090109 12:22]:
>
>>> Yeah: the archiver process doesn't have that information available.
>
>> Am I being really dim here - why isn't the first record in the WAL file
>> a fixed-length record containing e.g. txid_start, time_start, txid_end,
>> time_end, l
Tom Lane wrote:
> "Kevin Grittner" writes:
> > Greg Smith wrote:
> >> I thought at one point that the direction this was going toward was to
> >> provide the size of the WAL file as a parameter you can use in the
> >> archive_command:
>
> > Hard to beat for performance. I thought there was
Tom Lane wrote:
> I wonder if this can be improved:
> http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/optimizer/planner.h.diff?r1=1.41;r2=1.42
>
> Similar examples can be found elsewhere ...
Agreed, pgindent does a poor job aligning function pointers. I rerand
planner.h here --- 'plan
Simon Riggs wrote:
> Do you want me to start using the GIT repo to make it easier to
extract parts?
It would be useful. Even more so for your own sanity, I think :-). I
find maintaining multiple interdependent patches much easier with GIT,
though it's still easy to get confused.
Feel free t
Simon Riggs wrote:
On Fri, 2009-01-09 at 18:30 +0200, Heikki Linnakangas wrote:
How about we refactor things?
Was that a patch against HEAD or a patch on patch?
Against HEAD.
It would be useful to nibble away at the patch, committing all the
necessary refactorings to make the patch work. T
* Richard Huxton [090109 12:22]:
> > Yeah: the archiver process doesn't have that information available.
> Am I being really dim here - why isn't the first record in the WAL file
> a fixed-length record containing e.g. txid_start, time_start, txid_end,
> time_end, length? Write it once when you
Tom Lane wrote:
> "Kevin Grittner" writes:
>> Greg Smith wrote:
>>> I thought at one point that the direction this was going toward was to
>>> provide the size of the WAL file as a parameter you can use in the
>>> archive_command:
>
>> Hard to beat for performance. I thought there was some
Guillaume Smet wrote:
On Fri, Jan 9, 2009 at 5:24 PM, Tom Lane wrote:
However, the
de facto policy is that we try to keep them passing in locales that
are used by any of the regular developers. I think it would be useful
to have buildfarm members testing in a few common locales.
If
Jamie, et al,
* Jaime Casanova (jcasa...@systemguards.com.ec) wrote:
>
> ! Currently, PostgreSQL does not recognize
> ! column-level SELECT privileges when a JOIN is involved.
> One possible workaround is to create a view having just the desired
> columns and then grant p
On Fri, 2009-01-09 at 18:30 +0200, Heikki Linnakangas wrote:
> How about we refactor things?
Was that a patch against HEAD or a patch on patch?
It would be useful to nibble away at the patch, committing all the
necessary refactorings to make the patch work. That will reduce size of
eventual comm
>>> Aidan Van Dyk 01/09/09 10:22 AM >>>
> The reason *I* shy way from pg_lesslog and pg_clearxlogtail, is that
> they seem to possibly be frail... I'm just scared of somethign
> changing in PG some time, and my pg_clearxlogtail not nowing, me
> forgetting to upgrade, and me not doing enough test
--On Freitag, Januar 09, 2009 13:20:57 +0100 Bernd Helmle
wrote:
That means, View1 consists of View2 and so on. What happens now if
someone is going to change View3, so that it's not updatable anymore?
What the patch actually does is, scanning all relations/views involved in
a current view (an
On Fri, 2009-01-09 at 18:30 +0200, Heikki Linnakangas wrote:
> The hot standby patch has some hacks to decide which full-page-images
> can be restored holding an exclusive lock and which ones need a
> vacuum-strength lock. It's not very pretty as is, as mentioned in
> comments too.
Agreed!
>
On Fri, Jan 9, 2009 at 5:24 PM, Tom Lane wrote:
> However, the
> de facto policy is that we try to keep them passing in locales that
> are used by any of the regular developers. I think it would be useful
> to have buildfarm members testing in a few common locales.
If you define common locales,
On Fri, 2009-01-09 at 11:20 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > "If any condition required by Syntax Rules is not satisfied when the
> > evaluation of Access or General Rules is attempted and the
> > implementation is neither processing non-conforming SQL language nor
> > processing
I thought this was supposed to be driven by LC_TIME now, not
LC_MESSAGES.
Uga, yes yes!
HIROSHI=# set LC_TIME=Ja;
SET
HIROSHI=# select to_char(now(),'TMDay');
to_char
-
土曜日
(1 行)
Thanks:-)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
* Simon Riggs [090109 11:33]:
> The patch as stands is IMHO not acceptable because the work to zero the
> file is performed by the unlucky backend that hits EOF on the current
> WAL file, which is bad enough, but it is also performed while holding
> WALWriteLock.
Agreed, but noting that that
The hot standby patch has some hacks to decide which full-page-images
can be restored holding an exclusive lock and which ones need a
vacuum-strength lock. It's not very pretty as is, as mentioned in
comments too.
How about we refactor things so that redo-functions are responsible for
calling
On Fri, 2009-01-09 at 09:31 -0500, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > Tom Lane wrote:
> > >> Isn't this redundant given the existence of pglesslog?
> >
> > > It does the same as pglesslog, but is simpler to use because it is
> > > automatic.
> >
> > Which als
Andrew Dunstan writes:
> Peter Eisentraut wrote:
>> The regression tests should work just fine in non-C locales.
> It was discussed here at the time, IIRC, and we put in the check
> precisely because other locales broke the buildfarm. Originally
> buildfarm just inherited the locale from its en
"Hiroshi Saito" writes:
> HIROSHI=# set LC_MESSAGES=Ja;
> SET
> HIROSHI=# select to_char(now(),'TMDay');
> to_char
> --
> Saturday
> (1 è¡)
I thought this was supposed to be driven by LC_TIME now, not
LC_MESSAGES.
regards, tom lane
--
Sent via pgsql-hackers m
Simon Riggs writes:
> "If any condition required by Syntax Rules is not satisfied when the
> evaluation of Access or General Rules is attempted and the
> implementation is neither processing non-conforming SQL language nor
> processing conforming SQL language in a non-conforming manner, then an
>
All that is useless until we get a %l in archive_command...
*I* didn't see an easy way to get at the "written" size later on in the
chain (i.e. in the actual archiving), so I took the path of least
resitance.
The reason *I* shy way from pg_lesslog and pg_clearxlogtail, is that
they seem to possib
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
D'Arcy J.M. Cain a écrit :
>
> As Tom has pointed out, ReST has problems beyond our implementation.
> People who use it are aware of these warts. Given that I really think
> that the cleanest solution is to just give them "border 3", don't
> mention
"Kevin Grittner" writes:
> Greg Smith wrote:
>> I thought at one point that the direction this was going toward was to
>> provide the size of the WAL file as a parameter you can use in the
>> archive_command:
> Hard to beat for performance. I thought there was some technical
> snag.
Yeah:
On Fri, 2009-01-09 at 17:11 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Fri, 2009-01-09 at 16:14 +0200, Peter Eisentraut wrote:
> >> Simon Riggs wrote:
> >>> I notice that we allow commands such as
> >>>
> >>> SET TRANSACTION read only read write read only;
> >>>
> >>> BEGIN TRANS
Bruce Momjian writes:
> Tom Lane wrote:
>> Which also means that everyone pays the performance penalty whether
>> they get any benefit or not. The point of the external solution
>> is to do the work only in installations that get some benefit.
>> We've been over this ground before...
> If there
>>> Greg Smith wrote:
> I thought at one point that the direction this was going toward was
to
> provide the size of the WAL file as a parameter you can use in the
> archive_command: %p provides the path, %f the file name, and now %l
the
> length. That makes an example archive command someth
Hi.
Thanks all.
I tried CVS-HEAD now.
HIROSHI=# select to_char(now(),'TMDay');
to_char
--
Saturday
(1 行)
HIROSHI=# set LC_MESSAGES=Ja;
SET
HIROSHI=# select to_char(now(),'TMDay');
to_char
--
Saturday
(1 行)
===
Peter Eisentraut wrote:
Andrew Dunstan wrote:
Regression tests have always failed on non-C locales AFAIK. The
buildfarm goes out of its way to avoid that.
The regression tests should work just fine in non-C locales. If the
buildfarm goes out of its way to avoid non-C locales, then it loses
Simon Riggs wrote:
On Fri, 2009-01-09 at 16:14 +0200, Peter Eisentraut wrote:
Simon Riggs wrote:
I notice that we allow commands such as
SET TRANSACTION read only read write read only;
BEGIN TRANSACTION read only read only read only;
Unsurprisingly, these violate the SQL Standard:
* p.977 se
I wonder if this can be improved:
http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/optimizer/planner.h.diff?r1=1.41;r2=1.42
Similar examples can be found elsewhere ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
Heikki Linnakangas wrote:
The foreign_data test case is failing when I run "make installcheck"
against a server that's been initialized with a locale other than C
(en_GB.UTF-8).
I have removed one of the differences but can't reproduce the other
right now (although it looks consequential). I
On Fri, 2009-01-09 at 16:14 +0200, Peter Eisentraut wrote:
> Simon Riggs wrote:
> > I notice that we allow commands such as
> >
> > SET TRANSACTION read only read write read only;
> >
> > BEGIN TRANSACTION read only read only read only;
> >
> > Unsurprisingly, these violate the SQL Standard:
>
Peter Eisentraut writes:
> Simon Riggs wrote:
>> I notice that we allow commands such as
>> SET TRANSACTION read only read write read only;
>> BEGIN TRANSACTION read only read only read only;
> Well, we allow a lot of things. Violations of the SQL standard happen
> when a command that appears i
Attached is the latest version.
Changes:
. some tidy up as variously requested.
. some common code is factored out
. some descriptive comments added
. platform specific stuff (e.g. spawn, reap) is factored out
. --truncate_before_load is gone, and we now do this during parallel
restore if we cr
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Isn't this redundant given the existence of pglesslog?
>
> > It does the same as pglesslog, but is simpler to use because it is
> > automatic.
>
> Which also means that everyone pays the performance penalty whether
> they get any b
Magnus Hagander wrote:
> Magnus Hagander wrote:
> > Tom Lane wrote:
> >> Magnus Hagander writes:
> >>> Alvaro Herrera wrote:
> Not that this affects me in any way, but should there be a GUC variable
> to set the default behavior system-wide?
> >>> I thought about that, but I don't want t
On Thu, 8 Jan 2009 18:45:43 -0500 (EST)
Greg Smith wrote:
> >> A. Einstein was a really smart dude.
> > Which character in the above example would you escape.
>
> "." is on the long list of characters to be escaped I sent out earlier.
> The parser looks for all sorts of enumeration syntaxes--A.,
Andrew Dunstan wrote:
Regression tests have always failed on non-C locales AFAIK. The
buildfarm goes out of its way to avoid that.
The regression tests should work just fine in non-C locales. If the
buildfarm goes out of its way to avoid non-C locales, then it loses some
significant code cov
Andrew Dunstan wrote:
Heikki Linnakangas wrote:
The foreign_data test case is failing when I run "make installcheck"
against a server that's been initialized with a locale other than C
(en_GB.UTF-8).
The reason is the different ordering of upper and lower case
characters, per attached diff f
Heikki Linnakangas wrote:
The foreign_data test case is failing when I run "make installcheck"
against a server that's been initialized with a locale other than C
(en_GB.UTF-8).
The reason is the different ordering of upper and lower case
characters, per attached diff file. We can simply ad
Simon Riggs wrote:
I notice that we allow commands such as
SET TRANSACTION read only read write read only;
BEGIN TRANSACTION read only read only read only;
Unsurprisingly, these violate the SQL Standard:
* p.977 section 19.1 syntax (1)
* p.957 section 17.3 syntax (2)
Well, we allow a lot of
The foreign_data test case is failing when I run "make installcheck"
against a server that's been initialized with a locale other than C
(en_GB.UTF-8).
The reason is the different ordering of upper and lower case characters,
per attached diff file. We can simply add an alternative expected out
Peter Eisentraut writes:
>>> This area is under SQL standard control, so we can't really invent our
>>> own behavior.
>> What *would* do the right thing here, or would anything?
> I think we don't need GRANT to be recursive, but instead the permission
> checks at runtime should allow
> SELECT
David Fetter wrote:
On Thu, Jan 08, 2009 at 02:39:52PM +0200, Peter Eisentraut wrote:
David Fetter wrote:
+1 for adding recursion to GRANT/REVOKE :)
This area is under SQL standard control, so we can't really invent our
own behavior.
Consider the following:
CREATE TABLE persons (name, emai
ITAGAKI Takahiro writes:
> I think there two independent items here:
> [1] Should we add those statistics to pg_stat_statements or not?
> [2] Should we add those statistics to EXPLAIN ANALYZE or not?
> I wanted to have [1] and proposed it, but it is rejected from 8.4.
> However, the reason is
On Fri, 2009-01-09 at 14:38 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Fri, 2009-01-09 at 13:23 +0200, Heikki Linnakangas wrote:
> >> I mean the standby should stop trying to track the in progress
> >> transactions in recovery procs, and apply the WAL records like it does
> >>
ITAGAKI Takahiro wrote:
> Hiroshi Inoue wrote:
>
>> Seems LC_CTYPE and LC_TIME should be convertible even though we use
>> wcsftime (which internally calls strftime?).
>
> Ok, wcsftime() requries both LC_TIME and LC_CTYPE are the same setting
> (at least encoding) on Windows.
>
> The attached p
Simon Riggs wrote:
On Fri, 2009-01-09 at 13:23 +0200, Heikki Linnakangas wrote:
I mean the standby should stop trying to track the in progress
transactions in recovery procs, and apply the WAL records like it does
before the consistent state is reached.
...
So, if we don't PANIC, how should
On Fri, 2009-01-09 at 13:23 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Fri, 2009-01-09 at 12:33 +0200, Heikki Linnakangas wrote:
> >> A related issue is that currently the recovery PANICs if it runs out of
> >> recovery procs. I think that's not acceptable, regardless of whether
--On Sonntag, Dezember 28, 2008 15:29:58 +0100 Bernd Helmle
wrote:
maybe the better solution is to not allow such a view to be updatable
Yes, it seems we have to check for target lists having negative attnums in
checkTree(). Another solution would be to simply ignore those columns
(extract
Jeff Davis wrote:
On Wed, 2009-01-07 at 09:34 +0200, Heikki Linnakangas wrote:
autovacuum_freeze_max_age -> autovacuum_freeze_scan_age
vacuum_freeze_max_age -> vacuum_freeze_scan_age
vacuum_freeze_min_age -> vacuum_freeze_tuple_age
*_scan_age settings control when the table is fully scanned
Simon Riggs wrote:
On Fri, 2009-01-09 at 12:33 +0200, Heikki Linnakangas wrote:
A related issue is that currently the recovery PANICs if it runs out of
recovery procs. I think that's not acceptable, regardless of whether we
use slotids or some other method to avoid it in normal operation,
beca
On Fri, 2009-01-09 at 12:33 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Thu, 2009-01-08 at 15:50 -0500, Tom Lane wrote:
> >> Simon Riggs writes:
> >>> On Thu, 2009-01-08 at 22:31 +0200, Heikki Linnakangas wrote:
> When a backend dies with FATAL, it writes an abort record bef
> You don't want to just
> modify pg_standby to accept small files, because then you've made it
> harder to make absolutely sure when the file is ready to be
> processed if a non-atomic copy is being done.
It is hard, but I think it is the right way forward.
Anyway I think the size is not rob
For what it's worth this always bothered me. I often - but nit always
- - have kerberos tickets gsst...@... lying around but my unix id is
stark.
I never set up kerberos authentication for postgres but whrn the
tickets happen to be there it fails to authenticate. I think I
complained abou
Simon Riggs wrote:
On Thu, 2009-01-08 at 15:50 -0500, Tom Lane wrote:
Simon Riggs writes:
On Thu, 2009-01-08 at 22:31 +0200, Heikki Linnakangas wrote:
When a backend dies with FATAL, it writes an abort record before exiting.
(I was under the impression it doesn't until few minutes ago myself
Magnus Hagander wrote:
> Tom Lane wrote:
>> Magnus Hagander writes:
>>> Alvaro Herrera wrote:
Not that this affects me in any way, but should there be a GUC variable
to set the default behavior system-wide?
>>> I thought about that, but I don't want to add extra gucs without a good
>>> r
On Thu, 2009-01-08 at 15:50 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > On Thu, 2009-01-08 at 22:31 +0200, Heikki Linnakangas wrote:
> >> When a backend dies with FATAL, it writes an abort record before exiting.
> >>
> >> (I was under the impression it doesn't until few minutes ago myself,
87 matches
Mail list logo