Re: [HACKERS] Parameter name standby_mode

Joachim Wieland wrote: > On Fri, Feb 12, 2010 at 7:28 AM, Fujii Masao wrote: >> Yeah, even if primary_conninfo is not given, the standby tries to invoke >> walreceiver by using the another connection settings (environment variables >> or defaults). This is intentional behavior, and would make the

Re: [HACKERS] Parameter name standby_mode

Fujii Masao wrote: > On Fri, Feb 12, 2010 at 4:04 PM, Heikki Linnakangas > wrote: >> Fujii Masao wrote: >>> On Fri, Feb 12, 2010 at 3:19 PM, Heikki Linnakangas >>> wrote: Fujii Masao wrote: > But if we fail in restoring the archived WAL file, "standby_mode = on" > *always* tries to s

Re: [HACKERS] Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL

Simon Riggs wrote: > On Thu, 2010-02-11 at 13:08 -0500, Tom Lane wrote: >> Heikki Linnakangas writes: >>> -1. it isn't necessary for PITR. It's a new requirement for >>> standby_mode='on', unless we add the file size check into the backend. I >>> think we should add the file size check to the back

Re: [HACKERS] Confusion over Python drivers {license}

>Obviously this is less urgent than having a driver that works now, but >it's still important. I think we would attract some goodwill from the >python community if we were helping them move to python3, rather than >sitting around waiting 'til they've already moved and decided that they >can't use p

Re: [HACKERS] Confusion over Python drivers

>>>The solution is to write the query in an unambiguous way: >>> >>> SELECT $1::date + 1; >>> >>>which is good practice, anyway. If it's not obvious to the type >>>inference system, it's probably not obvious to you, and will probably >>>surprise you ;) >> >> That address this specific case, but it

Re: [HACKERS] Parameter name standby_mode

Fujii Masao wrote: > On Fri, Feb 12, 2010 at 3:19 PM, Heikki Linnakangas > wrote: >> Fujii Masao wrote: >>> But if we fail in restoring the archived WAL file, "standby_mode = on" >>> *always* tries to start streaming replication. >> Hmm, somehow I thought it doesn't if you don't set primary_connin

Re: [HACKERS] Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]

On Wed, Feb 3, 2010 at 6:41 PM, Andrew Dunstan wrote: > > > Tom Lane wrote: >> >> Andrew Dunstan writes: >> >>> >>> %_SHARED has been around for several years now, and if there are genuine >>> security concerns about it ISTM they would apply today, regardless of these >>> patches. >>> >> >> Yes.

Re: [HACKERS] Parameter name standby_mode

On Fri, Feb 12, 2010 at 7:28 AM, Fujii Masao wrote: > Yeah, even if primary_conninfo is not given, the standby tries to invoke > walreceiver by using the another connection settings (environment variables > or defaults). This is intentional behavior, and would make the setup of SR > easier. So I'd

Re: [HACKERS] Parameter name standby_mode

On Fri, Feb 12, 2010 at 3:19 PM, Heikki Linnakangas wrote: > Fujii Masao wrote: >> On Wed, Feb 10, 2010 at 8:16 PM, Heikki Linnakangas >> wrote: >>> If they want to implement the warm standby using the (new) built-in >>> logic to keep retrying restore_command, they would set >>> standby_mode='on'

Re: [HACKERS] Parameter name standby_mode

Fujii Masao wrote: > On Wed, Feb 10, 2010 at 8:16 PM, Heikki Linnakangas > wrote: >> If they want to implement the warm standby using the (new) built-in >> logic to keep retrying restore_command, they would set >> standby_mode='on'. standby_mode='on' doesn't imply streaming replication. > > But i

Re: [HACKERS] Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL

On Thu, Feb 11, 2010 at 11:22 PM, Heikki Linnakangas wrote: > Simon Riggs wrote: >> Might it not be simpler to add a parameter onto pg_standby? >> We send %s to tell pg_standby the standby_mode of the server which is >> calling it so it can decide how to act in each case. > > That would work too,

Re: [HACKERS] Writeable CTEs and empty relations

On Fri, Feb 12, 2010 at 12:11 AM, Tom Lane wrote: > Robert Haas writes: >> This looks simple and useful.  I haven't tested it, but if it's really >> this easy, we should definitely do it. > > I should be out from under the window functions patch tomorrow, > will look at this one then. Cool, than

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

