Re: [HACKERS] Re: new patch of MERGE (merge_204) & a question about duplicated ctid

On Tue, Jan 04, 2011 at 09:27:10PM -0500, Greg Smith wrote: > David Fetter wrote: > >How about implementing an UPSERT command as "take the lock, do the > >merge?" That way, we'd have both the simplicity for the simpler cases > >and a way to relax consistency guarantees for those who would like to

Re: [HACKERS] We need to log aborted autovacuums

Josh Berkus wrote: I've been trying to diagnose in a production database why certain tables never get autovacuumed despite having a substantial % of updates. The obvious reason is locks blocking autovacuum from vacuuming the table ... Missed this dicussion when it popped up but have plenty

Re: [HACKERS] WIP: Range Types

On Tue, 2011-01-04 at 16:45 -0800, Josh Berkus wrote: > On 1/4/11 10:18 AM, Jeff Davis wrote: > > The main drawback here is that only a select group of people will be > > defining discrete range types at all, because it would require them to > > define a function first. Perhaps that's for the best,

Re: [HACKERS] SQL/MED - core functionality

On Sat, 1 Jan 2011 23:54:05 -0500 Robert Haas wrote: > On Mon, Dec 27, 2010 at 10:16 PM, Robert Haas wrote: > > On Sat, Dec 25, 2010 at 11:52 PM, Robert Haas wrote: > >> I'm working on getting a first chunk of this committed. > > > > OK, here's the patch. > > I've now committed a version of thi

Re: [HACKERS] making an unlogged table logged

> > -- > > Robert Haas > > EnterpriseDB: http://www.enterprisedb.com > > The Enterprise PostgreSQL Company > > A couple thoughts: > 1. Could the making a table logged be a non-exclusive lock if the > ALTER is allowed to take a full checkpoint? If possible, that would certainly be better. If the

Re: [HACKERS] SQL/MED - core functionality

On Tue, 4 Jan 2011 22:16:26 -0500 Robert Haas wrote: > On Sat, Jan 1, 2011 at 11:54 PM, Robert Haas wrote: > > Hanada-san, can you rebase the fdw_scan patch over what I committed > > and post an updated version ASAP?  It'd be better for Heikki or Tom to > > work on that part of this than me, sinc

Re: [HACKERS] making an unlogged table logged

On Tue, Jan 4, 2011 at 7:41 PM, Robert Haas wrote: > Somebody asked about this on Depesz's blog today, and I think it's > come up here before too, so I thought it might be worth my writing up > a few comments on this.  I don't think I'm going to have time to work > on this any time soon, but if so

Re: [HACKERS] Streaming replication as a separate permissions

On Mon, Jan 3, 2011 at 5:50 PM, Magnus Hagander wrote: > On Mon, Jan 3, 2011 at 17:23, Robert Haas wrote: >> On Mon, Jan 3, 2011 at 11:20 AM, Tom Lane wrote: >>> Robert Haas writes: On the other hand, the REPLICATION privilege is denying you the right to perform an operation *even tho

Re: [HACKERS] SQL/MED - core functionality

On Sat, Jan 1, 2011 at 11:54 PM, Robert Haas wrote: > Hanada-san, can you rebase the fdw_scan patch over what I committed > and post an updated version ASAP?  It'd be better for Heikki or Tom to > work on that part of this than me, since they have a better > understanding of the executor than I do

[HACKERS] making an unlogged table logged

Somebody asked about this on Depesz's blog today, and I think it's come up here before too, so I thought it might be worth my writing up a few comments on this. I don't think I'm going to have time to work on this any time soon, but if someone else wants to work up a patch, I'm game to review. I

Re: [HACKERS] Re: new patch of MERGE (merge_204) & a question about duplicated ctid

David Fetter wrote: How about implementing an UPSERT command as "take the lock, do the merge?" That way, we'd have both the simplicity for the simpler cases and a way to relax consistency guarantees for those who would like to do so. Main argument against is that path leads to a permanent n

Re: [HACKERS] Re: new patch of MERGE (merge_204) & a question about duplicated ctid

