I have done my yearly TODO list cleanup, and I did more extensive item
removal this time. There were a number of entries I could not figure out
so if people want to review what is left and remove items that are
undesired or done, please do that. Thanks.
On Mon, Dec 21, 2015 at 07:54:43AM -0500, Robert Haas wrote:
> On Thu, Jul 9, 2015 at 4:49 PM, Jeff Janes wrote:
> > Is there anything in the below section which has been been implemented or
> > rendered irrelevant by BRIN indexes?
> >
> >
On Mon, Dec 21, 2015 at 8:06 AM, Simon Riggs wrote:
> On 21 December 2015 at 12:54, Robert Haas wrote:
>>
>> On Thu, Jul 9, 2015 at 4:49 PM, Jeff Janes wrote:
>> > Is there anything in the below section which has been been
On 21 December 2015 at 14:38, Robert Haas wrote:
> On Mon, Dec 21, 2015 at 8:06 AM, Simon Riggs
> wrote:
> > On 21 December 2015 at 12:54, Robert Haas wrote:
> >>
> >> On Thu, Jul 9, 2015 at 4:49 PM, Jeff Janes
On 21 December 2015 at 12:54, Robert Haas wrote:
> On Thu, Jul 9, 2015 at 4:49 PM, Jeff Janes wrote:
> > Is there anything in the below section which has been been implemented or
> > rendered irrelevant by BRIN indexes?
> >
> >
On Thu, Jul 9, 2015 at 4:49 PM, Jeff Janes wrote:
> Is there anything in the below section which has been been implemented or
> rendered irrelevant by BRIN indexes?
>
> https://wiki.postgresql.org/wiki/Todo#Indexes
>
> "Consider smaller indexes that record a range of values
On 16 October 2015 18:20:59 EEST, Bruce Momjian wrote:
>I think on-disk bitmap indexes would only beat GIN indexes in a
>read-only database on low-cardinality columns. For example, if you had
>a purchase_log table and wanted to know all the "blue" and "large"
>items
>sold at
On Fri, Oct 16, 2015 at 8:34 AM, Bruce Momjian wrote:
> I have spend the past few days updating our TODO list, removing
> completed and now-unnecessary items:
>
> https://wiki.postgresql.org/wiki/Todo
>
>
Thanks. It can help encourage many new entrants to community.
On Fri, Oct 16, 2015 at 02:50:04PM +0530, Amit Kapila wrote:
> On Fri, Oct 16, 2015 at 8:34 AM, Bruce Momjian wrote:
>
> I have spend the past few days updating our TODO list, removing
> completed and now-unnecessary items:
>
>
On Fri, Oct 16, 2015 at 12:00:11PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > I have spend the past few days updating our TODO list, removing
> > completed and now-unnecessary items:
> >
> > https://wiki.postgresql.org/wiki/Todo
>
> Thanks. We have "TodoDone" pages for items
On Fri, Oct 16, 2015 at 12:02:03PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > Are you suggesting I remove those links? It is kind of odd to have
> > links to patches for features we don't want, or just keep it?
>
> No, quite the contrary -- I think the links allow some other
Bruce Momjian wrote:
> I have spend the past few days updating our TODO list, removing
> completed and now-unnecessary items:
>
> https://wiki.postgresql.org/wiki/Todo
Thanks. We have "TodoDone" pages for items that were done in specific
releases, but only for 8.4, 9.0 and 9.1. I guess
Bruce Momjian wrote:
> Are you suggesting I remove those links? It is kind of odd to have
> links to patches for features we don't want, or just keep it?
No, quite the contrary -- I think the links allow some other person
research the issue including the history of patches and discussion, and
Bruce Momjian wrote:
> Probably the most controvertial change was to move on-disk bitmap
> indexes to the "not wanted" section, though I kept the links in case we
> change our minds. I just can't see how they would be a win with GIN and
> in-memory bitmaps.
Yeah, I recall we discussed bitmap
On Fri, Oct 16, 2015 at 11:43:10AM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > Probably the most controvertial change was to move on-disk bitmap
> > indexes to the "not wanted" section, though I kept the links in case we
> > change our minds. I just can't see how they would be a
I have spend the past few days updating our TODO list, removing
completed and now-unnecessary items:
https://wiki.postgresql.org/wiki/Todo
I encourage others to also update the list to make it more accurate.
Thanks.
--
Bruce Momjian http://momjian.us
I have removed the completed 9.2 TODO items so people can start updating
the TODO list completed items for 9.3.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Excerpts from Bruce Momjian's message of lun jul 11 18:58:35 -0400 2011:
I have updated the TODO wiki to remove the 9.1-completed items:
http://wiki.postgresql.org/wiki/Todo
This will allow us to now mark 9.2-completed items.
I have created TodoDone91 from the items marked TodoDone on
Alvaro Herrera wrote:
Excerpts from Bruce Momjian's message of lun jul 11 18:58:35 -0400 2011:
I have updated the TODO wiki to remove the 9.1-completed items:
http://wiki.postgresql.org/wiki/Todo
This will allow us to now mark 9.2-completed items.
I have created TodoDone91 from
I have updated the TODO wiki to remove the 9.1-completed items:
http://wiki.postgresql.org/wiki/Todo
This will allow us to now mark 9.2-completed items.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+
Pavel Stehule wrote:
Hello
I use a LISTEN/NOTIFY. Now I have to check, if second application that
creates channels is active. It should be simple with system view of
active channels.
I think you want pg_listening_channels().
--
Bruce Momjian br...@momjian.ushttp://momjian.us
Hello
I use a LISTEN/NOTIFY. Now I have to check, if second application that
creates channels is active. It should be simple with system view of
active channels.
Regards
Pavel Stehule
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Robert Haas wrote:
On Thu, Jan 20, 2011 at 4:40 PM, Simone Aiken
sai...@quietlycompetent.com wrote:
After playing with this in benchmarks and researching the weird results I
got I'm going to advise dropping the todo for now unless something happens
to change how postgres handles
On Wed, Jan 19, 2011 at 4:27 PM, Simone Aiken sai...@ulfheim.net wrote:
In my experience size increases related to documentation are almost always
worth it. So I'm prejudiced right out of the gate. I was wondering if
every pg_ table gets copied out to every database .. if there is already a
After playing with this in benchmarks and researching the weird results I
got I'm going to advise dropping the todo for now unless something happens
to change how postgres handles clustering. You guys probably already
grokked this so I am just recording it for the list archives.
The primary
On Thu, Jan 20, 2011 at 4:40 PM, Simone Aiken
sai...@quietlycompetent.com wrote:
After playing with this in benchmarks and researching the weird results I
got I'm going to advise dropping the todo for now unless something happens
to change how postgres handles clustering.
I agree, let's remove
Robert
I think the first
thing to do would be to try to come up with a reproducible test case
where clustering the tables improves performance.
On that note, is there any standard way you guys do benchmarks?
Bruce
I think CLUSTER is a win when you are looking up multiple rows in
On Tue, Jan 18, 2011 at 6:49 PM, Simone Aiken
sai...@quietlycompetent.com wrote:
Pages like this one have column comments for the system tables:
http://www.psql.it/manuale/8.3/catalog-pg-attribute.html
Oh, I see. I don't think we want to go there. We'd need some kind of
system for keeping
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 18, 2011 at 6:49 PM, Simone Aiken
sai...@quietlycompetent.com wrote:
Pages like this one have column comments for the system tables:
http://www.psql.it/manuale/8.3/catalog-pg-attribute.html
Oh, I see. I don't think we want to go there.
Excerpts from Robert Haas's message of mié ene 19 15:25:00 -0300 2011:
Oh, I see. I don't think we want to go there. We'd need some kind of
system for keeping the two places in sync.
Maybe autogenerate both the .sgml and the postgres.description files
from a single source.
And there'd be
On Wed, Jan 19, 2011 at 2:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 18, 2011 at 6:49 PM, Simone Aiken
sai...@quietlycompetent.com wrote:
Pages like this one have column comments for the system tables:
Robert Haas robertmh...@gmail.com writes:
On Wed, Jan 19, 2011 at 2:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Which brings up another point though. I have a personal TODO item to
make the comments for operator support functions more consistent:
On Wed, Jan 19, 2011 at 3:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Jan 19, 2011 at 2:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Which brings up another point though. I have a personal TODO item to
make the comments for operator support
Robert Haas robertmh...@gmail.com writes:
On Wed, Jan 19, 2011 at 3:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, on my machine pg_description is about 210K (per database) as of
HEAD. 90% of its contents are pg_proc entries, though I have no good
fix on how much of that is for
I seem to recall some muttering about teaching genbki to extract such
comments from the SGML sources or perhaps the C header files. I tend to
agree though that it would be a lot more work than it's worth. And as you
say, pg_description entries aren't free.
I know I can't do all of the work,
Excerpts from Simone Aiken's message of dom ene 16 02:11:26 -0300 2011:
Hello Postgres Hackers,
In reference to this todo item about clustering system table indexes,
( http://archives.postgresql.org/pgsql-hackers/2004-05/msg00989.php )
I have been studying the system tables
Excerpts from Simone Aiken's message of dom ene 16 02:11:26 -0300 2011:
Hello Postgres Hackers,
BTW whatever you do, don't start a new thread by replying to an existing
message and just changing the subject line. It will mess up the
threading for some readers, and some might not even see your
On Tue, Jan 18, 2011 at 8:35 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Simone Aiken's message of dom ene 16 02:11:26 -0300 2011:
Hello Postgres Hackers,
In reference to this todo item about clustering system table indexes,
(
On Jan 18, 2011, at 6:35 AM, Alvaro Herrera wrote:
Wow, this is really old stuff. I don't know if this is really of any
benefit, given that these catalogs are loaded into syscaches anyway.
The benefit is educational primarily. I was looking for a todo list item
that would expose me to
On Tue, Jan 18, 2011 at 8:35 AM, Alvaro Herrera alvhe...@commandprompt.com
wrote:
Excerpts from Simone Aiken's message of dom ene 16 02:11:26 -0300 2011:
Hello Postgres Hackers,
In reference to this todo item about clustering system table indexes,
(
Robert Haas wrote:
On Tue, Jan 18, 2011 at 8:35 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Simone Aiken's message of dom ene 16 02:11:26 -0300 2011:
Hello Postgres Hackers,
In reference to this todo item about clustering system table indexes,
(
On Tue, Jan 18, 2011 at 12:16 PM, Simone Aiken sai...@ulfheim.net wrote:
When I'm learning a new system I like to first learn how to use it,
second learn its data model, third start seriously looking at the code.
So that Todo is ideal for my learning method.
Sure - my point is just that we
-Original Message-
From: Robert Haas [mailto:robertmh...@gmail.com]
Sent: Tuesday, January 18, 2011 2:53 PM
To: Simone Aiken
Cc: Alvaro Herrera; pgsql-hackers
Subject: Re: [HACKERS] ToDo List Item - System Table Index Clustering
Sure - my point is just that we usually have
Followup on System Table Index clustering ToDo -
It looks like to implement this I need to do the following:
1 - Add statements to indexing.h to cluster the selected indexes.
A do-nothing define at the top to suppress warnings and then
lines below for perl to
Hello Postgres Hackers,
In reference to this todo item about clustering system table indexes,
( http://archives.postgresql.org/pgsql-hackers/2004-05/msg00989.php )
I have been studying the system tables to see which would benefit from
clustering. I have some index suggestions and
2011/1/16 Simone Aiken sai...@ulfheim.net:
is there a way to make queries on the system tables show me what
is actually there when I'm poking around? So for example:
Select * from pg_type limit 1;
tells me that the typoutput is 'boolout'. An english
Nicolas Barbier nicolas.barb...@gmail.com writes:
2011/1/16 Simone Aiken sai...@ulfheim.net:
... So even though the documentation says that column
maps to pg_proc.oid I can't then write:
Select * from pg_proc where oid = 'boolout';
Type type of typoutput is
Select typoutput::oid from pg_type limit 1;
Also, you *can* go back the other way. It's very common to write
Select * from pg_proc where oid = 'boolout'::regproc
rather than looking up the OID first.
see Object Identifier Types in the manual.
Many thanks to you
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
In reading through the TODO list, I noticed a few things that I think
are done, may be done, or may be partially done. See below.
Thoughts? ...Robert
Add missing operators for geometric data types
- this is at least partly
Robert Haas wrote:
In reading through the TODO list, I noticed a few things that I think
are done, may be done, or may be partially done. See below.
Thoughts? ...Robert
Add missing operators for geometric data types
- this is at least partly done. not sure if it is entirely done.
Add
2010/3/27 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
In reading through the TODO list, I noticed a few things that I think
are done, may be done, or may be partially done. See below.
Thoughts? ...Robert
Implement full support for window framing clauses.
- Not
In reading through the TODO list, I noticed a few things that I think
are done, may be done, or may be partially done. See below.
Thoughts? ...Robert
Add missing operators for geometric data types
- this is at least partly done. not sure if it is entirely done.
Add OR REPLACE to CREATE
Robert Haas robertmh...@gmail.com writes:
In reading through the TODO list, I noticed a few things that I think
are done, may be done, or may be partially done. See below.
Thoughts? ...Robert
Add missing operators for geometric data types
- this is at least partly done. not sure if it is
On Fri, Mar 26, 2010 at 12:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
In reading through the TODO list, I noticed a few things that I think
are done, may be done, or may be partially done. See below.
Thoughts? ...Robert
Add missing operators for
Robert Haas robertmh...@gmail.com writes:
As far as I know, exclusion constraints would work with hash opclasses
also.
Yeah, they do.
Do you think there's an advantage to having something that is
hash-specific a la the btree-specific stuff we already have?
Sure: it'll be more efficient
David E. Wheeler wrote:
On Nov 19, 2008, at 9:12 AM, Josh Berkus wrote:
Folks,
Since it's too late to look at this for 8.4, can the following go on
the TODO list?
Referential Integrity
[] Allow creation of FKs targeting unique expression indexes on the
referenced table.
Allowing foreign keys to point to expression indexes seems to open a can
of worms and I am not sure there is enough demand to warrant it.
It does open a can of worms. I've often wanting something related,
which is the ability to make a foreign key references a PARTIAL index.
...Robert
--
Folks,
Since it's too late to look at this for 8.4, can the following go on the
TODO list?
Referential Integrity
[] Allow creation of FKs targeting unique expression indexes on the
referenced table. Syntax: REFERENCES reftable ( ( column expression ) )
Reason: current FK rules do not
On Nov 19, 2008, at 9:12 AM, Josh Berkus wrote:
Folks,
Since it's too late to look at this for 8.4, can the following go on
the TODO list?
Referential Integrity
[] Allow creation of FKs targeting unique expression indexes on the
referenced table. Syntax: REFERENCES reftable ( ( column
On Wed, Mar 12, 2008 at 10:27:06AM -0400, Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Magnus Hagander wrote:
It's not. And I personally don't think it would be a problem.
But I think it'll be a lot easier to sell to those who prefer
textfiles in cvs (hello
On Wed, Mar 12, 2008 at 11:03:13AM -0400, Bruce Momjian wrote:
Magnus Hagander wrote:
If you change the text file, I will see the CVS update and update the
HTML --- I will never lose a change because my CVS sees your changes.
That seems like a lot of extra work that should be
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Mar 12, 2008 at 11:03:13AM -0400, Bruce Momjian wrote:
We need it to do a few things:
Actually, the part of the current process that a wiki would fail to
reproduce is the emails that Bruce sends out about TODO changes.
Do we still want those,
On Wed, Mar 12, 2008 at 11:36:52AM -0400, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Mar 12, 2008 at 11:03:13AM -0400, Bruce Momjian wrote:
We need it to do a few things:
Actually, the part of the current process that a wiki would fail to
reproduce is the emails
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Actually, the part of the current process that a wiki would fail to
reproduce is the emails that Bruce sends out about TODO changes.
Do we still want those, and if so what would we do about it?
Magnus said you can subscribe to a changes
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Mar 12, 2008 at 11:03:13AM -0400, Bruce Momjian wrote:
We need it to do a few things:
Actually, the part of the current process that a wiki would fail to
reproduce is the emails that Bruce sends out about TODO changes.
Do
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Actually, the part of the current process that a wiki would fail to
reproduce is the emails that Bruce sends out about TODO changes.
Do we still want those, and if so what would we do about it?
Magnus said you can
I have removed the developer names from the bottom of the TODO list now
that URLs are used to reference discussions. The URLs are much more
accurate than putting names on items.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard
On Sun, 2006-12-17 at 10:56 +0100, Lukas Kahwe Smith wrote:
PostgreSQL 8.2 is out of the door. Unfortunately the plans for a more
detailed todo list have not come into reality yet to assist in for the
next 8.3 release. A couple people have replied to my earlier request to
form a little
Hi,
PostgreSQL 8.2 is out of the door. Unfortunately the plans for a more
detailed todo list have not come into reality yet to assist in for the
next 8.3 release. A couple people have replied to my earlier request to
form a little team willing to work on this, but unfortunately people
seem
Great updates! Let me comment on each one.
I made a pass over the TODO list to see what was out of date.
* Allow administrators to safely terminate individual sessions either
via an SQL function or SIGTERM
Currently SIGTERM of a backend can lead to lock table corruption.
Alvaro Herrera wrote:
On Thu, Aug 25, 2005 at 01:53:32PM -, Greg Sabino Mullane wrote:
Tom Lane asked:
o Improve psql's handling of multi-line queries
Uh, what's wrong with it? This item seems far too vague.
I think perhaps this means adding multi-line support to
Hannu Krosing wrote:
On K, 2005-08-24 at 21:58 -0400, Tom Lane wrote:
* %Allow TRUNCATE ... CASCADE/RESTRICT
Huh? What would that do?
Maybe this was meant truncating of tables with dependent foreign keys ?
AFAIR this was solved by allowing truncating several tables in one
command
Jim C. Nasby wrote:
I *think* this is reffering to how pg_dump makes some assumptions about
what things are system objects.
http://archives.postgresql.org/pgsql-committers/2005-08/msg00203.php
doesn't help a heck of a lot...
Can we add an interface to the TODO list that contains search
Andrew Dunstan wrote:
Tom Lane wrote:
Or perhaps use a different separator:
junk=# select * from xyz;
id |name| address | del_addr
++---+--
1 | Joe Bloggs
On Fri, Aug 26, 2005 at 03:44:18PM -0400, Bruce Momjian wrote:
Jim C. Nasby wrote:
I *think* this is reffering to how pg_dump makes some assumptions about
what things are system objects.
http://archives.postgresql.org/pgsql-committers/2005-08/msg00203.php
doesn't help a heck of a
On Aug 25, 2005, at 10:58 AM, Tom Lane wrote:
* %Remove CREATE CONSTRAINT TRIGGER
This was used in older releases to dump referential integrity
constraints.
Do we really want to remove it, and thereby guarantee we can't load
dumps from those old releases?
Also, I believe CONSTRAINT
On K, 2005-08-24 at 21:58 -0400, Tom Lane wrote:
* %Allow TRUNCATE ... CASCADE/RESTRICT
Huh? What would that do?
Maybe this was meant truncating of tables with dependent foreign keys ?
AFAIR this was solved by allowing truncating several tables in one
command even if they have FK
On Wed, 2005-08-24 at 21:58, Tom Lane wrote:
o Add pg_dumpall custom format dumps.
This is probably best done by combining pg_dump and pg_dumpall
into a single binary.
This is probably obsoleted by events, too. Now that we can dump blobs
in text mode, I see no reason
On Thu, 2005-08-25 at 15:50 +0900, Michael Glaesemann wrote:
* %Remove CREATE CONSTRAINT TRIGGER
Do we really want to remove it,
Also, I believe CONSTRAINT TRIGGERS are the only way to provide
transaction level (rather than statement level) referential
integrity.
Don't deferrable
On Thu, Aug 25, 2005 at 01:53:32PM -, Greg Sabino Mullane wrote:
Tom Lane asked:
o Improve psql's handling of multi-line queries
Uh, what's wrong with it? This item seems far too vague.
I think perhaps this means adding multi-line support to
the tab-completion? Only thing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane asked:
o Improve psql's handling of multi-line queries
Uh, what's wrong with it? This item seems far too vague.
I think perhaps this means adding multi-line support to
the tab-completion? Only thing I can think of, cause other
Oliver Elphick olly@lfix.co.uk writes:
It would be better to show the columns aligned (perhaps without showing
separators for other columns so as not to give the impression that the
other columns contain null or empty strings):
junk=# select * from xyz;
id |name|
Tom Lane wrote:
Or perhaps use a different separator:
junk=# select * from xyz;
id |name| address | del_addr
++---+--
1 | Joe Bloggs | 1 Hindhead Villas,
On Wed, Aug 24, 2005 at 09:58:04PM -0400, Tom Lane wrote:
* %Allow RULE recompilation
Eh? Perhaps you meant automatically regenerate cached plans when
needed, in which case it's redundant with the Dependency Checking
entries. Whatever it means, this doesn't seem a particularly simple
On Aug 25, 2005, at 11:29 PM, Matt Miller wrote:
On Thu, 2005-08-25 at 15:50 +0900, Michael Glaesemann wrote:
* %Remove CREATE CONSTRAINT TRIGGER
Do we really want to remove it,
Also, I believe CONSTRAINT TRIGGERS are the only way to provide
transaction level (rather than statement
I made a pass over the TODO list to see what was out of date.
* Allow administrators to safely terminate individual sessions either
via an SQL function or SIGTERM
Currently SIGTERM of a backend can lead to lock table corruption.
This comment may be out of date. Suggest
Lock
On Wed, 24 Aug 2005, Tom Lane wrote:
* Fetch heap pages matching index entries in sequential order
Rather than randomly accessing heap pages based on index entries, mark
heap pages needing access in a bitmap and do the lookups in sequential
order. Another method would be to sort heap
Kris Jurka [EMAIL PROTECTED] writes:
On Wed, 24 Aug 2005, Tom Lane wrote:
This is done (see bitmap index scans).
Will the optimizer ever choose this plan when dealing with only one index?
Certainly. It's actually likely to prefer a bitmap scan whenever the
query is estimated to fetch more
Bruce Momjian said:
Andrew Dunstan wrote:
2 things.
I submitted a patch for this 5 months ago, which is still waiting to
be merged (hope it hasn't bitrotted in the meantime):
. Allow log lines to include session-level information, like database
and user
If nobody is working on this I am
Andrew Dunstan wrote:
Bruce Momjian said:
Andrew Dunstan wrote:
2 things.
I submitted a patch for this 5 months ago, which is still waiting to
be merged (hope it hasn't bitrotted in the meantime):
. Allow log lines to include session-level information, like database
and user
Bruce Momjian wrote:
Andrew Dunstan wrote:
I thought we had thrashed this out back in August. Certainly the only
thing I recall seeing after I submitted the patch was some stylistic
criticism from Neil, which I addressed in a revised patch.
Anyway, it is in principle doable. That's partly
On Tue, 6 Jan 2004, Andrew Dunstan wrote:
Also, I would like to see some kind of session identifier that is more
unique than pid, which wraps around. Ideally we could have 10{pid},
then then the pid wraps around, 20{pid), or something like that.
This requires some thought. ISTM it wouldn't
Am Tuesday 06 January 2004 21:30 schrieb Jon Jensen:
On Tue, 6 Jan 2004, Andrew Dunstan wrote:
Also, I would like to see some kind of session identifier that is more
unique than pid, which wraps around. Ideally we could have 10{pid},
then then the pid wraps around, 20{pid), or something
Andrew Dunstan wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:
I thought we had thrashed this out back in August. Certainly the only
thing I recall seeing after I submitted the patch was some stylistic
criticism from Neil, which I addressed in a revised patch.
Anyway, it is
Jon Jensen wrote:
On Tue, 6 Jan 2004, Andrew Dunstan wrote:
Also, I would like to see some kind of session identifier that is more
unique than pid, which wraps around. Ideally we could have 10{pid},
then then the pid wraps around, 20{pid), or something like that.
This requires some
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:
I thought we had thrashed this out back in August. Certainly the only
thing I recall seeing after I submitted the patch was some stylistic
criticism from Neil, which I addressed in a revised
2 things.
I submitted a patch for this 5 months ago, which is still waiting to be
merged (hope it hasn't bitrotted in the meantime):
. Allow log lines to include session-level information, like database
and user
If nobody is working on this I am prepared to look at it:
. Allow logging of
Andrew Dunstan wrote:
2 things.
I submitted a patch for this 5 months ago, which is still waiting to be
merged (hope it hasn't bitrotted in the meantime):
. Allow log lines to include session-level information, like database
and user
If nobody is working on this I am prepared to
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane said:
On an implementation level, where are you thinking of enforcing this?
Without digging deeply at all I thought probably in the postmaster.
Nah, that's a nonstarter, because the postmaster has basically
-0600
From: Larry Rosenman [EMAIL PROTECTED]
To: Gavin Sherry [EMAIL PROTECTED],
Bruce Momjian [EMAIL PROTECTED]
Cc: Marko Zmak [EMAIL PROTECTED], [EMAIL PROTECTED],
Olivier PRENANT [EMAIL PROTECTED]
Subject: Re: [HACKERS] TODO list
--On Thursday, December 18, 2003 08:07:03 +1100
1 - 100 of 122 matches
Mail list logo