On 30.03.2011 21:21, Jan Urbański wrote:
Valgrind showed me the way. PFA a trivial patch to avoid leaking a
PLyProcedure struct in inline blocks.
Hmm, any reason the PLyProcedure struct needs to be allocated in
TopMemoryContext in the first place? Could you palloc0 it in a
shorter-lived conte
On 31 March 2011 03:15, Steve Crawford wrote:
> On 03/29/2011 04:24 PM, Adrian Klaver wrote:
>> ...
>> Well the strange part is only fails for SUN:...
>> test(5432)aklaver=>select to_date('2011-13-SUN', 'IYYY-IW-DY');
>> to_date
>>
>> 2011-03-28
>> ...
>
> You specified Sunday as t
On Wed, Mar 30, 2011 at 10:54 PM, Robert Haas wrote:
> On Wed, Mar 30, 2011 at 4:08 AM, Fujii Masao wrote:
>> On Wed, Mar 30, 2011 at 5:03 PM, Heikki Linnakangas
>> wrote:
>>> On 30.03.2011 10:58, Fujii Masao wrote:
On Wed, Mar 30, 2011 at 4:24 PM, Heikki Linnakangas
wrote:
Bruce Momjian wrote:
> > It does seem possible that that could happen, but I'm not sure exactly
> > what would be causing autovacuum to fire in the first place. It
> > wouldn't have to be triggered by the anti-wraparound machinery - if
> > the table appeared to be in need of vacuuming, then we'd v
Robert Haas wrote:
> > So, we set the cluster xid while we do this schema-only restore. ?I
> > belive it might be possible for autovacuum to run while the schema is
> > restored, see an empty table, and set the relfrozenxid to be the current
> > xid, when in fact we are about to put a heap file in
On Wed, Mar 30, 2011 at 9:30 PM, Noah Misch wrote:
>> Perhaps it would be reasonable to extend ALTER TABLE .. [NO]
>> INHERIT to accept a type name as the final argument. If used in this
>> way, it converts a typed table into a regular table or visca versa.
>
> Why extend ALTER TABLE ... INHERIT?
On Wed, Mar 30, 2011 at 07:50:12PM +0300, Peter Eisentraut wrote:
> On tor, 2011-02-10 at 06:31 +0200, Peter Eisentraut wrote:
> > > ERROR: cannot drop column from typed table
> > >
> > > which probably is because test_type2 has a dropped column.
> >
> > It should call
> >
> > ALTER TYPE test_t
On Wed, Mar 30, 2011 at 10:14:03AM -0400, Robert Haas wrote:
> On Tue, Mar 29, 2011 at 5:50 PM, Noah Misch wrote:
> > To reproduce that catalog state, the dump would need to create the type,
> > create
> > all typed tables predating the DROP ATTRIBUTE, and finally create typed
> > tables
> > pos
On Wed, Mar 30, 2011 at 5:27 PM, Bruce Momjian wrote:
> First, I am not sure it is a problem, but based on the IRC reports I
> felt I should ask here for confirmation. Here is a sample pg_dump
> output:
>
> CREATE TABLE sample (
> x integer
> );
>
> -- For binary u
On Wed, Mar 30, 2011 at 2:35 PM, Merlin Moncure wrote:
>
> btw I haven't forgotten your idea to move TransactionIdInProgress
> Down. I think this is a good idea, and will experiment with it pre and
> post cache.
aside:
Moving TransactionIdInProgress below TransactionIdDidCommit can help
in once s
Bruce Momjian wrote:
> > I wonder if the fact that these people never reported the bug means
> > there were doing something odd with their servers.
>
> I just updated the C comment about what we are doing:
>
> * Using autovacuum=off disables cleanup vacuum and analyze, but
> * freeze va
Peter Eisentraut wrote:
> On ons, 2011-03-30 at 15:42 -0400, Bruce Momjian wrote:
> > Peter Eisentraut wrote:
> > > pg_upgrade complains if any of the libpq connection variables are set.
> > > That's probably reasonable by default, but it seems to me that we ought
> > > to allow keeping PGCLIENTENC
Bruce Momjian wrote:
> First, I am not sure it is a problem, but based on the IRC reports I
> felt I should ask here for confirmation. Here is a sample pg_dump
> output:
>
> CREATE TABLE sample (
> x integer
> );
>
> -- For binary upgrade, set relfrozenxid.
>
On ons, 2011-03-30 at 15:42 -0400, Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > pg_upgrade complains if any of the libpq connection variables are set.
> > That's probably reasonable by default, but it seems to me that we ought
> > to allow keeping PGCLIENTENCODING set, otherwise various value
Robert Haas wrote:
> On Wed, Mar 30, 2011 at 10:57 AM, Bruce Momjian wrote:
> > I think we have three options:
> >
> > ? ? ? ?o ?find if the use of autovacuum_freeze_max_age is safe, or make
> > ? ? ? ? ? it safe
> > ? ? ? ?o ?document that autovacuum_naptime always happens before
> > ? ? ? ? ? au
On ons, 2011-03-30 at 15:39 -0400, Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > On ons, 2011-03-30 at 10:57 -0400, Bruce Momjian wrote:
> > > Also, I am unclear if this is really our bug. At least one of the
> > > systems was on Ubuntu/Debian, and they might both have been, and I know
> > >
On Wed, 2011-03-30 at 16:46 -0400, Robert Haas wrote:
> I don't really
> understand why this is an issue in the first place, though. Surely we
> must be setting the XID counter on the new cluster to match the one on
> the old cluster, and migrating the relfrozenxid and datfrozenxid
> settings, so
On Wed, Mar 30, 2011 at 10:57 AM, Bruce Momjian wrote:
> I think we have three options:
>
> o find if the use of autovacuum_freeze_max_age is safe, or make
> it safe
> o document that autovacuum_naptime always happens before
> autovacuum does anything and set it
On Tue, Mar 29, 2011 at 2:29 PM, Noah Misch wrote:
>> It's actually not
>> clear to me what the user could usefully do other than trying to
>> preserve his transaction by setting a high deadlock_timeout - what is
>> the use case, other than that?
>
> The other major use case is reducing latency in
On 3/30/2011 9:49 AM, Robert Haas wrote:
On Tue, Mar 29, 2011 at 9:40 PM, Stephen Frost wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
I do think we need some kind way of capturing DDL events, though. I wonder if
the object-access-hook stuff KaiGai and I did to support SE-PostgreSQL co
Hi!
On Wed, Mar 30, 2011 at 8:40 AM, Alexey Klyukin wrote:
> I'd like to add an ability to validate the corectness of PostgreSQL
> configuration files, i.e. postgresql.conf, pg_hba.conf, pg_ident.conf without
> actually applying them. The idea is that it would be a command-line option to
> postg
Excerpts from Dimitri Fontaine's message of mié mar 30 15:05:36 -0300 2011:
> Andrew Dunstan writes:
> > I don't have any objection to putting some comments in the contrib Makefiles
> > telling people to use PGXS, but I don't think that at this stage of the
> > cycle we can start work on something
Peter Eisentraut wrote:
> pg_upgrade complains if any of the libpq connection variables are set.
> That's probably reasonable by default, but it seems to me that we ought
> to allow keeping PGCLIENTENCODING set, otherwise various values and
> error messages that are coming from the servers will not
Peter Eisentraut wrote:
> On ons, 2011-03-30 at 10:57 -0400, Bruce Momjian wrote:
> > Also, I am unclear if this is really our bug. At least one of the
> > systems was on Ubuntu/Debian, and they might both have been, and I know
> > Debian changes our source code. Where can I find a copy of the di
On Wed, Mar 30, 2011 at 11:23 AM, Heikki Linnakangas
wrote:
> On 30.03.2011 18:02, Robert Haas wrote:
>>
>> On Wed, Mar 30, 2011 at 10:40 AM, Greg Stark wrote:
>>>
>>> But one way or another the hint bits have to get set sometime. The
>>> sooner that happens the less clog i/o has to happen in the
On Wed, Mar 30, 2011 at 12:55 PM, Peter Eisentraut wrote:
> Maybe we could just copy the dropped attributes from the type when the
> table is created. That might be as simple as removing the
>
> if (attr->attisdropped)
> continue;
>
> in transformOfType().
Seems a bit fragile..
On 28/03/11 17:25, Stephen Frost wrote:
> * Jan Urbański (wulc...@wulczer.org) wrote:
>> On 28/03/11 04:31, Tom Lane wrote:
Do the other PLs we ship need similar fixes?
>>>
>>> Offhand I think the other PLs leave management of prepared plans to the
>>> user. If there are any places where they
Andrew Dunstan writes:
> I don't have any objection to putting some comments in the contrib Makefiles
> telling people to use PGXS, but I don't think that at this stage of the
> cycle we can start work on something that so far is just an idea from the
> top of my head.
I might be mistaken on how
pg_upgrade complains if any of the libpq connection variables are set.
That's probably reasonable by default, but it seems to me that we ought
to allow keeping PGCLIENTENCODING set, otherwise various values and
error messages that are coming from the servers will not be in the
encoding appropriate
On tis, 2011-03-29 at 17:50 -0400, Noah Misch wrote:
> Fixing that looks clear enough, but the right fix for the typed table
> issue is less clear to me. The pg_attribute tuples for a typed table
> will include any attributes dropped from the parent type after the
> table's creation, but not those
On tor, 2011-02-10 at 06:31 +0200, Peter Eisentraut wrote:
> > ERROR: cannot drop column from typed table
> >
> > which probably is because test_type2 has a dropped column.
>
> It should call
>
> ALTER TYPE test_type2 DROP ATTRIBUTE xyz CASCADE;
>
> instead. That will propagate to the table.
On ons, 2011-03-30 at 10:57 -0400, Bruce Momjian wrote:
> Also, I am unclear if this is really our bug. At least one of the
> systems was on Ubuntu/Debian, and they might both have been, and I know
> Debian changes our source code. Where can I find a copy of the diffs
> they have made?
http://ba
On Wed, Mar 30, 2011 at 11:23 AM, Heikki Linnakangas
wrote:
> Even if clog access was free, hint bits still give a significant speedup
> thanks to skipping all the other overhead like TransactionIdIsInProgress()
> and TransactionIdIsCurrentTransactionId(). Speeding up clog access is
> important; w
On 03/30/2011 12:29 PM, Dimitri Fontaine wrote:
Andrew Dunstan writes:
I think we're pretty much down to only fixing bugs now, for 9.1, and this
isn't a bug, however inconvenient it might be.
It's not just inconvenient, it's setting a bad example for people to
work on their own extensions.
Andrew Dunstan writes:
> I think we're pretty much down to only fixing bugs now, for 9.1, and this
> isn't a bug, however inconvenient it might be.
It's not just inconvenient, it's setting a bad example for people to
work on their own extensions. It's more than unfortunate. I will
prepare a doc
On 03/30/2011 09:15 AM, Steve Crawford wrote:
On 03/29/2011 04:24 PM, Adrian Klaver wrote:
...
Well the strange part is only fails for SUN:...
test(5432)aklaver=>select to_date('2011-13-SUN', 'IYYY-IW-DY');
to_date
2011-03-28
...
You specified Sunday as the day but the date return
On 30.03.2011 18:02, Robert Haas wrote:
On Wed, Mar 30, 2011 at 10:40 AM, Greg Stark wrote:
But one way or another the hint bits have to get set sometime. The
sooner that happens the less clog i/o has to happen in the meantime.
I talked about this with Merlin a bit yesterday. I think that hi
On 03/29/2011 04:24 PM, Adrian Klaver wrote:
...
Well the strange part is only fails for SUN:...
test(5432)aklaver=>select to_date('2011-13-SUN', 'IYYY-IW-DY');
to_date
2011-03-28
...
You specified Sunday as the day but the date returned is a Monday. I
would categorize that as
On Wed, Mar 30, 2011 at 10:43 AM, Alvaro Herrera
wrote:
> Excerpts from Merlin Moncure's message of mié mar 30 12:14:20 -0300 2011:
>
>> It is very different -- the slru layer is in shared memory and
>> requires locks to access. The entire point is trying to avoid
>> accessing this structure in
On Wed, Mar 30, 2011 at 8:52 AM, Heikki Linnakangas
wrote:
> Yeah, that's a straightforward way to fix it. I don't think the performance
> hit will be too bad. But we need to be careful not to hold locks while doing
> I/O, which might require some rearrangement of the code. We might want to do
> a
On 03/30/2011 11:37 AM, Dimitri Fontaine wrote:
Andrew Dunstan writes:
Maybe we could teach pg_config to report appropriate settings for
uninstalled source via an environment setting. Without changing pg_config it
looks like we have a chicken and egg problem.
(If my suggestion is right, this
Hi,
I'd like to add an ability to validate the corectness of PostgreSQL
configuration files, i.e. postgresql.conf, pg_hba.conf, pg_ident.conf without
actually applying them. The idea is that it would be a command-line option to
postgres for a stand-alone case, or a user-callable function when post
Excerpts from Merlin Moncure's message of mié mar 30 12:14:20 -0300 2011:
> It is very different -- the slru layer is in shared memory and
> requires locks to access. The entire point is trying to avoid
> accessing this structure in tight code paths. I'm actually very
> skeptical the slru layer
Andrew Dunstan writes:
> Maybe we could teach pg_config to report appropriate settings for
> uninstalled source via an environment setting. Without changing pg_config it
> looks like we have a chicken and egg problem.
>
> (If my suggestion is right, this would probably be a good beginner TODO.)
I
On 03/30/2011 09:42 AM, David Fetter wrote:
In http://archives.postgresql.org/pgsql-hackers/2009-07/msg00245.php
Tom writes:
The main reason contrib still has the alternate method is that PGXS
doesn't really work until after you've installed the core build.
Maybe we could have a look and tr
On Wed, Mar 30, 2011 at 9:40 AM, Greg Stark wrote:
> On Tue, Mar 29, 2011 at 10:34 PM, Merlin Moncure wrote:
>> So I went back to the drawing board, reviewed the archives, and came
>> up with a new proposal. I'd like to see a process local clog page
>> cache of around 1-4 pages (8-32kb typically
On Wed, Mar 30, 2011 at 10:40 AM, Greg Stark wrote:
> But one way or another the hint bits have to get set sometime. The
> sooner that happens the less clog i/o has to happen in the meantime.
I talked about this with Merlin a bit yesterday. I think that his
thought is that most transactions will
Alvaro Herrera wrote:
> Excerpts from Jeff Davis's message of mar mar 29 21:27:34 -0300 2011:
> > On Tue, 2011-03-29 at 15:52 -0400, Bruce Momjian wrote:
> > > Does anyone have any other suggestions on how to make sure autovacuum
> > > does not run in freeze mode?
> >
> > Can you run in single use
On Tue, Mar 29, 2011 at 4:48 PM, Peter Eisentraut wrote:
> As you might have heard, GCC 4.6 was released the other day. It
> generates a bunch of new warnings with the PostgreSQL source code, most
> of which belong to the new warning scenario -Wunused-but-set-variable,
> which is included in -Wal
On Tue, Mar 29, 2011 at 10:34 PM, Merlin Moncure wrote:
> So I went back to the drawing board, reviewed the archives, and came
> up with a new proposal. I'd like to see a process local clog page
> cache of around 1-4 pages (8-32kb typically) that would replace the
> current TransactionLogFetch la
On 30.03.2011 17:05, Merlin Moncure wrote:
*) Maybe the shared buffer cache currently being maintained over the
clog can be scrapped. I'm going to leave it alone for now, but I'm
quite skeptical it provides much benefit even without local process
cache. clog page have a very nice property that y
On Tue, Mar 29, 2011 at 5:50 PM, Noah Misch wrote:
> I took a look at the open item concerning typed tables and pg_upgrade:
> http://archives.postgresql.org/pgsql-hackers/2011-03/msg00767.php
Thanks!
> [ helpful summary of problem clipped ]
> To reproduce that catalog state, the dump would need
On Wed, Mar 30, 2011 at 9:59 AM, David Fetter wrote:
> On Tue, Mar 29, 2011 at 08:21:04PM -0400, Robert Haas wrote:
>> On Mar 29, 2011, at 2:17 PM, Christopher Browne wrote:
>> > A proposal to adding triggers to system catalog tables won't be
>> > terribly popular.
>>
>> Well, I'd support it if I
On Tue, Mar 29, 2011 at 4:34 PM, Merlin Moncure wrote:
> In a previous thread
> (http://postgresql.1045698.n5.nabble.com/Set-hint-bits-upon-eviction-from-BufMgr-td4264323.html)
> I was playing with the idea of granting the bgwriter the ability to
> due last chance hint bit setting before evicting
On Tue, Mar 29, 2011 at 08:21:04PM -0400, Robert Haas wrote:
> On Mar 29, 2011, at 2:17 PM, Christopher Browne wrote:
> > A proposal to adding triggers to system catalog tables won't be
> > terribly popular.
>
> Well, I'd support it if I thought it had any chance of actually
> working, but I don'
On Wed, Mar 30, 2011 at 4:08 AM, Fujii Masao wrote:
> On Wed, Mar 30, 2011 at 5:03 PM, Heikki Linnakangas
> wrote:
>> On 30.03.2011 10:58, Fujii Masao wrote:
>>>
>>> On Wed, Mar 30, 2011 at 4:24 PM, Heikki Linnakangas
>>> wrote:
>>> + A value of zero means wait forever. This parameter c
On Tue, Mar 29, 2011 at 9:40 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> I do think we need some kind way of capturing DDL events, though. I wonder
>> if the object-access-hook stuff KaiGai and I did to support SE-PostgreSQL
>> could be extended to meet this need..
On Wed, Mar 30, 2011 at 10:32:55AM -0300, Alvaro Herrera wrote:
> Excerpts from Alvaro Herrera's message of mié mar 30 10:27:39 -0300 2011:
> > Excerpts from Dimitri Fontaine's message of mié mar 30 05:27:07 -0300 2011:
>
> > > I'm not sure why we still support the pre-PGXS build recipe in the
> >
HI all,
I'm trying to compile PostgreSQL 9.0.3 on FreeBSD 8.1-stable, and I can make
it working if I compile without dtrace. However when I compile with --enable-
dtrace I'm unable to use the cluster and even initdb.
In particular initdb claims that:
fgets failure: No such file or directory
The p
Excerpts from Alvaro Herrera's message of mié mar 30 10:27:39 -0300 2011:
> Excerpts from Dimitri Fontaine's message of mié mar 30 05:27:07 -0300 2011:
> > I'm not sure why we still support the pre-PGXS build recipe in the
> > contrib Makefiles, and didn't want to change that as part as the
> > ex
On Wed, Mar 30, 2011 at 10:27:07AM +0200, Dimitri Fontaine wrote:
> I think we should lower the differences between contrib and external
> extensions, so that contrib is only about who maintains the code and
> distribute the extension.
+10 :)
Cheers,
David.
--
David Fetter http://fetter.org/
P
Excerpts from Dimitri Fontaine's message of mié mar 30 05:27:07 -0300 2011:
> Alvaro Herrera writes:
> > Why are you worrying with the non-PGXS build chain anyway? Just assume
> > that the module is going to be built with PGXS and things should just
> > work.
> >
> > We've gone over this a dozen
On 30.03.2011 06:24, 高增琦 wrote:
Should we do full-page write for visibilitymap all the time?
Now, when clear visiblitymap, there is no full-page write for vm
since we don't save buffer info in insert/update/delete's log.
The full-page write is used to protect pages from disk failure. Without it,
2011/3/30 aaronenabs :
> Can you alos advise how i change the the HeapTupleSatisfiesVisibility() to
> true within the source code:
[..]
> #define HeapTupleSatisfiesVisibility(tuple, snapshot, buffer) \
> ((*(snapshot)->satisfies) ((tuple)->t_data, snapshot, buffer))
As someone totally no
Sorry about that, here is the section before the make.
dllwrap -o cygpq.dll --dllname cygpq.dll --def libpqdll.def fe-auth.o
fe-connec
t.o fe-exec.o fe-misc.o fe-print.o fe-lobj.o fe-protocol2.o fe-protocol3.o
pqexp
buffer.o pqsignal.o fe-secure.o libpq-events.o md5.o ip.o wchar.o encnames.o
nob
2011/3/30 aaronenabs :
> Hi all i have been trying to compile the sourcecode for postgresql but keep
> getting an error message when running it in cygwin.
>
> it states:
>
> dllwrap: gcc exited with status 1
> make[3]: *** [cygpq.dll] Error 1
> make[3]: Leaving directory
> `/postgresql-9.0.3/postg
Alvaro Herrera writes:
> Why are you worrying with the non-PGXS build chain anyway? Just assume
> that the module is going to be built with PGXS and things should just
> work.
>
> We've gone over this a dozen times in the past.
+1
I'm not sure why we still support the pre-PGXS build recipe in t
On Wed, Mar 30, 2011 at 4:56 PM, Heikki Linnakangas
wrote:
>> Attached patch reverts that. Comments?
>
> Looks good, committed.
Thanks!
> We could also improve the error message. If we haven't reached the
> end-of-backup location, we could say something along the lines of:
>
> ERROR: WAL ends be
On Wed, Mar 30, 2011 at 5:03 PM, Heikki Linnakangas
wrote:
> On 30.03.2011 10:58, Fujii Masao wrote:
>>
>> On Wed, Mar 30, 2011 at 4:24 PM, Heikki Linnakangas
>> wrote:
>> + A value of zero means wait forever. This parameter can only be
>> set in
>>
>> The first sentence sounds misleadin
On 30.03.2011 09:25, Fujii Masao wrote:
On Wed, Mar 30, 2011 at 11:39 AM, Fujii Masao wrote:
On Wed, Mar 30, 2011 at 12:54 AM, Heikki Linnakangas
wrote:
Hmm, why did we change that?
I'm not sure, but I guess that's because I missed the case where crash
recovery starts from the backup :(
On 30.03.2011 10:58, Fujii Masao wrote:
On Wed, Mar 30, 2011 at 4:24 PM, Heikki Linnakangas
wrote:
+A value of zero means wait forever. This parameter can only be set in
The first sentence sounds misleading. Even if you set the parameter to zero,
replication connections can be termina
On Wed, Mar 30, 2011 at 5:29 AM, Fujii Masao wrote:
> I'm very excited about new options, especially recv. But I agree with
> Robert and Heikki because what the patch provides looks like new
> feature rather than bug fix. And I think that we still require some
> discussions of the design; how far
On Wed, Mar 30, 2011 at 4:24 PM, Heikki Linnakangas
wrote:
>> + pq_putmessage_noblock('d', msgbuf, 1 +
>> sizeof(WalDataMessageHeader) + nbytes);
>>
>> Don't we need to check the return value of pq_putmessage_noblock? That
>> can return EOF when trouble happens (for example the send system c
>> Ok. It seems I need to patch PostgreSQL.
>
> Why is that feature required? It's for pgpool-II?
Yes. And probably any automated failover management tool will require
the functionality.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.
On 29.03.2011 07:55, Fujii Masao wrote:
On Mon, Mar 28, 2011 at 7:49 PM, Heikki Linnakangas
wrote:
pq_flush_if_writable() calls internal_flush() without using PG_TRY block.
This seems unsafe because for example pgwin32_waitforsinglesocket()
called by secure_write() can throw ERROR.
Perhaps i
75 matches
Mail list logo