Kevin Grittner wrote: Greg Smith wrote: I could see shipping this with the automatic heavy LOCK TABLE in there. How would you handle or document behavior in REPEATABLE READ isolation? The lock doesn't do much good unless you acquire it before you get your snapshot, right? Han

Re: [HACKERS] Sync Rep Design

Simon Riggs wrote: Based upon that series of conversations, I've reworked the design so that there is (currently) only a single standby offering sync rep at any one time. Other standbys can request to be sync standbys but they only become the sync standby if the first one fails. Which was simple

Re: [HACKERS] can shared cache be swapped to disk?

On Tue, Jan 4, 2011 at 2:52 PM, Martijn van Oosterhout wrote: > On Tue, Jan 04, 2011 at 09:51:05AM -0800, Jeff Janes wrote: >> > Correct. The kernel ignores locking requests because it's a great way >> > to DOS a machine. For example, mlock() of large blocks of memory is >> > also not permitted fo

Re: [HACKERS] system views for walsender activity

On Wed, Jan 5, 2011 at 04:56, Heikki Linnakangas wrote: >> I think pg_stat_replication is better than pg_stat_standby, but I'm >> still not convinced we shouldn't go with the obvious >> pg_stat_walsenders. > > How about pg_stat_replication_activity? If I understood correctly, the view > is similar

Re: [HACKERS] WIP: Range Types

On 1/4/11 10:18 AM, Jeff Davis wrote: > The main drawback here is that only a select group of people will be > defining discrete range types at all, because it would require them to > define a function first. Perhaps that's for the best, because, (as Tom > pointed out) we don't want someone using f

Re: [HACKERS] ALTER EXTENSION UPGRADE patch v1

On Tue, Jan 04, 2011 at 08:31:19PM +0100, Dimitri Fontaine wrote: > David Fetter writes: > > Do you plan to have > > > > ALTER EXTENSION ... UPGRADE TO VERSION ... > > > > , or the more general, > > > > ALTER EXTENSION ... ALTER VERSION TO ... ? > > Well why not, but I'm not sure I understand wha

Re: [HACKERS] Sync Rep Design

> I was just thinking that you could prepend a reject line at the right > place in the file. Hmmm, that's worth thinking about. How do others feel about this? -- -- Josh Berkus PostgreSQL Experts Inc.

Re: [HACKERS] Fixing GIN for empty/null/full-scan cases

On 1/4/11 1:49 PM, Tom Lane wrote: > I don't think it's really worth the trouble. The GIN code has been > broken for these types of queries since day one, and yet we've had only > maybe half a dozen complaints about it. Moreover there's no practical > way to "avoid trying to use the index", since

Re: [HACKERS] Fixing GIN for empty/null/full-scan cases

On Tue, Jan 4, 2011 at 4:49 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Jan 4, 2011 at 4:09 PM, Tom Lane wrote: >>> * Existing GIN indexes are upwards compatible so far as on-disk storage >>> goes, but they will of course be missing entries for empty, null, or >>> null-containing items.

Re: [HACKERS] can shared cache be swapped to disk?

On Tue, Jan 04, 2011 at 09:51:05AM -0800, Jeff Janes wrote: > > Correct. The kernel ignores locking requests because it's a great way > > to DOS a machine. For example, mlock() of large blocks of memory is > > also not permitted for similar reasons. > > Does it ignore such requests in general, or

Re: [HACKERS] Sync Rep Design

Josh Berkus writes: >> What about the HBA here? > > Hmmm. That's tempting; an "synchronous" HBA instead of a GUC? But that > doesn't solve the problem of "standby #6 is failing, I want to kick it > off synch rep". > > I'd be opposed to having a GUC *and* an HBA. making DBAs set things > indepen

Re: [HACKERS] Sync Rep Design

> What about the HBA here? Hmmm. That's tempting; an "synchronous" HBA instead of a GUC? But that doesn't solve the problem of "standby #6 is failing, I want to kick it off synch rep". I'd be opposed to having a GUC *and* an HBA. making DBAs set things independantly in two places just frustra

