Re: [HACKERS] FSM search modes

On Sep 18, 2009, at 1:09 AM, Simon Riggs wrote: On Fri, 2009-09-18 at 10:47 +0900, Itagaki Takahiro wrote: Simon Riggs wrote: * compact - page selection specifically attempts to find the lowest numbered blocks, so that the table will naturally shrink over time. We cannot shrink the table if

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

On Thu, 2009-09-17 at 17:44 -0400, Tom Lane wrote: > Dimitri Fontaine writes: > > I don't see any reason why not breaking the user visible behavior of > > tuples CTID between any two major releases, > > > Am I completely wet here? > > Completely. This is a user-visible behavior that we have en

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

Tom Lane wrote: > > I don't see any reason why not breaking the user visible behavior of > > tuples CTID between any two major releases, > > > Am I completely wet here? > > Completely. This is a user-visible behavior that we have encouraged > people to rely on, and for which there is no easy sub

Re: [HACKERS] Hot Standby 0.2.1

On Thu, 2009-09-17 at 19:01 -0400, Robert Haas wrote: > > > > I'm going to put the index-only scans aside for now to focus on hot > > standby and streaming replication. Both are big patches, so there's > > plenty of work in those two alone, and not only for me. > > What is the best way to attack

Re: [HACKERS] [patch] pg_ctl init extension

Bernd Helmle píše v čt 17. 09. 2009 v 23:26 +0200: > > --On 17. September 2009 23:00:12 +0300 Peter Eisentraut > wrote: > > > f the name is a problem, why not change the name? What you are > > proposing above is effectively a very elaborate name change, so why not > > go for a simpler one? >

Re: [HACKERS] [patch] pg_ctl init extension

Peter Eisentraut píše v čt 17. 09. 2009 v 23:00 +0300: > On tor, 2009-09-17 at 21:43 +0200, Zdenek Kotala wrote: > > Attached patch extends pg_ctl command with init option. > > > > pg_ctl -D /var/lib/postgres [-s] init > > > > This should replace usage of initdb command which has problematic na

Re: [HACKERS] [PATCH] pgbench: new feature allowing to launch shell commands

> > You really should be returning a value at the point since the function > signature defines a return type. If not the function should be void, > which it cannot be in this context since it is used for boolean tests > elsewhere. The returns in question are all part of error blocks and > should re

Re: [HACKERS] FSM search modes

On Fri, 2009-09-18 at 10:47 +0900, Itagaki Takahiro wrote: > Simon Riggs wrote: > > > * compact - page selection specifically attempts to find the lowest > > numbered blocks, so that the table will naturally shrink over time. > > We cannot shrink the table if one tuple remains at the end of tab

Re: [HACKERS] Streaming Replication patch for CommitFest 2009-09

Hi, On Thu, Sep 17, 2009 at 8:32 PM, Heikki Linnakangas wrote: > Some random comments: Thanks for the comments. > I don't think we need the new PM_SHUTDOWN_3 postmaster state. We can > treat walsenders the same as the archive process, and kill and wait for > both of them to die in PM_SHUTDOWN_2

Re: [HACKERS] patch: Review handling of MOVE and FETCH (ToDo)

ok, thank you, I'll look on these issues early regards Pavel 2009/9/18 Selena Deckelmann : > Hi! > > John Naylor and I reviewed this patch. John created two test cases to > demonstrated issues described later in this email.  I've attached > those for reference. > > On Thu, Aug 27, 2009 at 8:04 P

Re: [HACKERS] patch: Review handling of MOVE and FETCH (ToDo)

Hi! John Naylor and I reviewed this patch. John created two test cases to demonstrated issues described later in this email. I've attached those for reference. On Thu, Aug 27, 2009 at 8:04 PM, Pavel Stehule wrote: > Hello, > > this small patch complete MOVE support in plpgsql and equalize plpgs

Re: [HACKERS] Bulk Inserts

2009/9/16 Pierre Frédéric Caillaud > > OK, that makes sense. I thought you had hacked either XLogInsert or the >> heap WAL replay code so that you could just accumulate tuples in the rdata >> chain and then submit them all under the cover of a single WALInsertLock. >> > > Ah, no, I did not do t

Re: [HACKERS] LDAP where DN does not include UID attribute

