Re: [HACKERS] Block-level CRC checks

On Mon, 2009-11-30 at 20:02 -0500, Tom Lane wrote: > Simon Riggs writes: > > On Mon, 2009-11-30 at 16:49 -0500, Aidan Van Dyk wrote: > >> No, I believe the torn-page problem is exactly the thing that made the > >> checksum talks stall out last time... The torn page isn't currently a > >> problem

Re: [HACKERS] [PATCH] Add solaris path for docbook COLLATEINDEX

On mån, 2009-11-30 at 20:57 +0100, Zdenek Kotala wrote: > I'm not sgml//docbook guru. Do you think that Solaris location of > collateindex.pl is wrong? Does exist any recommendation for this? I > could log a bug, but I need some link with recommendation. It's a normal program, so you install it wh

Re: [HACKERS] enable-thread-safety defaults?

On mån, 2009-11-30 at 12:21 -0500, Bruce Momjian wrote: > ! for thread safety; use --disable-thread-safety to disable > threading.]) --disable-thread-safety does not disable threading, it disables thread safety. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make chan

[HACKERS] Recover deleted records using

Hi Everyone, Where/What source can I modify to retrieve deleted records using HeapTupleSatisfiesVisibility() I am using postgres 8.1.11 source The database has not yet been vacuumed. Regards, Allan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] SE-PgSQL patch review

David Fetter wrote: > On Mon, Nov 30, 2009 at 11:03:08PM -0500, Bruce Momjian wrote: >> KaiGai Kohei wrote: >>> In summary, it was similar approach with what I already proposed >>> in the CF#2, but rejected. >>> >>> During the first commit-fest of v8.5 development cycle, Stephen >>> Frost suggested

Re: [HACKERS] SE-PgSQL patch review

Bruce Momjian wrote: > KaiGai Kohei wrote: >> In summary, it was similar approach with what I already proposed in the CF#2, >> but rejected. >> >> During the first commit-fest of v8.5 development cycle, Stephen Frost >> suggested >> to rework the default PG's access controls to host other optional

Re: [HACKERS] SE-PgSQL patch review

On Mon, Nov 30, 2009 at 11:03:08PM -0500, Bruce Momjian wrote: > KaiGai Kohei wrote: > > In summary, it was similar approach with what I already proposed > > in the CF#2, but rejected. > > > > During the first commit-fest of v8.5 development cycle, Stephen > > Frost suggested to rework the default

Re: [HACKERS] CommitFest status/management

Tom Lane wrote: I'm going to look at the YAML format for EXPLAIN patch shortly. Do we have consensus yet that we want YAML? It seemed, well, yet another format without all that much advantage over what's there. I think you and I are the two main skeptics ;

Re: [HACKERS] CommitFest status/management

On Nov 30, 2009, at 8:08 PM, Tom Lane wrote: >> I'm going to look at the YAML format for EXPLAIN patch shortly. > > Do we have consensus yet that we want YAML? It seemed, well, > yet another format without all that much advantage over what's > there. Legibility++ David -- Sent via pgsql-hack

Re: [HACKERS] CommitFest status/management

Andrew Dunstan writes: > As I have observed before, I think we need some infrastructure to help > committers claim items, so we don't duplicate work. Robert acknowledged the need for a "claimed by committer" field in the fest application, but he hasn't got round to it yet. In the meantime I've

Re: [HACKERS] SE-PgSQL patch review

KaiGai Kohei wrote: > In summary, it was similar approach with what I already proposed in the CF#2, > but rejected. > > During the first commit-fest of v8.5 development cycle, Stephen Frost > suggested > to rework the default PG's access controls to host other optional security > features, not on

Re: [HACKERS] CommitFest status/management

Greg Smith wrote: If the need here is to speed up how fast things are fed to committers, we can certainly do that. The current process still favors having reviewers do as much as possible first, as shown by all the stuff sitting in the re-review queue. The work we're waiting on them for

Re: [HACKERS] CommitFest status/management