Re: [HACKERS] Sync Rep Design

Josh Berkus writes: > So, again, I don't agree that a separate synchrep permission is useful, > or warranted. +1 > However, your arguments *do* make me backpedal on the issue of having a > list of synch rep roles on the master. I can easily imagine a DBA > needing to rapidly disable synch rep i

Re: [HACKERS] Re: Vacuum of newly activated 8.3.12 standby receives warnings page xxx is uninitialized --- fixing

On 05/01/11 04:43, Devrim GÜNDÜZ wrote: On Fri, 2010-12-31 at 11:11 +1300, Mark Kirkwood wrote: I note that this uninitialized pages with standbys has cropped up from time to time - I wonder if in most/all the cases folk were using Pitrtools? I deployed Pitrtools a lot when I was working for CM

Re: [HACKERS] Fixing GIN for empty/null/full-scan cases

Robert Haas writes: > On Tue, Jan 4, 2011 at 4:09 PM, Tom Lane wrote: >> * Existing GIN indexes are upwards compatible so far as on-disk storage >> goes, but they will of course be missing entries for empty, null, or >> null-containing items.  Users who want to do searches that should find >> suc

Re: [HACKERS] Fixing GIN for empty/null/full-scan cases

On Tue, Jan 4, 2011 at 4:09 PM, Tom Lane wrote: > * Existing GIN indexes are upwards compatible so far as on-disk storage > goes, but they will of course be missing entries for empty, null, or > null-containing items.  Users who want to do searches that should find > such items will need to reinde

[HACKERS] Fixing GIN for empty/null/full-scan cases

I've been thinking about how to fix GIN's assorted corner-case problems, as has been discussed several times, most recently here: http://archives.postgresql.org/pgsql-hackers/2010-10/msg00521.php See also http://wiki.postgresql.org/wiki/Todo#GIN There are basically three related issues: 1. GIN do

Re: [HACKERS] Upgrading Extension, version numbers

On Jan 4, 2011, at 12:05 PM, Dimitri Fontaine wrote: > "David E. Wheeler" writes: >> * Prefer convention over configuration > > The previous idea about the convention is not flying well with the very > recent proposal of ALTER EXTENSION ... UPGRADE TO VERSION ..., because > it would certainly re

Re: [HACKERS] Tracking latest timeline in standby mode

On 02.11.2010 07:15, Fujii Masao wrote: On Mon, Nov 1, 2010 at 8:32 PM, Heikki Linnakangas wrote: Yeah, that's one approach. Another is to validate the TLI in the xlog page header, it should always match the current timeline we're on. That would feel more robust to me. Yeah, that seems bette

Re: [HACKERS] Upgrading Extension, version numbers

"David E. Wheeler" writes: > * Prefer convention over configuration The previous idea about the convention is not flying well with the very recent proposal of ALTER EXTENSION ... UPGRADE TO VERSION ..., because it would certainly require that the extension's name include its major version number,

Re: [HACKERS] system views for walsender activity

On Tue, Jan 04, 2011 at 10:50:12AM -0800, Josh Berkus wrote: > > > Eh... I may be showing my status as a non-normal human, but I know > > exactly what pg_stat_walsender is (it's the view that shows you the > > status of the WAL senders you've allowed by configuring > > max_wal_senders>0) but I hav

Re: [HACKERS] system views for walsender activity

On 04.01.2011 21:43, Robert Haas wrote: On Tue, Jan 4, 2011 at 2:31 PM, Magnus Hagander wrote: On Tue, Jan 4, 2011 at 20:28, Josh Berkus wrote: hmmm I think "pg_stat_standby" might be more relevant but I definitely agree something more newbie appropriate is in order. I'd be fine with that

Re: [HACKERS] Sync Rep Design

On Tue, Jan 4, 2011 at 2:50 PM, Stefan Kaltenbrunner wrote: > On 01/04/2011 07:51 PM, Simon Riggs wrote: >> >> On Tue, 2011-01-04 at 10:28 -0800, Josh Berkus wrote: >> >>> The relevant question is: which configuration(s) can we have ready for >>> the next CommitFest and alpha release? >> >> Based

