Re: [HACKERS] [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

2010/1/31 KaiGai Kohei : > The attached patch modified find_all_inheritors() to return the list of > expected inhcount, if List * pointer is given. And, it focuses on only > the bugs in renameatt() case. I have cleaned up and simplified this patch. Attached is the version I intend to commit. Cha

Re: [HACKERS] contrib\xml2 package's xpath_table function in PostgreSQL

Is there a way to fix it so that those functions are usable in 8.4 without crashing the server? Thanks, M Z On Mon, Feb 1, 2010 at 10:50 AM, Robert Haas wrote: > The functions haven't actually been removed in 8.4, in spite of the > deprecation notice. But it's very easy to use them in a way th

Re: [HACKERS] plpython3

On Sat, Jan 23, 2010 at 3:28 PM, James William Pye wrote: > On Jan 14, 2010, at 7:08 PM, Greg Smith wrote: >> So more targeted examples like you're considering now would help. > > Here's the trigger example which should help reveal some of the advantages of > "native typing". This is a generic tr

Re: [HACKERS] contrib\xml2 package's xpath_table function in PostgreSQL

On Mon, Feb 1, 2010 at 1:20 PM, M Z wrote: > Is there a way to fix it so that those functions are usable in 8.4 without > crashing the server? Nobody seems to be interested enough to figure that out and submit a patch to fix it. If someone does, I think it would have a good chance of being accep

Re: [HACKERS] remove contrib/xml2

On Thu, Jan 28, 2010 at 5:41 PM, Tom Lane wrote: > Andrew Dunstan writes: >> Robert Haas wrote: >>> I think we need to either (1) fix the bugs and update the >>> documentation to remove the statement that this will be removed or (2) >>> actually remove it. > >> I agree it's a mess but I don't thi

Re: [HACKERS] plpython3

On Mon, 2010-02-01 at 13:20 -0500, Robert Haas wrote: > On the basis of all of the foregoing, I don't think we can consider > this patch further for this CommitFest and will update > commitfest.postgresql.org accordingly. If the user community grows or > if one of the committers takes an interest

Re: [HACKERS] [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

Robert Haas writes: > I have cleaned up and simplified this patch. Attached is the version > I intend to commit. Changes: Minor suggestions: I think the names like "rel_parents" would read better as "rel_numparents" etc. As-is, the reader could be forgiven for expecting that this will be a li

Re: [HACKERS] remove contrib/xml2

Robert Haas writes: > My feeling is that if it's as flakey and unreliable as it currently > is, we shouldn't ship it. Removing it from CVS doesn't mean "you > can't use this any more"; this is open source. It just means people > will have to go and get an old copy out of CVS and presumably in so

Re: [HACKERS] plpython3

On Mon, Feb 1, 2010 at 1:29 PM, Joshua D. Drake wrote: > On Mon, 2010-02-01 at 13:20 -0500, Robert Haas wrote: >> On the basis of all of the foregoing, I don't think we can consider >> this patch further for this CommitFest and will update >> commitfest.postgresql.org accordingly.  If the user com

Re: [HACKERS] [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

On Mon, Feb 1, 2010 at 1:31 PM, Tom Lane wrote: > Robert Haas writes: >> I have cleaned up and simplified this patch.  Attached is the version >> I intend to commit.  Changes: > > Minor suggestions: > > I think the names like "rel_parents" would read better as > "rel_numparents" etc.  As-is, the

Re: [HACKERS] remove contrib/xml2

On Mon, Feb 1, 2010 at 1:38 PM, Tom Lane wrote: > Robert Haas writes: >> My feeling is that if it's as flakey and unreliable as it currently >> is, we shouldn't ship it.  Removing it from CVS doesn't mean "you >> can't use this any more"; this is open source.  It just means people >> will have to

Re: [HACKERS] mailing list archiver chewing patches

2010/2/1 Robert Haas : > On Mon, Feb 1, 2010 at 11:41 AM, Tom Lane wrote: >> Robert Haas writes: >>> On Mon, Feb 1, 2010 at 11:28 AM, Tom Lane wrote:        * A sends a message        * B replies, cc'ing A and the list        * B's reply to list is delayed by greylisting    

Re: [HACKERS] plpython3

Robert Haas writes: > To recap the votes I've seen on this thread and elsewhere: > - JD is very enthusiastic about this patch > - So is the OP > - Josh Berkus and I are both dubious about having two in-core PL/pythons > - Peter Eisentraut prefers the original implementation > - Greg Smith thinks

Re: [HACKERS] [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

On Mon, Feb 1, 2010 at 1:40 PM, Robert Haas wrote: >> Looks sane otherwise. > > Thanks for the review. Oh, one other thing. Should we backpatch this, or just apply to HEAD? ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: ht

Re: [HACKERS] plpython3

Tom Lane escribió: > The first thought that comes to mind is "plpythonng", following a > tradition established by the tcl client rewrite among others ... but > that double n doesn't read very well. plpythoNG perhaps? -- Alvaro Herrerahttp://www.CommandPrompt.com/

Re: [HACKERS] plpython3

On Mon, Feb 1, 2010 at 2:00 PM, Alvaro Herrera wrote: > Tom Lane escribió: > >> The first thought that comes to mind is "plpythonng", following a >> tradition established by the tcl client rewrite among others ... but >> that double n doesn't read very well. > > plpythoNG perhaps? ROFL. It's a s

Re: [HACKERS] Pathological regexp match

On Jan 31, 2010, at 22:14 , Tom Lane wrote: The Tcl folk accepted that patch, so I went ahead and applied it to our code. It would still be a good idea for us to do any testing we can on it, though. I applied the patch and ran both the test query I submitted as well as original problematic

Re: [HACKERS] [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

Robert Haas writes: > Oh, one other thing. Should we backpatch this, or just apply to HEAD? Just HEAD imo. Without any complaints from the field, I don't think it's worth taking any risks for. It's not like multiple inheritance is heavily used ... regards, tom lane --

Re: [HACKERS] plpython3

On Feb 1, 2010, at 10:53 AM, Tom Lane wrote: > The first thought that comes to mind is "plpythonng", following a > tradition established by the tcl client rewrite among others ... but > that double n doesn't read very well. And without it, you have a thong. Who's going to wear that? Best, David

Re: [HACKERS] plpython3

On Feb 1, 2010, at 11:29 AM, Joshua D. Drake wrote: > On Mon, 2010-02-01 at 13:20 -0500, Robert Haas wrote: > >> On the basis of all of the foregoing, I don't think we can consider >> this patch further for this CommitFest and will update >> commitfest.postgresql.org accordingly. If the user com

Re: [HACKERS] Hot Standby: Relation-specific deferred conflict resolution

On Fri, 2010-01-29 at 15:01 +, Simon Riggs wrote: > Putting it back takes time and > given enough of that rare cloth, it will eventually be put back. Looks like I'll have time to add the starts-at-shutdown-checkpoint item back in after all. I'd appreciate it if you could review the relation-

Re: [HACKERS] [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

On Mon, Feb 1, 2010 at 2:03 PM, Tom Lane wrote: > Robert Haas writes: >> Oh, one other thing.  Should we backpatch this, or just apply to HEAD? > > Just HEAD imo.  Without any complaints from the field, I don't think > it's worth taking any risks for.  It's not like multiple inheritance > is heav

Re: [HACKERS] plpython3

> On the basis of all of the foregoing, I don't think we can consider > this patch further for this CommitFest and will update > commitfest.postgresql.org accordingly. FWIW, I am very excited about this patch and would be happy to review it but have been very busy over the past month. If I can pro

Re: [HACKERS] plpython3

On Mon, 2010-02-01 at 12:01 -0800, Nathan Boley wrote: > > On the basis of all of the foregoing, I don't think we can consider > > this patch further for this CommitFest and will update > > commitfest.postgresql.org accordingly. > > FWIW, I am very excited about this patch and would be happy to re

Re: [HACKERS] plpython3

On Mon, Feb 1, 2010 at 3:01 PM, Nathan Boley wrote: >> On the basis of all of the foregoing, I don't think we can consider >> this patch further for this CommitFest and will update >> commitfest.postgresql.org accordingly. > > FWIW, I am very excited about this patch and would be happy to review >

Re: [HACKERS] Hot Standby and VACUUM FULL

I wrote: > The design I sketched doesn't require such an assumption anyway. Once > the map file is written, the relocation is effective, commit or no. > As long as we restrict relocations to maintenance operations such as > VACUUM FULL, which have no transactionally significant results, this > doe

Re: [HACKERS] plpython3

> I think it would be great for you to review it... I doubt that will > cause it to get committed for 9.0, but my doubt is no reason for you > to hold off reviewing it. I assumed so, but the pretense of a chance will probably help to motivate me :-) I'll have something by Thursday, and then 'Retu

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

2010/1/12 Boszormenyi Zoltan : > Tom Lane írta: >> Alvaro Herrera writes: >> >>> But it would be broken in very obvious ways, no?  It's not like it would >>> be silently broken and thus escape testing ... >>> >> >> Well, if we wanted to adopt that approach, we should add the count to >> *all* SELE

Re: [HACKERS] plpython3

On mån, 2010-02-01 at 12:01 -0800, Nathan Boley wrote: > I code nearly exclusively in python and C, but I have > often found pl/python to be very unwieldy. For this reason I often > use pl/perl or pl/pgsql for problems that, outside of postgres, I > would always use python. I find that curious, b

Re: [HACKERS] plpython3

On Mon, 2010-02-01 at 22:35 +0200, Peter Eisentraut wrote: > On mån, 2010-02-01 at 12:01 -0800, Nathan Boley wrote: > > I code nearly exclusively in python and C, but I have > > often found pl/python to be very unwieldy. For this reason I often > > use pl/perl or pl/pgsql for problems that, outsid

Re: [HACKERS] plpython3

Peter Eisentraut escribió: > On mån, 2010-02-01 at 12:01 -0800, Nathan Boley wrote: > > I code nearly exclusively in python and C, but I have > > often found pl/python to be very unwieldy. For this reason I often > > use pl/perl or pl/pgsql for problems that, outside of postgres, I > > would alway

Re: [HACKERS] plpython3

Alvaro Herrera wrote: > Peter Eisentraut escribi?: > > On m?n, 2010-02-01 at 12:01 -0800, Nathan Boley wrote: > > > I code nearly exclusively in python and C, but I have > > > often found pl/python to be very unwieldy. For this reason I often > > > use pl/perl or pl/pgsql for problems that, outsid

Re: [HACKERS] plpython3

On Mon, 2010-02-01 at 16:13 -0500, Bruce Momjian wrote: > Alvaro Herrera wrote: > > Peter Eisentraut escribi?: > > > On m?n, 2010-02-01 at 12:01 -0800, Nathan Boley wrote: > > > > I code nearly exclusively in python and C, but I have > > > > often found pl/python to be very unwieldy. For this reas

Re: [HACKERS] plpython3

Joshua D. Drake wrote: > On Mon, 2010-02-01 at 16:13 -0500, Bruce Momjian wrote: > > Alvaro Herrera wrote: > > > Peter Eisentraut escribi?: > > > > On m?n, 2010-02-01 at 12:01 -0800, Nathan Boley wrote: > > > > > I code nearly exclusively in python and C, but I have > > > > > often found pl/python

[HACKERS] Make TOAST_TUPLES_PER_PAGE configurable per table.

Hi This is my first attempt to hack PostgreSQL (even C actually), so bear over with obvious mistakes done. I've had a wish to be able to teach Postgres a bit more about how to store its data on disk. Our systems is a typical web-based system where all access more or less can be devided into 2 cat

Re: [HACKERS] plpython3

On Mon, 2010-02-01 at 16:31 -0500, Bruce Momjian wrote: > > > > I would love to know why PL/Python can't be incrementally improved like > > > the rest of our code. > > > > It has been. That is exactly what PeterE has been doing. > > > > However, if you look at this whole thread, you will see th

Re: [HACKERS] plpython3

On Feb 1, 2010, at 2:13 PM, Bruce Momjian wrote: > I would love to know why PL/Python can't be incrementally improved like > the rest of our code. AFAICT, there are two primary, perhaps identifying, parts to a PL extension: code management (compilation, execution, etc) and type I/O (conversion in

Re: [HACKERS] plpython3

On 2/1/10 1:39 PM, Joshua D. Drake wrote: > On Mon, 2010-02-01 at 16:31 -0500, Bruce Momjian wrote: >> I would love to know why PL/Python can't be incrementally improved like the rest of our code. >>> It has been. That is exactly what PeterE has been doing. >>> >>> However, if you look

Re: [HACKERS] plpython3

On Mon, Feb 1, 2010 at 4:30 PM, Joshua D. Drake wrote: > On Mon, 2010-02-01 at 16:13 -0500, Bruce Momjian wrote: >> Alvaro Herrera wrote: >> > Peter Eisentraut escribi?: >> > > On m?n, 2010-02-01 at 12:01 -0800, Nathan Boley wrote: >> > > > I code nearly exclusively in python and C, but I have >>

Re: [HACKERS] remove contrib/xml2

Robert Haas wrote: (2) add a very, very large warning that this will crash if you do almost anything with it. I think that's an exaggeration. Certain people are known to be using it quite successfully. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or

[HACKERS] Database-Role settings behaviour and docs mismatch

In the docs it says "It is also possible to tie a session default to a specific database rather than to a role; see ALTER DATABASE. If there is a conflict, database-role-specific settings override role-specific ones, which in turn override database-specific ones." Whereas in process_settings() th

Re: [HACKERS] plpython3

On Feb 1, 2010, at 1:23 PM, Nathan Boley wrote: >> I think it would be great for you to review it... I doubt that will >> cause it to get committed for 9.0, but my doubt is no reason for you >> to hold off reviewing it. > > I assumed so, but the pretense of a chance will probably help to motivate

Re: [HACKERS] Database-Role settings behaviour and docs mismatch

Simon Riggs wrote: > Whereas in process_settings() the sequence is this > > ApplySetting(databaseid, roleid, relsetting, PGC_S_DATABASE_USER); > ApplySetting(InvalidOid, roleid, relsetting, PGC_S_USER); > ApplySetting(databaseid, InvalidOid, relsetting, PGC_S_DATABASE); > > which looks to me lik

Re: [HACKERS] Database-Role settings behaviour and docs mismatch

On Mon, 2010-02-01 at 20:11 -0300, Alvaro Herrera wrote: > It'd probably be worth changing the order of the ApplySetting calls so > that it doesn't look suspicious. Just a comment would be enough I think on ApplySetting to make it clear that it really means ApplySettingIfNotAlreadySet() -- Sim

Re: [HACKERS] development setup and libdir

On Sun, 31 Jan 2010 22:24:40 + Mark Cave-Ayland wrote: > Ivan Sergio Borgonovo wrote: > > > Of course I can write a script that can workaround this. > > It seems that the only thing missing is that pgxs 8.3 used to > > prefix .so with lib and then rename them at install time, but > > pgxs 8.

Re: [HACKERS] Database-Role settings behaviour and docs mismatch

Simon Riggs writes: > On Mon, 2010-02-01 at 20:11 -0300, Alvaro Herrera wrote: >> It'd probably be worth changing the order of the ApplySetting calls so >> that it doesn't look suspicious. > Just a comment would be enough I think Yeah. Changing the order would mean that we'd do extra work apply

Re: [HACKERS] Make TOAST_TUPLES_PER_PAGE configurable per table.

Jesper Krogh writes: > This patch enables users to set TOAST_TUPLES_PER_PAGE with > ALTER TABLE SET (tuples_per_page = X); .. currently with 1 <= X > <= 32; It's not clear to me that fiddling with that is useful unless the toast tuple size also changes; and unfortunately changing that is much ha

Re: [HACKERS] Largeobject Access Controls (r2460)

KaiGai Kohei wrote: > > Can we remove such path and raise an error instead? > > Also, even if we support the older servers in the routine, > > the new bytea format will be another problem anyway. > > OK, I'll fix it. I think we might need to discuss about explicit version checks in pg_restore.

Re: [HACKERS] New VACUUM FULL crashes on temp relations

Simon Riggs wrote: > TRAP: FailedAssertion("!(typeNamespace == typ->typnamespace)", File: > "pg_type.c", Line: 658) > > Test case attached, repeated, consistent failure on CVS HEAD. I see the same assertion failure on 8.4.2, too. I'll investigating it... -- minimum reproducible pattern drop t

Re: [HACKERS] [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

(2010/02/02 3:01), Robert Haas wrote: > 2010/1/31 KaiGai Kohei: >> The attached patch modified find_all_inheritors() to return the list of >> expected inhcount, if List * pointer is given. And, it focuses on only >> the bugs in renameatt() case. > > I have cleaned up and simplified this patch. At

Re: [HACKERS] remove contrib/xml2

On Mon, Feb 1, 2010 at 5:23 PM, Andrew Dunstan wrote: > Robert Haas wrote: >> (2) add a very, very large warning that this will crash if you do >> almost anything with it. > > I think that's an exaggeration. Certain people are known to be using it > quite successfully. Hmm. Well, all I know is t

Re: [HACKERS] [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

(2010/02/02 9:48), KaiGai Kohei wrote: >>> Also, the ALTER COLUMN TYPE case should be also fixed in the 9.1 release >>> (or 9.0.1?). >> >> If the fix is something we could commit for 9.0.1, then we ought to do >> it now before 9.0 is released. If you want to submit a follow-on >> patch to address

Re: [HACKERS] Largeobject Access Controls (r2460)

(2010/02/02 9:33), Takahiro Itagaki wrote: > > KaiGai Kohei wrote: > >>> Can we remove such path and raise an error instead? >>> Also, even if we support the older servers in the routine, >>> the new bytea format will be another problem anyway. >> >> OK, I'll fix it. > > I think we might need t

Re: [HACKERS] contrib\xml2 package's xpath_table function in PostgreSQL

I am very interested in doing it. However I am new to postgresql. Could you and anyone here please give me some hint, which way I should, which part of code I should focus to fix it? Thanks, M Z On Mon, Feb 1, 2010 at 1:23 PM, Robert Haas wrote: > On Mon, Feb 1, 2010 at 1:20 PM, M Z wrote: > >

Re: [HACKERS] [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

KaiGai Kohei writes: > The attached one also clean up ATPrepAddColumn() and ATExecAddColumn() code, > not only ATPrepAlterColumnType(), according to what I mentioned above. What exactly do you claim is wrong with the ADD COLUMN case? regards, tom lane -- Sent via pgsql-

Re: [HACKERS] [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

(2010/02/02 11:09), Tom Lane wrote: > KaiGai Kohei writes: >> The attached one also clean up ATPrepAddColumn() and ATExecAddColumn() code, >> not only ATPrepAlterColumnType(), according to what I mentioned above. > > What exactly do you claim is wrong with the ADD COLUMN case? ADD COLUMN case wo

Re: [HACKERS] [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

2010/2/1 KaiGai Kohei : > (2010/02/02 11:09), Tom Lane wrote: >> KaiGai Kohei  writes: >>> The attached one also clean up ATPrepAddColumn() and ATExecAddColumn() code, >>> not only ATPrepAlterColumnType(), according to what I mentioned above. >> >> What exactly do you claim is wrong with the ADD CO

Re: [HACKERS] [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

KaiGai Kohei writes: > (2010/02/02 11:09), Tom Lane wrote: >> KaiGai Kohei writes: >>> The attached one also clean up ATPrepAddColumn() and ATExecAddColumn() code, >>> not only ATPrepAlterColumnType(), according to what I mentioned above. >> >> What exactly do you claim is wrong with the ADD COL

Re: [HACKERS] [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

(2010/02/02 11:31), Robert Haas wrote: > 2010/2/1 KaiGai Kohei: >> (2010/02/02 11:09), Tom Lane wrote: >>> KaiGai Koheiwrites: The attached one also clean up ATPrepAddColumn() and ATExecAddColumn() code, not only ATPrepAlterColumnType(), according to what I mentioned above. >>>

Re: [HACKERS] [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

2010/2/1 KaiGai Kohei : > (2010/02/02 11:31), Robert Haas wrote: >> 2010/2/1 KaiGai Kohei: >>> (2010/02/02 11:09), Tom Lane wrote: KaiGai Kohei    writes: > The attached one also clean up ATPrepAddColumn() and ATExecAddColumn() > code, > not only ATPrepAlterColumnType(), according

Re: [HACKERS] Package namespace and Safe init cleanup for plperl UPDATE 3 [PATCH]

On Mon, Feb 1, 2010 at 03:58, Tim Bunce wrote: > On Sat, Jan 30, 2010 at 06:38:59PM -0700, Alex Hunsaker wrote: > >> plc_safe_ok.pl seems to loose its CVS $PostgreSQL$ keyword. >Probably a slip-up when I merged the changes from HEAD up through my >chain of branches. Can you send an updated patch?

Re: [HACKERS] [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

(2010/02/02 11:44), Robert Haas wrote: > 2010/2/1 KaiGai Kohei: >> (2010/02/02 11:31), Robert Haas wrote: >>> 2010/2/1 KaiGai Kohei: (2010/02/02 11:09), Tom Lane wrote: > KaiGai Kohei writes: >> The attached one also clean up ATPrepAddColumn() and ATExecAddColumn() >> code, >

Re: [HACKERS] PITR - Bug or feature?

Hi, On Mon, Feb 1, 2010 at 7:33 PM, Rafael Martinez wrote: > The PITR backup history file named > pg_xlog/00010038.0020.backup included this information: > > START WAL LOCATION: 38/20 (file 00010038) > ST

[HACKERS] Re: [COMMITTERS] pgsql: Write a WAL record whenever we perform an operation without

On Mon, Feb 1, 2010 at 7:40 PM, Heikki Linnakangas wrote: > So you get those messages when the table is *not* a temporary table. I > can see now what Fujii was trying to say. His patch seems Ok, though > perhaps it would be better to move the responsibility of calling > XLogReportUnloggedStatement

Re: [HACKERS] Largeobject Access Controls (r2460)

>>> The --schema-only with large objects might be unnatural, but the >>> --data-only with properties of large objects are also unnatural. >>> Which behavior is more unnatural? >> >> I think large object metadata is a kind of row-based access controls. >> How do we dump and restore ACLs per rows whe

Re: [HACKERS] New VACUUM FULL crashes on temp relations

Takahiro Itagaki wrote: > > TRAP: FailedAssertion("!(typeNamespace == typ->typnamespace)", File: > > "pg_type.c", Line: 658) It comes from swapping toast relations: DEBUG: typeNamespace mismatch: 99 (pg_toast) vs. 16386 (pg_toast_temp_2) AFAICS, the assertion is broken, but the code is corr

Re: [HACKERS] Make TOAST_TUPLES_PER_PAGE configurable per table.

Tom Lane wrote: > Jesper Krogh writes: >> This patch enables users to set TOAST_TUPLES_PER_PAGE with >> ALTER TABLE SET (tuples_per_page = X); .. currently with 1 <= X >> <= 32; > > It's not clear to me that fiddling with that is useful unless the toast > tuple size also changes; and unfortunate

Re: [HACKERS] Largeobject Access Controls (r2460)

(2010/02/01 14:19), Takahiro Itagaki wrote: > As far as I read, the patch is almost ready to commit > except the following issue about backward compatibility: > >> * "BLOB DATA" >> This section is same as existing "BLOBS" section, except for _LoadBlobs() >> does not create a new large object befor

Re: [HACKERS] Hot Standby and deadlock detection

Simon Riggs wrote: > The way this would work is if Startup waits on a buffer pin we > immediately send out a request to all backends to cancel themselves if > they are holding the buffer pin required && waiting on a lock. We then > sleep until max_standby_delay. When max_standby_delay = -1 we only

Re: [HACKERS] Hot Standby and VACUUM FULL

Tom Lane wrote: > Hm ... do we want an LWLock per map file, or is one lock to rule them all > sufficient? LWLock per database seems problematic. With an HW lock there > wouldn't be a problem with that. HW lock would allow concurrent updates of > the map files of different DBs, but is that worth

Re: [HACKERS] mailing list archiver chewing patches

On 01/02/2010 03:27, Alvaro Herrera wrote: Matteo Beccati wrote: Incidentally, I've just found out that the mailing lists are dropping some messages. According to my qmail logs the AOX account never received Joe's message yesterday, nor quite a few others: M156252, M156259, M156262, M156273, M

[HACKERS] New VACUUM FULL crashes on temp relations

TRAP: FailedAssertion("!(typeNamespace == typ->typnamespace)", File: "pg_type.c", Line: 658) Test case attached, repeated, consistent failure on CVS HEAD. Crash occurs with either CLUSTER or VACUUM FULL. Passed on without further investigation. -- Simon Riggs www.2ndQuadrant.com --

[HACKERS] Re: [COMMITTERS] pgsql: Write a WAL record whenever we perform an operation without

I'm seeing these messages in the standby server log: WARNING: unlogged operation performed, data may be missing HINT: This can happen if you temporarily disable archive_mode without taking a new base backup. CONTEXT: xlog redo unlogged operation: heap inserts on "pg_temp_65646" which connected

Re: [HACKERS] Hot Standby and VACUUM FULL

On Sun, 2010-01-31 at 22:49 -0500, Tom Lane wrote: > Simon Riggs writes: > > I'll do a little work towards step (1) just so we can take a more > > informed view once you've had a better look at just what (2) involves. > > I spent a couple of hours reading code and believe that I've identified > a

Re: [HACKERS] odd output in initdb

2010/2/1 Andrew Dunstan : > > Magnus Hagander wrote: >>> >>> Actually, on close inspection it looks to me like this commit: "Create >>> typedef pgsocket for storing socket descriptors." >>> >>> c

Re: [HACKERS] mailing list archiver chewing patches

2010/2/1 Matteo Beccati : > On 01/02/2010 03:27, Alvaro Herrera wrote: >> >> Matteo Beccati wrote: >> >>> Incidentally, I've just found out that the mailing lists are >>> dropping some messages. According to my qmail logs the AOX account >>> never received Joe's message yesterday, nor quite a few o

Re: [HACKERS] Hot Standby and VACUUM FULL

On Mon, Feb 1, 2010 at 8:54 AM, Simon Riggs wrote: >> Disallow catalog relocation inside subtransactions, to avoid having >> to handle subxact abort effects on the local-map-changes state. >> This could be implemented if desired, but doesn't seem worth it >> at least in first pass. > > Agreed, not

[HACKERS] Re: [COMMITTERS] pgsql: Write a WAL record whenever we perform an operation without

Simon Riggs wrote: > I'm seeing these messages in the standby server log: > > WARNING: unlogged operation performed, data may be missing > HINT: This can happen if you temporarily disable archive_mode without > taking a new base backup. > CONTEXT: xlog redo unlogged operation: heap inserts on "

[HACKERS] Re: [COMMITTERS] pgsql: Write a WAL record whenever we perform an operation without

On Mon, 2010-02-01 at 11:33 +0200, Heikki Linnakangas wrote: > Can you reproduce that? Every time -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-

Re: [HACKERS] Re: [COMMITTERS] pgsql: Write a WAL record whenever we perform an operation without

On Mon, Feb 1, 2010 at 6:33 PM, Heikki Linnakangas wrote: > Hmm. The "unlogged" record is written here: > > ... > void > heap_sync(Relation rel) > { >        char reason[NAMEDATALEN + 30]; > >        /* temp tables never need fsync */ >        if (rel->rd_istemp) >                return; > >      

[HACKERS] Re: [COMMITTERS] pgsql: Write a WAL record whenever we perform an operation without

Simon Riggs wrote: > On Mon, 2010-02-01 at 11:33 +0200, Heikki Linnakangas wrote: >> Can you reproduce that? > > Every time Ok, good :-). What I really meant was: How? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@po

Re: [HACKERS] Hot Standby and deadlock detection

On Mon, 2010-02-01 at 09:40 +0200, Heikki Linnakangas wrote: > Simon Riggs wrote: > > The way this would work is if Startup waits on a buffer pin we > > immediately send out a request to all backends to cancel themselves if > > they are holding the buffer pin required && waiting on a lock. We then

[HACKERS] Re: [COMMITTERS] pgsql: Write a WAL record whenever we perform an operation without

On Mon, 2010-02-01 at 12:11 +0200, Heikki Linnakangas wrote: > Simon Riggs wrote: > > On Mon, 2010-02-01 at 11:33 +0200, Heikki Linnakangas wrote: > >> Can you reproduce that? > > > > Every time > > Ok, good :-). What I really meant was: How? As mentioned in first post: VACUUM FULL and CLUSTER.

Re: [HACKERS] Re: [COMMITTERS] pgsql: Write a WAL record whenever we perform an operation without

On Mon, Feb 1, 2010 at 6:58 PM, Fujii Masao wrote: >    if (XLogIsNeeded()) >    { >        snprintf(reason, sizeof(reason), "heap inserts on \"%s\"", >                         RelationGetRelationName(rel)); >        XLogReportUnloggedStatement(reason); >    } Oops! Typo: XLogIsNeeded() --> !XLog

Re: [HACKERS] Re: [COMMITTERS] pgsql: Write a WAL record whenever we perform an operation without

Fujii Masao wrote: > The cause of the problem seems to be the new heap created by > rebuild_relation() and copy_heap_data(), i.e., new VACUUM FULL. > Since it's not a temporary heap, its rd_istemp is off. OTOH > it needs to be synced after physical copy from old heap. Why does it need to be synced

[HACKERS] Re: [COMMITTERS] pgsql: Write a WAL record whenever we perform an operation without

Simon Riggs wrote: > On Mon, 2010-02-01 at 12:11 +0200, Heikki Linnakangas wrote: >> Simon Riggs wrote: >>> On Mon, 2010-02-01 at 11:33 +0200, Heikki Linnakangas wrote: Can you reproduce that? >>> Every time >> Ok, good :-). What I really meant was: How? > > As mentioned in first post: VACUUM

[HACKERS] PITR - Bug or feature?

Hello Today we have got one PITR backup history file in one of our systems with a format change. The PITR backup history file named pg_xlog/00010038.0020.backup included this information: START WAL LOCATION: 38/20 (file

Re: [HACKERS] Re: [COMMITTERS] pgsql: Write a WAL record whenever we perform an operation without

On Mon, Feb 1, 2010 at 7:27 PM, Heikki Linnakangas wrote: > Fujii Masao wrote: >> The cause of the problem seems to be the new heap created by >> rebuild_relation() and copy_heap_data(), i.e., new VACUUM FULL. >> Since it's not a temporary heap, its rd_istemp is off. OTOH >> it needs to be synced

Re: [HACKERS] Re: [COMMITTERS] pgsql: Write a WAL record whenever we perform an operation without

On Mon, Feb 1, 2010 at 7:30 PM, Heikki Linnakangas wrote: > CREATE TEMPORARY TABLE foo (id int4); > VACUUM FULL foo; How about issuing just "VACUUM FULL" after creating log-shipping environment? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center

[HACKERS] Re: [COMMITTERS] pgsql: Write a WAL record whenever we perform an operation without

Heikki Linnakangas wrote: > Simon Riggs wrote: >> On Mon, 2010-02-01 at 12:11 +0200, Heikki Linnakangas wrote: >>> Simon Riggs wrote: On Mon, 2010-02-01 at 11:33 +0200, Heikki Linnakangas wrote: > Can you reproduce that? Every time >>> Ok, good :-). What I really meant was: How? >> As

[HACKERS] Re: [COMMITTERS] pgsql: Write a WAL record whenever we perform an operation without

On Mon, 2010-02-01 at 12:30 +0200, Heikki Linnakangas wrote: > Simon Riggs wrote: > > On Mon, 2010-02-01 at 12:11 +0200, Heikki Linnakangas wrote: > >> Simon Riggs wrote: > >>> On Mon, 2010-02-01 at 11:33 +0200, Heikki Linnakangas wrote: > Can you reproduce that? > >>> Every time > >> Ok, good

Re: [HACKERS] Package namespace and Safe init cleanup for plperl UPDATE 3 [PATCH]

On Sat, Jan 30, 2010 at 06:38:59PM -0700, Alex Hunsaker wrote: > On Sat, Jan 30, 2010 at 16:16, Tim Bunce wrote: > > This is an update to the final plperl patch in the series from me. > > > > Changes in the original patch: > > plc_safe_ok.pl seems to loose its CVS $PostgreSQL$ keyword. Probably

Re: [HACKERS] About "Our CLUSTER implementation is pessimal" patch

I know you're all very busy getting 9.0 out, but I think the results in heap scanning + sort instead of index scanning for CLUSTER are very good... I would like to know if I did something wrong/I should improve something in the patch... I haven't tested it with index expressions yet (but the tests

Re: [HACKERS] Review: listagg aggregate

I noticed that the regression test results don't include the following case: select string_agg(a) from (values(null),(null)) g(a); There is one similar where a delimiter is provided. Which leads me to ask for clarification, would it be safe to assume that string_agg can never itself return null?

[HACKERS] Allow parentheses around the query expression that follows a WITH clause

I've got a question related to new feature in 8.5alpha, i.e. "Allow parentheses around the query expression that follows a WITH clause". What does that mean in fact? I can't see any difference between 8.4.2 and 8.5alpha3 on Solaris x86.

Re: [HACKERS] odd output in initdb

Magnus Hagander wrote: Did those two members produce consistent issues? Can you give them a couple of kicks to get enough buidls out of them to figure out if this solved the problem? Not very easily. I am currently travelling. It was happening fairly consistently on red_bat and seems to

[HACKERS] Re: [COMMITTERS] pgsql: Define INADDR_NONE on Solaris when it's missing.

2010/1/28 Magnus Hagander : > On Thu, Jan 28, 2010 at 21:16, Tom Lane wrote: >> Magnus Hagander writes: >>> On Thu, Jan 28, 2010 at 17:16, Tom Lane wrote: However, now that I know the real issue is you're using inet_addr, I would like to know why you're not using inet_aton instead; or

Re: [HACKERS] mailing list archiver chewing patches

On 01/02/2010 10:26, Magnus Hagander wrote: Does the MBOX importer support incremental loading? Because majordomo spits out MBOX files for us already. Unfortunately the aoximport shell command doesn't support incremental loading. One option could be to use SMTP with a subscription as the pr

Re: [HACKERS] Review: listagg aggregate

2010/2/1 Thom Brown : > I noticed that the regression test results don't include the following case: > > select string_agg(a) from (values(null),(null)) g(a); > > There is one similar where a delimiter is provided. > > Which leads me to ask for clarification, would it be safe to assume that > strin

Re: [HACKERS] Review: listagg aggregate

On 1 February 2010 13:40, Pavel Stehule wrote: > 2010/2/1 Thom Brown : > > I noticed that the regression test results don't include the following > case: > > > > select string_agg(a) from (values(null),(null)) g(a); > > > > There is one similar where a delimiter is provided. > > > > Which leads m

  1   2   >