On Wed, Feb 10, 2010 at 6:04 PM, Kurt Harriman wrote: > By the way, suggestions which must be carried out without > question are "orders", not "advice".  When a statement, > meant to be imperative, is phrased softly as advice, it can > easily be mistaken as optional by newcomers who may not have >

Re: [HACKERS] Writeable CTEs and empty relations

Robert Haas writes: > This looks simple and useful. I haven't tested it, but if it's really > this easy, we should definitely do it. I should be out from under the window functions patch tomorrow, will look at this one then. regards, tom lane -- Sent via pgsql-hackers

Re: [HACKERS] Hostnames in pg_hba.conf

On 02/11/2010 09:38 PM, Euler Taveira de Oliveira wrote: Mark Mielke escreveu: Of course, then I'll ask for the ability to simplify specifying multiple databases: We already support multiple users and/or databases for a single pg_hba.conf line ... Is there a reason you trimmed

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

On Wed, Feb 10, 2010 at 5:53 PM, Kurt Harriman wrote: > Revised patch is attached (4th edition). This looks generally sane to me, though it seems entirely imaginable that it might break something, somewhere, for somebody... in which case I suppose we'll adjust as needed. Peter, are you planning

Re: [HACKERS] Writeable CTEs and empty relations

On Thu, Feb 11, 2010 at 12:35 PM, Marko Tiikkaja wrote: > On Thu, 11 Feb 2010 19:28:28 +0200, I wrote: >> On Thu, 11 Feb 2010 10:53:22 -0500, Robert Haas >> wrote: >>> On Thu, Feb 11, 2010 at 8:46 AM, Marko Tiikkaja >>> wrote: On 2010-02-11 03:44 +0200, I wrote: > I'm going to have to d

Re: [HACKERS] TCP keepalive support for libpq

On Fri, Feb 12, 2010 at 1:33 AM, Peter Geoghegan wrote: > Why hasn't libpq had keepalives for years? I guess that it's because keepalive doesn't work as expected in some cases. For example, if the network outage happens before a client sends some packets, keepalive doesn't work, then it would hav

Re: [HACKERS] Hostnames in pg_hba.conf

Mark Mielke escreveu: > Of course, then I'll ask for the ability to simplify specifying multiple > databases: > We already support multiple users and/or databases for a single pg_hba.conf line ... -- Euler Taveira de Oliveira http://www.timbira.com/ -- Sent via pgsql-hackers mailing list

Re: [HACKERS] psql tab completion for DO blocks

On Fri, Feb 12, 2010 at 12:21:02AM -0200, Euler Taveira de Oliveira wrote: > David Fetter escreveu: > > It's consistent with how we do CREATE FUNCTION, where the order of > > parameters after RETURNS is arbitrary. > > > If it is arbitrary the synopsis is wrong because it is imposing that > code sh

Re: [HACKERS] psql tab completion for DO blocks

David Fetter escreveu: > It's consistent with how we do CREATE FUNCTION, where the order of > parameters after RETURNS is arbitrary. > If it is arbitrary the synopsis is wrong because it is imposing that code should be written after DO. It should be: DO { [ LANGUAGE lang_name ] | code } ... --

Re: [HACKERS] psql tab completion for DO blocks

On Thu, Feb 11, 2010 at 11:26:10PM -0200, Euler Taveira de Oliveira wrote: > Takahiro Itagaki escreveu: > > Should we fix the documentation when we add the tab completion? > > > Yes, it seems consistent with other commands having optional > parameters in the middle of the command rather than at th

Re: [HACKERS] psql tab completion for DO blocks

On Fri, Feb 12, 2010 at 09:24:55AM +0900, Takahiro Itagaki wrote: > > David Fetter wrote: > > > > Syntax of DO command is: > > > DO code [ LANGUAGE lang_name ] > > > > That's not the only syntax. > > DO [LANGUAGE lang_name] code > > also works, e.g.: > > Hmmm, but we mention only above

Re: [HACKERS] Hostnames in pg_hba.conf

On 02/11/2010 05:12 PM, Bart Samwel wrote: On Thu, Feb 11, 2010 at 23:01, Mark Mielke > wrote: On 02/11/2010 04:54 PM, Bart Samwel wrote: ISSUE #3: Multiple hostnames? Currently, a pg_hba entry lists an IP / netmask combination. I would

Re: [HACKERS] Parameter name standby_mode