Bruce Momjian wrote: So, if someone writes a patch, and it is reviewed, and the patch author updates the patch and replies, it still should be reviewed again before being committed? That's generally how things were expected to happen--to at least double-check that the proposed fixes match what w

Re: [HACKERS] A thought about regex versus multibyte character sets

I wrote: > I therefore propose the following idea: if the database encoding is > UTF8, allow the regc_locale.c functions to call the > functions, assuming that wchar_t and pg_wchar_t share the same > representation. On platforms where wchar_t is only 16 bits, we can do > this up to U+ and be

Re: [HACKERS] ProcessUtility_hook

Tom Lane wrote: > Bruce Momjian writes: > > So, if someone writes a patch, and it is reviewed, and the patch author > > updates the patch and replies, it still should be reviewed again before > > being committed? > > Well, that's for the reviewer to say --- if the update satisfies his > concerns,

Re: [HACKERS] ProcessUtility_hook

OK, reverted and placed back in "Needs Review" status. --- Tom Lane wrote: > I wrote: > > It wasn't marked Ready For Committer, so presumably the reviewer > > wasn't done with it. I know I hadn't looked at it at all, becaus

Re: [HACKERS] ProcessUtility_hook

Bruce Momjian writes: > So, if someone writes a patch, and it is reviewed, and the patch author > updates the patch and replies, it still should be reviewed again before > being committed? Well, that's for the reviewer to say --- if the update satisfies his concerns, he should sign off on it, if

Re: [HACKERS] ProcessUtility_hook

I wrote: > It wasn't marked Ready For Committer, so presumably the reviewer > wasn't done with it. I know I hadn't looked at it at all, because > I was waiting for the commitfest review process to finish. ... and now that I have, I find at least four highly questionable things about it: 1. The p

Re: [HACKERS] ProcessUtility_hook

Tom Lane wrote: > Bruce Momjian writes: > > Tom Lane wrote: > >> Uh, we weren't even done reviewing this were we? > > > Uh, I am new to this commitfest wiki thing, but it did have a review by > > Euler Taveira de Oliveira: > > https://commitfest.postgresql.org/action/patch_view?id=196 > > and

Re: [HACKERS] ProcessUtility_hook

Bruce Momjian writes: > Tom Lane wrote: >> Uh, we weren't even done reviewing this were we? > Uh, I am new to this commitfest wiki thing, but it did have a review by > Euler Taveira de Oliveira: > https://commitfest.postgresql.org/action/patch_view?id=196 > and the author replied. Is there

Re: [HACKERS] ProcessUtility_hook

Tom Lane wrote: > Bruce Momjian writes: > > I have applied this patch, with only a minor wording improvement: > > Uh, we weren't even done reviewing this were we? Uh, I am new to this commitfest wiki thing, but it did have a review by Euler Taveira de Oliveira: https://commitfest.postgr

Re: [HACKERS] ProcessUtility_hook

Bruce Momjian writes: > I have applied this patch, with only a minor wording improvement: Uh, we weren't even done reviewing this were we? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http:

Re: [HACKERS] Deleted WAL files held open by backends in Linux

"Kevin Grittner" writes: > Tom Lane wrote: >> There has to be something causing those sessions to touch WAL, and >> the dirty-buffer scenario doesn't seem reliable enough. > This is seeming fairly likely to be the cause, though. It may be a > combination of the nightly VACUUM FREEZE ANALYZE w

Re: [HACKERS] ProcessUtility_hook

I have applied this patch, with only a minor wording improvement: Specify on to track DDL commands, which excludes SELECT, ^^ Thanks. --- Itagaki Takahiro wrote

Re: [HACKERS] Block-level CRC checks

Simon Riggs writes: > On Mon, 2009-11-30 at 16:49 -0500, Aidan Van Dyk wrote: >> No, I believe the torn-page problem is exactly the thing that made the >> checksum talks stall out last time... The torn page isn't currently a >> problem on only-hint-bit-dirty writes, because if you get >> half-old

Re: [HACKERS] Application name patch - v4