On Thu, Sep 17, 2009 at 6:24 PM, Robert Fleming wrote: > The new patch ... > s/printf/ereport(LOG,/

Re: [HACKERS] PGCluster-II Progress

Excellent news,Mitani. My personal intention if to help you with this work for the redesign of PGCluster-II, or on the coding of it. If we work like a team, we can release this new version of the project more quickly. Do you have any sources repository of this new version? I work fine with CVS

Re: [HACKERS] Patch for 8.5, transformationHook

On Sun, Sep 13, 2009 at 10:32 PM, Robert Haas wrote: > On Tue, Aug 11, 2009 at 12:09 AM, Pavel Stehule > wrote: >> 2009/8/10 Tom Lane : >>> Robert Haas writes: On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehule wrote: > new patch add new contrib "transformations" with three modules >

[HACKERS] pg_class_ownercheck() in EnableDisableRule()

I found a strange checks in the native database privilege stuff. The EnableDisableRule() calls pg_class_ownercheck() to check the ownership of the relation which has a rule to be turned on/off. Only ATExecEnableDisableRule() calls the EnableDisableRule(), and only ATExecCmd() calls the ATExecEnab

Re: [HACKERS] FSM search modes

Simon Riggs wrote: > * compact - page selection specifically attempts to find the lowest > numbered blocks, so that the table will naturally shrink over time. We cannot shrink the table if one tuple remains at the end of table and the tuple is always HOT-updated, because we put a new tuple into

Re: [HACKERS] PGCluster-II Progress

I'm sorry for late my response. I already sent same contents to Marcos, but I did not cc to all of yours. (I'll join pgsql-hackers ML). 1. Statement of PGCluster-II The state of PGCluster-II is re designing. I developed and demonstorated PGCluster-II as full data shared model in 2006. It worked fi

Re: [HACKERS] LDAP where DN does not include UID attribute

On Thu, Sep 17, 2009 at 11:15 AM, Magnus Hagander wrote: > On Thu, Sep 17, 2009 at 18:02, Robert Fleming wrote: > > Following a discussion on the pgsql-admin list > > , I > have > > created a patch to (optionally) allow PostgreSQL t

Re: [HACKERS] generic copy options

Robert Haas wrote: On Thu, Sep 17, 2009 at 8:31 PM, Dan Colish wrote: Ok, so I ran something like you suggested and did a simple copy from an empty file to just test the parsing. I have the COPY statement run 3733 times in the transaction block and did the select timestamps, but I still on

Re: [HACKERS] RfD: more powerful "any" types

On Tue, Sep 15, 2009 at 07:38:18AM +0200, Pavel Stehule wrote: > it isn't fair :) why you use $$ without single quote? And still this > case should be vulnerable on SQL injection. Maybe you or me knows, > what SQL injection means, but beginners knows nothing and this people > use following bad code

Re: [HACKERS] generic copy options

On Thu, Sep 17, 2009 at 8:31 PM, Dan Colish wrote: > Ok, so I ran something like you suggested and did a simple copy from an > empty file to just test the parsing. I have the COPY statement run 3733 > times in the transaction block and did the select timestamps, but I > still only was a few millis

Re: [HACKERS] generic copy options

On Thu, Sep 17, 2009 at 07:45:45PM -0400, Andrew Dunstan wrote: > > > Dan Colish wrote: >> CREATE TABLE >> INSERT 0 10 >> Timing is on. >> COPY 10 >> Time: 83.273 ms >> BEGIN >> Time: 0.412 ms >> TRUNCATE TABLE >> Time: 0.357 ms >> COPY 1000

Re: [HACKERS] generic copy options

Dan Colish wrote: CREATE TABLE INSERT 0 10 Timing is on. COPY 10 Time: 83.273 ms BEGIN Time: 0.412 ms TRUNCATE TABLE Time: 0.357 ms COPY 10 Time: 140.911 ms COMMIT Time: 4.909 ms

Re: [HACKERS] generic copy options

On that particular patch, as Robert mentioned, only the parsing has changed. In the case of \copy, the parsing is much lighter than before in psql (remains the same in the server). The bigger the COPY operation the less you will see the impact of the parsing since it is done only once for the e