On Wed, Feb 10, 2010 at 8:16 PM, Heikki Linnakangas wrote: > If they want to implement the warm standby using the (new) built-in > logic to keep retrying restore_command, they would set > standby_mode='on'. standby_mode='on' doesn't imply streaming replication. But if we fail in restoring the arc

Re: [HACKERS] psql tab completion for DO blocks

Takahiro Itagaki escreveu: > Should we fix the documentation when we add the tab completion? > Yes, it seems consistent with other commands having optional parameters in the middle of the command rather than at the end. -- Euler Taveira de Oliveira http://www.timbira.com/ -- Sent via pgsq

Re: [HACKERS] review: More frame options in window functions

2010/2/12 Tom Lane : > The real question is whether it's time to bite the bullet and stop > overloading the opclass infrastructure for semantics-declaration > purposes.  Are there any other foreseeable cases where we are going > to need to add operator knowledge of this sort? Table partitioning wi

Re: [HACKERS] psql tab completion for DO blocks

David Fetter wrote: > > Syntax of DO command is: > > DO code [ LANGUAGE lang_name ] > > That's not the only syntax. > DO [LANGUAGE lang_name] code > also works, e.g.: Hmmm, but we mention only above syntax in the documentation. http://developer.postgresql.org/pgdocs/postgres/sql-do.htm

Re: [HACKERS] Confusion over Python drivers {license}

On Wed, 2010-02-10 at 23:13 -0500, Greg Smith wrote: > Until then, working apps have to > be the primary motivation for what to work on here, unless there's a > really terrible problem with the driver. The existing psycopg license > and the web site issues were in combination enough to reach th

Re: [HACKERS] review: More frame options in window functions

On Thu, Feb 11, 2010 at 4:31 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Feb 8, 2010 at 10:37 PM, Hitoshi Harada wrote: >>> 2010/2/9 Tom Lane : Given the lack of time remaining in this CF, I'm tempted to propose ripping out the RANGE support and just trying to get ROWS committ

Re: [HACKERS] log_error_verbosity function display

On Thu, Feb 11, 2010 at 5:47 PM, Bruce Momjian wrote: > Tom Lane wrote: >> Bruce Momjian writes: >> > Jaime Casanova wrote: >> >> i like this with or without the (), but maybe we are breaking client >> >> apps if change that >> >> > Ah, so you like FUNCTION. >> >> You can NOT change the line tag

Re: [GENERAL] [HACKERS] Bug on pg_lesslog

In addition, in the fix, I'm thinking I should add at least the following check mechanism; 1. Check XNOOP record size to match the original WAL record. 2. Restore WAL segment at the time of pg_compress, compare restored WAL with the original and check it is safe to use in the restoration, both eac

Re: [HACKERS] log_error_verbosity function display

Tom Lane wrote: > Bruce Momjian writes: > > Jaime Casanova wrote: > >> i like this with or without the (), but maybe we are breaking client > >> apps if change that > > > Ah, so you like FUNCTION. > > You can NOT change the line tag without almost certainly breaking > log-reading tools like pgfo

Re: [GENERAL] [HACKERS] Bug on pg_lesslog

Thank you very much for the advice. Yes I think it should go to announce. I will post a message. -- Koichi Suzuki 2010/2/12 Karl Denninger : > Joshua D. Drake wrote: > > On Thu, 2010-02-11 at 23:39 +0900, Koichi Suzuki wrote: > > > Dear Folks; > > A very serious bug was reported on p

Re: [HACKERS] Hostnames in pg_hba.conf

On Thu, Feb 11, 2010 at 23:01, Mark Mielke wrote: > On 02/11/2010 04:54 PM, Bart Samwel wrote: > > ISSUE #3: Multiple hostnames? >> >> Currently, a pg_hba entry lists an IP / netmask combination. I would >> suggest allowing lists of hostnames in the entries, so that you can at least >> mimic t

Re: [HACKERS] Hostnames in pg_hba.conf

On Thu, Feb 11, 2010 at 17:21, Tom Lane wrote: > Bart Samwel writes: > > I've been working on a patch to add hostname support to pg_hba.conf. > > Have you read the previous discussions about that? > Yes, mostly. The previous discussions included all sorts of complex stuff such as wildcards. Pe

Re: [HACKERS] Hostnames in pg_hba.conf

On 02/11/2010 04:54 PM, Bart Samwel wrote: On Thu, Feb 11, 2010 at 16:36, Mark Mielke > wrote: ISSUE #3: Multiple hostnames? Currently, a pg_hba entry lists an IP / netmask combination. I would suggest allowing lists of hostnames in the entries, so that