Re: [HACKERS] Upgrading Extension, version numbers

On Jan 4, 2011, at 11:48 AM, Dimitri Fontaine wrote: >> As Tom pointed out, you can do the same with naming conventions by having >> scripts \i each other as appropriate. > > This is a deprecated idea, though. We're talking about the > pg_execute_from_file() patch that has been applied, but wit

Re: [HACKERS] WIP: Range Types

On Tue, Jan 4, 2011 at 1:18 PM, Jeff Davis wrote: > On Tue, 2011-01-04 at 12:21 -0500, Robert Haas wrote: >> > It doesn't allow for all of the suggested features. In particular, it >> > would not allow "granules" to be specified for discrete ranges. But on >> > balance, it seems like this is the m

Re: [HACKERS] Sync Rep Design

On 01/04/2011 07:51 PM, Simon Riggs wrote: On Tue, 2011-01-04 at 10:28 -0800, Josh Berkus wrote: The relevant question is: which configuration(s) can we have ready for the next CommitFest and alpha release? Based upon that series of conversations, I've reworked the design so that there is (cu

Re: [HACKERS] Upgrading Extension, version numbers

"David E. Wheeler" writes: > As Tom pointed out, you can do the same with naming conventions by having > scripts \i each other as appropriate. This is a deprecated idea, though. We're talking about the pg_execute_from_file() patch that has been applied, but without the pg_execute_sql_file() fun

Re: [HACKERS] system views for walsender activity

On Tue, Jan 4, 2011 at 2:31 PM, Magnus Hagander wrote: > On Tue, Jan 4, 2011 at 20:28, Josh Berkus wrote: >> >>> hmmm I think "pg_stat_standby" might be more relevant but I definitely >>> agree something more newbie appropriate is in order. >> >> I'd be fine with that name, too. > > That seems ki

Re: [HACKERS] ALTER EXTENSION UPGRADE patch v1

David Fetter writes: > Do you plan to have > > ALTER EXTENSION ... UPGRADE TO VERSION ... > > , or the more general, > > ALTER EXTENSION ... ALTER VERSION TO ... ? Well why not, but I'm not sure I understand what you have in mind here. I don't exactly see how to install more than one version on t

Re: [HACKERS] system views for walsender activity

On Tue, Jan 4, 2011 at 20:28, Josh Berkus wrote: > >> hmmm I think "pg_stat_standby" might be more relevant but I definitely >> agree something more newbie appropriate is in order. > > I'd be fine with that name, too. That seems kind of backwards though - given that the view only contains data on

Re: [HACKERS] system views for walsender activity

> hmmm I think "pg_stat_standby" might be more relevant but I definitely > agree something more newbie appropriate is in order. I'd be fine with that name, too. -- -- Josh Berkus PostgreSQL Experts Inc.

Re: [HACKERS] system views for walsender activity

On Tue, 2011-01-04 at 10:50 -0800, Josh Berkus wrote: > > Eh... I may be showing my status as a non-normal human, but I know > > exactly what pg_stat_walsender is (it's the view that shows you the > > status of the WAL senders you've allowed by configuring > > max_wal_senders>0) but I have no idea

Re: [HACKERS] Sync Rep Design

> I'm not feeling well now, so I'm going to go to bed, not just to avoid > snapping at people. Even given that short interlude, I see no problem > about delivery. Cool! Thanks Simon. Feel better. Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt

Re: [HACKERS] Sync Rep Design

On Sun, Jan 2, 2011 at 4:19 PM, Simon Riggs wrote: > On Sun, 2011-01-02 at 18:54 +0200, Heikki Linnakangas wrote: > >> I believe we all agree that there's different use cases that require >> different setups. Both "first-past-the-post" and "wait-for-all-to-ack" >> have their uses. > > Robert's ana

Re: [HACKERS] Sync Rep Design