Re: [HACKERS] generic copy options

On Thu, Sep 17, 2009 at 07:10:35PM -0400, Andrew Dunstan wrote: > > > Greg Smith wrote: >> On Thu, 17 Sep 2009, Dan Colish wrote: >> >>> - Performance appears to be the same although I don't have a good >>> way for >>> testing this at the moment >> >> Here's what I do to generate simple

Re: [HACKERS] generic copy options

Greg Smith wrote: On Thu, 17 Sep 2009, Dan Colish wrote: - Performance appears to be the same although I don't have a good way for testing this at the moment Here's what I do to generate simple COPY performance test cases: CREATE TABLE t (i integer); INSERT INTO t SELECT x FROM

Re: [HACKERS] generic copy options

On Thu, Sep 17, 2009 at 6:54 PM, Greg Smith wrote: > On Thu, 17 Sep 2009, Dan Colish wrote: > >>        - Performance appears to be the same although I don't have a good >> way for >>          testing this at the moment > > Here's what I do to generate simple COPY performance test cases: > > CREAT

Re: [HACKERS] Hot Standby 0.2.1

On Thu, Sep 17, 2009 at 2:54 AM, Heikki Linnakangas wrote: > Robert Haas wrote: >> On Wed, Sep 16, 2009 at 6:05 PM, Josh Berkus wrote: >>> Now that Simon has submitted this, can some of the heavy-hitters here >>> review it?  Heikki? >>> >>> Nobody's name is next to it. >> >> I don't think anyone

Re: [HACKERS] generic copy options

On Thu, 17 Sep 2009, Dan Colish wrote: - Performance appears to be the same although I don't have a good way for testing this at the moment Here's what I do to generate simple COPY performance test cases: CREATE TABLE t (i integer); INSERT INTO t SELECT x FROM generate_seri

Re: [HACKERS] [PATCH] pgbench: new feature allowing to launch shell commands

On Thu, Sep 17, 2009 at 09:56:44AM +0900, Michael Paquier wrote: > Hi all, > > Sorry for my late reply. > There is no other update for this patch since the 13th of August, at least > until today. The new patch is attached > By the way I worked on the comments that Dan and Gabriel pointed out. > I

Re: [HACKERS] gcc versus division-by-zero traps

Tom Lane wrote: > I hope that the bug will get fixed in due course, but even if they > respond pretty quickly it will be years before the problem disappears > from every copy of gcc in the field. So I'm thinking that it would > behoove us to install a workaround, now that we've characterized the >

Re: [HACKERS] generic copy options

Hi, I have read through the patch a few times and it looks OK. The additions to the COPY syntax work as expected and as agreed upon based on the thread. Below are some points from my checklist. - Patch applies cleanly - Included new tests and documentation

[HACKERS] Re: [COMMITTERS] pgsql: CVS NULL Documentation Clearify documentation of CVS's output of

Tom Lane wrote: > momj...@postgresql.org (Bruce Momjian) writes: > > Log Message: > > --- > > CVS NULL Documentation > > > Clearify documentation of CVS's output of NULL values, per suggestion > > from Magnus. > > This has not "clarified" anything; what it has done is transformed > correc

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