Re: [HACKERS] Hostnames in pg_hba.conf

On Thu, Feb 11, 2010 at 16:36, Mark Mielke wrote: > On 02/11/2010 08:13 AM, Bart Samwel wrote: > ISSUE #2: Reverse lookup? > > There was a suggestion on the TODO list on the wiki, which basically said > that maybe we could use reverse lookup to find "the" hostname and then check > for that hostn

Re: [HACKERS] knngist patch support

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Feb 11, 2010 at 03:19:14PM +0100, Dimitri Fontaine wrote: > Robert Haas writes: > > It seems that you're sort of frustrated with the system and the need > > to go through a process before committing a patch; > > I've been handling arround he

Re: [HACKERS] review: More frame options in window functions

Dimitri Fontaine writes: > Tom Lane writes: >> However, what it *is* associated with is a sort ordering, and the notion >> that btree opclasses are what define orderings is sufficiently deeply >> wired into the system that undoing it would be a huge PITA. So unless >> we can see a pretty clear f

Re: [HACKERS] review: More frame options in window functions

Tom Lane writes: > However, what it *is* associated with is a sort ordering, and the notion > that btree opclasses are what define orderings is sufficiently deeply > wired into the system that undoing it would be a huge PITA. So unless > we can see a pretty clear future need for more information

Re: [HACKERS] review: More frame options in window functions

Robert Haas writes: > On Mon, Feb 8, 2010 at 10:37 PM, Hitoshi Harada wrote: >> 2010/2/9 Tom Lane : >>> Given the lack of time remaining in this CF, I'm tempted to propose >>> ripping out the RANGE support and just trying to get ROWS committed. >>> That should be substantially less controversial

Re: [HACKERS] Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL

On Thu, 2010-02-11 at 19:29 +0200, Heikki Linnakangas wrote: > Aidan Van Dyk wrote: > > * Heikki Linnakangas [100211 09:17]: > > > >> Yeah, if you're careful about that, then this change isn't required. But > >> pg_standby protects against that, so I think it'd be reasonable to have > >> the same

Re: [HACKERS] review: More frame options in window functions

On Thu, 11 Feb 2010, Robert Haas wrote: On Thu, Feb 11, 2010 at 3:26 PM, Tom Lane wrote: Martijn van Oosterhout writes: On Tue, Feb 09, 2010 at 12:37:32PM +0900, Hitoshi Harada wrote: Now that specialized hard-coding "+"/"-" in source seems unacceptable, I would like to hear how to handle t

Re: [HACKERS] review: More frame options in window functions

Robert Haas writes: > On Thu, Feb 11, 2010 at 3:26 PM, Tom Lane wrote: >> The real question is whether it's time to bite the bullet and stop >> overloading the opclass infrastructure for semantics-declaration >> purposes.  Are there any other foreseeable cases where we are going >> to need to add

Re: [HACKERS] review: More frame options in window functions

On Thu, Feb 11, 2010 at 3:26 PM, Tom Lane wrote: > Martijn van Oosterhout writes: >> On Tue, Feb 09, 2010 at 12:37:32PM +0900, Hitoshi Harada wrote: >>> Now that specialized hard-coding "+"/"-" in source seems unacceptable, >>> I would like to hear how to handle this. Is there any better than >>>

Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while

Simon Riggs writes: > I understand that the final process to switch from one release to > another needs to be quick. Before that we can have any number of > preparatory steps. One of those is backup, if you're sane. Another one > should be a preparatory step that can be performed while the databas

Re: [HACKERS] psql tab completion for DO blocks

On Wed, Feb 10, 2010 at 11:00:00AM +0900, Takahiro Itagaki wrote: > Bruce Momjian wrote: > > > Where are we on this patch? We should at least implement the completion > > for 'LANGUAGE' in 'DO', and use the existing pg_language query for > > completion. I am attaching a patch that does exactly

Re: [HACKERS] review: More frame options in window functions

Martijn van Oosterhout writes: > On Tue, Feb 09, 2010 at 12:37:32PM +0900, Hitoshi Harada wrote: >> Now that specialized hard-coding "+"/"-" in source seems unacceptable, >> I would like to hear how to handle this. Is there any better than >> introducing new mechanism such like opclass? > I imagi

Re: [HACKERS] log_error_verbosity function display