On Tue, 2011-01-04 at 10:28 -0800, Josh Berkus wrote: > The relevant question is: which configuration(s) can we have ready for > the next CommitFest and alpha release? Based upon that series of conversations, I've reworked the design so that there is (currently) only a single standby offering syn

Re: [HACKERS] WIP: Range Types

On Tue, 2011-01-04 at 23:04 +0900, Hitoshi Harada wrote: > 2011/1/4 Jeff Davis : > > I have been updating my work in progress here: > > > > http://git.postgresql.org/gitweb?p=users/jdavis/postgres.git;a=log;h=refs/heads/rangetypes > > > > Right now, it's not in a reviewable state, but those interes

Re: [HACKERS] system views for walsender activity

> Eh... I may be showing my status as a non-normal human, but I know > exactly what pg_stat_walsender is (it's the view that shows you the > status of the WAL senders you've allowed by configuring > max_wal_senders>0) but I have no idea what pg_stat_replication_sent > and pg_stat_replication_recei

Re: [HACKERS] system views for walsender activity

On Tue, Jan 4, 2011 at 12:48 PM, Simon Riggs wrote: > The sent pointer is needed whether or not we have sync rep. We should > also include application name, since the user may set that in the > standby for all the same reasons it is set elsewhere. > > Small point: please lets not call this pg_stat

Re: [HACKERS] Sync Rep Design

On 1/2/11 12:35 AM, Heikki Linnakangas wrote: > Very likely. A synchronous standby can bring the master to a halt, while > an asynchronous one is rather harmless. If I were a DBA, and the data > wasn't very sensitive, I would liberally hand out async privileges to my > colleagues to set up reportin

Re: [HACKERS] Sync Rep Design

All, This is a pointless argument. Eventually, we will be implementing all possible sync rep configurations, because different users *need* different configurations. Some users care more about durability, some more about availability, and some more about response time. And you can't have all th

Re: [HACKERS] WIP: Range Types

On Tue, 2011-01-04 at 14:18 +, Florian Weimer wrote: > * Jeff Davis: > > > 4. For the GiST penalty function, and perhaps some picksplit algorithms, > > it might be nice to know the length of a range, or do some other kinds > > of math. It introduces a lot of complexity to try to define math >

Re: [HACKERS] WIP: Range Types

On Tue, 2011-01-04 at 12:21 -0500, Robert Haas wrote: > > It doesn't allow for all of the suggested features. In particular, it > > would not allow "granules" to be specified for discrete ranges. But on > > balance, it seems like this is the most conceptually simple and I think > > it satisfies the

Re: [HACKERS] can shared cache be swapped to disk?

On Sun, Dec 19, 2010 at 6:14 AM, Martijn van Oosterhout wrote: > On Sat, Dec 18, 2010 at 11:59:33PM -0800, Jeff Janes wrote: >> On Sat, Dec 18, 2010 at 10:11 PM, flyusa2010 fly >> wrote: >> > hi, folks! >> > I see that shared cache is implemented by system v shared memory. I wonder >> > whether

Re: [HACKERS] system views for walsender activity

On Tue, 2011-01-04 at 15:51 +0900, Itagaki Takahiro wrote: > On Tue, Dec 28, 2010 at 22:17, Magnus Hagander wrote: > >>> We definitely need the very basic level for 9.1, and we can always > >>> improve on it later :-) > > > >>> pg_stat_walsender. It would then only need the columns for procpid, >

Re: [HACKERS] Upgrading Extension, version numbers

On Jan 4, 2011, at 12:46 AM, Dimitri Fontaine wrote: > "David E. Wheeler" writes: >> Just so long as you're aware that you might get more challenges on this >> going forward. > > Sure, thanks for the reminder. That said I also remember the reaction > when I used to scan the SHARE/contrib direc

Re: [HACKERS] WIP: Range Types

On Tue, Jan 4, 2011 at 2:29 AM, Jeff Davis wrote: > I liked Robert's suggestion here: > > http://archives.postgresql.org/message-id/aanlktiks_x93_k82b4f_ga634wci0oeb9ftrurf28...@mail.gmail.com > > which says that the user can just define a "canonicalize" function that > will take a range as input