On Tuesday 01 December 2009 01:11:13 Tom Lane wrote: > Robert Haas writes: > > On Mon, Nov 30, 2009 at 4:54 PM, Dimitri Fontaine > > > > wrote: > >> Le 30 nov. 2009 à 22:38, Robert Haas a écrit : > >>> I still don't really understand why we wouldn't want RESET ALL to > >>> reset the application n

Re: [HACKERS] Application name patch - v4

Robert Haas writes: > On Mon, Nov 30, 2009 at 4:54 PM, Dimitri Fontaine > wrote: >> Le 30 nov. 2009 à 22:38, Robert Haas a écrit : >>> I still don't really understand why we wouldn't want RESET ALL to >>> reset the application name.  In what circumstances would you want the >>> application name t

Re: [HACKERS] Application name patch - v4

Robert Haas wrote: > On Mon, Nov 30, 2009 at 4:54 PM, Dimitri Fontaine > wrote: > > Le 30 nov. 2009 ? 22:38, Robert Haas a ?crit : > >> I still don't really understand why we wouldn't want RESET ALL to > >> reset the application name. ?In what circumstances would you want the > >> application name

Re: [HACKERS] Block-level CRC checks

On Mon, 2009-11-30 at 16:49 -0500, Aidan Van Dyk wrote: > * Simon Riggs [091130 16:28]: > > > > You've written that as if you are spotting a problem. It sounds to me > > that this is exactly the situation we would like to detect and this is a > > perfect way of doing that. > > > > What do you se

Re: [HACKERS] Application name patch - v4

On Mon, Nov 30, 2009 at 4:54 PM, Dimitri Fontaine wrote: > Le 30 nov. 2009 à 22:38, Robert Haas a écrit : >> I still don't really understand why we wouldn't want RESET ALL to >> reset the application name.  In what circumstances would you want the >> application name to stay the same across a RESE

Re: [HACKERS] Application name patch - v4

Le 30 nov. 2009 à 22:38, Robert Haas a écrit : > I still don't really understand why we wouldn't want RESET ALL to > reset the application name. In what circumstances would you want the > application name to stay the same across a RESET ALL? I can't see any use case, but SET/RESET is tied to SESS

Re: [HACKERS] Block-level CRC checks

* Simon Riggs [091130 16:28]: > > You've written that as if you are spotting a problem. It sounds to me > that this is exactly the situation we would like to detect and this is a > perfect way of doing that. > > What do you see is the purpose here apart from spotting corruptions? > > Do we thin

Re: [HACKERS] draft RFC: concept for partial, wal-based replication

On 30/11/2009 11:07 PM, Tom Lane wrote: Craig Ringer writes: Just a side note: in addition to its use for partial replication, this might have potential for performance-prioritizing databases or tablespaces. Being able to separate WAL logging so that different DBs, tablespaces, etc went to d

Re: [HACKERS] New VACUUM FULL

On Mon, 2009-11-30 at 15:10 -0500, Greg Smith wrote: > Itagaki Takahiro wrote: > > Done. (vacuum-full_20091130.patch) > > > Is this ready for a committer now? Not sure whether Jeff intends to > re-review here or not, given that the suggestions and their fixes were > pretty straightforward. I

Re: [HACKERS] OpenSSL key renegotiation with patched openssl

Magnus Hagander writes: > I haven't looked into the details but - is there a point for us to > remove the requests for renegotiation completely? The periodic renegotiations are a recommended security measure. Fixing one hole by introducing a different attack vector doesn't seem to me to be an imp

Re: [HACKERS] Application name patch - v4

On Mon, Nov 30, 2009 at 4:11 PM, Dimitri Fontaine wrote: > Le 30 nov. 2009 à 00:25, Tom Lane a écrit : >> The thing is that the libpq API treats application_name as a *property >> of the connection*. > > Oh. Yeah. > >> We could add a third keyword, say SET DEFAULT, that would have the >> behavior

Re: [HACKERS] Deleted WAL files held open by backends in Linux

Tom Lane wrote: > There has to be something causing those sessions to touch WAL, and > the dirty-buffer scenario doesn't seem reliable enough. This is seeming fairly likely to be the cause, though. It may be a combination of the nightly VACUUM FREEZE ANALYZE we typically do on every database