Bruce Momjian writes: > Jaime Casanova wrote: >> i like this with or without the (), but maybe we are breaking client >> apps if change that > Ah, so you like FUNCTION. You can NOT change the line tag without almost certainly breaking log-reading tools like pgfouine. Even changing the content o

Re: [HACKERS] review: More frame options in window functions

On Tue, Feb 09, 2010 at 12:37:32PM +0900, Hitoshi Harada wrote: > I know "+"/"-" part is an issue. But as far as I know there's been no > infrastructure to handle such situation. My ideal plan is to introduce > some mechanism to make "+"/"-" operation abstract enough such like > sort opclass/opfami

Re: [HACKERS] [PATCH] Provide rowcount for utility SELECTs

Alvaro Herrera írta: > Robert Haas escribió: > >> On Thu, Feb 11, 2010 at 2:38 PM, Alvaro Herrera >> wrote: >> >>> Robert Haas escribió: >>> >>> I was all prepared to admit that I hadn't actually looked at the patch carefully enough, but I just looked at (and CVS HEAD) aga

Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while

Robert Haas escribió: > On Thu, Feb 11, 2010 at 2:46 PM, Alvaro Herrera > wrote: > > Robert Haas escribió: > > > >> I'm not quite sure how to do this in practice.  One idea would be to > >> record the catversion that created the relation in pg_class, and make > >> pg_upgrade preserve the catversio

Re: [HACKERS] [PATCH] Provide rowcount for utility SELECTs

Alvaro Herrera írta: > Boszormenyi Zoltan escribió: > >> Robert Haas írta: >> >>> ... >>> OK, please change it. >>> >>> >> New patch is attached with the discussed changes. >> > > This looks all wrong. PORTAL_ONE_SELECT is now being passed through > FillPortalStore, Where d

Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while

On Thu, Feb 11, 2010 at 2:46 PM, Alvaro Herrera wrote: > Robert Haas escribió: > >> I'm not quite sure how to do this in practice.  One idea would be to >> record the catversion that created the relation in pg_class, and make >> pg_upgrade preserve the catversion, but make CLUSTER or similar bump

Re: [HACKERS] [PATCH] Provide rowcount for utility SELECTs

On Thu, Feb 11, 2010 at 2:47 PM, Alvaro Herrera wrote: > Robert Haas escribió: >> On Thu, Feb 11, 2010 at 2:38 PM, Alvaro Herrera >> wrote: >> > Robert Haas escribió: >> > >> >> I was all prepared to admit that I hadn't actually looked at the patch >> >> carefully enough, but I just looked at (an

Re: [HACKERS] Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL

On Thu, Feb 11, 2010 at 01:22:44PM -0500, Kevin Grittner wrote: > Heikki Linnakangas wrote: > > > I think 'rsync' has the same problem. > > There is a switch you can use to create the problem under rsync, but > by default rsync copies to a temporary file name and moves the > completed file to

Re: [HACKERS] [PATCH] Provide rowcount for utility SELECTs

Robert Haas escribió: > On Thu, Feb 11, 2010 at 2:38 PM, Alvaro Herrera > wrote: > > Robert Haas escribió: > > > >> I was all prepared to admit that I hadn't actually looked at the patch > >> carefully enough, but I just looked at (and CVS HEAD) again and what > >> you've written here doesn't appe

Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while

Robert Haas escribió: > I'm not quite sure how to do this in practice. One idea would be to > record the catversion that created the relation in pg_class, and make > pg_upgrade preserve the catversion, but make CLUSTER or similar bump > it on successful completion. But I'm not sure if that cover

Re: [HACKERS] [PATCH] Provide rowcount for utility SELECTs

On Thu, Feb 11, 2010 at 2:38 PM, Alvaro Herrera wrote: > Robert Haas escribió: > >> I was all prepared to admit that I hadn't actually looked at the patch >> carefully enough, but I just looked at (and CVS HEAD) again and what >> you've written here doesn't appear to describe what I'm seeing in th

Re: [HACKERS] log_error_verbosity function display

On Thu, Feb 11, 2010 at 2:08 PM, Alvaro Herrera wrote: > Bruce Momjian wrote: > >> FYI, here is the output that had me confused: >> >>       ERROR:  42P01: relation "lkjasdf" does not exist at character 15 >>       LOCATION:  parserOpenTable, parse_relation.c:858 >>       STATEMENT:  select * from

Re: [HACKERS] log_error_verbosity function display