Re: [HACKERS] Re: new patch of MERGE (merge_204) & a question about duplicated ctid

On Tue, Jan 04, 2011 at 07:02:54PM +0200, Marko Tiikkaja wrote: > On 2011-01-04 6:27 PM, David Fetter wrote: > >On Tue, Jan 04, 2011 at 04:44:32AM -0500, Greg Smith wrote: > >>Heikki Linnakangas wrote: > >>>You can of course LOCK TABLE as a work-around, if that's what you want. > >> > >>Presuming t

Re: [HACKERS] Re: new patch of MERGE (merge_204) & a question about duplicated ctid

On 2011-01-04 6:27 PM, David Fetter wrote: On Tue, Jan 04, 2011 at 04:44:32AM -0500, Greg Smith wrote: Heikki Linnakangas wrote: You can of course LOCK TABLE as a work-around, if that's what you want. Presuming the code quality issues and other little quirks I've documented (and new ones yet

Re: [HACKERS] ALTER EXTENSION UPGRADE patch v1

On Tue, Jan 04, 2011 at 12:31:55PM +0100, Dimitri Fontaine wrote: > Hi, > > Please find attached the patch to support ALTER EXTENSION UPGRADE, Do you plan to have ALTER EXTENSION ... UPGRADE TO VERSION ... , or the more general, ALTER EXTENSION ... ALTER VERSION TO ... ? I get that this might

Re: [HACKERS] Implementing pg_dump_sort.c topological sorting in sql/plpgsql/plperl?

On Tue, Jan 04, 2011 at 09:29:55AM +0100, Joel Jacobson wrote: > Hi hackers, > > The project I'm currently working with fsnapshot[1], is written in > plain plpgsql and I need to sort all the oids in their > creatable/droppable order. This has already been properly > implemented in pg_dump_sort.c

Re: [HACKERS] Implementing pg_dump_sort.c topological sorting in sql/plpgsql/plperl?

Joel Jacobson writes: > It's not possible to use a plain recursive query to do the trick (due > to 'i' bidirectional dependencies and dependency loops). Well I came up with that while working on some extension related fun dependency problems, I guess it could help you: ~:5490=# WITH RECURSIVE de

Re: [HACKERS] WIP: Range Types

Jeff Davis writes: > 2. We need to use the subtype's IO functions, but those may not be > immutable. So, rather than create new IO functions for each range type, > I was thinking that I'd use just three (anyrange_i_in, anyrange_s_in, > and anyrange_v_in), and select the right one at definition tim

Re: [HACKERS] Re: new patch of MERGE (merge_204) & a question about duplicated ctid

On Tue, Jan 04, 2011 at 04:44:32AM -0500, Greg Smith wrote: > Heikki Linnakangas wrote: > >You can of course LOCK TABLE as a work-around, if that's what you want. > > Presuming the code quality issues and other little quirks I've > documented (and new ones yet to be discovered) can get resolved >

Re: [HACKERS] regclass without error?

Tatsuo Ishii writes: >> Why is any of this necessary? It sure looks like you are solving a >> problem at the wrong level. > Please read upthread. You haven't made any argument why this shouldn't be solvable at the client side, or at worst with a plpgsql DO block; either of which answer would ha

Re: [HACKERS] regclass without error?

> Why is any of this necessary? It sure looks like you are solving a > problem at the wrong level. Please read upthread. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@post

Re: [HACKERS] Re: Vacuum of newly activated 8.3.12 standby receives warnings page xxx is uninitialized --- fixing

On Fri, 2010-12-31 at 11:11 +1300, Mark Kirkwood wrote: > > I note that this uninitialized pages with standbys has cropped up from > time to time - I wonder if in most/all the cases folk were using > Pitrtools? I deployed Pitrtools a lot when I was working for CMD, and I haven't seen any issues w

Re: [HACKERS] regclass without error?

Tatsuo Ishii writes: >> It's not generally safe to suppress errors like that. You could leak >> locks or tuple descriptors etc. And if the error is not "no scuh >> table", but e.g. out of memory, you don't want to suppress it anyway. > Thanks. I will create more "invasive" patch. Why is any of t

Re: [HACKERS] back branches vs. VS 2008

On 01/04/2011 04:43 AM, Magnus Hagander wrote: OK, what's going here is that, in the newer SDK, IPV6_V6ONLY is defined unconditionally, but IPPROTO_IPV6 is only defined if _WIN32_WINNT is set to 0x0501 or higher. We defined _WIN32_WINNT as 0x0500 until 9.0, when we changed it specifically to

Re: [HACKERS] texteq/byteaeq: avoid detoast

Hi Pavel, On Tue, Jan 04, 2011 at 03:13:11PM +0100, Pavel Stehule wrote: > I looked on patch Thanks. > does work toast_raw_datum_size on packed varlena corectly? Yes, as best I can tell. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] WIP: Range Types

