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 exit recovery mode.
I believe we also need to prevent
On 26.09.2011 21:06, Simon Riggs wrote:
On Mon, Sep 26, 2011 at 10:50 AM, Fujii Masao wrote:
Currently, if a reference to an invalid page is found during recovery,
its information
is saved in hash table "invalid_page_tab". Then, if such a reference
is resolved,
its information is removed from
Brar Piening wrote:
It's a pity that the Unicode standard actually allows something that
can cause problems but blaming the non-platform again doesn't solve
the existing issues.
To put in a more humoruos but actually correct way:
M$ has found a standard conforming way of preventing users to
On Tue, Sep 27, 2011 at 11:56 AM, Fujii Masao wrote:
>> In backup.sgml the new section titled "Making a Base Backup during
>> Recovery" I would prefer to see some mention in the title that this
>> procedure is for standby servers ie "Making a Base Backup from a Standby
>> Database". Users who h
Tom Lane wrote:
Note that the reference to byte order betrays the implicit context
assumption: that we're talking about UTF16 or UTF32 representation.
Note that there is no implicit context assumption in the Unicode FAQ.
It's equally covering UTF-8, UTF-16 and UTF-32.
Another quote:
Q: Can a UT
On Tue, Sep 27, 2011 at 1:05 PM, Tom Lane wrote:
> Fujii Masao writes:
>> ISTM that writing an invalid-page table to the disk for every restartpoints
>> is
>> better approach.
>
> I still say that's uncalled-for overkill. The invalid-page table is not
> necessary for recovery, it's only a debug
Alvaro Herrera writes:
> I just tweaked isolationtester so that it collects the error messages
> and displays them all together at the end of the test. After seeing it
> run, I didn't like it -- I think I prefer something more local, so that
> in the only case where we call try_complete_step twic
Fujii Masao writes:
> ISTM that writing an invalid-page table to the disk for every restartpoints is
> better approach.
I still say that's uncalled-for overkill. The invalid-page table is not
necessary for recovery, it's only a debugging cross-check. You're more
likely to introduce bugs than fi
Excerpts from Noah Misch's message of lun sep 26 21:57:40 -0300 2011:
> These sporadic failures happen whenever the test case takes longer than
> deadlock_timeout (currently 100ms for these tests) to setup the deadlock. I
> outlined some mitigating strategies here:
> http://archives.postgresql.or
On Mon, Sep 26, 2011 at 11:39 AM, Steve Singer wrote:
> I have looked at both Jun's patch from Sept 13 and Fujii's updates to the
> patch. I agree that Fujii's updated version should be used as the basis for
> changes going forward. My comments below refer to that version (unless
> otherwise no
Peter Eisentraut wrote:
> 8.4 -> master upgrade fails like this:
>
> Restoring user relation files
> Mismatch of relation names in database "regression": old name
> "pg_toast.pg_toast_27437", new name "pg_toast.pg_toast_27309"
> Failure, exiting
>
> This has been 100% reproducible for me.
I can
Hi Bruce,
on the old DB I've got 465783 as oid whereas on the new one it is 16505.
is not in the dump file (old db), even 16385 (i guess this is a typo here)
or 16505 are not.
The only line in which 465783 could be found is
Is that enough information or should I send the whole dump? That's a bit
On Mon, Sep 26, 2011 at 01:10:27PM -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > We are seeing numerous occasional buildfarm failures of the fk-deadlock2
> > isolation test,
>
> Yeah, I complained about this already, but Kevin disclaims all
> responsibility for the fk isolation tests. It
On 09/25/2011 02:39 PM, Joshua Berkus wrote:
There might be a use case for a separate directive include_if_exists,
or some such name. But I think the user should have to tell us very
clearly that it's okay for the file to not be found.
Better to go back to include_directory, then.
I rath
On Tue, Sep 27, 2011 at 7:28 AM, 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 exit recovery mode.
>
> I believe w
Alvaro Herrera writes:
> To be honest, I panicked for a second when I saw the new
> SnapshotResetXmin call, before I realized that it wasn't necessary
> before. The serializable case makes more sense the patched way, I
> think.
Yeah, in the old coding, SnapshotResetXmin would have happened
impli
Excerpts from Tom Lane's message of lun sep 26 20:59:45 -0300 2011:
> Well, I soon ran into the issue that delaying the snapshot release makes
> TopTransactionResourceOwner spit up. After some reflection I decided
> that the real problem is a circular dependency: snapshot management must
> be co
I wrote:
> Alvaro Herrera writes:
>> Shall I work on a fix? I expect you are plenty busy with commitfest
>> stuff, but please let me know otherwise.
> I have what-I-think-is-the-fix pretty clear in my own mind, so let me
> give it a try. If it doesn't work I'll bounce it back to you.
Well, I s
panam wrote:
> Hi Bruce,
>
> on the old DB I've got 465783 as oid whereas on the new one it is 16505.
>
> is not in the dump file (old db), even 16385 (i guess this is a typo here)
> or 16505 are not.
> The only line in which 465783 could be found is
I need to see the lines after this.
> Is tha
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 exit recovery mode.
I believe we also need to prevent the creation of restart points before
we
On 09/26/2011 05:07 PM, Jeff Janes wrote:
But in any case, considering that we are both wondering if it works on
Windows, I think that argues that an automatic regression test would
be very handy.
I think an automated test should be possible. Something like:
\setenv PGFOO blurfl
\!
Hi,
Magnus's patch for adding tab completion of views to the TABLE statement
reminded me of a minor annoyance of mine -- that EXECUTE always
completes with "PROCEDURE" as if it would have been part of CREATE
TRIGGER ... EXECUTE even when it is the first word of the line.
Attached is a simple
On Mon, Sep 26, 2011 at 12:07 PM, Josh Kupershmidt wrote:
> On Thu, Sep 15, 2011 at 7:02 PM, Andrew Dunstan wrote:
>> On Thu, September 15, 2011 6:10 pm, Josh Kupershmidt wrote:
>>> [need way to show current values]
>> \! echo $foo
>>
>> (which is how I tested the patch, of course)
>
> Ah, right.
2011/9/26 Tom Lane :
> Kohei KaiGai writes:
>> One possible idea not to store the flag in RangeTblEntry is to utilize
>> rte->relid to show the relation-id of the source view, when rtekind is
>> RTE_SUBQUERY; that enables to pull the security_barrier flag in
>> executor stage.
>
> Maybe I'm confus
Kohei KaiGai writes:
> One possible idea not to store the flag in RangeTblEntry is to utilize
> rte->relid to show the relation-id of the source view, when rtekind is
> RTE_SUBQUERY; that enables to pull the security_barrier flag in
> executor stage.
Maybe I'm confused here, but what does the exe
Simon Riggs writes:
> On Mon, Sep 26, 2011 at 10:50 AM, Fujii Masao wrote:
>> To prevent the above problem, we should write the contents of the hash table
>> to
>> the disk for every restartpoints, I think. Then, when the server
>> starts recovery,
>> it should reload the hash table from the dis
On Mon, Sep 12, 2011 at 3:31 PM, Kohei KaiGai wrote:
> The Part-2 tries to tackles a leaky-view scenarios by functions with
> very tiny cost
> estimation value. It was same one we had discussed in the commitfest-1st.
> It prevents to launch functions earlier than ones come from inside of views
>
2011/9/26 Tom Lane :
> Kohei KaiGai writes:
>> Sorry, are you saying the current (in other words, rte->security_barrier
>> stores the state of reloption) approach is not a good idea?
>
> Yes. I think the same as Robert: the way to handle this is to store it
> in RelOptInfo for the duration of pla
2011/9/26 Tom Lane :
> Kohei KaiGai writes:
>> However, the interface to reference reloptions are designed to pull
>> this information with Relation pointer, rather than lsyscache, so
>> I implemented this revision with a new rte->security_barrier member.
>
> This approach will guarantee that we c
Kohei KaiGai writes:
> Sorry, are you saying the current (in other words, rte->security_barrier
> stores the state of reloption) approach is not a good idea?
Yes. I think the same as Robert: the way to handle this is to store it
in RelOptInfo for the duration of planning, and pull it from the
ca
Kohei KaiGai writes:
> How about this fix on regression test of sepgsql?
IMO, the fundamental problem with the sepgsql regression tests is that
they think they don't need to play by the rules that apply to every
other PG regression test. I don't think this patch is fixing that
problem; it's just
Kohei KaiGai writes:
> However, the interface to reference reloptions are designed to pull
> this information with Relation pointer, rather than lsyscache, so
> I implemented this revision with a new rte->security_barrier member.
This approach will guarantee that we can never implement an ALTER V
Brar Piening writes:
> Citing from the Unicode FAQ again:
> Q: Where is a BOM useful?
> A: A BOM is useful at the beginning of files that are typed as text, but
> for which it is not known whether they are in big or little endian
> formatit can also serve as a hint indicating that the file is
Pavel Stehule writes:
> 2011/9/23 Robert Haas :
>> On Fri, Sep 23, 2011 at 12:26 AM, Pavel Stehule
>> wrote:
>>> I fixed crash that described Tom. Do you know about other?
>> No, I just don't see a new version of the patch.
> sorry - my mistake - I sent it only to Tom
Applied with corrections
How about this fix on regression test of sepgsql?
It disables to launch regression test together with other modules,
and adds its own build target "sepgsql-installcheck" that launches
chkselinuxenv script then pg_regress command as currently we
are doing.
It allows users to launch regression test
2011/9/26 Robert Haas :
> On Mon, Sep 26, 2011 at 5:58 AM, Kohei KaiGai wrote:
>>> I think it is. If you create a view that involves an RTE, the node
>>> tree is going to get stored in pg_rewrite.ev_action. And it's going
>>> to include the security_barrier attribute, because you added outfuncs
On Mon, Sep 26, 2011 at 10:50 AM, Fujii Masao wrote:
> Currently, if a reference to an invalid page is found during recovery,
> its information
> is saved in hash table "invalid_page_tab". Then, if such a reference
> is resolved,
> its information is removed from the hash table. If there is unres
Robert Haas wrote:
The thing that makes me doubt that is this comment from Tatsuo Ishii:
TI> COPY explicitly specifies the encoding (to be UTF-8 in this case). So
TI> I think we should not regard U+FEFF as "BOM" in COPY, rather we should
TI> regard U+FEFF as "ZERO WIDTH NO-BREAK SPACE".
If
On Thu, Sep 15, 2011 at 7:02 PM, Andrew Dunstan wrote:
> On Thu, September 15, 2011 6:10 pm, Josh Kupershmidt wrote:
>> [need way to show current values]
> \! echo $foo
>
> (which is how I tested the patch, of course)
Ah, right. IMO it'd be helpful to mention that echo example in your
changes to
Tom Lane wrote:
Yeah, that's a reasonable argument for rejecting the patch altogether.
I'm not qualified to decide whether it outweighs the "we need to be able
to read Notepad output" argument.
Actually it's not only notepad.
I quite often find myself doing something like the following when mo
Tom Lane wrote:
Putting a BOM into UTF8 data is flat out invalid per spec --- the fact
that Microsloth does it does not make it standards-conformant.
Could you share a pointer to the spec?
All I've ever heard is that a BOM is optional for UTF-8 but not forbidden.
The Unicode FAQ (http://unicod
On mån, 2011-09-26 at 14:44 -0400, Robert Haas wrote:
> > We did recently accept a patch for psql -f to skip over a UTF-8
> > byte-order mark. We had a lot of this same discussion there.
>
> But that case is different, because zero-width, non-breaking space has
> no particular meaning in an SQL s
On 09/26/2011 02:38 PM, Peter Eisentraut wrote:
On mån, 2011-09-26 at 13:19 -0400, Robert Haas wrote:
The thing that makes me doubt that is this comment from Tatsuo Ishii:
TI> COPY explicitly specifies the encoding (to be UTF-8 in this case).
So
TI> I think we should not regard U+FEFF as "B
On Mon, Sep 26, 2011 at 2:38 PM, Peter Eisentraut wrote:
> On mån, 2011-09-26 at 13:19 -0400, Robert Haas wrote:
>> The thing that makes me doubt that is this comment from Tatsuo Ishii:
>>
>> TI> COPY explicitly specifies the encoding (to be UTF-8 in this case).
>> So
>> TI> I think we should not
On mån, 2011-09-26 at 13:19 -0400, Robert Haas wrote:
> The thing that makes me doubt that is this comment from Tatsuo Ishii:
>
> TI> COPY explicitly specifies the encoding (to be UTF-8 in this case).
> So
> TI> I think we should not regard U+FEFF as "BOM" in COPY, rather we
> should
> TI> regard
On Mon, Sep 26, 2011 at 5:58 AM, Kohei KaiGai wrote:
>> I think it is. If you create a view that involves an RTE, the node
>> tree is going to get stored in pg_rewrite.ev_action. And it's going
>> to include the security_barrier attribute, because you added outfuncs
>> support for it...
>>
>> No
On tis, 2011-09-27 at 00:09 +0900, Tatsuo Ishii wrote:
> Suppose a user uses brain-dead editor, which does not accept UTF-8
> without BOM.
I would first like to see evidence that such an editor exists.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Robert Haas writes:
> On Mon, Sep 26, 2011 at 1:28 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> The thing that makes me doubt that is this comment from Tatsuo Ishii:
>>> TI> COPY explicitly specifies the encoding (to be UTF-8 in this case). So
>>> TI> I think we should not regard U+FEFF as "B
On Mon, Sep 26, 2011 at 1:28 PM, Tom Lane wrote:
> Robert Haas writes:
>> The thing that makes me doubt that is this comment from Tatsuo Ishii:
>> TI> COPY explicitly specifies the encoding (to be UTF-8 in this case). So
>> TI> I think we should not regard U+FEFF as "BOM" in COPY, rather we shou
Robert Haas writes:
> The thing that makes me doubt that is this comment from Tatsuo Ishii:
> TI> COPY explicitly specifies the encoding (to be UTF-8 in this case). So
> TI> I think we should not regard U+FEFF as "BOM" in COPY, rather we should
> TI> regard U+FEFF as "ZERO WIDTH NO-BREAK SPACE".
Robert Haas writes:
> On Mon, Sep 26, 2011 at 11:09 AM, Tatsuo Ishii wrote:
>> Suppose a user uses brain-dead editor, which does not accept UTF-8
>> without BOM.
> Maybe this needs to be an optional behavior, controlled by some COPY option.
I'm not excited about emitting non-standards-conforman
On Sep26, 2011, at 11:50 , Fujii Masao wrote:
> Currently, if a reference to an invalid page is found during recovery,
> its information
> is saved in hash table "invalid_page_tab". Then, if such a reference
> is resolved,
> its information is removed from the hash table. If there is unresolved
> r
On Mon, Sep 26, 2011 at 1:15 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Sep 26, 2011 at 11:09 AM, Tatsuo Ishii wrote:
>>> Suppose a user uses brain-dead editor, which does not accept UTF-8
>>> without BOM.
>
>> Maybe this needs to be an optional behavior, controlled by some COPY option
Andrew Dunstan writes:
> We are seeing numerous occasional buildfarm failures of the fk-deadlock2
> isolation test,
Yeah, I complained about this already, but Kevin disclaims all
responsibility for the fk isolation tests. It looks like Alvaro
and Noah Misch are the people to be harassing.
I've been continuing work on modifying the system to let foreign keys
coexist concurrently with updates that do not touch the "key" columns.
I've made a lot of progress and things seem to be working rather well.
However, I just struck an obstacle that seemed problematic: handling the
truncation of
On Mon, Sep 26, 2011 at 11:03 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Sep 26, 2011 at 10:04 AM, Tom Lane wrote:
>>> Another possibility is to remove the Makefile's knowledge of how to run
>>> the tests, and change chkselinuxenv into something that both verifies
>>> the environment a
On Mon, Sep 26, 2011 at 11:09 AM, Tatsuo Ishii wrote:
>> "David E. Wheeler"
>> writes:
>>> On Sep 25, 2011, at 9:58 PM, Itagaki Takahiro wrote:
I'm thinking about only COPY FROM for reads, but if someone wants to add
BOM in COPY TO, we might also support COPY TO WITH BOM for writes.
>
Andrew Dunstan wrote:
> We are seeing numerous occasional buildfarm failures of the
> fk-deadlock2 isolation test
> If this is harmless, we could provide an alternative results file
> as a simple fix. If it's not harmless, it should be fixed.
I agree, but don't look at me. I'm not the one w
Peter Eisentraut writes:
> On mån, 2011-09-26 at 10:08 -0400, Tom Lane wrote:
>> No, it's a hundred times worse than that, because in collations other
>> than C there typically *is* no total order. The collation behavior of
>> many characters is context-sensitive, thanks to the multi-pass behavi
We are seeing numerous occasional buildfarm failures of the fk-deadlock2
isolation test, that look like this:
***
*** 32,39
step s2u1: UPDATE B SET Col2 = 1 WHERE BID = 2;
step s1u2: UPDATE B SET Col2 = 1 WHERE BID = 2;
step s2u2: UPDATE B SET Col2 = 1
On Fri, Sep 23, 2011 at 2:49 PM, Robert Haas wrote:
> On Mon, Sep 19, 2011 at 4:36 PM, Dan McGee wrote:
>> [ patch ]
>
> I suppose it's Tom who really needs to comment on this, but I'm not
> too enthusiastic about this approach. Duplicating the Linux kernel
> calculation into our code means that
Kerem Kat writes:
> In the parser while analyzing SetOperationStmt, larg and rarg needs to be
> transformed as subqueries. SetOperationStmt can have two fields representing
> larg and rarg with projected columns according to corresponding:
> larg_corresponding,
> rarg_corresponding.
Why? CORRESP
> compression is an interesting topic: the guys over at tokudb are
> making some wild claims...i'm curious if they are real, and what the
> real tradeoffs are.
I don't know how much of the performance they claim comes from
compression and how much from the different indexing technique they
use
2011/9/26 Tom Lane :
> Robert Haas writes:
>> On Mon, Sep 26, 2011 at 10:04 AM, Tom Lane wrote:
>>> Another possibility is to remove the Makefile's knowledge of how to run
>>> the tests, and change chkselinuxenv into something that both verifies
>>> the environment and then launches the tests.
>
> "David E. Wheeler"
> writes:
>> On Sep 25, 2011, at 9:58 PM, Itagaki Takahiro wrote:
>>> I'm thinking about only COPY FROM for reads, but if someone wants to add
>>> BOM in COPY TO, we might also support COPY TO WITH BOM for writes.
>
>> I think it would have to be optional, since "some recip
Robert Haas writes:
> On Mon, Sep 26, 2011 at 10:04 AM, Tom Lane wrote:
>> Another possibility is to remove the Makefile's knowledge of how to run
>> the tests, and change chkselinuxenv into something that both verifies
>> the environment and then launches the tests.
> That's not a bad fix, eith
On Mon, Sep 26, 2011 at 9:21 AM, Robert Haas wrote:
> On Mon, Sep 26, 2011 at 10:02 AM, Merlin Moncure wrote:
>> On Mon, Sep 26, 2011 at 5:41 AM, crocket wrote:
>>> MySQL already has unsigned INT type, and it has double the range of
>>> signed INT type.
>>> It's not just the bigger range that UI
> I'd like to support UTF-8 text or csv files that has BOM (byte order mark)
> in COPY FROM command. BOM will be automatically detected and ignored
> if the file encoding is UTF-8. WIP patch attached.
>From RFC3629(http://tools.ietf.org/html/rfc3629#section-6):
o A protocol SHOULD forbid use of
"David E. Wheeler"
writes:
> On Sep 25, 2011, at 9:58 PM, Itagaki Takahiro wrote:
>> I'm thinking about only COPY FROM for reads, but if someone wants to add
>> BOM in COPY TO, we might also support COPY TO WITH BOM for writes.
> I think it would have to be optional, since "some recipients of U
On Mon, Sep 26, 2011 at 9:51 AM, Kohei KaiGai wrote:
>> No, you're missing my point completely. If we use a flexible options
>> syntax here, then we have to decide on what behavior CREATE OR REPLACE
>> should have for all future options, without knowing what they are yet,
>> or what behavior will
On mån, 2011-09-26 at 10:08 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > On fre, 2011-09-23 at 20:35 +0300, Marcin Mańk wrote:
> >> One idea:
> >> col like 'foo%' could be translated to col >= 'foo' and col <= foo ||
> >> 'zzz' , where 'z' is the largest possible character. This should b
Dimitri Fontaine writes:
> I'm in the middle of catching-up with pgsql-general and I see several
> confused users about how to upgrade directly from 8.4. As Tom said, we
> could easily provide upgrade scripts to handle the move, we just
> didn't, so there's some more manual work to do.
> I'm won
On Wed, 21 Sep 2011, Tom Lane wrote:
Euler Taveira de Oliveira writes:
On 21-09-2011 13:28, Daniel VАzquez wrote:
"unaccent" is compatible with postgresql 8.4 (but not is in their contrib
version distribution)
No, it is not. AFAICS it is necessary to add some backend code that is not in
8
On Mon, Sep 26, 2011 at 10:02 AM, Merlin Moncure wrote:
> On Mon, Sep 26, 2011 at 5:41 AM, crocket wrote:
>> MySQL already has unsigned INT type, and it has double the range of
>> signed INT type.
>> It's not just the bigger range that UINT type brings.
>> If unsigned INT type exists, I wouldn't
On Mon, Sep 26, 2011 at 10:04 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On sön, 2011-09-25 at 23:49 -0400, Robert Haas wrote:
>>> In fact, I've been wondering if we ought to go a step further and not
>>> recurse into the sepgsql directory for *any* of the targets. Then we
>>> could get r
Peter Eisentraut writes:
> On fre, 2011-09-23 at 20:35 +0300, Marcin MaÅk wrote:
>> One idea:
>> col like 'foo%' could be translated to col >= 'foo' and col <= foo || 'zzz'
>> , where 'z' is the largest possible character. This should be good enough
>> for calculating stats.
>> How to find suc
Peter Eisentraut writes:
> On sön, 2011-09-25 at 23:49 -0400, Robert Haas wrote:
>> In fact, I've been wondering if we ought to go a step further and not
>> recurse into the sepgsql directory for *any* of the targets. Then we
>> could get rid of the associated configure option, which no longer
>
On Mon, Sep 26, 2011 at 5:41 AM, crocket wrote:
> MySQL already has unsigned INT type, and it has double the range of
> signed INT type.
> It's not just the bigger range that UINT type brings.
> If unsigned INT type exists, I wouldn't have to execute "create domain
> UINT" in every database.
>
> I
On 26 September 2011 04:46, Robert Haas wrote:
> I don't want to take time to review this in detail right now, because
> I don't think it would be fair to put this ahead of things that were
> submitted for the current CommitFest, but I'm impressed.
Thank you.
Now that I think about it, the if st
2011/9/26 Robert Haas :
> On Mon, Sep 26, 2011 at 6:28 AM, Kohei KaiGai wrote:
>> 2011/9/26 Robert Haas :
>>> On Sun, Sep 25, 2011 at 10:38 PM, Noah Misch wrote:
On Sun, Sep 25, 2011 at 11:22:03AM -0500, Kevin Grittner wrote:
> Robert Haas 09/25/11 10:58 AM >>>
>
> > I'm not sur
Hi,
I'm in the middle of catching-up with pgsql-general and I see several
confused users about how to upgrade directly from 8.4. As Tom said, we
could easily provide upgrade scripts to handle the move, we just
didn't, so there's some more manual work to do.
I'm wondering how much work that reall
On Mon, Sep 26, 2011 at 6:28 AM, Kohei KaiGai wrote:
> 2011/9/26 Robert Haas :
>> On Sun, Sep 25, 2011 at 10:38 PM, Noah Misch wrote:
>>> On Sun, Sep 25, 2011 at 11:22:03AM -0500, Kevin Grittner wrote:
Robert Haas 09/25/11 10:58 AM >>>
> I'm not sure we've been 100% consistent abo
Hi Greg,
(2011/08/28 18:54), Greg Smith wrote:
> Updated patch cleans up two diff mistakes made when backing out the
> progress report feature. The tip-off I screwed up should have been the
> absurdly high write rate shown. The usleep was accidentally deleted, so
> it was running without cost l
Dimitri Fontaine writes:
> The patches are not in git am format nor in patch format, so I could
> only read them, I didn't install them nor compiled the code, didn't run
> the regression tests.
I've marked the patch as Waiting on Author and referred to my previous
message. Thanks,
--
Dimitri F
On Mon, Sep 26, 2011 at 10:37:50AM +0200, Magnus Hagander wrote:
> On Sun, Sep 25, 2011 at 15:06, Dean Rasheed wrote:
> > On 24 September 2011 11:59, Magnus Hagander wrote:
> >> TABLE tab completion in psql only completes to tables, not views. but
> >> the TABLE command works fine for both tables
On Fri, Sep 23, 2011 at 12:44 AM, Magnus Hagander wrote:
> Would it make sense for pg_start_backup() to have the ability to wait
> for the next restartpoint in a case like this, if we know that FPW has
> been set? Instead of failing? Or maybe that's just overcomplicating
> things when trying to be
On 09/26/2011 07:12 AM, Magnus Hagander wrote:
On Mon, Sep 26, 2011 at 06:58, Itagaki Takahiro
wrote:
Hi,
I'd like to support UTF-8 text or csv files that has BOM (byte order mark)
in COPY FROM command. BOM will be automatically detected and ignored
if the file encoding is UTF-8. WIP patch
On Mon, Sep 26, 2011 at 13:36, Itagaki Takahiro
wrote:
> On Mon, Sep 26, 2011 at 20:12, Magnus Hagander wrote:
>> I like it in general. But if we're looking at the BOM, shouldn't we
>> also look and *reject* the file if it's a BOM for a non-UTF8 file? Say
>> if the BOM claims it's UTF16?
>
> -1 b
On Mon, Sep 26, 2011 at 20:12, Magnus Hagander wrote:
> I like it in general. But if we're looking at the BOM, shouldn't we
> also look and *reject* the file if it's a BOM for a non-UTF8 file? Say
> if the BOM claims it's UTF16?
-1 because we're depending on manual configuration for now.
It would
On Mon, Sep 26, 2011 at 06:58, Itagaki Takahiro
wrote:
> Hi,
>
> I'd like to support UTF-8 text or csv files that has BOM (byte order mark)
> in COPY FROM command. BOM will be automatically detected and ignored
> if the file encoding is UTF-8. WIP patch attached.
>
> I'm thinking about only COPY F
On mån, 2011-09-26 at 19:41 +0900, crocket wrote:
> MySQL already has unsigned INT type, and it has double the range of
> signed INT type.
> It's not just the bigger range that UINT type brings.
> If unsigned INT type exists, I wouldn't have to execute "create domain
> UINT" in every database.
>
>
On fre, 2011-09-23 at 20:35 +0300, Marcin Mańk wrote:
> One idea:
> col like 'foo%' could be translated to col >= 'foo' and col <= foo || 'zzz' ,
> where 'z' is the largest possible character. This should be good enough for
> calculating stats.
>
> How to find such a character, i do not know.
MySQL already has unsigned INT type, and it has double the range of
signed INT type.
It's not just the bigger range that UINT type brings.
If unsigned INT type exists, I wouldn't have to execute "create domain
UINT" in every database.
If "INT unsigned" and "SERIAL unsigned" exist, PostgreSQL would
On sön, 2011-09-25 at 12:58 -0400, Tom Lane wrote:
> And it's not like we don't break configuration file
> contents in most releases anyway, so I really fail to see why this one
> has suddenly become sacrosanct.
Well, there is a slight difference. Changes in postgresql.conf
parameter names and s
On lör, 2011-09-24 at 14:02 +0100, Simon Riggs wrote:
> The semantics are clear: recovery.conf is read first, then
> postgresql.conf. It's easy to implement (1 line of code) and easy to
> understand.
What's clear about that? My intuition would have been that
recovery.conf is read second.
--
Se
On lör, 2011-09-24 at 13:04 -0400, Tom Lane wrote:
> > What if we modified pg_ctl to allow passing configuration parameters
> > through to postmaster,
>
> You mean like pg_ctl -o?
Note that pg_ctl -o saves the parameters it uses and reapplies them
after a restart. So this is not really the way t
2011/9/26 Robert Haas :
> On Sun, Sep 25, 2011 at 10:38 PM, Noah Misch wrote:
>> On Sun, Sep 25, 2011 at 11:22:03AM -0500, Kevin Grittner wrote:
>>> Robert Haas 09/25/11 10:58 AM >>>
>>>
>>> > I'm not sure we've been 100% consistent about that, since we
>>> > previously made CREATE OR REPLACE LAN
On sön, 2011-09-25 at 23:49 -0400, Robert Haas wrote:
> In fact, I've been wondering if we ought to go a step further and not
> recurse into the sepgsql directory for *any* of the targets. Then we
> could get rid of the associated configure option, which no longer
> serves any other purpose, and j
2011/9/26 Robert Haas :
> On Sun, Sep 25, 2011 at 3:25 PM, Kohei KaiGai wrote:
>>> I'm a bit nervous about storing security_barrier in the RTE. What
>>> happens to stored rules if the security_barrier option gets change
>>> later?
>>>
>> The rte->security_barrier is evaluated when a query referen
Hi,
Currently, if a reference to an invalid page is found during recovery,
its information
is saved in hash table "invalid_page_tab". Then, if such a reference
is resolved,
its information is removed from the hash table. If there is unresolved
reference to
an invalid page in the hash table at the
1 - 100 of 105 matches
Mail list logo