Jaime Casanova wrote: > On Thu, Feb 11, 2010 at 6:03 AM, Bruce Momjian wrote: > > > > Of course, maybe the word LOCATION is wrong and it should be FUNCTION: > > > > ? ? ? ?ERROR: ?42P01: relation "lkjasdf" does not exist at character 15 > > ? ? ? ?FUNCTION: ?parserOpenTable(), parse_relation.c:858

Re: [HACKERS] [PATCH] Provide rowcount for utility SELECTs

Robert Haas escribió: > I was all prepared to admit that I hadn't actually looked at the patch > carefully enough, but I just looked at (and CVS HEAD) again and what > you've written here doesn't appear to describe what I'm seeing in the > code: > > if ((portal->stra

Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while

On Thu, Feb 11, 2010 at 2:03 PM, Simon Riggs wrote: > On Thu, 2010-02-11 at 13:42 -0500, Robert Haas wrote: >> On Thu, Feb 11, 2010 at 1:33 PM, Simon Riggs wrote: >> > Avoiding a scan before running pg_upgrade is just a performance >> > optimisation. >> >> But using pg_upgrade AT ALL is also a pe

Re: [HACKERS] log_error_verbosity function display

Alvaro Herrera wrote: > Bruce Momjian wrote: > > > FYI, here is the output that had me confused: > > > > ERROR: 42P01: relation "lkjasdf" does not exist at character 15 > > LOCATION: parserOpenTable, parse_relation.c:858 > > STATEMENT: select * from lkjasdf; > > How about somethin

Re: [HACKERS] [PATCH] Provide rowcount for utility SELECTs

On Thu, Feb 11, 2010 at 2:04 PM, Alvaro Herrera wrote: > Boszormenyi Zoltan escribió: >> Robert Haas írta: >> > ... >> > OK, please change it. >> > >> >> New patch is attached with the discussed changes. > > This looks all wrong.  PORTAL_ONE_SELECT is now being passed through > FillPortalStore, wh

Re: [HACKERS] log_error_verbosity function display

On Thu, Feb 11, 2010 at 6:03 AM, Bruce Momjian wrote: > > Of course, maybe the word LOCATION is wrong and it should be FUNCTION: > >        ERROR:  42P01: relation "lkjasdf" does not exist at character 15 >        FUNCTION:  parserOpenTable(), parse_relation.c:858 >        STATEMENT:  select * fro

Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while

Simon Riggs writes: > Avoiding a scan before running pg_upgrade is just a performance > optimisation. I don't think we should be optimising an upgrade in this > way, especially since sane people do database backups before upgrade > anyway. The optimisation is misplaced. The fact that we are active

Re: [HACKERS] log_error_verbosity function display

Bruce Momjian wrote: > FYI, here is the output that had me confused: > > ERROR: 42P01: relation "lkjasdf" does not exist at character 15 > LOCATION: parserOpenTable, parse_relation.c:858 > STATEMENT: select * from lkjasdf; How about something like ERROR: 42P01: relation "l

Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while

On Thu, 2010-02-11 at 13:42 -0500, Robert Haas wrote: > On Thu, Feb 11, 2010 at 1:33 PM, Simon Riggs wrote: > > Avoiding a scan before running pg_upgrade is just a performance > > optimisation. > > But using pg_upgrade AT ALL is also a performance optimization; in > fact AFAICS it's the only reas

Re: [HACKERS] [PATCH] Provide rowcount for utility SELECTs

Boszormenyi Zoltan escribió: > Robert Haas írta: > > ... > > OK, please change it. > > > > New patch is attached with the discussed changes. This looks all wrong. PORTAL_ONE_SELECT is now being passed through FillPortalStore, which runs it to completion, whereas it was previously passed via P

Re: [HACKERS] [PATCH] Provide rowcount for utility SELECTs

On Mon, Feb 8, 2010 at 5:53 AM, Boszormenyi Zoltan wrote: > New patch is attached with the discussed changes. This looks OK to me now, but it lacks docs. I'll set it to Waiting on Author. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your s

Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while

On Thu, Feb 11, 2010 at 1:33 PM, Simon Riggs wrote: > Avoiding a scan before running pg_upgrade is just a performance > optimisation. But using pg_upgrade AT ALL is also a performance optimization; in fact AFAICS it's the only reason to use pg_upgrade. So if you take that away there's no reason

Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while

On Thu, 2010-02-11 at 11:27 -0500, Tom Lane wrote: > Simon Riggs writes: > > You still have to perform a backup of the database prior to upgrade and > > that also must scan the whole database, so the overall time to upgrade > > will still vary according to database size. So I don't see any overall

Re: [HACKERS] TCP keepalive support for libpq

]] Robert Haas | I've sometimes wondered why keepalives aren't the default for all TCP | connections. They seem like they're usually a Good Thing (TM), but I | wonder if we can think of any situations where someone might not want | them? As somebody mentioned somewhere else (I think): If you pa