* Jeff Davis: > 4. For the GiST penalty function, and perhaps some picksplit algorithms, > it might be nice to know the length of a range, or do some other kinds > of math. It introduces a lot of complexity to try to define math > functions for each subtype, and try to make sure they behave sanely

Re: [HACKERS] texteq/byteaeq: avoid detoast

Hello I looked on patch does work toast_raw_datum_size on packed varlena corectly? regards Pavel Stehule 2011/1/4 Noah Misch : > On Mon, Jan 03, 2011 at 10:23:03PM -0500, Robert Haas wrote: >> Can you add this to the currently-open CommitFest, so we don't lose track of >> it? >> >> https://co

Re: [HACKERS] WIP: Range Types

2011/1/4 Jeff Davis : > I have been updating my work in progress here: > > http://git.postgresql.org/gitweb?p=users/jdavis/postgres.git;a=log;h=refs/heads/rangetypes > > Right now, it's not in a reviewable state, but those interested can > glance through the code. > > Quick synopsis (for illustrati

Re: [HACKERS] texteq/byteaeq: avoid detoast

On Mon, Jan 03, 2011 at 10:23:03PM -0500, Robert Haas wrote: > Can you add this to the currently-open CommitFest, so we don't lose track of > it? > > https://commitfest.postgresql.org/action/commitfest_view/open Done. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To mak

Re: [HACKERS] pg_dump --split patch

Joel Jacobson wrote: To understand a change to my database functions, I would start by looking at the top-level, only focusing on the names of the functions modified/added/removed. At this stage, you want as little information as possible about each change, such as only the names of the functio

Re: [HACKERS] keeping a timestamp of the last stats reset (for a db, table and function)

Tomas Vondra wrote: OK, so here goes the simplified patch - it tracks one reset timestamp for a background writer and for each database. Adding timestamps like this was something I wanted to do after adding pg_stat_reset_shared to 9.0, so since you've beaten me to it I'll review your patch

Re: [HACKERS] regclass without error?

> It's not generally safe to suppress errors like that. You could leak > locks or tuple descriptors etc. And if the error is not "no scuh > table", but e.g. out of memory, you don't want to suppress it anyway. Thanks. I will create more "invasive" patch. -- Tatsuo Ishii SRA OSS, Inc. Japan English

Re: [HACKERS] keeping a timestamp of the last stats reset (for a db, table and function)

t...@fuzzy.cz wrote: - I really am not sure about the changes made in pg_proc.h. I'm not sure how to assign OIDs to the new functions (I've simply chosen values that are were not used in this file), and I'm not sure about the other columns (I've copied and modified another function with the same

Re: [HACKERS] Re: new patch of MERGE (merge_204) & a question about duplicated ctid

Greg Smith wrote: > I could see shipping this with the automatic heavy LOCK TABLE in > there. How would you handle or document behavior in REPEATABLE READ isolation? The lock doesn't do much good unless you acquire it before you get your snapshot, right? -Kevin -- Sent via pgsql-hackers m

Re: [HACKERS] regclass without error?

