On Thu, 2009-01-08 at 15:50 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com 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
Magnus Hagander wrote:
Tom Lane wrote:
Magnus Hagander mag...@hagander.net 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
Simon Riggs wrote:
On Thu, 2009-01-08 at 15:50 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com 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
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
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 si...@2ndquadrant.com writes:
On Thu, 2009-01-08 at 22:31 +0200, Heikki Linnakangas wrote:
When a backend dies with FATAL, it writes an abort
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,
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 robust
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
--On Sonntag, Dezember 28, 2008 15:29:58 +0100 Bernd Helmle
be...@oopsware.de 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
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 we
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
ITAGAKI Takahiro wrote:
Hiroshi Inoue in...@tpf.co.jp 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
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
before the
ITAGAKI Takahiro itagaki.takah...@oss.ntt.co.jp 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
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,
Peter Eisentraut pete...@gmx.net 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
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
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
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 add
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
On Thu, 8 Jan 2009 18:45:43 -0500 (EST)
Greg Smith gsm...@gregsmith.com 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
Magnus Hagander wrote:
Magnus Hagander wrote:
Tom Lane wrote:
Magnus Hagander mag...@hagander.net 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
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
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
Peter Eisentraut pete...@gmx.net 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
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
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 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
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
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
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
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 行)
Greg Smith gsm...@gregsmith.com 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
Bruce Momjian br...@momjian.us 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
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 TRANSACTION read only read
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Greg Smith gsm...@gregsmith.com 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
-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 ReST
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
Simon Riggs si...@2ndquadrant.com 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
Hiroshi Saito z-sa...@guitar.ocn.ne.jp 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
Andrew Dunstan and...@dunslane.net 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
On Fri, 2009-01-09 at 09:31 -0500, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
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
* Simon Riggs si...@2ndquadrant.com [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,
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
On Fri, 2009-01-09 at 11:20 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com 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
On Fri, Jan 9, 2009 at 5:24 PM, Tom Lane t...@sss.pgh.pa.us 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
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!
How
--On Freitag, Januar 09, 2009 13:20:57 +0100 Bernd Helmle
maili...@oopsware.de 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
Aidan Van Dyk ai...@highrise.ca 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
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
Jamie, et al,
* Jaime Casanova (jcasa...@systemguards.com.ec) wrote:
para
! Currently, productnamePostgreSQL/productname does not recognize
! column-level SELECT privileges when a JOIN is involved.
One possible workaround is to create a view having just the desired
Guillaume Smet wrote:
On Fri, Jan 9, 2009 at 5:24 PM, Tom Lane t...@sss.pgh.pa.us 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
Tom Lane wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Greg Smith gsm...@gregsmith.com 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
* Richard Huxton d...@archonet.com [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
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.
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
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 ---
Tom Lane wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Greg Smith gsm...@gregsmith.com 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
Aidan Van Dyk wrote:
* Richard Huxton d...@archonet.com [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,
Simon Riggs si...@2ndquadrant.com 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
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
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 via
Tom Lane t...@sss.pgh.pa.us 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
On Fri, 2009-01-09 at 13:22 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com 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
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 si...@2ndquadrant.com writes:
On Thu, 2009-01-08 at 22:31 +0200, Heikki Linnakangas
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, Services
Hiroshi, is this patch still needed?
---
Hiroshi Inoue wrote:
Magnus Hagander wrote:
On 25 nov 2008, at 05.00, Tom Lane t...@sss.pgh.pa.us wrote:
Hiroshi Inoue in...@tpf.co.jp writes:
Tom Lane wrote:
If that's
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 to
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:
1. New patch
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
Stephen Frost sfr...@snowman.net 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
Bruce Momjian br...@momjian.us 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
Greg Smith gsm...@gregsmith.com 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
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
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 March
Tom Lane t...@sss.pgh.pa.us 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
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:
Bruce Momjian br...@momjian.us 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:
Heikki Linnakangas wrote:
Alvaro Herrera wrote:
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
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
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 entries
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);
where the
* Greg Smith gsm...@gregsmith.com [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
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
85 matches
Mail list logo