Tom Lane writes: > Completely. This is a user-visible behavior that we have encouraged > people to rely on, and for which there is no easy substitute. Excited to have self-healing tables (against bloat), I parse this as an opening. Previously on this thread you say: > (Actually, the ctid is onl

Re: [HACKERS] Fwd: Copy out wording

Andrew Dunstan wrote: > > > Bruce Momjian wrote: > > Magnus Hagander wrote: > > > >> On Thu, Sep 3, 2009 at 13:31, Andrew Dunstan wrote: > >> > >>> Magnus Hagander wrote: > >>> > Oh, hang on, "the NULL string" refers to the copy parameter? Not a > part of the data? I read

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

Dimitri Fontaine writes: > I don't see any reason why not breaking the user visible behavior of > tuples CTID between any two major releases, > Am I completely wet here? Completely. This is a user-visible behavior that we have encouraged people to rely on, and for which there is no easy substit

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

Hannu Krosing writes: > But maybe something can be tahen from this discussion the other way > round - maybe we should not be afraid of doing null updates during > in-place update The problem for in-place update is that it can't assume that any of the normal infrastructure (like index insertion or

Re: [HACKERS] Logging configuration changes [REVIEW]

On ons, 2009-09-16 at 10:54 +0530, Abhijit Menon-Sen wrote: > I can't help but think that it would be nice to report the default value > of a parameter that is reset (i.e. "parameter $x reset to default value > $y"). The first attached patch does this by calling GetConfigOption() > after the value

Re: [HACKERS] Fwd: Copy out wording

Bruce Momjian wrote: Magnus Hagander wrote: On Thu, Sep 3, 2009 at 13:31, Andrew Dunstan wrote: Magnus Hagander wrote: Oh, hang on, "the NULL string" refers to the copy parameter? Not a part of the data? I read it as "a string being NULL". Maybe something like "the value of th

Re: [HACKERS] [COMMITTERS] pgsql: CVS NULL Documentation Clearify documentation of CVS's output of

On Thu, Sep 17, 2009 at 5:22 PM, Tom Lane wrote: > momj...@postgresql.org (Bruce Momjian) writes: >> Log Message: >> --- >> CVS NULL Documentation > >> Clearify documentation of CVS's output of NULL values, per suggestion >> from Magnus. > > This has not "clarified" anything; what it has d

Re: [HACKERS] [patch] pg_ctl init extension

--On 17. September 2009 23:00:12 +0300 Peter Eisentraut wrote: f the name is a problem, why not change the name? What you are proposing above is effectively a very elaborate name change, so why not go for a simpler one? I don't like the solution by using -o "" to push down command line

Re: [HACKERS] [COMMITTERS] pgsql: CVS NULL Documentation Clearify documentation of CVS's output of

momj...@postgresql.org (Bruce Momjian) writes: > Log Message: > --- > CVS NULL Documentation > Clearify documentation of CVS's output of NULL values, per suggestion > from Magnus. This has not "clarified" anything; what it has done is transformed correct statements into incorrect ones. Y

Re: [HACKERS] updated join removal patch

On Thu, Sep 17, 2009 at 4:59 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Sep 15, 2009 at 9:29 PM, Tom Lane wrote: >>> Robert Haas writes: Here we go again.  Following Tom's advice to not insert crocks in add_path(), I've instead introduced a noopjoin path type which ignores >

Re: [HACKERS] Fwd: Copy out wording

Magnus Hagander wrote: > On Thu, Sep 3, 2009 at 13:31, Andrew Dunstan wrote: > > > > > > Magnus Hagander wrote: > >> > >> Oh, hang on, "the NULL string" refers to the copy parameter? Not a > >> part of the data? I read it as "a string being NULL". Maybe something > >> like "the value of the NULL st

Re: [HACKERS] generic copy options

Here you go. Emmanuel Dan Colish wrote: On Thu, Sep 17, 2009 at 02:56:07PM -0400, Emmanuel Cecchet wrote: Dan, My bad, I copy/pasted the hard link in output/copy.source instead of @abs_build...@. Here is a complete version of the patch with the fix on output/copy.source. Emmanuel

Re: [HACKERS] updated join removal patch

Robert Haas writes: > On Tue, Sep 15, 2009 at 9:29 PM, Tom Lane wrote: >> Robert Haas writes: >>> Here we go again.  Following Tom's advice to not insert crocks in >>> add_path(), I've instead introduced a noopjoin path type which ignores >>> its inner side. I've committed this with some revisi

Re: [HACKERS] Linux LSB init script

On Thu, Sep 17, 2009 at 4:18 PM, Peter Eisentraut wrote: > On tor, 2009-09-17 at 11:59 -0500, Kevin Grittner wrote: >> > Well, in such cases it may be useful to add an option such as >> > --oknodo to select the idempotent behavior. >> >> I found that confusing (as did Robert); how about --lsm-conf

Re: [HACKERS] generic copy options

On Thu, Sep 17, 2009 at 02:56:07PM -0400, Emmanuel Cecchet wrote: > Dan, > > My bad, I copy/pasted the hard link in output/copy.source instead of > @abs_build...@. > Here is a complete version of the patch with the fix on output/copy.source. > > Emmanuel Emmanuel, Thanks for ge

Re: [HACKERS] Linux LSB init script

On tor, 2009-09-17 at 14:21 -0400, Greg Smith wrote: > I've implemented exactly the same logic Kevin describes for a past > consulting customer and for multiple forms of shutdown scripts at > Truviso. > I would suggest the situation here is that it's so easy to script a > custom > solution that

Re: [HACKERS] Linux LSB init script

On tor, 2009-09-17 at 11:59 -0500, Kevin Grittner wrote: > > Well, in such cases it may be useful to add an option such as > > --oknodo to select the idempotent behavior. > > I found that confusing (as did Robert); how about --lsm-conforming? s/lsm/lsb/ I'm not so sure that I would label it as

Re: [HACKERS] Linux LSB init script

On tor, 2009-09-17 at 09:26 -0400, Robert Haas wrote: > On Thu, Sep 17, 2009 at 1:30 AM, Peter Eisentraut wrote: > > Well, in such cases it may be useful to add an option such as --oknodo > > to select the idempotent behavior. > > It took me about 60 seconds to figure out what I thought you were

Re: [HACKERS] [patch] pg_ctl init extension

On tor, 2009-09-17 at 21:43 +0200, Zdenek Kotala wrote: > Attached patch extends pg_ctl command with init option. > > pg_ctl -D /var/lib/postgres [-s] init > > This should replace usage of initdb command which has problematic name > as we already discussed several times. Initdb binary will be st

[HACKERS] [patch] pg_ctl init extension

Attached patch extends pg_ctl command with init option. pg_ctl -D /var/lib/postgres [-s] init This should replace usage of initdb command which has problematic name as we already discussed several times. Initdb binary will be still there, but it can be renamed and move into execlib dir in the fu

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

Hi, Forewords: re-reading, I hope my english will not make this sound like a high-kick when I'm just struggling to understand what all this is about. Sending in order not to regret missing the oportunity I think I'm seeing... Tom Lane writes: > Hannu Krosing writes: >> On Wed, 2009-09-16 at 21:

Re: [HACKERS] generic copy options

On Thu, Sep 17, 2009 at 02:56:07PM -0400, Emmanuel Cecchet wrote: > Dan, > > My bad, I copy/pasted the hard link in output/copy.source instead of > @abs_build...@. > Here is a complete version of the patch with the fix on output/copy.source. > > Emmanuel > Hooray, that works just fine now. I gue

Re: [HACKERS] generic copy options

Dan, My bad, I copy/pasted the hard link in output/copy.source instead of @abs_build...@. Here is a complete version of the patch with the fix on output/copy.source. Emmanuel On Thu, Sep 17, 2009 at 11:07:33AM -0400, Emmanuel Cecchet wrote: Tom Lane wrote: I wonder though if we cou

Re: [HACKERS] generic copy options

On Thu, Sep 17, 2009 at 11:07:33AM -0400, Emmanuel Cecchet wrote: > Tom Lane wrote: >> I wonder though if we couldn't simplify matters. Offhand it seems to me >> that psql doesn't need to validate the command's syntax fully. All it >> really needs to do is find the target filename and replace it w

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

On Thu, 2009-09-17 at 14:33 -0400, Greg Smith wrote: > On Wed, 16 Sep 2009, Tom Lane wrote: > > >> * Shrink a table in place - when no space available > > To be addressed by the UPDATE-style tuple-mover (which could be thought > > of as VACUUM FULL rewritten to not use any special mechanisms). >

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

On Thu, 2009-09-17 at 12:36 -0400, Tom Lane wrote: > Hannu Krosing writes: > > On Thu, 2009-09-17 at 12:18 -0400, Tom Lane wrote: > >> Or for an update without having to hold a transaction open. We have > >> recommended this type of technique in the past: > > > If you need real locking, then jus

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

On Wed, 16 Sep 2009, Tom Lane wrote: * Shrink a table in place - when no space available To be addressed by the UPDATE-style tuple-mover (which could be thought of as VACUUM FULL rewritten to not use any special mechanisms). Is there any synergy here with the needs of a future in-place upgrad

Re: [HACKERS] Schedule for 8.5 Development

Josh Berkus wrote: > Hackers, > > Per discussions on two other threads on this list which have apparently > reached consensus, we will be going with the following schedule: > > CF1 7/15 to 8/14 > Alpha1by 8/20 > CF2 9/15 to 10/14 > Alpha2by 10/20 > CF3 11/15 to 12/14 > Alpha

Re: [HACKERS] pg_hba.conf: samehost and samenet

[Thanks for the heads up about the MessageID missing when posting this previously. Was doing some mail filter development, and accidentally left it in place... ] Magnus Hagander wrote: > 2009/8/25 Alvaro Herrera : >> Something to keep in mind -- my getifaddrs(3) manpage says that on BSD >> it can

Re: [HACKERS] Linux LSB init script

On Thu, 17 Sep 2009, Peter Eisentraut wrote: On ons, 2009-09-16 at 12:05 -0500, Kevin Grittner wrote: Well, with differences in behavior, of course, like attempting a fast shutdown, and escalating to an immediate shutdown if that doesn't succeed in the allowed time. Right, but if you think th

Re: [HACKERS] LDAP where DN does not include UID attribute

On Thu, Sep 17, 2009 at 18:02, Robert Fleming wrote: > Following a discussion on the pgsql-admin list > , I have > created a patch to (optionally) allow PostgreSQL to do a LDAP search to > determine the user's DN (as is done in Apach

Re: [HACKERS] opportunistic tuple freezing

On Thu, 2009-09-17 at 12:36 -0400, Robert Haas wrote: > Despite my recent screw-up in this department, it should really be the > patch author's responsibility to test the patch first. Then the > reviewing process can involve additional testing. So I would say this > should be moved to Returned Wi

Re: [HACKERS] community decision-making & 8.5

Selena Deckelmann wrote: > On Thu, Sep 3, 2009 at 9:00 AM, Robert Haas wrote: > > > Yeah, I'm game, though I'm hoping not to become the guy who spends all > > his time doing release planning, because I like writing code, too. > > Hopefully Selena won't mind my mentioning that she sent me a private

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

On Thu, 2009-09-17 at 12:30 -0400, Tom Lane wrote: > Simon Riggs writes: > > The update utility being discussed is in danger of confusing these two > > goals > > * compact the table using minimal workspace > > * compact the table with minimal interruption to concurrent updaters > > Actually, the

Re: [HACKERS] Linux LSB init script

Peter Eisentraut wrote: > I think it's important to consider what the "conforming behavior" > really achieves in practice. The INFO section is essential nowadays > for correct functioning on a large portion of distributions. The > exit codes are relatively uninteresting but occasionally useful

Re: [HACKERS] opportunistic tuple freezing

On Thu, Sep 17, 2009 at 12:24 PM, Tom Lane wrote: > Jeff Janes writes: >> Does the community think that experimental performance testing is a >> must-have in order for this patch to be acceptable? > > Dunno about others, but I think so.  It's complicating both the > implementation and the users-e

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

Hannu Krosing writes: > On Thu, 2009-09-17 at 12:18 -0400, Tom Lane wrote: >> Or for an update without having to hold a transaction open. We have >> recommended this type of technique in the past: > If you need real locking, then just define a locked (or locked_by or > locked_until) column and u

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

On Thu, Sep 17, 2009 at 12:31 PM, Hannu Krosing wrote: >> Exactly.  The application is typically going to throw a "concurrent >> update" type of error when this happens, and we don't want magic >> background operations to cause that. > > Would'nt current VACUUM FULL or CLUSTER cause much more grie

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

On Thu, Sep 17, 2009 at 12:18 PM, Tom Lane wrote: >> It's no different from the situation where another backend UPDATEs the >> row under your nose, but it's not something you want to do automatically >> without notice. > > Exactly.  The application is typically going to throw a "concurrent > updat

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

On Thu, 2009-09-17 at 12:18 -0400, Tom Lane wrote: > Heikki Linnakangas writes: > > Robert Haas wrote: > >> On Thu, Sep 17, 2009 at 10:21 AM, Tom Lane wrote: > >>> Anything that moves tuples is not acceptable as a hidden background > >>> operation, because it will break applications that depend o

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

Simon Riggs writes: > The update utility being discussed is in danger of confusing these two > goals > * compact the table using minimal workspace > * compact the table with minimal interruption to concurrent updaters Actually, the update utility is explicitly meant to satisfy both of those goals

Re: [HACKERS] opportunistic tuple freezing

Jeff Janes writes: > Does the community think that experimental performance testing is a > must-have in order for this patch to be acceptable? Dunno about others, but I think so. It's complicating both the implementation and the users-eye view of VACUUM, and I want more than a hypothesis that we

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

On Thu, 2009-09-17 at 10:32 -0400, Tom Lane wrote: > Hannu Krosing writes: > > On Thu, 2009-09-17 at 10:21 -0400, Tom Lane wrote: > >> because it will break applications that depend on CTID. > > > Do you know of any such applications out in the wild ? > > Yes, they're out there. How do they dea

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

Heikki Linnakangas writes: > Robert Haas wrote: >> On Thu, Sep 17, 2009 at 10:21 AM, Tom Lane wrote: >>> Anything that moves tuples is not acceptable as a hidden background >>> operation, because it will break applications that depend on CTID. >> I'm a bit confused. CTIDs change all the time an

Re: [HACKERS] opportunistic tuple freezing

On Mon, Sep 14, 2009 at 2:07 AM, Jeff Davis wrote: > On Mon, 2009-08-17 at 10:22 -0400, Tom Lane wrote: > > As always with patches that are meant to improve performance, > > some experimental evidence would be a good thing. > > I haven't had time to performance test this patch yet, and it looks l

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

Robert Haas wrote: > On Thu, Sep 17, 2009 at 10:21 AM, Tom Lane wrote: >> Hannu Krosing writes: >>> On Wed, 2009-09-16 at 21:19 -0400, Tom Lane wrote: VACUUM FULL CONCURRENTLY is a contradiction in terms. Wishing it were possible doesn't make it so. >>> It depends on what do you mean b

[HACKERS] LDAP where DN does not include UID attribute

Following a discussion on the pgsql-admin list < http://archives.postgresql.org/pgsql-admin/2009-09/msg00075.php>, I have created a patch to (optionally) allow PostgreSQL to do a LDAP search to determine the user's DN (as is done in Apache, MediaWiki, Bugzilla, et al.) instead of building the DN fr

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

On Thu, 2009-09-17 at 11:25 -0400, Robert Haas wrote: > On Thu, Sep 17, 2009 at 10:21 AM, Tom Lane wrote: > > Hannu Krosing writes: > >> On Wed, 2009-09-16 at 21:19 -0400, Tom Lane wrote: > >>> VACUUM FULL CONCURRENTLY is a contradiction in terms. Wishing it were > >>> possible doesn't make it

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

On Thu, 2009-09-17 at 10:45 -0400, Tom Lane wrote: > Hannu Krosing writes: > > On Thu, 2009-09-17 at 09:45 -0400, Robert Haas wrote: > >> Making the code more complicated so that it's easier to tune something > >> that isn't very hard to tune anyway doesn't seem like a good > >> trade-off. > > >

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

On Thu, Sep 17, 2009 at 10:21 AM, Tom Lane wrote: > Hannu Krosing writes: >> On Wed, 2009-09-16 at 21:19 -0400, Tom Lane wrote: >>> VACUUM FULL CONCURRENTLY is a contradiction in terms.  Wishing it were >>> possible doesn't make it so. > >> It depends on what do you mean by "VACUUM FULL" > > Anyt

[HACKERS] FSM search modes

Just been looking again at the way FSM works. In fsm_search_avail() we essentially have just a single way for working out how to search the tree. Seems like it would be good to abstract this so that we can implement a number of FSM search strategies * (current) randomize - page selection encoura

Re: [HACKERS] generic copy options

Tom Lane wrote: I wonder though if we couldn't simplify matters. Offhand it seems to me that psql doesn't need to validate the command's syntax fully. All it really needs to do is find the target filename and replace it with STDIN/STDOUT. Could we have it just treat the remainder of the line li

Re: [HACKERS] generic copy options

Emmanuel Cecchet writes: > Does that mean that we can drop the 7.3 syntax or should we just keep it? I wouldn't object to dropping the 7.3 syntax now, especially if we're about to introduce a new syntax and deprecate the old one ... regards, tom lane -- Sent via pgsql-h

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

Hannu Krosing writes: > On Thu, 2009-09-17 at 09:45 -0400, Robert Haas wrote: >> Making the code more complicated so that it's easier to tune something >> that isn't very hard to tune anyway doesn't seem like a good >> trade-off. > I think that just making sure that pessimal cases don't happen sh

Re: [HACKERS] generic copy options

Tom Lane wrote: Emmanuel Cecchet writes: Tom Lane wrote: psql has MORE need to support old syntax than the backend does, because it's supposed to work against old servers. Well, I wonder how many users just upgrade psql vs upgrade the server. We have established a proje

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

Hannu Krosing writes: > On Thu, 2009-09-17 at 10:21 -0400, Tom Lane wrote: >> because it will break applications that depend on CTID. > Do you know of any such applications out in the wild ? Yes, they're out there. regards, tom lane -- Sent via pgsql-hackers mailing li

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

On Thu, 2009-09-17 at 10:21 -0400, Tom Lane wrote: > Hannu Krosing writes: > > On Wed, 2009-09-16 at 21:19 -0400, Tom Lane wrote: > >> VACUUM FULL CONCURRENTLY is a contradiction in terms. Wishing it were > >> possible doesn't make it so. > > > It depends on what do you mean by "VACUUM FULL" >

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

On Thu, 2009-09-17 at 09:45 -0400, Robert Haas wrote: > On Thu, Sep 17, 2009 at 9:35 AM, Joshua Tolley wrote: > > On Wed, Sep 16, 2009 at 09:48:20PM -0400, Tom Lane wrote: > >> Seems like there would > >> be lots of situations where short exclusive-lock intervals could be > >> tolerated, even thou

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

Hannu Krosing writes: > On Wed, 2009-09-16 at 21:19 -0400, Tom Lane wrote: >> VACUUM FULL CONCURRENTLY is a contradiction in terms. Wishing it were >> possible doesn't make it so. > It depends on what do you mean by "VACUUM FULL" Anything that moves tuples is not acceptable as a hidden backgrou

Re: [HACKERS] generic copy options

Emmanuel Cecchet writes: > Tom Lane wrote: >> psql has MORE need to support old syntax than the backend does, because >> it's supposed to work against old servers. >> > Well, I wonder how many users just upgrade psql vs upgrade the server. We have established a project policy that psql backslash

Re: [HACKERS] generic copy options

2009/9/17 Emmanuel Cecchet : > Pavel Stehule wrote: >>> >>> Well, I wonder how many users just upgrade psql vs upgrade the server. I >>> was >>> thinking that when users perform a database upgrade their application >>> often >>> remain the same and therefore the server needs to support the old synt

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

On Thu, Sep 17, 2009 at 9:35 AM, Joshua Tolley wrote: > On Wed, Sep 16, 2009 at 09:48:20PM -0400, Tom Lane wrote: >> Seems like there would >> be lots of situations where short exclusive-lock intervals could be >> tolerated, even though not long ones.  So that's another argument >> for being able

Re: [HACKERS] generic copy options

Emmanuel Cecchet wrote: > I just wonder how many users are using a single psql to manage > multiple server instances of different older versions. I do that, but I do try to keep all the active versions on my machine, so that I can use one which exactly matches any of our 100 servers when it m

Re: [HACKERS] Feedback on getting rid of VACUUM FULL

On Wed, Sep 16, 2009 at 09:48:20PM -0400, Tom Lane wrote: > Seems like there would > be lots of situations where short exclusive-lock intervals could be > tolerated, even though not long ones. So that's another argument > for being able to set an upper bound on how many tuples get moved > per call

Re: [HACKERS] Linux LSB init script

On Thu, Sep 17, 2009 at 1:30 AM, Peter Eisentraut wrote: > Well, in such cases it may be useful to add an option such as --oknodo > to select the idempotent behavior. It took me about 60 seconds to figure out what I thought you were going for there, so I submit that's not a good choice of option

Re: [HACKERS] generic copy options

Pavel Stehule wrote: Well, I wonder how many users just upgrade psql vs upgrade the server. I was thinking that when users perform a database upgrade their application often remain the same and therefore the server needs to support the old syntax. Unless you are upgrading a machine where a bunch

  1   2   >