Re: [HACKERS] Largeobject Access Controls (r2460)

KaiGai Kohei wrote: > The attached patch uses one TOC entry for each blob objects. This patch does not only fix the existing bugs, but also refactor the dump format of large objects in pg_dump. The new format are more similar to the format of tables: Section -

Re: [HACKERS] Review: listagg aggregate

2010/2/1 Takahiro Itagaki : > > Robert Haas wrote: > >> > ok - I am only one who like original behave - so I ?am withdrawing. >> > Robert, If you like, please commit Itagaki's patch. + add note about >> > behave when second parameter isn't stable. >> >> I haven't even looked at this code - I sort

Re: [HACKERS] Hot Standby and VACUUM FULL

FYI, getting rid of VACUUM FULL in a .0 release does make more sense than doing it in a .1 release. --- Tom Lane wrote: > Simon Riggs writes: > > I'll do a little work towards step (1) just so we can take a more > > informe

Re: [HACKERS] Hot Standby and VACUUM FULL

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 all the pain points for allowing relocation of system catalogs (

Re: [HACKERS] Review: listagg aggregate

Robert Haas wrote: > > ok - I am only one who like original behave - so I ?am withdrawing. > > Robert, If you like, please commit Itagaki's patch. + add note about > > behave when second parameter isn't stable. > > I haven't even looked at this code - I sort of assumed Itagaki was > handling th

Re: [HACKERS] Pathological regexp match

I wrote: > I found a possible patch that seems to improve matters: AFAICS the DFA > matching is independent of the checking that cdissect() and friends do, > so we can apply that check first instead of second. This brings the > runtime down from minutes to sub-second on my machine. However I don'

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

(2010/02/01 8:41), KaiGai Kohei wrote: > (2010/01/30 3:36), Robert Haas wrote: >> 2010/1/28 KaiGai Kohei: >>> (2010/01/29 9:58), KaiGai Kohei wrote: (2010/01/29 9:29), Robert Haas wrote: > 2010/1/28 KaiGai Kohei: >> (2010/01/29 0:46), Robert Haas wrote: >>> 2010/1/27 KaiGai Kohei:

Re: [HACKERS] HS/SR and smart shutdown

On Sat, Jan 30, 2010 at 12:54 PM, Fujii Masao wrote: >> HOWEVER, I do believe this is an issue we could live with for 9.0 if >> it's going to lead to a whole lot of additional debugging of SR. But if >> it's an easy fix, it'll avoid a lot of complaints on pgsql-general. > > I think that the latte

Re: [HACKERS] mailing list archiver chewing patches

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, M156275 > > and I've verified that i

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

Hi, We have a huge system based on PostgreSQL with xml2 functions. From the PostgreSQL 8.4 documentation F.38.1. Deprecation notice, it looks like those functions are removed. However, our solution is very huge, and heavily depends on them. 1. Could you please give me some instructions to get

Re: [HACKERS] odd output in initdb

Magnus Hagander wrote: Actually, on close inspection it looks to me like this commit: "Create typedef pgsocket for storing socket descriptors." could well be the culprit. I'm not cla

[HACKERS] Aggressive freezing versus caching of pg_proc entries

There are various places in the backend that rely on comparing a catalog tuple's TID and XMIN to values saved in a cache entry in order to detect whether the tuple changed since the cache entry was made. (So far as I can find, the only places that do this are looking at pg_proc entries --- fmgr.c

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

(2010/01/30 3:36), Robert Haas wrote: > 2010/1/28 KaiGai Kohei: >> (2010/01/29 9:58), KaiGai Kohei wrote: >>> (2010/01/29 9:29), Robert Haas wrote: 2010/1/28 KaiGai Kohei: > (2010/01/29 0:46), Robert Haas wrote: >> 2010/1/27 KaiGai Kohei: >>> Hmm, indeed, this logic (V3/V5) is bust

Re: [HACKERS] Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to

On Sun, 2010-01-31 at 17:10 -0500, Tom Lane wrote: > Simon Riggs writes: > > Should I revoke this change? > > Please. Will do, in morning. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscriptio

Re: [HACKERS] Eliminating VACUUM FULL WAS: remove flatfiles.c

On Sun, Jan 31, 2010 at 3:36 PM, Tom Lane wrote: > Back in September I wrote: >> ... The sticking point --- not only for pg_class, >> but for shared catalogs such as pg_database --- is the lack of a >> way to track relfilenode if it ever changes.  What if we keep >> the relfilenode of these critic

Re: [HACKERS] development setup and libdir

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.4 build them directly without prefix. I'm just speculating this is the issue an

Re: [HACKERS] Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to

Simon Riggs writes: > Should I revoke this change? Please. We can always put it back later if nothing better gets implemented. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.post

Re: [HACKERS] Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to

On Sun, 2010-01-31 at 23:43 +0200, Heikki Linnakangas wrote: > IIRC it was Greg Stark who suggested last time this was discussed that > we could calculate the exact value for latestRemovedXid in the > standby. When replaying the deletion record, the standby could look at > all the heap tuples whose

[HACKERS] Hot Standby and deadlock detection

Greg Stark has requested that I re-add max_standby_delay = -1. I deferred that in favour of relation-specific conflict resolution, though that seems too major a change from comments received. As discussed in various other posts, in order to re-add the -1 option we need to add deadlock detection. I

Re: [HACKERS] Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to

Heikki Linnakangas writes: > IIRC it was Greg Stark who suggested last time this was discussed that > we could calculate the exact value for latestRemovedXid in the standby. > When replaying the deletion record, the standby could look at all the > heap tuples whose index pointers are being removed

Re: [HACKERS] Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to

Simon Riggs wrote: > On Sun, 2010-01-31 at 22:05 +0100, Stefan Kaltenbrunner wrote: > >> hmm makes sense from the HS side - but I think to make a case for a GUC >> it would help a lot to see actual numbers(as in benchmarks) showing how >> much of a hit it is to the master. > > Agreed, though my

Re: [HACKERS] Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to

On Sun, 2010-01-31 at 22:05 +0100, Stefan Kaltenbrunner wrote: > hmm makes sense from the HS side - but I think to make a case for a GUC > it would help a lot to see actual numbers(as in benchmarks) showing how > much of a hit it is to the master. Agreed, though my approach to benchmarking was

Re: [HACKERS] Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to

Simon Riggs wrote: On Sun, 2010-01-31 at 20:48 +0100, Stefan Kaltenbrunner wrote: Simon Riggs wrote: On Sun, 2010-01-31 at 14:07 -0500, Tom Lane wrote: The commit is a one line change, with parameter to control it, discussed by Heikki and myself in December 2008. I stand by the accuracy of th

Re: [HACKERS] Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to

On Sun, 2010-01-31 at 15:41 -0500, Tom Lane wrote: > Simon Riggs writes: > > At the moment a btree delete record will cancel every request > > 1. no matter how long they have been running > > 2. no matter if they haven't accessed the index being cleaned (they > > might later, is the thinking...) >

Re: [HACKERS] ordered aggregates using WITHIN GROUP (was Re: can somebody execute this query on Oracle 11.2g and send result?)

2010/2/1 Tom Lane : > Hitoshi Harada writes: >> In other words, the queries can be the same: > >> SELECT array_agg(val ORDER BY sk) FROM ... >> SELECT array_agg(val) WITHIN GROUP (ORDER BY sk) FROM ... > > One more time: THOSE DON'T MEAN THE SAME THING.  If we ever get > around to implementing the

Re: [HACKERS] Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to

Simon Riggs writes: > At the moment a btree delete record will cancel every request > 1. no matter how long they have been running > 2. no matter if they haven't accessed the index being cleaned (they > might later, is the thinking...) That seems seriously horrid. What is the rationale for #2 in

Re: [HACKERS] Hot Standby and VACUUM FULL

On Sun, 2010-01-31 at 15:14 -0500, Tom Lane wrote: > If the only benefit of getting rid of VACUUM FULL were simplifying > Hot Standby, I'd agree with you. But there are numerous other benefits. > The double-commit hack you mention is something we need to get rid of > for general system stability

Re: [HACKERS] Eliminating VACUUM FULL WAS: remove flatfiles.c

Back in September I wrote: > ... The sticking point --- not only for pg_class, > but for shared catalogs such as pg_database --- is the lack of a > way to track relfilenode if it ever changes. What if we keep > the relfilenode of these critical tables someplace else? For > instance, we could have

Re: [HACKERS] Hot Standby and VACUUM FULL

On Sun, 2010-01-31 at 15:14 -0500, Tom Lane wrote: > Simon Riggs writes: > > On Sun, 2010-01-31 at 14:35 -0500, Tom Lane wrote: > >> Anyway, it's still not apparent to me exactly what the connection is > >> between VACUUM FULL and Hot Standby. I remember that we said HS didn't > >> work with VACU

Re: [HACKERS] Hot Standby and VACUUM FULL

Simon Riggs writes: > On Sun, 2010-01-31 at 14:35 -0500, Tom Lane wrote: >> Anyway, it's still not apparent to me exactly what the connection is >> between VACUUM FULL and Hot Standby. I remember that we said HS didn't >> work with VACUUM FULL (INPLACE) but I don't recall why that is, and the [

Re: [HACKERS] Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to

On Sun, 2010-01-31 at 20:48 +0100, Stefan Kaltenbrunner wrote: > Simon Riggs wrote: > > On Sun, 2010-01-31 at 14:07 -0500, Tom Lane wrote: > > > >>> The commit is a one line change, with parameter to control it, discussed > >>> by Heikki and myself in December 2008. I stand by the accuracy of the

Re: [HACKERS] Hot Standby and VACUUM FULL

On Sun, 2010-01-31 at 14:44 -0500, Tom Lane wrote: > Simon Riggs writes: > > Having said that I now realise a few things I didn't before: > > > * Approach (2) effects the core of Postgres, even if you don't use Hot > > Standby. > > * I've had to remove 7 sanity checks to get the first few VACUUMs

Re: [HACKERS] development setup and libdir

Ivan Sergio Borgonovo writes: > Being able to compile and install an extension without a full dev > environment is nonsense. > and without being root That's easy on a development environment, but you keep insisting in not having one. Now that's your problem. > Sorry if it seemed I was complai

Re: [HACKERS] Hot Standby and VACUUM FULL

On Sun, 2010-01-31 at 14:35 -0500, Tom Lane wrote: > Simon Riggs writes: > > On Sat, 2010-01-30 at 15:17 -0500, Tom Lane wrote: > >> Simon Riggs writes: > >>> The options to do this were and still are: > >>> (1) Add WAL messages for non-transactional relcache invalidations > >>> (2) Allow system

Re: [HACKERS] Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to

Simon Riggs wrote: On Sun, 2010-01-31 at 14:07 -0500, Tom Lane wrote: The commit is a one line change, with parameter to control it, discussed by Heikki and myself in December 2008. I stand by the accuracy of the change; the parameter is really to ensure we can test during beta. Well, I was w

Re: [HACKERS] development setup and libdir

Hi, Ivan Sergio Borgonovo writes: > But considering that what it's really missing between what I need > and what I get is renaming a file... it's just a pain I've to set up > a whole new instance of postgres, install the whole source etc... Untrue. Get the sources with git clone, them ./config

Re: [HACKERS] Hot Standby and VACUUM FULL

Simon Riggs writes: > Having said that I now realise a few things I didn't before: > * Approach (2) effects the core of Postgres, even if you don't use Hot > Standby. > * I've had to remove 7 sanity checks to get the first few VACUUMs > working. ISTM that removing various basic checks in the code

Re: [HACKERS] Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to

On Sun, 2010-01-31 at 14:07 -0500, Tom Lane wrote: > > The commit is a one line change, with parameter to control it, discussed > > by Heikki and myself in December 2008. I stand by the accuracy of the > > change; the parameter is really to ensure we can test during beta. > > Well, I was waiting

Re: [HACKERS] Hot Standby and VACUUM FULL

Simon Riggs writes: > On Sat, 2010-01-30 at 15:17 -0500, Tom Lane wrote: >> Simon Riggs writes: >>> The options to do this were and still are: >>> (1) Add WAL messages for non-transactional relcache invalidations >>> (2) Allow system relations to be cluster-ed/vacuum full-ed. >> Refresh my memor

Re: [HACKERS] Hot Standby and VACUUM FULL

On Sun, 2010-01-31 at 21:00 +0200, Heikki Linnakangas wrote: > Simon Riggs wrote: > > On Sat, 2010-01-30 at 15:17 -0500, Tom Lane wrote: > >> Simon Riggs writes: > >>> The last item on my list before close is making VACUUM FULL and Hot > >>> Standby play nicely together. > >>> The options to do th

Re: [HACKERS] Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to

Simon Riggs writes: > On Fri, 2010-01-29 at 14:04 -0500, Tom Lane wrote: >> WTF? Simon, this seems to be getting way way beyond anything the >> community has agreed to. Particularly, inventing GUCs is not something >> to be doing without consensus. > If you or anybody else would like me to revo

Re: [HACKERS] Hot Standby and VACUUM FULL

Simon Riggs wrote: > On Sat, 2010-01-30 at 15:17 -0500, Tom Lane wrote: >> Simon Riggs writes: >>> The last item on my list before close is making VACUUM FULL and Hot >>> Standby play nicely together. >>> The options to do this were and still are: >>> (1) Add WAL messages for non-transactional rel

Re: [HACKERS] Memory leak in deferrable index constraints

Dean Rasheed writes: > On 31 January 2010 16:03, Tom Lane wrote: >> It seems a bit unlikely that this would be the largest memory leak in >> that area.  Can you show a test case that demonstrates this is worth >> worrying about? > create table foo(a int unique deferrable initially deferred); > i

Re: [HACKERS] mailing list archiver chewing patches

On Sun, Jan 31, 2010 at 15:09, Matteo Beccati wrote: > On 31/01/2010 13:45, Magnus Hagander wrote: >> >> On Sat, Jan 30, 2010 at 22:43, Matteo Beccati  wrote: >>> >>> On 30/01/2010 17:54, Alvaro Herrera wrote: * While I don't personally care, some are going to insist that the site w

Re: [HACKERS] Using the new libpq connection functions in PostgreSQL binaries

On 01/31/2010 09:42 AM, Guillaume Lelarge wrote: > I don't find that horrid. AFAICT, that's the only advantage of the > two-arrays method. By the way, it's that kind of code (keywords > declaration separated from values declaration) that got commited in the > previous patch > (http://archives.postg

Re: [HACKERS] Using the new libpq connection functions in PostgreSQL binaries

Le 31/01/2010 17:35, Tom Lane a écrit : > Guillaume Lelarge writes: > >> */ >> do >> { >> + const char *values[] = { >> + my_opts->hostname, >> + my_opts->port, >> + my_opts->dbname, >> + my_opts->user

Re: [HACKERS] odd output in initdb

On Sun, Jan 31, 2010 at 18:33, Tom Lane wrote: > Magnus Hagander writes: >> On Sun, Jan 31, 2010 at 17:56, Tom Lane wrote: >>> I notice pgstat_send is still using "if (pgStatSock < 0)" to detect >>> PGINVALID_SOCKET ... > >> That's certainly so, but that shouldn't have any effect on this - >> si

Re: [HACKERS] odd output in initdb

Magnus Hagander writes: > On Sun, Jan 31, 2010 at 17:56, Tom Lane wrote: >> I notice pgstat_send is still using "if (pgStatSock < 0)" to detect >> PGINVALID_SOCKET ... > That's certainly so, but that shouldn't have any effect on this - > since on that platform it's defined to -1 anyway. But I'll

Re: [HACKERS] HS/SR and smart shutdown

On Sat, Jan 30, 2010 at 01:05, Robert Haas wrote: > On Fri, Jan 29, 2010 at 7:01 PM, Josh Berkus wrote: It's a good question if that still makes sense with Hot Standby. Perhaps we should redefine smart shutdown in standby mode to shut down as soon as all read-only connections have

Re: [HACKERS] odd output in initdb

On Sun, Jan 31, 2010 at 17:56, Tom Lane wrote: > Magnus Hagander writes: >> On Fri, Jan 29, 2010 at 23:28, Andrew Dunstan wrote:   initializing dependencies ... WARNING:  pgstat wait timeout > >> I'm not claiming it's not, but what exactly points to that? Does the >> problem go away if you

Re: [HACKERS] pg_listener entries deleted under heavy NOTIFY load only on Windows

On Fri, Jan 22, 2010 at 22:30, Radu Ilie wrote: > On a Windows server under heavy load of NOTIFY events, entries in > pg_listener table for some events are deleted. It is like UNLISTEN was > called. > > PostgreSQL version: 8.3.9. > Operating System: Windows XP. > > PostgreSQL believes that if it f

Re: [HACKERS] Pathological regexp match

On Sat, Jan 30, 2010 at 08:07, Tom Lane wrote: > Michael Glaesemann writes: >> We came across a regexp that takes very much longer than expected. > > I poked into this a little bit.  What seems to be happening is that the > use of non-greedy quantifiers plus backreferences turns off most of the >

Re: [HACKERS] odd output in initdb

Magnus Hagander writes: > On Fri, Jan 29, 2010 at 23:28, Andrew Dunstan wrote: >>>   initializing dependencies ... WARNING:  pgstat wait timeout > I'm not claiming it's not, but what exactly points to that? Does the > problem go away if you move to a version before that? > Because I'm 99% sure

Re: [HACKERS] Using the new libpq connection functions in PostgreSQL binaries

Guillaume Lelarge writes: >*/ > do > { > + const char *values[] = { > + my_opts->hostname, > + my_opts->port, > + my_opts->dbname, > + my_opts->username, > + password, > +

Re: [HACKERS] odd output in initdb

On Fri, Jan 29, 2010 at 23:28, Andrew Dunstan wrote: > > > Andrew Dunstan wrote: >> >> >>   initializing dependencies ... WARNING:  pgstat wait timeout >>   WARNING:  pgstat wait timeout >>   ok >>     vacuuming database template1 ... WARNING:  pgstat wait timeout >>   WARNING:  pgstat wait timeou

Re: [HACKERS] Memory leak in deferrable index constraints

On 31 January 2010 16:03, Tom Lane wrote: > Dean Rasheed writes: >> Oops, my fault. The list returned by ExecInsertIndexTuples() needs to be >> freed otherwise lots of lists (one per row) will build up and not be freed >> until the end of the query. This actually accounts for even more memory >>

Re: [HACKERS] ordered aggregates using WITHIN GROUP (was Re: can somebody execute this query on Oracle 11.2g and send result?)

Hitoshi Harada writes: > As far as I know is used to do "what-if" > analysis. rank(val1) within group (order by sk1) chooses the rank > value so that val1 is equivalent to or just greater than sk1 when you > calculate rank() over (partition by group order by sk1) within the > group. Hmm. I foun

Re: [HACKERS] Memory leak in deferrable index constraints

Dean Rasheed writes: > Oops, my fault. The list returned by ExecInsertIndexTuples() needs to be > freed otherwise lots of lists (one per row) will build up and not be freed > until the end of the query. This actually accounts for even more memory > than the after-trigger event queue. Patch attache

[HACKERS] Memory leak in deferrable index constraints

Oops, my fault. The list returned by ExecInsertIndexTuples() needs to be freed otherwise lots of lists (one per row) will build up and not be freed until the end of the query. This actually accounts for even more memory than the after-trigger event queue. Patch attached. Of course the after-trigge

Re: [HACKERS] mailing list archiver chewing patches

On 31/01/2010 13:45, Magnus Hagander wrote: On Sat, Jan 30, 2010 at 22:43, Matteo Beccati wrote: On 30/01/2010 17:54, Alvaro Herrera wrote: * While I don't personally care, some are going to insist that the site works with Javascript disabled. I didn't try but from your description it doesn't

Re: [HACKERS] development setup and libdir

Ivan Sergio Borgonovo wrote: When I'd like to try something new I'd like to put myself in the most diffused, standard environment eg. one thing I'd like to avoid is choosing my own flavour of compile options. This is just nonsense, as we have explained to you several times and you keep

Re: [HACKERS] Using the new libpq connection functions in PostgreSQL binaries

Le 31/01/2010 13:39, Magnus Hagander a écrit : > On Sun, Jan 31, 2010 at 09:34, Guillaume Lelarge > wrote: >> Hi, >> >> I worked on a patch to make PostgreSQL binaries use the new >> PQconnectdbParams() libpq functions. I tried to mimic the way Joe Conway >> changed my previous patch. >> >> I kno

Re: [HACKERS] mailing list archiver chewing patches

On Sat, Jan 30, 2010 at 22:43, Matteo Beccati wrote: > On 30/01/2010 17:54, Alvaro Herrera wrote: >> * While I don't personally care, some are going to insist that the site >> works with Javascript disabled.  I didn't try but from your description >> it doesn't seem like it would.  Is this easily

Re: [HACKERS] development setup and libdir

On Sun, 31 Jan 2010 02:44:13 -0200 Euler Taveira de Oliveira wrote: > Ivan Sergio Borgonovo escreveu: > > I'm pretty sure that what you're pointing at is not going to work > > unless you specify a bunch of other parameters. > Ugh? Are you saying there is something wrong in our *official* > docum

Re: [HACKERS] Using the new libpq connection functions in PostgreSQL binaries

On Sun, Jan 31, 2010 at 09:34, Guillaume Lelarge wrote: > Hi, > > I worked on a patch to make PostgreSQL binaries use the new > PQconnectdbParams() libpq functions. I tried to mimic the way Joe Conway > changed my previous patch. > > I know I'm way over the deadline for this commitfest. I couldn't

Re: [HACKERS] mailing list archiver chewing patches

On 30/01/2010 22:18, Joe Conway wrote: On 01/30/2010 01:14 PM, Dimitri Fontaine wrote: Matteo Beccati writes: I've been following the various suggestions. Please take a look at the updated archives proof of concept: http://archives.beccati.org/ I like the features a lot, and the only remark

Re: [HACKERS] development setup and libdir

Ivan Sergio Borgonovo escreveu: > I'm pretty sure that what you're pointing at is not going to work > unless you specify a bunch of other parameters. > Ugh? Are you saying there is something wrong in our *official* documentation? It is just a normal compilation command; if you're a C programmer yo

[HACKERS] Using the new libpq connection functions in PostgreSQL binaries

Hi, I worked on a patch to make PostgreSQL binaries use the new PQconnectdbParams() libpq functions. I tried to mimic the way Joe Conway changed my previous patch. I know I'm way over the deadline for this commitfest. I couldn't do it before because my previous patch (on this commit fest) propose