Robert,
I checked the v2 patch, but I could not find anything to comment
except for its patch format.
The -v2 patch still uses unified format, instead of context format.
I believe it is just a careless miss. Please fix it later, if necessary.
When I submit a patch, I makes it as follows :D
git
Bruce Momjian writes:
> Fujii Masao wrote:
>> On Thu, Jun 10, 2010 at 5:06 AM, Tom Lane wrote:
>>> My feeling about it is that if you want fast failover you should not
>>> have your failover target server configured as hot standby at all, let
>>> alone hot standby with a long max_standby_delay.
Fujii Masao wrote:
> On Thu, Jun 10, 2010 at 5:06 AM, Tom Lane wrote:
> > Josh Berkus writes:
> >> The fact that failover current does *not* terminate existing queries and
> >> transactions was regarded as a feature by the audience, rather than a
> >> bug, when I did demos of HS/SR. ?Of course, t
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > The attached patch shows the hint only during recovery.
> >
> > BTW, it would be easier and more consistent with the rest of the code to
> > look at InRecovery, instead of messing around with the function
> > signature. And t
Leonardo F wrote:
> I'm trying to find more docs that explain the "improvements" of
> bitmap indexes in other products... but most of what I've found
> talks about bitmapAND/OR which is something that is very
> cool, but that postgres already does even with btree indexes...
> or index creation
hello:
I have good news for you. Last week ,I have Order china New Apple
iPad Wi-Fi 32GB
this website: www.Toradeo.com
I have received the product!
I believe you will find what you want there and have an good experience
on shopping from them.
Regards!
--
Sent via pgsql-hackers mailing list (pgsq
On Thu, Jul 1, 2010 at 12:25 PM, Mike Fowler wrote:
> Quoting Mike Fowler :
>
>> Should the IS DOCUMENT predicate support this? At the moment you get
>> the following:
>>
>> template1=# SELECT
>>
>> 'Bidford-on-AvonCwmbranBristol'
>> IS
>> DOCUMENT;
>> ?column?
>> --
>> t
>> (1 row)
>>
>>
Le 01/07/2010 22:13, Robert Haas a écrit :
> On Thu, Jul 1, 2010 at 12:11 PM, Guillaume Lelarge
> wrote:
>> Le 01/07/2010 17:54, Robert Haas a écrit :
>>> On Thu, Jul 1, 2010 at 10:18 AM, Robert Haas wrote:
On Thu, Jul 1, 2010 at 5:30 AM, Guillaume Lelarge
wrote:
On Tue, Jun 2
Hello
I actualised plpgsql tutorial on address
http://www.pgsql.cz/index.php/PL/pgSQL_%28en%29#Design_of_triggers_in_PL.2FpgSQL
I hope so this document can be useful for people who start with plpgsql.
Sorry - my English is good for reading mailing list and coding in C
lang. Can some native engli
On Thu, Jul 1, 2010 at 12:11 PM, Guillaume Lelarge
wrote:
> Le 01/07/2010 17:54, Robert Haas a écrit :
>> On Thu, Jul 1, 2010 at 10:18 AM, Robert Haas wrote:
>>> On Thu, Jul 1, 2010 at 5:30 AM, Guillaume Lelarge
>>> wrote:
>>> On Tue, Jun 29, 2010 at 9:42 PM, Bruce Momjian wrote:
S
On Thu, Jul 1, 2010 at 12:19 PM, Michael Tharp
wrote:
> That said, as Martin mentions one can easily place the log directory outside
> of the data directory and set appropriate directory permissions.
If I can offer my $0.02, I recently solved such a problem on SuSE
Linux with apache logs. I used
On 07/01/2010 12:56 PM, Kevin Grittner wrote:
I just tried creating a symbolic link to the pg_log directory and
flagging the existing logs within it to 640. As a member of the
group I was able to list and view the contents of log files through
the symbolic link, even though I didn't have any aut
Martin Pihlak writes:
> Tom Lane wrote:
>> It doesn't appear to me that this helps unless you are willing to make
>> the containing director(ies) group-readable/executable as well, which is
>> something we've resisted doing.
> The log can be moved outside of data directory by setting "log_directo
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Martin Pihlak writes:
> > It'd be convenient if the log files would have group read access. Then we
> > could
> > make all the DBA or monitoring users members of the postgres group and
> > they'd
> > have direct access to the logs. However, as the "group
Tom Lane wrote:
> It doesn't appear to me that this helps unless you are willing to make
> the containing director(ies) group-readable/executable as well, which is
> something we've resisted doing.
>
The log can be moved outside of data directory by setting "log_directory"
to an absolute path. Th
Tom Lane wrote:
> Martin Pihlak writes:
>> It'd be convenient if the log files would have group read access.
>> Then we could make all the DBA or monitoring users members of the
>> postgres group and they'd have direct access to the logs.
>> However, as the "group read" is not likely a universall
Martin Pihlak writes:
> It'd be convenient if the log files would have group read access. Then we
> could
> make all the DBA or monitoring users members of the postgres group and they'd
> have direct access to the logs. However, as the "group read" is not likely a
> universally correct setting, t
> In
> principle a bitmap index scan should be significantly faster if the
> index can
> return the bitmap more or less "natively" rather than having
> to construct
> it.
The problem I'm seeing is that even on a 20M rows table, doing a
select * from t where c1=10 and c2=1
where c1 and c2 ar
Quoting Mike Fowler :
Should the IS DOCUMENT predicate support this? At the moment you get
the following:
template1=# SELECT
'Bidford-on-AvonCwmbranBristol'
IS
DOCUMENT;
?column?
--
t
(1 row)
template1=# SELECT
'Bidford-on-AvonCwmbranBristolIS
DOCUMENT;
ERROR: invalid XML content
Martin Pihlak wrote:
> Attached is a patch that adds a GUC "log_file_mode" which allows to specify
> the creation mode for the log files. Presently it lacks documentation, which
> I'll add if the idea is generally acceptable.
>
Now it really is attached.
regards,
Martin
*** a/src/backend/comman
With logging_collector enabled, all the postgres log files are created with
mode 0600. This makes life complicated if users other than "postgres" need
to be able to examine the log files as well. Common example of this is when the
database runs under "postgres" user and DBA-s have named accounts.
Le 01/07/2010 17:54, Robert Haas a écrit :
> On Thu, Jul 1, 2010 at 10:18 AM, Robert Haas wrote:
>> On Thu, Jul 1, 2010 at 5:30 AM, Guillaume Lelarge
>> wrote:
>> On Tue, Jun 29, 2010 at 9:42 PM, Bruce Momjian wrote:
>>> So this is not something we want fixed for 9.0, as indicated by Sim
Currently REASSIGN OWNED complains "unexpected classid" for operator
class and family.
For example,
create two users, user1 and user2
under user1:
create type oxetype as enum ('oxe1');
create operator class oxeops
default for type oxetype using btree as
function 1 array_lower(anyarray,integer);
On Thu, Jul 1, 2010 at 10:18 AM, Robert Haas wrote:
> On Thu, Jul 1, 2010 at 5:30 AM, Guillaume Lelarge
> wrote:
> On Tue, Jun 29, 2010 at 9:42 PM, Bruce Momjian wrote:
>> So this is not something we want fixed for 9.0, as indicated by Simon?
>> I don't see the patch on the commit-fe
On Thu, Jul 1, 2010 at 11:21 AM, Tom Lane wrote:
> In particular, I recall some discussions about developing a "streaming
> API" whereby an index AM could return a bitmap page-by-page or so,
> rather than having to construct the whole thing in-memory before
> anything could happen. This would be
Robert Haas writes:
> Hmm... no performance improvement? That's not encouraging.
> The index being smaller ought to by itself provide some performance
> improvement if, say, the smaller index can fit in cache and the larger
> one can't. With a 6-15x size difference, that's presumably not an
> i
On Thu, Jul 1, 2010 at 9:23 AM, Leonardo F wrote:
> Using as a starting point the old bitmap patch in:
>
> http://archives.postgresql.org/message-id/20081101000154.go27...@fune
>
>
> I re-applied and re-worked the patch to see what kind of improvements over
> btrees bitmaps actually provided.
>
>
Tom Lane wrote:
> Robert Haas writes:
> > While looking at Guillaume Lelarge's patch to add
> > CHECK_FOR_INTERRUPTS() within copydir(), I noticed that we seem to
> > have a $SUBJECT.
>
> > Trivial patch attached.
>
> The rmtree() declaration below it shouldn't be there either ...
When pg_upgra
Robert Haas writes:
> While looking at Guillaume Lelarge's patch to add
> CHECK_FOR_INTERRUPTS() within copydir(), I noticed that we seem to
> have a $SUBJECT.
> Trivial patch attached.
The rmtree() declaration below it shouldn't be there either ...
regards, tom lane
--
While looking at Guillaume Lelarge's patch to add
CHECK_FOR_INTERRUPTS() within copydir(), I noticed that we seem to
have a $SUBJECT.
Trivial patch attached.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
remove-stray-copydir.patch
Description: Binary
On Thu, Jul 1, 2010 at 5:30 AM, Guillaume Lelarge
wrote:
On Tue, Jun 29, 2010 at 9:42 PM, Bruce Momjian wrote:
> So this is not something we want fixed for 9.0, as indicated by Simon?
> I don't see the patch on the commit-fest page yet.
>
> Finally, I added it to the next commit fest
Leonardo F wrote:
> Using as a starting point the old bitmap patch in:
>
> http://archives.postgresql.org/message-id/20081101000154.go27...@fune
>
>
> I re-applied and re-worked the patch to see what kind of improvements over
> btrees bitmaps actually provided.
>
> Using a 20M rows table of 10/
Using as a starting point the old bitmap patch in:
http://archives.postgresql.org/message-id/20081101000154.go27...@fune
I re-applied and re-worked the patch to see what kind of improvements over
btrees bitmaps actually provided.
Using a 20M rows table of 10/100/1000 random values, I've found t
On Wed, Jun 30, 2010 at 12:37 PM, Robert Haas wrote:
> One thought that occurred to me is that if the master and standby were
> more tightly coupled, you could recover after a crash by making the
> one with the further-advanced WAL position the master, and the other
> one the standby. That would
Le 30/06/2010 06:53, Guillaume Lelarge a écrit :
> Le 30/06/2010 05:25, Tom Lane a écrit :
>> Robert Haas writes:
>>> On Tue, Jun 29, 2010 at 9:42 PM, Bruce Momjian wrote:
So this is not something we want fixed for 9.0, as indicated by Simon?
I don't see the patch on the commit-fest pag
35 matches
Mail list logo