Re: [HACKERS] Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL

Heikki Linnakangas wrote: > I think 'rsync' has the same problem. There is a switch you can use to create the problem under rsync, but by default rsync copies to a temporary file name and moves the completed file to the target name. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hack

Re: [HACKERS] Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL

On Thu, 2010-02-11 at 13:08 -0500, Tom Lane wrote: > Heikki Linnakangas writes: > > -1. it isn't necessary for PITR. It's a new requirement for > > standby_mode='on', unless we add the file size check into the backend. I > > think we should add the file size check to the backend instead and save >

Re: [HACKERS] Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL

Aidan Van Dyk wrote: > * Heikki Linnakangas [100211 12:04]: > >>> But it can be a problem - without the last WAL (or at least enough of >>> it) the master switched and archived, you have no guarantee of having >>> being consistent again (I'm thinking specifically of recovering from a >>> fresh ba

Re: [HACKERS] Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL

Heikki Linnakangas writes: > -1. it isn't necessary for PITR. It's a new requirement for > standby_mode='on', unless we add the file size check into the backend. I > think we should add the file size check to the backend instead and save > admins the headache. I think the file size check needs to

Re: [GENERAL] [HACKERS] Bug on pg_lesslog

Joshua D. Drake wrote: > On Thu, 2010-02-11 at 23:39 +0900, Koichi Suzuki wrote: > >> Dear Folks; >> >> A very serious bug was reported on pg_lesslog. So far, I found it's >> a bug in pg_compresslog. Please do not use pg_compresslog and >> pg_decompresslog until improved version is uploaded.

Re: [HACKERS] a common place for pl/perlu modules

On Feb 11, 2010, at 7:07 PM, Andrew Dunstan wrote: > > > Alexey Klyukin wrote: >> On Feb 11, 2010, at 6:24 PM, Andrew Dunstan wrote: >> >> >>> Alexey Klyukin wrote: >>> Hello, When developing pl/perlu functions common definitions and methods are often stored in exte

Re: [HACKERS] Writeable CTEs and empty relations

On Thu, 11 Feb 2010 19:28:28 +0200, I wrote: > On Thu, 11 Feb 2010 10:53:22 -0500, Robert Haas > wrote: >> On Thu, Feb 11, 2010 at 8:46 AM, Marko Tiikkaja >> wrote: >>> On 2010-02-11 03:44 +0200, I wrote: I'm going to have to disappoint a bunch of people and give up. :-( >>> >>> Btw. would i

Re: [HACKERS] Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL

* Heikki Linnakangas [100211 12:04]: > > But it can be a problem - without the last WAL (or at least enough of > > it) the master switched and archived, you have no guarantee of having > > being consistent again (I'm thinking specifically of recovering from a > > fresh backup) > > You have to wa

Re: [HACKERS] Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL

Aidan Van Dyk wrote: > * Heikki Linnakangas [100211 09:17]: > >> Yeah, if you're careful about that, then this change isn't required. But >> pg_standby protects against that, so I think it'd be reasonable to have >> the same level of protection built-in. It's not a lot of code. > > This 1 check

Re: [HACKERS] Writeable CTEs and empty relations

On Thu, 11 Feb 2010 10:53:22 -0500, Robert Haas wrote: > On Thu, Feb 11, 2010 at 8:46 AM, Marko Tiikkaja > wrote: >> On 2010-02-11 03:44 +0200, I wrote: >>> I'm going to have to disappoint a bunch of people and give up. :-( >> >> Btw. would it make sense to apply the WITH-on-top-of-DML part of th

Re: [HACKERS] Bug on pg_lesslog

On Thu, 2010-02-11 at 23:39 +0900, Koichi Suzuki wrote: > Dear Folks; > > A very serious bug was reported on pg_lesslog. So far, I found it's > a bug in pg_compresslog. Please do not use pg_compresslog and > pg_decompresslog until improved version is uploaded. > > I strongly advise to take ba

Re: [HACKERS] TCP keepalive support for libpq

On Thu, 11 Feb 2010, Andrew Chernow wrote: Although, I think Dave's comments have made me change my mind about this patch. Looks like it serves a good purpose. That said, there is no guarentee the driver will implement the new feature ... JDBC seems to lack the ability to get the backing

Re: [HACKERS] TCP keepalive support for libpq

Also, more importantly (from http://www.slony.info/documentation/slonyadmin.html): "A WAN outage (or flakiness of the WAN in general) can leave database connections "zombied", and typical TCP/IP behaviour will allow those connections to persist, preventing a slon restart for around two hours. "

Re: [HACKERS] Confusion over Python drivers

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 >>The solution is to write the query in an unambiguous way: >> >> SELECT $1::date + 1; >> >>which is good practice, anyway. If it's not obvious to the type >>inference system, it's probably not obvious to you, and will probably >>surprise you ;

Re: [HACKERS] a common place for pl/perlu modules

Alexey Klyukin wrote: On Feb 11, 2010, at 6:24 PM, Andrew Dunstan wrote: Alexey Klyukin wrote: Hello, When developing pl/perlu functions common definitions and methods are often stored in external .pm modules. During deployment the modules should be installed somewhere in @INC to

Re: [HACKERS] Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL

Aidan Van Dyk wrote: > * Heikki Linnakangas [100211 09:17]: > >> If the file is just being copied to the archive when restore_command >> ('cp', say) is launched, it will copy a half file. That's not a problem >> for PITR, because PITR will end at the end of valid WAL anyway, but >> returning a ha

Re: [HACKERS] TCP keepalive support for libpq

"Kevin Grittner" writes: > those people who create 2000 lightly used connections to the > database might feel differently. Yeah I still run against installation using the infamous PHP pconnect() function. You certainly don't want to add some load there, but that could urge them into arranging for

Re: [HACKERS] knngist patch support

On Thu, 11 Feb 2010, Oleg Bartunov wrote: On Thu, 11 Feb 2010, Tom Lane wrote: My own feeling about it is that I much preferred the original proposal of a contrib module with little or no change to core code. I don't want to be changing core code for this at this late hour. If it were only t

Re: [HACKERS] a common place for pl/perlu modules

On Feb 11, 2010, at 6:24 PM, Andrew Dunstan wrote: > > > Alexey Klyukin wrote: >> Hello, >> >> When developing pl/perlu functions common definitions and methods are often >> stored in external .pm modules. During deployment the modules should be >> installed somewhere in @INC to be reachable

Re: [HACKERS] Avoiding bad prepared-statement plans.

2010/2/11 Tom Lane : > Robert Haas writes: >> On Thu, Feb 11, 2010 at 7:48 AM, Bart Samwel wrote: >>> Because that's the >>> underlying assumption of the "ratio" criterion -- that re-planning with >>> filled-in parameters takes about as much time as the initial planning run >>> took. > >> We only

Re: [HACKERS] TCP keepalive support for libpq

Robert Haas wrote: On Thu, Feb 11, 2010 at 2:15 AM, Tollef Fog Heen wrote: ]] daveg | I disagree. I have clients who have problems with leftover client connections | due to server host failures. They do not write apps in C. For a non-default | change to be effective we would need to have all t

Re: [HACKERS] TCP keepalive support for libpq

>From the Slony-I docs (http://www.slony.info/documentation/faq.html) : "Supposing you experience some sort of network outage, the connection between slon and database may fail, and the slon may figure this out long before the PostgreSQL instance it was connected to does. The result is that there

[HACKERS] Bug on pg_lesslog

Dear Folks; A very serious bug was reported on pg_lesslog. So far, I found it's a bug in pg_compresslog. Please do not use pg_compresslog and pg_decompresslog until improved version is uploaded. I strongly advise to take base backup of your database. I apologize for inconvenience. I'll upl

Re: [HACKERS] TCP keepalive support for libpq

Robert Haas wrote: > I've sometimes wondered why keepalives aren't the default for all > TCP connections. They seem like they're usually a Good Thing > (TM), but I wonder if we can think of any situations where someone > might not want them? I think it's insane not to use them at all, but the

Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while

Simon Riggs writes: > You still have to perform a backup of the database prior to upgrade and > that also must scan the whole database, so the overall time to upgrade > will still vary according to database size. So I don't see any overall > benefit, just risk, and I cited a similar situation wher

  1   2   >