their behaviour is correct according
to POSIX makes me uneasy...)
It'd be very cool if we shipped a tool that did that correctly (pg_walcopy
maybe?) on all supported platforms.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
from ever seeing that.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sep12, 2011, at 14:54 , Peter Eisentraut wrote:
On mån, 2011-09-12 at 16:46 +1000, George Barnett wrote:
On 12/09/2011, at 3:59 PM, Florian Pflug wrote:
Still, I agree with Noah and Kevin that we ought to deal more gracefully
with this, i.e. resubmit after a partial read() or write
primitives are by no means right. At best, they're
a compromise between complexity and functionality for I/O devices with rather
short (and bounded) communication timeouts - because in that case, processes are
only blocked un-interruptibly for a short while.
best regards,
Florian Pflug
--
Sent via
[CC'ing to the list again - I assume you omitted pgsql-hackers from the
recipient list by accident]
On Sep13, 2011, at 03:00 , George Barnett wrote:
On 12/09/2011, at 11:39 PM, Florian Pflug wrote:
Also, non-interruptible IO primitives are by no means right. At best,
they're
a compromise
On Sep13, 2011, at 13:07 , Florian Pflug wrote:
Here's my suggested implementation for pg_write_nointr. pg_read_nointr should
be similar
(but obviously without the ENOSPC handling)
wrong pg_write_nointr implementation snipped
Sorry for the self-reply. I realized only after hitting send
pg_write_nointr
inlined) and a few conditional jumps (which branch prediction should be
able to take care of). These are bound to disappear in the noise compared
to the cost of the actual syscall.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Sep13, 2011, at 15:05 , Aidan Van Dyk wrote:
On Tue, Sep 13, 2011 at 7:30 AM, Florian Pflug f...@phlo.org wrote:
Sorry for the self-reply. I realized only after hitting send that I
got the ENOSPC handling wrong again - we probably ought to check for
ENOSPC as well as ret == 0. Also
On Sep13, 2011, at 16:25 , Tom Lane wrote:
Florian Pflug f...@phlo.org writes:
On Sep13, 2011, at 15:05 , Aidan Van Dyk wrote:
Personally, I'ld think that's ripe for bugs. If the contract is that
ret != amount is the error case, then don't return -1 for an error
*sometimes*.
Hm
UNION instead of UNION ALL. Am I missing something, or is that
a genuine bug?
Just FYI, this question should probably have gone to -general, not -hackers.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
...)
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sep19, 2011, at 17:59 , David Fetter wrote:
On Mon, Sep 19, 2011 at 05:12:15PM +0200, Florian Pflug wrote:
My first try, BTW, was
WITH RECURSIVE infinite(value) AS (SELECT 1 UNION ALL SELECT 1)
SELECT * FROM infinite
but that returns only two rows. I'd have expected it to returns
On Sep19, 2011, at 17:46 , Jeff Davis wrote:
On Mon, 2011-09-19 at 17:23 +0200, Florian Pflug wrote:
The one reason I can see in favour of supporting N-U-L-L there is
compatibility with arrays.
But arrays actually do store and produce NULLs; ranges don't.
Hm, yeah, granted. But OTOH
functions. But couldn't for example the WAL CRC
computation be moved to a GPU? Or, to get really crazy, even the search
for the optimal join order (only for a large number of joins though,
i.e. where we currently switch to a genetic algorithmn)?
best regards,
Florian Pflug
--
Sent via pgsql-hackers
On Sep21, 2011, at 09:23 , Jeff Davis wrote:
On Mon, 2011-09-19 at 18:32 +0200, Florian Pflug wrote:
No, but more similar the format are the easier it gets to at least factor
the hairy parts of such a parser into a common subroutine. Assume that we
don't support NULL as an alias for INF. What
, '()') be '()',
but I'm not sure that's an improvement. And even if it was, you'd still
need to quote X if it contained one of (,),[,] or ,. So most
client would probably still choose to quote unconditionally, instead of
detecting whether it was necessary or not.
best regards,
Florian Pflug
--
Sent via pgsql-hackers
On Sep21, 2011, at 16:41 , Tom Lane wrote:
Florian Pflug f...@phlo.org writes:
On Sep21, 2011, at 14:00 , Robert Haas wrote:
Otherwise, anyone
who wants to construct these strings programatically is going to need
to escape everything and always write (cat,dog) or however you do
2011-09-21 13:41:05 CEST FATAL: could not access status of transaction
1188673
2011-09-21 13:41:05 CEST DETAIL: Could not read from file pg_clog/0001 at
offset 32768: Success.
Whats the size of the file (pg_clog/0001) on both the master and the slave?
best regards,
Florian Pflug
--
Sent
with '(,)' and '[,]' (which we already
decided should represent the full range).
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sep21, 2011, at 19:02 , Jeff Davis wrote:
On Wed, 2011-09-21 at 13:24 +0200, Florian Pflug wrote:
I've thought about this some more, and came to realize that the question
here really is whether
floatrange(0, 'Infinity'::float, '[)')
and
floatrange(0, NULL, '[)')
are the same
-backup checkpoint is commencing. That'd explain why the
problem goes away with immediate checkpoints, because those make the windows
mach smaller. But I haven't got a concrete theory of whats happening..
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers
to on
during a hot backup. If a page was modified at all between pg_start_backup() and
pg_stop_backup(), we essentially have to assume it's totally garbled.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
reached consistency,
we shouldn't attempt to read anything because the data can be pretty arbitrarily
garbled.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
dir
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
references
have been resolved after we've reached a consistent state, and to skip creating
restart points while there're unresolved page references.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
a truncation that happened after the checkpoint
(but before pg_stop_backup()) might or might not be reflected in the
online backup.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
On Sep27, 2011, at 07:59 , Heikki Linnakangas wrote:
On 27.09.2011 00:28, Florian Pflug wrote:
On Sep26, 2011, at 22:39 , Tom Lane wrote:
It might be worthwhile to invoke XLogCheckInvalidPages() as soon as
we (think we) have reached consistency, rather than leaving it to be
done only when we
/
The actual parser is generated from gram.y by a tool called bison. You can find
the manual at http://www.gnu.org/s/bison/.
Beware, though, that you'll have a rather steep learning curve ahead of you
if you've never used flex or bison before.
best regards,
Florian Pflug
--
Sent via pgsql-hackers
when a file vanishes after rsync computed the
file list, but before it is sent. rsync 3.0.7 on OSX, at least, complains
loudly, and doesn't sync the file. It BTW also exits non-zero, with a special
exit code for precisely that failure case.
best regards,
Florian Pflug
--
Sent via pgsql-hackers
FK constraint with CREATE CONSTRAINT TRIGGER and specified one of
the functions from ri_triggers.c as the procedure to execute.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
) parameters for a
GET request. For example, not too long ago I needed to access the Google Maps
API from postgres. I ended up using pl/python, and now wonder if your FDW would
support that use-case.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers
of server and local user.
I suggest you look at the MySQL FDW (https://github.com/dpage/mysql_fdw)
- they presumably re-use the same connection over multiple foreign scans,
which seems to be a problem similar to yours.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers
recovery code, or (quite unlikely)
a corrupted WAL that passed the CRC check. In both cases, the likelyhood
of data-corruption seems high, so PANICing seems like the right thing to do.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Sep29, 2011, at 16:43 , Dickson S. Guedes wrote:
2011/9/29 Florian Pflug f...@phlo.org:
You could use a hash table, allocated in the top-level memory context,
to store one authentication token per combination of server and local user.
In fact I started something in this way, with ldap_fdw
as a non-error case.
Oh, cool. I was about to suggest that we add something along these lines
to the docs - guess I should RTFM from time to time ;-)
best regards,
Florian Pflug
--
Sincerely,
Linas Virbalas
http://flyingclusters.blogspot.com/
--
Sent via pgsql-hackers mailing list (pgsql
the built-in canonization functions produce, and stick with it.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.
There has been talk about reducing the use of of SnapshotNow for catalog access,
but AFAIK there's no concrete proposal, and certainly no patch, available.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
aftwards.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
that sets one flag, it'd
say let's add it.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
AS SELECT * from foo;
So the question makes perfect sense, and the answer is: No, postgres currently
doesn't support that, i.e. doesn't deduce the nullability of result columns,
not even in the simplest cases.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers
forking a backend, and
make it watch for broken connections using select(). But with a large
max_backends
settings, we'd risk running out of fds in the postmaster...
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Oct7, 2011, at 00:02 , Alex Goncharov wrote:
,--- Florian Pflug (Thu, 6 Oct 2011 23:16:53 +0200) *
| Sure, but there are still a lot of cases where the database could deduce
| (quite easily) that a result column cannot be null.
Right. Of course. I can do it in 'psql'.
For the result
after you put
considerable effort into this.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Oct9, 2011, at 14:20 , Kevin Grittner wrote:
Florian Pflug wrote:
Coming up with a reasonable algorithm isn't *that* hard.
Agreed. Our shop has used a home-grown framework for over a decade
where we parse queries using ANTLR ( http://www.antlr.org/ ) and we
tracked this trough all
(assuming A,B are tables with cardinality |A|, |B|).
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Oct9, 2011, at 17:56 , Tom Lane wrote:
Florian Pflug f...@phlo.org writes:
On Oct9, 2011, at 14:20 , Kevin Grittner wrote:
Yeah. It would be nice to see at least one use case. The only
comment I recall is a vague suggestion that that people might want to
select data from a table
constructors.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
discrete, one continuous. So would we
make int4range(1, 2) include 2, but float8range(1.0, 2.0) *not* include 2.0?
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Oct10, 2011, at 19:41 , Jeff Davis wrote:
On Mon, 2011-10-10 at 19:22 +0200, Florian Pflug wrote:
I still think we should strive for consistency here, so let's also make
'[]' the default flags for the range constructors.
For continuous ranges I don't think that's a good idea. Closed-open
On Oct10, 2011, at 21:25 , Magnus Hagander wrote:
On Thu, Oct 6, 2011 at 23:46, Florian Pflug f...@phlo.org wrote:
It'd be nice to generally terminate a backend if the client vanishes, but so
far I haven't had any bright ideas. Using FASYNC and F_SETOWN unfortunately
sends a signal *everytime
representation, i.e. what you get back
when SELECTing a range (over a discrete base type).
Certainly not the end of the world, but is the convenience of being
able to write somerange(a, b) instead of somerange(a, b, '[)') really
worth it? I kind of doubt that...
best regards,
Florian Pflug
need to lookup the leaf page where the new
tuple will eventually go in the index we're supposed to maintain CLUSTER
for. Then we'd check if any of the pages referenced there contains enough
space, and if so place the new tuple there. If not it'd go at the end.
best regards,
Florian Pflug
--
Sent
that backwards compatibility, while very
important in a lot of cases, has the potential to do just as much harm
if overdone.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Oct11, 2011, at 23:35 , Simon Riggs wrote:
On Tue, Oct 11, 2011 at 10:30 PM, Florian Pflug f...@phlo.org wrote:
That experience has taught me that backwards compatibility, while very
important in a lot of cases, has the potential to do just as much harm
if overdone.
Agreed. Does my
setting.
We do transmit the individual parts of a NOTICE separately, so I'd say
suppressing some of them is the client's job. So, instead of a GUC I'd say
we'd need a psql setting ERROR_VERBOSITY.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
get that information if an actual error occurs.
Not in this instance, no.
But I still believe this is something that should be done client-side.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
, I probably want to include as much context information
as necessary in order to be able to debug possible problems post-mortem.
Having said that, having the option to not emit CONTEXT lines in the
first place wouldn't hurt of course.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing
On Oct11, 2011, at 09:21 , Magnus Hagander wrote:
On Tue, Oct 11, 2011 at 03:29, Florian Pflug f...@phlo.org wrote:
On Oct10, 2011, at 21:25 , Magnus Hagander wrote:
On Thu, Oct 6, 2011 at 23:46, Florian Pflug f...@phlo.org wrote:
It'd be nice to generally terminate a backend if the client
necessarily returned in ascending order, though.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
which uses the view.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Oct16, 2011, at 19:09 , Tom Lane wrote:
Florian Pflug f...@phlo.org writes:
On Oct15, 2011, at 20:58 , Tom Lane wrote:
So, at least as far as btrees are concerned, it seems like I implemented
the ScalarArrayOpExpr logic at the wrong level and it ought to be pushed
down into the index AM
there's an ORDER BY.
Or maybe even throw an error?
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Oct17, 2011, at 00:14 , Tom Lane wrote:
Florian Pflug f...@phlo.org writes:
But some frame clauses (row 1 preceding, for example) have an effect despite
there being no ORDER BY, like here:
Yeah, why did you expect differently? Without ORDER BY, all rows are
peers in the frame ordering
On Oct17, 2011, at 01:09 , Tom Lane wrote:
Florian Pflug f...@phlo.org writes:
... reading those parts again, I realize the it says When ORDER BY is
omitted
the *default* frame consists ... , and that the second quote is followed
by a footnote which says
There are options to define
On Oct16, 2011, at 20:26 , Tom Lane wrote:
Florian Pflug f...@phlo.org writes:
On Oct16, 2011, at 19:09 , Tom Lane wrote:
That doesn't seem like the same thing at all, because the indexed column
is on different sides of the expression in the two cases. The situation
that I'm worried about
On Oct19, 2011, at 17:47 , Greg Jaskiewicz wrote:
On 15 Oct 2011, at 11:31, Florian Pflug wrote:
Ok, here's a first cut.
So I looked at the patch, and first thing that pops out,
is lack of the volatile keyword before the ClientConnectionLostPending
variable is defined. Is that done
On Oct19, 2011, at 18:05 , Greg Jaskiewicz wrote:
On 19 Oct 2011, at 17:54, Florian Pflug wrote:
On Oct19, 2011, at 17:47 , Greg Jaskiewicz wrote:
On 15 Oct 2011, at 11:31, Florian Pflug wrote:
Ok, here's a first cut.
So I looked at the patch, and first thing that pops out,
is lack
structures.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Oct19, 2011, at 19:49 , Kevin Grittner wrote:
Robert Haas robertmh...@gmail.com wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Florian Pflug f...@phlo.org writes:
This allows a deferrable snapshot to be used on a second
connection (by e.g. pg_dump), and still be marked as DEFERRABLE.
If we
to be sufficient.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Oct20, 2011, at 01:19 , Tom Lane wrote:
Florian Pflug f...@phlo.org writes:
Taking this even further, why do we bother with non-immutable (i.e.,
depending on the database's contents) checks during ALTER ROLE/DATABASET SET
at all?
Yeah, I was wondering about that one too. It would
a new Ubuntu VM instead of playing with this.
best regards,
Florian Pflug
[1] http://psoos.blogspot.com/2009/09/building-postgresql-documentation-on.html
macports.docbook-sgml-4.2.tar.bz2
Description: BZip2 compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
on this. Do we really wanna go there?
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Oct21, 2011, at 19:09 , Tom Lane wrote:
Florian Pflug f...@phlo.org writes:
On Oct21, 2011, at 17:36 , Tom Lane wrote:
3. Remove the optimization that lets GetOldestXmin ignore XIDs outside
the current database. This sounds bad, but OTOH I don't think there's
ever been any proof
, at least for roles, because roles are
shared objects, but referenced objects might be database-local.
(search_path, for example).
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
On Oct21, 2011, at 19:47 , Robert Haas wrote:
On Fri, Oct 21, 2011 at 1:40 PM, Florian Pflug f...@phlo.org wrote:
AFAIR, the performance hit we'd take by making the vacuum cutoff point
(i.e. GetOldestXmin()) global instead of database-local has been repeatedly
used in the past as an against
,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
, is probably correct. The
question is, why?
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
not the checkpoint's location, so we ought to log an
oldestActiveXID
corresponding to that location.
What I don't understand is how this affects the CLOG. How does oldestActiveXID
factor into CLOG initialization?
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql
what happens stopwords aren't removed from the query
(Now, the tsvector ends up being 'car', but the query is 'the:* car:*')
postgres=# select to_tsvector('english', 'these cars') @@ to_tsquery('simple',
'the:* car:*');
?column?
--
f
(1 row)
best regards,
Florian Pflug
--
Sent via
On Oct25, 2011, at 18:47 , Sushant Sinha wrote:
On Tue, 2011-10-25 at 18:05 +0200, Florian Pflug wrote:
On Oct25, 2011, at 17:26 , Sushant Sinha wrote:
I am currently using the prefix search feature in text search. I find
that the prefix characters are treated the same as a normal lexeme
On Oct20, 2011, at 05:07 , Dan Ports wrote:
On Thu, Oct 20, 2011 at 02:02:09AM +0200, Florian Pflug wrote:
I've patched the ports for openjade, iso8879 and docbook-dsssl,
and added a new port for docbook-sgml-4.2. These patches are sitting
in the macports trac now, waiting to be applied
On Oct25, 2011, at 14:51 , Simon Riggs wrote:
On Tue, Oct 25, 2011 at 12:39 PM, Florian Pflug f...@phlo.org wrote:
What I don't understand is how this affects the CLOG. How does
oldestActiveXID
factor into CLOG initialization?
It is an entirely different error.
Ah, OK. I assumed
On Oct25, 2011, at 13:39 , Florian Pflug wrote:
On Oct25, 2011, at 11:13 , Simon Riggs wrote:
On Tue, Oct 25, 2011 at 8:03 AM, Simon Riggs si...@2ndquadrant.com wrote:
We are starting recovery at the right place but we are initialising
the clog and subtrans incorrectly. Precisely
page accessible?
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Oct26, 2011, at 15:57 , Florian Pflug wrote:
As you said, the CLOG page corresponding to nextId
*should* always be accessible at the start of recovery (Unless whole file
has been removed by VACUUM, that is). So we shouldn't need to extends CLOG.
Yet the error suggest that the CLOG
enough to require a CLOG extension.
That alone isn't enough to trigger the error - the CLOG extension must also
*not* make it to the disk before the checkpoint completes - but it's
a required precondition for the error to occur.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing
On Oct26, 2011, at 18:08 , Simon Riggs wrote:
On Wed, Oct 26, 2011 at 3:47 PM, Florian Pflug f...@phlo.org wrote:
On Oct26, 2011, at 15:57 , Florian Pflug wrote:
Thus, if the CLOG is extended after (or in the middle of) CheckPointGuts(),
but
before LogStandbySnapshot(), then we end up
On Oct27, 2011, at 08:57 , Heikki Linnakangas wrote:
On 27.10.2011 02:29, Florian Pflug wrote:
Per my theory about the cause of the problem in my other mail, I think you
might see StartupCLOG failures even during crash recovery, provided that
wal_level was set to hot_standby when the primary
On Oct27, 2011, at 15:51 , Simon Riggs wrote:
On Thu, Oct 27, 2011 at 12:29 AM, Florian Pflug f...@phlo.org wrote:
Here's what I image CreateCheckPoint() should look like:
1) LogStandbySnapshot() and fill out oldestActiveXid
2) Fill out REDO
3) Wait for concurrent commits
4) Fill out
On Oct27, 2011, at 16:30 , Simon Riggs wrote:
On Thu, Oct 27, 2011 at 3:03 PM, Florian Pflug f...@phlo.org wrote:
I think you make a good case for doing this.
However, I'm concerned that moving LogStandbySnapshot() in a backpatch
seems more risky than it's worth. We could easily introduce
On Oct27, 2011, at 23:02 , Bruce Momjian wrote:
Florian Pflug wrote:
On Oct21, 2011, at 16:42 , Phil Sorber wrote:
If you did want to make them immutable, I also like Florian's idea of
a dependency graph. This would make the dumps less readable though.
Hm, I kinda reversed my opinion
of this in (much) more detail.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
be done as a separate patch.
Thanks!
Woo! Congrats Jeff. Awesome news. Very excited about this feature. Thanks for
getting this in, Heikki.
+1. Great work, guys!
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Nov4, 2011, at 11:15 , Yoann Moreau wrote:
On 03/11/11 19:19, Florian Pflug wrote:
Postgres doesn't seem to contain such a function currently (don't believe
that,
though - go and recheck the documentation. I don't know all thousands of
built-in
functions by heart). But it's easy to add
as to the problem.
Have you tried to set the same locale as postgres (using setlocale()) in
your tests?
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
be
a good place for such a warning?
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
about helping the compiler produce better code,
I think we should try to make our code safe under strict aliasing
rules. AFAIK, that generally helps much more than const-correctness.
(Dunno how feasible that is, though)
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql
501 - 600 of 757 matches
Mail list logo
