On Fri, Apr 9, 2010 at 12:17 AM, Joachim Wieland wrote:
> One question that I do not yet see answered is, do we risk violating a
> patent even if we just link against a compression library, for example
> liblzf, without shipping the actual code?
>
Generally patents are infringed on when the proce
Hi,I'm using VC2005 to create PG C-language Fun in my contrib xml_index,
which import other library, and I have add the include and lib directory by
changing Mkvcbuild.pm and config.pl.
But after I executed the following commands:build DEBUGperl
install.pl "C:\Program F
Greg Smith wrote:
> An introduction to the current state of work in progress for adding
> improved partitioning features to PostgreSQL is documented at
> http://wiki.postgresql.org/wiki/Table_partitioning
Also, here is my latest patch for it:
http://repo.or.cz/w/pgsql-fdw.git/shortlog/refs/he
There are a couple of features that were considered but not committed
for 9.0 which require additional information about the properties of
various data types. At PGeast I had a chance to talk with Jeff Davis
about this briefly, and wanted to write up some of what we talked
about plus some further
I'd like to revive the discussion about offering another compression
algorithm than zlib to at least pg_dump. There has been a previous
discussion here:
http://archives.postgresql.org/pgsql-performance/2009-08/msg00053.php
and it ended without any real result. The results so far were:
- There ex
On Wed, Apr 07, 2010 at 01:07:21PM -0400, Robert Haas wrote:
> On Wed, Apr 7, 2010 at 10:46 AM, Tom Lane wrote:
> > Simon Riggs writes:
> >> When there is a specific reject rule, why does the server say
> >> FATAL: no pg_hba.conf entry
> >
> > It's intentional. We try to expose the minimum amou
An introduction to the current state of work in progress for adding
improved partitioning features to PostgreSQL is documented at
http://wiki.postgresql.org/wiki/Table_partitioning
If you can find a small, targeted piece of that overall plan that builds
on the work already done, and is in the
Andrew Dunstan wrote:
> Heikki Linnakangas wrote:
>> I'm going to see what happens if I remove all the #ifdef WIN32 blocks in
>> syslogger, and let it use pgpipe() and select() instead of the extra
>> thread.
>
> Sounds reasonable. Let's see how big the changes are on HEAD. I'm not
> sure it's wort
On Thu, Apr 8, 2010 at 20:35, Kevin Grittner
wrote:
> Greg Stark wrote:
>
>> But all it means is you get a random subset of the messages.
>> You're still missing most of the admin or sql or performance
>> related threads since they're mostly on -general anyways. Those
>> three categories cover pr
On Thu, Apr 8, 2010 at 7:58 PM, Ned Lilly wrote:
> +1 for the idea, and +1 for the Zork reference. Hello sailor.
fwiw it's older than Zork. It comes from Adventure
(http://en.wikipedia.org/wiki/Colossal_Cave_Adventure)
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
On Thu, Apr 8, 2010 at 4:23 PM, Necati Batur wrote:
> In order to make a system change a student need to be more informed
> and experienced for the issue.Nonetheless,this step of work is
> actually not the phase of determining all the details,I
> guess.Otherwise,I would just do a few weeks of codi
Hi,
So I'm still investigating data corruption issues. They have some
serious TOAST index corruption too; for example,
For example, notice how an indexscan returns invalid chunk_ids here:
select xmin,xmax,ctid,cmin, chunk_id, chunk_seq,length(chunk_data)
from pg_toast.pg_toast_18141
where chun
In order to make a system change a student need to be more informed
and experienced for the issue.Nonetheless,this step of work is
actually not the phase of determining all the details,I
guess.Otherwise,I would just do a few weeks of coding in summer to
complete the project and I would be the perso
On Thu, Apr 8, 2010 at 4:14 PM, Necati Batur wrote:
> The more specific of the items will just be the exact job I guess.
> However the detailed form will be hard to write now.
> Or should I explain the sql issues for each point?
Partitioning is a big project. It seems to me that if you want to
h
The more specific of the items will just be the exact job I guess.
However the detailed form will be hard to write now.
Or should I explain the sql issues for each point?
2010/4/8 Necati Batur :
> Benefits of Project
>
> Partitioning refers to splitting what is logically one large table
> into sm
On Thu, Apr 8, 2010 at 3:58 PM, Necati Batur wrote:
> *The trigger based operations can be done automatically
>
> *The stored procedures can help us to do some functionalities like
> check constraint problem
>
> *manual VACUUM or ANALYZE commands can be handled by using triggers
> DBMS SQL can hel
Benefits of Project
Partitioning refers to splitting what is logically one large table
into smaller physical pieces. Partitioning can provide several
benefits:
Query performance can be improved dramatically in certain situations,
particularly when most of the heavily accessed rows of the table ar
On Thu, Apr 8, 2010 at 3:22 PM, Oleg Bartunov wrote:
>> On general thought I've had is that it would be nice if the first
>> attempt to SELECT against a table with no statistics would trigger an
>> automatic ANALYZE by the backend on which the query was executed.
>> It's pretty common to populate
On Thu, 8 Apr 2010, Robert Haas wrote:
On Thu, Apr 8, 2010 at 2:53 PM, Alvaro Herrera
wrote:
Oleg Bartunov wrote:
our client complained about slow query, which involves temporary tables.
Analyzing them manually solved the problem. I don't remember
arguments against temporary tables support b
On Thu, Apr 8, 2010 at 3:09 PM, Joshua D. Drake wrote:
> On Thu, 2010-04-08 at 15:06 -0400, Jaime Casanova wrote:
>> >
>>
>> if we want specific topics, then remove -general, -novice, -admin
>
> This will likely never fly, see the archives.
>
well, -novice shuold be easy... actually it has no rea
Robert Haas wrote:
> On Thu, Apr 8, 2010 at 2:53 PM, Alvaro Herrera
>> Autovacuum can't process temp tables; they could reside in a
>> backend's private temp buffers (local memory, not shared).
>
> it would be nice if the first attempt to SELECT against a table
> with no statistics would trigge
On Thu, 2010-04-08 at 15:06 -0400, Jaime Casanova wrote:
> On Thu, Apr 8, 2010 at 2:31 PM, Robert Haas wrote:
> > On Thu, Apr 8, 2010 at 2:30 PM, Greg Stark wrote:
> >> On Thu, Apr 8, 2010 at 5:09 PM, Kevin Grittner
> >> wrote:
> >>> My set is different, but the principle is the same -- I can't
On Thu, Apr 8, 2010 at 2:53 PM, Alvaro Herrera
wrote:
> Oleg Bartunov wrote:
>
>> our client complained about slow query, which involves temporary tables.
>> Analyzing them manually solved the problem. I don't remember
>> arguments against temporary tables support by autovacuum. I'd
>> appreciate
On Thu, Apr 8, 2010 at 2:31 PM, Robert Haas wrote:
> On Thu, Apr 8, 2010 at 2:30 PM, Greg Stark wrote:
>> On Thu, Apr 8, 2010 at 5:09 PM, Kevin Grittner
>> wrote:
>>> My set is different, but the principle is the same -- I can't find
>>> the time to read all messages to all lists (really, I've t
+1 for the idea, and +1 for the Zork reference. Hello sailor.
On 4/8/2010 1:11 AM Greg Stark wrote:
I've often said in the past that we have too many mailing lists with
overlapping and vague charters. I submit the following thread as
evidence that this causes real problems.
http://archives.pos
Greg Stark wrote:
> But all it means is you get a random subset of the messages.
> You're still missing most of the admin or sql or performance
> related threads since they're mostly on -general anyways. Those
> three categories cover pretty much all of -general.
Well, one of these more specif
Oleg Bartunov wrote:
> our client complained about slow query, which involves temporary tables.
> Analyzing them manually solved the problem. I don't remember
> arguments against temporary tables support by autovacuum. I'd
> appreciate any
> pointers.
Autovacuum can't process temp tables; they co
Greg Stark wrote:
> But all it means is you get a random subset of the messages.
> You're still missing most of the admin or sql or performance
> related threads since they're mostly on -general anyways. Those
> three categories cover pretty much all of -general.
Perhaps -general should be eli
On Thu, Apr 8, 2010 at 2:30 PM, Greg Stark wrote:
> On Thu, Apr 8, 2010 at 5:09 PM, Kevin Grittner
> wrote:
>> My set is different, but the principle is the same -- I can't find
>> the time to read all messages to all lists (really, I've tried), so
>> I limit by list to try to target the issues o
On Thu, Apr 8, 2010 at 5:09 PM, Kevin Grittner
wrote:
> My set is different, but the principle is the same -- I can't find
> the time to read all messages to all lists (really, I've tried), so
> I limit by list to try to target the issues of most interest to me.
But all it means is you get a rand
Hi there,
our client complained about slow query, which involves temporary tables.
Analyzing them manually solved the problem. I don't remember arguments
against temporary tables support by autovacuum. I'd appreciate any
pointers.
Also, it's worth to add autovacuum_enable_temp_tables variable
Am Donnerstag, den 08.04.2010, 10:27 +0900 schrieb Takahiro Itagaki:
> Frank Jagusch wrote:
>
> > "de_DE_phoneb" is the name of an alternative sorting in german (only a
> > few languages have alternate sorting). You may find some information
> > when you search the MSDN for "de_DE_phoneb", i.e.
>
On 4/7/10 10:11 PM, Greg Stark wrote:
> Likewise I don't think we should have pgsql-performance or pgsql-sql
> or pgsql-novice -- any thread appropriate for any of these would be
> better served by sending it to pgsql-general anyways (with the
> exception of pgsql-performance which has a weird comb
On Thu, 2010-04-08 at 19:02 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > OK, that seems better. I'm happy with that instead.
> >
> > Have you tested this? Is it ready to commit?
>
> Only very briefly. I think the code is ready, but please review and test
> to see I didn't miss anythi
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Perhaps further clarifying the charters of the various lists would
> help, but folding too much into any one list is likely to reduce the
> number of readers or cause "spotty" attention. (When I was
> attempting to follow all the lists, I'd t
Robert Haas wrote:
> Dave Page wrote:
>> Greg Stark wrote:
>>> Because the poster chose to send it to pgsql-admin instead of
>>> pgsql-general (or pgsql-bugs) very few of the usual suspects had
>>> a chance to see it. 7 days later a question about a rather
>>> serious database corruption prob
Simon Riggs wrote:
> OK, that seems better. I'm happy with that instead.
>
> Have you tested this? Is it ready to commit?
Only very briefly. I think the code is ready, but please review and test
to see I didn't miss anything.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
On Thu, 2010-04-08 at 18:35 +0300, Heikki Linnakangas wrote:
>
> > So I have introduced the new mode ("snapshot mode") to enter hot
> standby
> > anyway. That avoids us having to screw around with the loop logic
> for
> > redo. I don't see any need to support the case of where we have no
> WAL
> >
Heikki Linnakangas wrote:
On Windows, syslogger uses two threads. The main thread loops and polls
if any SIGHUPs have been received or if the log file needs to be
rotated. Another thread, "pipe thread", does ReadFile() on the pipe that
other processes send their log messages to. ReadFile() bloc
Simon Riggs wrote:
> In StartupXlog() when we get to the point where we "Find the first
> record that logically follows the checkpoint", in the current code
> ReadRecord() loops forever, spitting out
> LOG: record with zero length at 0/C88
> ...
>
> That prevents us from going further down Sta
On Windows, syslogger uses two threads. The main thread loops and polls
if any SIGHUPs have been received or if the log file needs to be
rotated. Another thread, "pipe thread", does ReadFile() on the pipe that
other processes send their log messages to. ReadFile() blocks, and
whenever new data arri
On Thu, Apr 8, 2010 at 9:56 AM, Simon Riggs wrote:
> On Thu, 2010-04-08 at 09:40 -0400, Robert Haas wrote:
>> On Thu, Apr 8, 2010 at 8:00 AM, Simon Riggs wrote:
>> > On Thu, 2010-04-08 at 07:53 -0400, Robert Haas wrote:
>> >
>> >> > I do. I see no reason to do the latter, ever, so should not be a
On Thu, 2010-04-08 at 09:40 -0400, Robert Haas wrote:
> On Thu, Apr 8, 2010 at 8:00 AM, Simon Riggs wrote:
> > On Thu, 2010-04-08 at 07:53 -0400, Robert Haas wrote:
> >
> >> > I do. I see no reason to do the latter, ever, so should not be added to
> >> > any TODO.
> >>
> >> Well, stopping recovery
Hi all,
On Thu, 2010-04-08 at 07:45 -0400, Robert Haas wrote:
> >> 2010/4/8 Thom Brown :
> >> > So you could write:
> >> >
> >> > DELETE FROM massive_table WHERE id < 4000 LIMIT 1;
> I've certainly worked around the lack of this syntax more than once.
> And I bet it's not even that hard t
On 7 avr, 17:44, nicolas.barb...@gmail.com (Nicolas Barbier) wrote:
> 2010/4/7 Olivier Baheux :
>
> > i'm trying to find where are stored sequence definition
> > (increment,minvalue,maxvalue,start,cache) in system tables. Atm I
> > found everything exept sequence.
>
> It's in the sequence itself (w
On Thu, Apr 8, 2010 at 6:16 AM, Simon Riggs wrote:
> If standby_mode is enabled and there is no source of WAL, then we get a
> stream of messages saying
>
> LOG: record with zero length at 0/C88
> ...
>
> but most importantly we never get to the main recovery loop, so Hot
> Standby never gets
On Thu, Apr 8, 2010 at 8:00 AM, Simon Riggs wrote:
> On Thu, 2010-04-08 at 07:53 -0400, Robert Haas wrote:
>
>> > I do. I see no reason to do the latter, ever, so should not be added to
>> > any TODO.
>>
>> Well, stopping recovery earlier would mean fewer locks, which would
>> mean a better chance
On Thu, 2010-04-08 at 07:53 -0400, Robert Haas wrote:
> > I do. I see no reason to do the latter, ever, so should not be added to
> > any TODO.
>
> Well, stopping recovery earlier would mean fewer locks, which would
> mean a better chance for the read-only backends to finish their work
> and exit
On Thu, Apr 8, 2010 at 7:37 AM, Simon Riggs wrote:
> On Thu, 2010-04-08 at 06:58 -0400, Robert Haas wrote:
>
>> >> Thanks. Committed.
>> >
>> > Thanks. The following TODO item should be removed?
>> >
>> > "Redefine smart shutdown in standby mode to exist as soon as all
>> > read-only connections
On Thu, Apr 8, 2010 at 7:05 AM, Thom Brown wrote:
> On 8 April 2010 11:55, Ian Barwick wrote:
>>
>> 2010/4/8 Thom Brown :
>> > I couldn't find any discussion on this, but the request is quite
>> > straightforward. Implement a LIMIT on DELETE statements like SELECT
>> > statements.
>> >
>> > So y
On Thu, 2010-04-08 at 06:58 -0400, Robert Haas wrote:
> >> Thanks. Committed.
> >
> > Thanks. The following TODO item should be removed?
> >
> > "Redefine smart shutdown in standby mode to exist as soon as all
> > read-only connections are gone."
> > http://wiki.postgresql.org/wiki/Todo#Standby_s
On Thu, 2010-04-08 at 13:33 +0300, Heikki Linnakangas wrote:
> > If standby_mode is enabled and there is no source of WAL, then we get a
> > stream of messages saying
> >
> > LOG: record with zero length at 0/C88
> > ...
> >
> > but most importantly we never get to the main recovery loop, s
On 8 April 2010 11:55, Ian Barwick wrote:
> 2010/4/8 Thom Brown :
> > I couldn't find any discussion on this, but the request is quite
> > straightforward. Implement a LIMIT on DELETE statements like SELECT
> > statements.
> >
> > So you could write:
> >
> > DELETE FROM massive_table WHERE id <
On Thu, Apr 8, 2010 at 2:54 AM, Fujii Masao wrote:
> On Thu, Apr 8, 2010 at 10:41 AM, Robert Haas wrote:
>> On Wed, Apr 7, 2010 at 8:17 AM, Simon Riggs wrote:
>>> OK, that looks a lot less risky than I had understood from discussions.
>>> The main thing for me is it doesn't interfere with Startu
On Thu, Apr 8, 2010 at 3:46 AM, Dave Page wrote:
> On Thu, Apr 8, 2010 at 6:11 AM, Greg Stark wrote:
>> Because the poster chose to send it to pgsql-admin instead of
>> pgsql-general (or pgsql-bugs) very few of the usual suspects had a
>> chance to see it. 7 days later a question about a rather s
Simon Riggs wrote:
> On Tue, 2010-04-06 at 10:22 +0100, Simon Riggs wrote:
>
>> Initial patch. I will be testing over next day. No commit before at
>> least midday on Wed 7 Apr.
>
> Various previous discussions sidelined a very important point: what
> exactly does it mean to "start recovery from
On Tue, 2010-04-06 at 10:22 +0100, Simon Riggs wrote:
> Initial patch. I will be testing over next day. No commit before at
> least midday on Wed 7 Apr.
Various previous discussions sidelined a very important point: what
exactly does it mean to "start recovery from a shutdown checkpoint"?
If sta
Takahiro Itagaki writes:
> I found raw_expression_tree_walker() is oddly indented in 8.4 and HEAD.
> I expected pgindent would fix those clutter, but it could not.
> Should we cleanup it manually, or leave it as-is?
There is exactly zero point in a manual cleanup, because pgindent will
just do it
On Thu, Apr 8, 2010 at 9:46 AM, Dave Page wrote:
> On Thu, Apr 8, 2010 at 6:11 AM, Greg Stark wrote:
>> Because the poster chose to send it to pgsql-admin instead of
>> pgsql-general (or pgsql-bugs) very few of the usual suspects had a
>> chance to see it. 7 days later a question about a rather s
On Wed, Apr 7, 2010 at 1:45 AM, Magnus Hagander wrote:
> No, I don't mean that. I mean store it in one place, and copy/link it
> into where it's used. Look at for example how crypt.c and
> getaddrinfo.c are handled in libpq.
Thanks for the advice!
> Not sure how that will play with PGXS, though,
On Thu, Apr 8, 2010 at 8:46 AM, Dave Page wrote:
> I can't argue with that... but a counter argument is ...
Yes, I know. Clearly it's coffee time :-p
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
On Thu, 2010-04-08 at 16:41 +0900, Fujii Masao wrote:
> >> > Why? The tli of the last WAL record received is always the
> >> > recovery target tli currently.
> >>
> >> True.
> >
> > Only in streaming mode. If you use the current TLI as I have suggested
> > then it will be correct in more cases.
>
On Thu, Apr 8, 2010 at 6:11 AM, Greg Stark wrote:
> Because the poster chose to send it to pgsql-admin instead of
> pgsql-general (or pgsql-bugs) very few of the usual suspects had a
> chance to see it. 7 days later a question about a rather serious
> database corruption problem had no responses.
On Thu, Apr 8, 2010 at 4:06 PM, Simon Riggs wrote:
> On Thu, 2010-04-08 at 09:54 +0300, Heikki Linnakangas wrote:
>> Fujii Masao wrote:
>> > On Wed, Apr 7, 2010 at 7:23 PM, Heikki Linnakangas
>> > wrote:
>> >> This commit is a stop-gap solution until we figure out what exactly to
>> >> do about t
On Thu, 2010-04-08 at 09:54 +0300, Heikki Linnakangas wrote:
> Fujii Masao wrote:
> > On Wed, Apr 7, 2010 at 7:23 PM, Heikki Linnakangas
> > wrote:
> >> This commit is a stop-gap solution until we figure out what exactly to
> >> do about that. Masao-san wrote a patch that included the TLI in the
>
65 matches
Mail list logo
