On Aug11, 2011, at 09:16 , Peter Eisentraut wrote:
> On fre, 2011-07-29 at 11:37 +0200, Florian Pflug wrote:
>> On Jul28, 2011, at 22:51 , Peter Eisentraut wrote:
>>> On ons, 2011-07-27 at 23:21 +0200, Florian Pflug wrote:
>>>> On Jul27, 2011, at 23:08 , Peter Eisentr
for each of the insertions would see
> all the inserted rows.
Don't we run AFTER ROW triggers after inserting *all* the tuples anyway? At
least this is what we do in the case of INSERT/UPDATE/DELETE if I'm not
mistaken.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing
tead of at the end even over a single connection and when
writing tarfiles?
Couldn't we send all available WAL after each single data-file instead
of waiting for all data files to be transferred before sending WAL?
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
ng asynchronous IO
> (the aio_read and aio_write) and I don't know if they can be combined
> with the fdatasync() syscall?
Someone else (maybe the POSIX spec?) must answer that as I know very little
about asynchronous IO.
best regards,
Florian Pflug
--
Sent via pgsql-hackers m
went as far as arguing 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@postg
ase in code complexity should be
negligible. If we do that, however, I believe we might as well handle EINTR
correctly, even if SA_RESTART should prevent us 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. resubmi
try loop around "read" and "write".
Also, non-interruptible IO 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
[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". A
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)
>
>
Sorry for the self-reply. I realized only after hitting send that I
got the ENOSPC
#x27;t make 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.o
On Sep13, 2011, at 15:05 , Aidan Van Dyk wrote:
> On Tue, Sep 13, 2011 at 7:30 AM, Florian Pflug 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
On Sep13, 2011, at 16:25 , Tom Lane wrote:
> Florian Pflug 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 r
viour I get is what I'd have expected if I had
written "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-hack
and output
asymmetric for some DateStyle settings? Asymmetric like in you need to
send one format, but get back another...)
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 retu
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.
H
ntially
arbitrary user-defined 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,
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 suppor
or 'Infinity' or whatever), I don't see a way
around the need for quotes in the general case. Well, expect making the
representation of
range(X, NULL, '[)') be '[X)',
the one of
range(NULL, X, '(]') be '(X]'
and the one of
rang
On Sep21, 2011, at 16:41 , Tom Lane wrote:
> Florian Pflug 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 (&qu
8673
> 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 via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
27;()' and '[]',
which are too easily confused 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, &
we fail while trying to read from the
clog. When do we do that during normal (non-standby) recovery?
One other possibility would be that the problem is somehow triggered by vacuum
running while the start-backup checkpoint is commencing. That'd explain why the
problem goes away with imme
also the reasons we need to force full_page_writes 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 (pgsq
cy?
I came the the same conclusion. It seems the before we've 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 chan
particular recovery (and then delete
> them again, or leave them in place, confusing the next guy). But
> perhaps that's worth the overall simplification.
OTOH, if they're GUCs, you can specify them on the postmaster's
command line. We could even get crazy and patch pg_ctl to all
cur before we reach a consistent
state? If so, the right fix would be to check whether all invalid page
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
re
not an error, since 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:
h
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 tha
eforge.net/manual/
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
tdown checkpoint, which shouldn't be the case for the OP.
I also checked what rsync does 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 specia
lict from times where
you'd create 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 subscr
ss (dynamic) 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 (pg
cated in the top-level memory context,
to store one authentication token per combination 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
obably either a bug in our 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@p
On Sep29, 2011, at 16:43 , Dickson S. Guedes wrote:
> 2011/9/29 Florian Pflug :
>> 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 th
files", and you can write a driver script to accept
> Docs> this exit code 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,
27; since that
is what all 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
tNow and
its transaction's MVCC snapshot.
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@po
the pre-existing
object prior to restoring, and rename it back 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
cessary - but it would at least
> help those doing pg_cancel_backend()... thoughts?
If all that's needed is a simple SIGINT handler 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
es do
that - for example, I believe to remember that Microsoft SQL Server preserves
NOT NULL constraints if you do
CREATE TABLE bar 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 nullabil
select() in CHECK_FOR_INTERRUPTS seems far too expensive. We could
make the postmaster keep the fd's of around even after 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 postmaste
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 &
esign of this *before*
starting work (in a separate thread). Otherwise, you might discover objections
to the general approach, or even to the whole feature, only 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
ause I don't really see the benefit. But since most of
our competitors seem to support this, and since Sun even put this into the JDBC
spec, I guess a whole lot of people disagree.
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 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.or
cal join, instead of |A| * |B| rows for a remote
join (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 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
>>>
;s also make
'[]' the default flags for the range 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
alf-open. And there's timestamp, which
is continuous so we'd make its default half-open. That doesn't seem exactly
intuitive to me.
Second, there's int4 and float8, one discrete, one continuous. So would we
make int4range(1, 2) include 2, but float8range(1.0, 2.0) *not* inclu
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 ran
On Oct10, 2011, at 21:25 , Magnus Hagander wrote:
> On Thu, Oct 6, 2011 at 23:46, Florian Pflug 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
>>
nge construction,
but [] being the canonical 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 o
ed
table, though.
Upon INSERT and UPDATE, we'd 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.
bles, once the view
is created...
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.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On Oct11, 2011, at 23:35 , Simon Riggs wrote:
> On Tue, Oct 11, 2011 at 10:30 PM, Florian Pflug 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 overdo
t;
> Yeah, what we'd need is a client_error_verbosity 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 Pfl
ctions without seeing all the CONTEXT and STATEMENT noise when running
them via
psql, yet still 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 pg
me everything I need to know.
When I'm running the same function in a setting where there messages
go to a log file, 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
On Oct11, 2011, at 09:21 , Magnus Hagander wrote:
> On Tue, Oct 11, 2011 at 03:29, Florian Pflug wrote:
>> On Oct10, 2011, at 21:25 , Magnus Hagander wrote:
>>> On Thu, Oct 6, 2011 at 23:46, Florian Pflug wrote:
>>>> It'd be nice to generally terminate a
LECT * FROM view"). As a rule of thumb, ORDER BY in a view only makes
sense if there's also a LIMIT clause. You are then guaranteed that the
view returns the first rows according to the specified order.
Don't assume they're 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
y useless.
Things are different for views that combine ORDER BY and LIMIT, of course.
Then, not only the order of the view's results changes, but also it's output
set. Which of course affects every statement 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
s ought to be more efficient.
So maybe we should remove the support for ScalarArrayOpExpr from the main
executor, but add support for it to GIST?
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 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
ray_agg(v) over (rows 1 preceding) from d;
array_agg
---
{1}
{1,2}
{2,3}
ISTM that we probably should ignore frame clauses, unless 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 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 i
On Oct17, 2011, at 01:09 , Tom Lane wrote:
> Florian Pflug 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
&
On Oct16, 2011, at 20:26 , Tom Lane wrote:
> Florian Pflug 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 situati
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
&
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.
>&
nsaction, because those cannot participate in dangerous (i.e.
non-serializable) dependency 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 wrote:
>> Tom Lane wrote:
>>> Florian Pflug writes:
>
>>>> This allows a deferrable snapshot to be used on a second
>>>> connection (by e.g. pg_dump), and still be marked as DEFERRAB
g dropped *after* the ALTER ROLE/DATABASE
SET occurred...
If we're trying to protect against typos in settings such as default_tablespace,
a WARNING ought 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 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 t
aying 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)
To make changes to your subscrip
remove the GetOldestXmin optimization, we're essentially reversing
course 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 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
doesn't work, 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.po
On Oct21, 2011, at 19:47 , Robert Haas wrote:
> On Fri, Oct 21, 2011 at 1:40 PM, Florian Pflug 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
p label, shouldn't 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
Simon's theory that we're starting recovery from the wrong place,
i.e. should start with an earlier WAL location, 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
SUBTRANS state, we error out.
Your patch seems sensible, because the checkpoint "logically" occurs at the
REDO location 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. Ho
hese cars') @@ to_tsquery('english',
'the:* & car:*');
?column?
--
t
(1 row)
Here 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_tsve
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 t
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
On Oct25, 2011, at 14:51 , Simon Riggs wrote:
> On Tue, Oct 25, 2011 at 12:39 PM, Florian Pflug wrote:
>
>> What I don't understand is how this affects the CLOG. How does
>> oldestActiveXID
>> factor into CLOG initialization?
>
> It is an entirely different
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 wrote:
>>> We are starting recovery at the right place but we are initialising
>>> the clog and subtrans incorrectly. Precis
MMIT record may very well lie before the checkpoint's REDO
pointer, so the CLOG we copied better contained their correct state. Yet if
it does, then why isn't the nextId's CLOG 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
em's likelihood decreasing" instead
of "vanishing". The point is, the longer the checkpoint takes, the higher
the chance the nextId is advanced far enough to require a CLOG extension.
That alone isn't enough to trigger the error - the CLOG extension must also
*not* make it t
On Oct26, 2011, at 18:08 , Simon Riggs wrote:
> On Wed, Oct 26, 2011 at 3:47 PM, Florian Pflug 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 LogStandbySnapsh
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
On Oct27, 2011, at 15:51 , Simon Riggs wrote:
> On Thu, Oct 27, 2011 at 12:29 AM, Florian Pflug wrote:
>> Here's what I image CreateCheckPoint() should look like:
>>
>> 1) LogStandbySnapshot() and fill out oldestActiveXid
>> 2) Fill out REDO
>> 3) Wait
On Oct27, 2011, at 16:30 , Simon Riggs wrote:
> On Thu, Oct 27, 2011 at 3:03 PM, Florian Pflug wrote:
>
>>> I think you make a good case for doing this.
>>>
>>> However, I'm concerned that moving LogStandbySnapshot() in a backpatch
>>> seems more r
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
anning the internal btree index. In the case of tsvector and tsquery, the
implementation of these functions are gin_extract_tsquery() and
gin_tsquery_consistent(), found also in tsginidx.c.
I suggest you read http://www.postgresql.org/docs/9.1/interactive/gin.html,
it explains all 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
a clear TODO. But that can well 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 mail
601 - 700 of 759 matches
Mail list logo