Re: [HACKERS] OpenSSL key renegotiation with patched openssl

2009/11/27 Tom Lane : > Stefan Kaltenbrunner writes: >> Tom Lane wrote: >>> The discussion I saw suggested that you need such a patch at both ends. > >> and likely requires a restart of both postgresql and slony afterwards... > > Actually, after looking through the available info about this: > htt

Re: [HACKERS] Block-level CRC checks

On Mon, 2009-11-30 at 22:27 +0200, Heikki Linnakangas wrote: > Simon Riggs wrote: > > Proposal > > > > * We reserve enough space on a disk block for a CRC check. When a dirty > > block is written to disk we calculate and annotate the CRC value, though > > this is *not* WAL logged. > > Imagine thi

Re: [HACKERS] Application name patch - v4

Le 30 nov. 2009 à 00:25, Tom Lane a écrit : > The thing is that the libpq API treats application_name as a *property > of the connection*. Oh. Yeah. > We could add a third keyword, say SET DEFAULT, that would have the > behavior of setting the value in a fashion that would persist across > resets

Re: [HACKERS] Block-level CRC checks

Simon Riggs wrote: > Proposal > > * We reserve enough space on a disk block for a CRC check. When a dirty > block is written to disk we calculate and annotate the CRC value, though > this is *not* WAL logged. Imagine this: 1. A hint bit is set. It is not WAL-logged, but the page is dirtied. 2. Th