On 04.01.2011 11:07, Tatsuo Ishii wrote: Datum pgpool_regclass(PG_FUNCTION_ARGS) { char*pro_name_or_oid = PG_GETARG_CSTRING(0); Oid result; PG_TRY(); { result = DirectFunctionCall1(regclassin,

[HACKERS] ALTER EXTENSION UPGRADE patch v1

Hi, Please find attached the patch to support ALTER EXTENSION UPGRADE, following exchanges made on this list — we can't really speak about decisions here, apparently, until commit is done :) The documentation is available online for easy browsing here: http://pgsql.tapoueh.org/extensions/doc/h

Re: [HACKERS] SSPI client authentication in non-Windows builds

* Robert Haas wrote: On Mon, Jan 3, 2011 at 8:11 AM, Christian Ullrich wrote: this patch adds support for connecting to servers running on Windows and requesting SSPI authentication. It does this by treating AUTH_REQ_SSPI the same as AUTH_REQ_GSS if no native SSPI support is available. I h

Re: [HACKERS] Re: new patch of MERGE (merge_204) & a question about duplicated ctid

Robert Haas wrote: And even if it isn't, the MERGE syntax is insane if what you really want to do is insert or update ONE record. If all we have is MERGE, people will keep doing it with a PL/pgsql stored procedure or some crummy application logic just so that they don't have to spend several day

Re: [HACKERS] pg_dump --split patch

On 28.12.2010 17:00, Joel Jacobson wrote: Dear fellow hackers, Problem: A normal diff of two slightly different schema dump files (pg_dump -s), will not produce a user-friendly diff, as you get all changes in the same file. Another Solution: I have used a python script for spliiting "dump -s

Re: [HACKERS] pg_dump --split patch

On 28.12.2010 23:51, Tom Lane wrote: Andrew Dunstan writes: On 12/28/2010 04:44 PM, Joel Jacobson wrote: Perhaps abbreviations are to prefer, e.g., myfunc_i, myfunc_i_c, etc to reduce the need of truncating filenames. I think that's just horrible. Does the i stand for integer or inet? And it

Re: [HACKERS] pg_dump --split patch

On 28.12.2010 22:44, Joel Jacobson wrote: Sent from my iPhone On 28 dec 2010, at 21:45, Gurjeet Singh > wrote: The problem I see with suffixing a sequence id to the objects with name collision is that one day the dump may name myfunc(int) as myfunc.sql and a

Re: [HACKERS] Re: new patch of MERGE (merge_204) & a question about duplicated ctid

Heikki Linnakangas wrote: You can of course LOCK TABLE as a work-around, if that's what you want. What I was trying to suggest upthread is that while there are other possible ways around this problem, the only one that has any hope of shipping with 9.1 is to do just that. So from my perspect

Re: [HACKERS] back branches vs. VS 2008

On Tue, Jan 4, 2011 at 04:49, Andrew Dunstan wrote: > > On 01/03/2011 12:15 PM, I wrote: >> >> The following patch allows me to build the 8.3 and 8.4 branches using >> Visual Studio 2008, once the build system is patched. But I don't really >> know why. HEAD and 9.0 build fine without it. But thos

Re: [HACKERS] regclass without error?

Long time ago, I propose regclass like function which does not throw an error if the table is not found. Instead I want to let it return InvalidOid or NULL. >> Tatsuo Ishii writes: >> > Is there any way to use regclass without having ERROR? >> >> > pgpool-II needs to find the oid from table name

Re: [HACKERS] Upgrading Extension, version numbers

"David E. Wheeler" writes: > Just so long as you're aware that you might get more challenges on this going > forward. Sure, thanks for the reminder. That said I also remember the reaction when I used to scan the SHARE/contrib directory to find the extension control file having the right name pr

Re: [HACKERS] Extension upgrade, patch v0: debug help needed

Robert Haas writes: > Committed. Thanks! -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Implementing pg_dump_sort.c topological sorting in sql/plpgsql/plperl?

Hi hackers, The project I'm currently working with fsnapshot[1], is written in plain plpgsql and I need to sort all the oids in their creatable/droppable order. This has already been properly implemented in pg_dump_sort.c using Knuth's algorithm for topological sorting, with some special magic to