Re: [HACKERS] [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION

Jeff Davis wrote: COPY target FROM FUNCTION foo() WITH RECORDS; In what format would the records be? What was your intended internal format for this form to process? -- Greg Smith2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQua

Re: [HACKERS] Initial refactoring of plperl.c [PATCH]

On Mon, Nov 30, 2009 at 12:50:41PM -0500, Andrew Dunstan wrote: > > Tim Bunce wrote: >> In summary, changing between multiplicity and non-multiplicity libperls >> after building postgresql isn't safe or supported. > > OK, good. Are you adding a check at load time that the library loaded is > what

Re: [HACKERS] New VACUUM FULL

Itagaki Takahiro wrote: Done. (vacuum-full_20091130.patch) Is this ready for a committer now? Not sure whether Jeff intends to re-review here or not, given that the suggestions and their fixes were pretty straightforward. It looks pretty solid at this point to me. -- Greg Smith2ndQua

Re: [HACKERS] cvs chapters in our docs

Chris Browne wrote: Wikis have a habit of getting out of date in ways that make them even more difficult to rectify, because the data is frequently structured in a way that doesn't make it particularly easy to pull it out and transform it into other forms. The standard way to backup a Mediawik

Re: [HACKERS] [PATCH] Add solaris path for docbook COLLATEINDEX

Peter Eisentraut píše v po 30. 11. 2009 v 21:27 +0200: > On mån, 2009-11-30 at 19:53 +0100, Zdenek Kotala wrote: > > Bruce Momjian píše v po 30. 11. 2009 v 12:32 -0500: > > > I am not happy looking in a directory _above_ a specified directory by > > > default: > > > > > >[$DOCBOOKS

Re: [HACKERS] Deleted WAL files held open by backends in Linux

Tom Lane wrote: > It's not about the size of a temp table, because writes to the > temp table itself aren't WAL-logged. However, the system catalog > entries for a temp table *are* WAL-logged. Definitely not issuing any CREATE TEMP statements of any kind, unless the JDBC driver is doing that

Re: [HACKERS] Deleted WAL files held open by backends in Linux

"Kevin Grittner" writes: > Tom Lane wrote: >> You sure it's not creating any temp tables? You didn't mention >> revoking TEMP privilege. > They have not been revoked, but I am sure the software publisher > doesn't explicitly create any, and I'd be very surprised if the > monitoring software d

Re: [HACKERS] Deleted WAL files held open by backends in Linux

Tom Lane wrote: > You sure it's not creating any temp tables? You didn't mention > revoking TEMP privilege. They have not been revoked, but I am sure the software publisher doesn't explicitly create any, and I'd be very surprised if the monitoring software did. The tables are small enough t

Re: [HACKERS] [PATCH] Add solaris path for docbook COLLATEINDEX

On mån, 2009-11-30 at 19:53 +0100, Zdenek Kotala wrote: > Bruce Momjian píše v po 30. 11. 2009 v 12:32 -0500: > > I am not happy looking in a directory _above_ a specified directory by > > default: > > > > [$DOCBOOKSTYLE/bin $DOCBOOKSTYLE/.. $PATH]) > > > > That seems possibly un

Re: [HACKERS] Writeable CTE patch

Tom Lane wrote: It would be altogether cleaner though if the CommandCounterIncrement responsibility were in the same place it is now, ie the caller of the executor. Which could be possible if we restructure the rewriter/planner output as a list of Queries instead of just one. I'm not currently

Re: [HACKERS] Writeable CTE patch

Marko Tiikkaja writes: > Tom Lane wrote: >> (BTW, I also think >> it would work better if you had the CommandCounterIncrement at the bottom >> of the loop, after the subquery execution not before it. But I'm not sure >> it's safe for ExecutePlan to be modifying the snapshot it's handed anyway.)

Re: [HACKERS] [PATCH] Add solaris path for docbook COLLATEINDEX

Bruce Momjian píše v po 30. 11. 2009 v 12:32 -0500: > Zdenek Kotala wrote: > > collateindex.pl is stored in /usr/share/sgml/docbook/. Attached fix > > modify docbook.m4 to find correct path. > > > > It would be nice also backported the fix back at least to 8.2. > > I am not happy looking in a dir

Re: [HACKERS] Deleted WAL files held open by backends in Linux

"Kevin Grittner" writes: > Tom Lane wrote: >> A backend would never open a WAL file unless it had to write a WAL >> record, so I'm having a hard time believing that these were >> totally read-only transactions. Can you give specifics? > You will note that the connections logged in as "viewer" (

Re: [HACKERS] Writeable CTE patch

Tom Lane wrote: 1. I thought we'd agreed at http://archives.postgresql.org/pgsql-hackers/2009-10/msg00558.php that the patch should support WITH on DML statements, eg with (some-query) insert into foo ... This might not take much more than grammar additions, but it's definitely lacking at

Re: [HACKERS] lexeme ordering in tsvector

Sushant Sinha writes: > Was this change in ordering deliberate? Yes. > Wouldn't length comparison be cheaper than memcmp? It's not just about "cheapest" anymore, it also has to support prefix operations. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-

[HACKERS] lexeme ordering in tsvector

It seems like the ordering of lexemes in tsvector has changed from 8.3 to 8.4. For example in 8.3.1, postgres=# select to_tsvector('english', 'quit everytime'); to_tsvector --- 'quit':1 'everytim':2 The lexemes are arranged by length and then by string comparison

Re: [HACKERS] Deleted WAL files held open by backends in Linux

Tom Lane wrote: >> It seemed strange that the only backends which were holding open >> deleted WAL files were ones where the connection was established >> with a login which has no write permissions. > > A backend would never open a WAL file unless it had to write a WAL > record, so I'm having a

Re: [HACKERS] Block-level CRC checks

On Mon, 2009-11-30 at 13:21 +, Simon Riggs wrote: > On Fri, 2008-10-17 at 12:26 -0300, Alvaro Herrera wrote: > > So this discussion died with no solution arising to the > > hint-bit-setting-invalidates-the-CRC problem. > > > > Apparently the only solution in sight is to WAL-log hint bits. Sim

[HACKERS] A thought about regex versus multibyte character sets

We've had many complaints about the fact that the regex functions are not bright about locale-dependent operations in multibyte character sets, especially case-insensitive matching. The reason for this, as was discussed in this thread http://archives.postgresql.org/pgsql-hackers/2008-12/msg00433.p

Re: [HACKERS] [PATCH] hstore documentation update

On Dec 1, 2009, at 3:01 AM, David E. Wheeler wrote: On Dec 1, 2009, at 2:56 AM, Bruce Momjian wrote: Applied. Thanks. Thanks, I'll remove it from the next CF list, then. Oh, you already marked it as committed. Thanks! David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgres

Re: [HACKERS] [PATCH] hstore documentation update

On Dec 1, 2009, at 2:56 AM, Bruce Momjian wrote: Applied. Thanks. Thanks, I'll remove it from the next CF list, then. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] draft RFC: concept for partial, wal-based replication

On Monday 30 November 2009 17:46:45 Hans-Jürgen Schönig wrote: > On Nov 30, 2009, at 10:32 AM, Stefan Kaltenbrunner wrote: > > the question is if filtering on the sending side is actually the > > "right thing" to do. > > It increases the overhead and the complexity on the master, > > especially if

Re: [HACKERS] [PATCH] hstore documentation update

Applied. Thanks. --- David E. Wheeler wrote: > From: David E. Wheeler > > As I threatened when I reviewed hstore in the last two commit > fests, I've finally seen may way to edit the documentation. This > is mostly word-s

Re: [HACKERS] Initial refactoring of plperl.c [PATCH]

Tim Bunce wrote: In summary, changing between multiplicity and non-multiplicity libperls after building postgresql isn't safe or supported. OK, good. Are you adding a check at load time that the library loaded is what we expect? cheers andrew -- Sent via pgsql-hackers mailing list (

Re: [HACKERS] is isolation level 'Serializable' in pg not same as 'serializable' in SQL-92?

2009/11/30 张茂森 : > pgsql-hackers is not the right place for user questions; try pgsql-general or pgsql-novice. The answer to your question is in the documentation. You can find it here: http://www.postgresql.org/docs/8.4/static/transaction-iso.html#MVCC-SERIALIZABILITY ...Robert -- Sent via

Re: [HACKERS] [PATCH] Add solaris path for docbook COLLATEINDEX

Zdenek Kotala wrote: > collateindex.pl is stored in /usr/share/sgml/docbook/. Attached fix > modify docbook.m4 to find correct path. > > It would be nice also backported the fix back at least to 8.2. I am not happy looking in a directory _above_ a specified directory by default:

Re: [HACKERS] enable-thread-safety defaults?

Magnus Hagander wrote: > 2009/11/24 Tom Lane : > > Magnus Hagander writes: > >> ISTM that it should be as simple as the attached patch. Seems to work > >> for me :-) But I'm no autoconf guru, so maybe I missed something? > > > > This patch sort of begs the question "what about > > enable-thread-s

[HACKERS] Cost of sort/order by not estimated by the query planner

Friendly greetings ! I use postgresql 8.3.6. here is a few info about the table i'm querying : - - select count(*) from _article : 17301610 - select count(*) from _article WHERE (_article.bitfield && getbit(0)) : 6729 Here are both requ

Re: [HACKERS] set the cost of an aggregate function

2009/11/30 Jaime Casanova : > Hi, > > why we can't do $subject? it could have any benefit on the planner? > seems like while we can set the cost of the state transition function, that cost is not propagated... -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarr

Re: [HACKERS] draft RFC: concept for partial, wal-based replication

Just a side note: in addition to its use for partial replication, this might have potential for performance-prioritizing databases or tablespaces. hello ... this is an absolutely non-starter. the WAL is designed to be "hyper ordered" and hyper critical. once you fuck up order you will

Re: [HACKERS] draft RFC: concept for partial, wal-based replication

On Nov 30, 2009, at 10:32 AM, Stefan Kaltenbrunner wrote: Andres Freund wrote: On Monday 30 November 2009 03:57:11 Itagaki Takahiro wrote: Boszormenyi Zoltan wrote: we tried to discuss on a lower level what should be needed for a partial replication based on streaming replication. We need t

Re: [HACKERS] OpenSSL key renegotiation with patched openssl

On Fri, Nov 27, 2009 at 4:58 PM, Tom Lane wrote: > Stefan Kaltenbrunner writes: >> Tom Lane wrote: >>> The discussion I saw suggested that you need such a patch at both ends. > >> and likely requires a restart of both postgresql and slony afterwards... > > Actually, after looking through the avai

Re: [HACKERS] Empty dictionary file when creating text search dictionary

=?ISO-8859-1?Q?Robert_Gravsj=F6?= writes: > Found this a couple of weeks back and just re-tested against head: > CREATE TEXT SEARCH DICTIONARY with an empty thesaurus file will crasch > the backend. Fixed, thanks for the report! regards, tom lane -- Sent via pgsql-hack

Re: [HACKERS] Initial refactoring of plperl.c [PATCH]

On Sat, Nov 28, 2009 at 09:35:10AM -0500, Andrew Dunstan wrote: > > Tim Bunce wrote: >> - Changed MULTIPLICITY check from runtime to compiletime. >> No loads the large Config module. > > ISTM the trouble with this is that it assumes that the library that we > compile with is the same as the li

[HACKERS] Empty dictionary file when creating text search dictionary

Found this a couple of weeks back and just re-tested against head: CREATE TEXT SEARCH DICTIONARY with an empty thesaurus file will crasch the backend. To reproduce: $ echo "" > $(pg_config --sharedir)/tsearch_data/thesaurus_empty.ths Then use this thesaurus to create a text search dictionary:

Re: [HACKERS] OpenSSL key renegotiation with patched openssl

Tom Lane wrote: > Dave Cramer writes: > >> Recently openssl has been patched to not renegotiate keys. >> http://www.links.org/?p=780 >> After a certain amount of data has gone through a postgresql connection >> the server will attempt to switch session keys. >> What is the workaround (if any )

Re: [HACKERS] Patch: Remove gcc dependency in definition of inline functions

On 11/30/09, Bruce Momjian wrote: > Peter Eisentraut wrote: > > On m?n, 2009-11-30 at 07:06 -0500, Bruce Momjian wrote: > > > I thought one problem was that inline is a suggestion that the compiler > > > can ignore, while macros have to be implemented as specified. > > > > Sure, but one could

Re: [HACKERS] draft RFC: concept for partial, wal-based replication

Craig Ringer writes: > Just a side note: in addition to its use for partial replication, this > might have potential for performance-prioritizing databases or tablespaces. > Being able to separate WAL logging so that different DBs, tablespaces, > etc went to different sets of WAL logs would allow

Re: [HACKERS] Patch: Remove gcc dependency in definition of inline functions

Peter Eisentraut wrote: > On m?n, 2009-11-30 at 07:06 -0500, Bruce Momjian wrote: > > I thought one problem was that inline is a suggestion that the compiler > > can ignore, while macros have to be implemented as specified. > > Sure, but one could argue that a compiler that doesn't support inline

Re: [HACKERS] Patch: Remove gcc dependency in definition of inline functions

On mån, 2009-11-30 at 07:06 -0500, Bruce Momjian wrote: > I thought one problem was that inline is a suggestion that the compiler > can ignore, while macros have to be implemented as specified. Sure, but one could argue that a compiler that doesn't support inline usefully is probably not the sort

Re: [HACKERS] Feature request: permissions change history for auditing

Thom Brown wrote: 2009/11/30 Glyn Astill > --- On Mon, 30/11/09, Thom Brown mailto:thombr...@gmail.com>> wrote: > As far as I am aware, there is no way to tell when a > user/role was granted permissions or had permissions > revoked, or who made t

Re: [HACKERS] Feature request: permissions change history for auditing

2009/11/30 Glyn Astill > --- On Mon, 30/11/09, Thom Brown wrote: > > > As far as I am aware, there is no way to tell when a > > user/role was granted permissions or had permissions > > revoked, or who made these changes. I'm wondering if > > it would be useful for security auditing to maintain

Re: [HACKERS] Block-level CRC checks

On Fri, 2008-10-17 at 12:26 -0300, Alvaro Herrera wrote: > So this discussion died with no solution arising to the > hint-bit-setting-invalidates-the-CRC problem. > > Apparently the only solution in sight is to WAL-log hint bits. Simon > opines it would be horrible from a performance standpoint t

Re: [HACKERS] Listen / Notify - what to do when the queue is full

Hi Jeff, the current patch suffers from what Heikki recently spotted: If one backend is putting notifications in the queue and meanwhile another backend executes LISTEN and commits, then this listening backend committed earlier and is supposed to receive the notifications of the notifying backend

Re: [HACKERS] Feature request: permissions change history for auditing

--- On Mon, 30/11/09, Thom Brown wrote: > As far as I am aware, there is no way to tell when a > user/role was granted permissions or had permissions > revoked, or who made these changes.  I'm wondering if > it would be useful for security auditing to maintain a > history of permissions changes o

[HACKERS] Feature request: permissions change history for auditing

Hi, As far as I am aware, there is no way to tell when a user/role was granted permissions or had permissions revoked, or who made these changes. I'm wondering if it would be useful for security auditing to maintain a history of permissions changes only accessible to superusers? Thanks Thom

Re: [HACKERS] Patch: Remove gcc dependency in definition of inline functions

Marko Kreen wrote: > On 11/29/09, Tom Lane wrote: > > Kurt Harriman writes: > > > (Does anybody still use a C compiler that doesn't support > > > inline functions?) > > +1 for modern C. > > > The question isn't so much that, it's whether the compiler supports > > inline functions with the sa

Re: [HACKERS] draft RFC: concept for partial, wal-based replication

On Nov 30, 2009, at 1:55 AM, Craig Ringer wrote: Boszormenyi Zoltan wrote: c. splitting wal into different replication sets Just a side note: in addition to its use for partial replication, this might have potential for performance-prioritizing databases or tablespaces. Being able to

Re: [HACKERS] Aggregate ORDER BY patch

) aorder-20091130.patch.gz Description: aggregate order by patch -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Hot Standby remaining issues

Simon Riggs wrote: > @@ -654,10 +656,13 @@ LockAcquire(const LOCKTAG *locktag, > elog(PANIC, "lock table corrupted"); > } > LWLockRelease(partitionLock); > - ereport(ERROR, > - (errcode(ERRCODE_OUT_OF_

Re: [HACKERS] draft RFC: concept for partial, wal-based replication

On Monday 30 November 2009 10:32:50 Stefan Kaltenbrunner wrote: > Andres Freund wrote: > > On Monday 30 November 2009 03:57:11 Itagaki Takahiro wrote: > >> Boszormenyi Zoltan wrote: > >>> we tried to discuss on a lower level what should be needed > >>> for a partial replication based on streaming

Re: [HACKERS] pg_read_file() and non-ascii input file

Itagaki Takahiro wrote: > pg_read_file() takes byte-offset and length as arguments, > but we don't check the result text with pg_verify_mbstr(). > Should pg_read_file() return bytea instead of text or adding > some codes to verify the input? Only superusers are allowed > to use the function, but

Re: [HACKERS] draft RFC: concept for partial, wal-based replication

Andres Freund wrote: On Monday 30 November 2009 03:57:11 Itagaki Takahiro wrote: Boszormenyi Zoltan wrote: we tried to discuss on a lower level what should be needed for a partial replication based on streaming replication. We need to discuss a "partial recovery" before the partial replicatio

[HACKERS] is isolation level 'Serializable' in pg not same as 'serializable' in SQL-92?

Re: [HACKERS] draft RFC: concept for partial, wal-based replication

Andres Freund wrote: > > We need to discuss a "partial recovery" before the partial replication. > If you do the filtering on the sending side you dont actually need partial > recover in the sense that you filter in the rmgr or similar. > > Or do I miss something? Sorry, I didn't explain well

Re: [HACKERS] draft RFC: concept for partial, wal-based replication

On Monday 30 November 2009 03:57:11 Itagaki Takahiro wrote: > Boszormenyi Zoltan wrote: > > we tried to discuss on a lower level what should be needed > > for a partial replication based on streaming replication. > We need to discuss a "partial recovery" before the partial replication. If you do t