On Tue, Dec 22, 2009 at 3:30 PM, Heikki Linnakangas
wrote:
> I think we can just use load_external_function() to load the library and
> call WalReceiverMain from AuxiliaryProcessMain(). Ie. hard-code the
> library name. Walreceiver is quite tightly coupled with the rest of the
> backend anyway, so
(2009/12/21 12:53), Robert Haas wrote:
> On Thu, Dec 17, 2009 at 7:19 PM, Tom Lane wrote:
>> KaiGai Kohei writes:
>>> [ patch to remove EnableDisableRule's permissions check ]
>>
>> I don't particularly like this patch, mainly because I disagree with
>> randomly removing permissions checks withou
Fujii Masao wrote:
> On Tue, Dec 22, 2009 at 2:31 AM, Heikki Linnakangas
> wrote:
>> 2. Move walreceiver altogether into a loadable module, which is linked
>> as usual to libpq. Like e.g contrib/dblink.
>>
>> Thoughts? Both seem reasonable to me. I tested the 2nd option (see
>> 'replication' branc
(2009/12/21 9:39), KaiGai Kohei wrote:
> (2009/12/19 12:05), Robert Haas wrote:
>> On Fri, Dec 18, 2009 at 9:48 PM, Tom Lane wrote:
>>> Robert Haas writes:
Oh. This is more complicated than it appeared on the surface. It
seems that the string "BLOB COMMENTS" actually gets inserted i
On Sat, Dec 19, 2009 at 1:03 AM, Heikki Linnakangas
wrote:
> I don't think it's worthwhile to modify pg_stop_backup() like that. We
> should address the general problem. At the moment, you're fine if you
> also configure WAL archiving and log file shipping, but it would be nice
> to have some simp
David E. Wheeler wrote:
On Dec 21, 2009, at 2:34 PM, David E. Wheeler wrote:
On Dec 21, 2009, at 2:13 PM, Tim Bunce wrote:
You're using 5.8.8. In 5.10.0 $^V was changed to be an object.
I'm working in that area. I'll look into it.
While you're at it, I have a new problem:
Fujii Masao writes:
> Though I seem not to understand what a loadable module means, I wonder
> how the walreceiver module is loaded.
Put it in shared_preload_libraries, perhaps.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
Tom Lane wrote:
> I suggest that we might want to just
> rip out the support for copying comments on indexes. Or maybe even the
> whole copy-comments aspect of it.
We have two related ToDo items below. They are a bit inconsintent,
but they mean we should forbid COMMENT on columns of an index,
On Tue, Dec 22, 2009 at 2:31 AM, Heikki Linnakangas
wrote:
> 2. Move walreceiver altogether into a loadable module, which is linked
> as usual to libpq. Like e.g contrib/dblink.
>
> Thoughts? Both seem reasonable to me. I tested the 2nd option (see
> 'replication' branch in my git repository), spl
On Monday 21 December 2009 16:48:52 Simon Riggs wrote:
> Giving the drop database a snapshot is not the answer. I expect Andres
> to be able to fix this with a simple patch that would not effect the
> case of normal running.
Actually its less simply than I had thought at first - I don't think the c
Hi,
I found there is no "primary" tag for the HS parameters
in config.sgml. Attached patch adds that tag.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
*** a/doc/src/sgml/config.sgml
--- b/doc/src/sgml/config.sgml
***
*** 1753,175
On Dec 21, 2009, at 2:34 PM, David E. Wheeler wrote:
> On Dec 21, 2009, at 2:13 PM, Tim Bunce wrote:
>
>> You're using 5.8.8. In 5.10.0 $^V was changed to be an object.
>>
>> I'm working in that area. I'll look into it.
>
> While you're at it, I have a new problem:
>
>CREATE OR REPLACE FUN
Peter Eisentraut writes:
> On mån, 2009-12-21 at 00:03 -0500, Tom Lane wrote:
>> Well, we could tamp down the risks considerably if we undid my point
>> (1), namely to still consider only the first index column when
>> generating a name.
> I think putting all the column names into the index name
On Dec 21, 2009, at 2:13 PM, Tim Bunce wrote:
> You're using 5.8.8. In 5.10.0 $^V was changed to be an object.
>
> I'm working in that area. I'll look into it.
While you're at it, I have a new problem:
CREATE OR REPLACE FUNCTION wtf(
expression text
) RETURNS text LANGUAGE plpe
On Mon, Dec 21, 2009 at 02:46:17PM -0500, Andrew Dunstan wrote:
>
>
> David E. Wheeler wrote:
>> At least I think it's a segfault. This function returns a vstring:
>>
>> CREATE OR REPLACE FUNCTION wtf(
>> ) RETURNS text LANGUAGE plperl IMMUTABLE STRICT AS $X$
>> return $^V;
>> $X$;
>>
>> Here's
On mån, 2009-12-21 at 00:03 -0500, Tom Lane wrote:
> Well, we could tamp down the risks considerably if we undid my point
> (1), namely to still consider only the first index column when
> generating a name.
I think putting all the column names into the index names instead of
only the first is a s
Peter Eisentraut wrote:
On mån, 2009-12-21 at 14:46 -0500, Andrew Dunstan wrote:
BTW, this should arguably not be an immutable function. You could
replace the perl library, so it's not solely dependent on the input
for
the result.
By this logic, no function could be immutable, becau
On mån, 2009-12-21 at 14:46 -0500, Andrew Dunstan wrote:
> BTW, this should arguably not be an immutable function. You could
> replace the perl library, so it's not solely dependent on the input
> for
> the result.
By this logic, no function could be immutable, because you could replace
the C l
On Dec 21, 2009, at 11:46 AM, Andrew Dunstan wrote:
> It's not doing that for me.
Odd.
> The plperl code has no way at all of knowing that the bytes you are returning
> come from $^V. If you really want the version back, do what the perl docs
> tell you and sprintf the value:
It works fine if
David E. Wheeler wrote:
At least I think it's a segfault. This function returns a vstring:
CREATE OR REPLACE FUNCTION wtf(
) RETURNS text LANGUAGE plperl IMMUTABLE STRICT AS $X$
return $^V;
$X$;
Here's what happens when I call it:
try=# select wtf();
server closed the connection unexpect
At least I think it's a segfault. This function returns a vstring:
CREATE OR REPLACE FUNCTION wtf(
) RETURNS text LANGUAGE plperl IMMUTABLE STRICT AS $X$
return $^V;
$X$;
Here's what happens when I call it:
try=# select wtf();
server closed the connection unexpectedly
This probably m
Heikki Linnakangas writes:
> Fujii Masao wrote:
> I'm not sure which problem in that thread you're referring to, but I can
> see two options:
> 1. Use dlopen()/dlsym() in walreceiver to use libpq. A bit awkward,
> though we could write a bunch of macros to hide that and make the libpq
> calls loo
Greg Stark writes:
> On Mon, Dec 21, 2009 at 5:02 PM, Greg Smith wrote:
>> Right; that's exactly the way I'm computing things now, I just have to crawl
>> way too much catalog data to do it. I also agree that if we provide
>> pg_table_size, the issue of "pg_relation_size doesn't do what I want"
On Mon, Dec 21, 2009 at 5:02 PM, Greg Smith wrote:
> Tom Lane wrote:
>>
>> Perhaps invent pg_table_size() = base table + toast table + toast index
>> and pg_indexes_size() = all other indexes for table
>> giving us the property pg_table_size + pg_indexes_size =
>> pg_total_relation_si
On Mon, Dec 21, 2009 at 08:22:54AM -0800, David E. Wheeler wrote:
> On Dec 21, 2009, at 7:18 AM, Tim Bunce wrote:
>
> >> Given the above three things it seems like we could define 5.8.1 as the
> >> minimum required version.
> >
> > I'd be delighted with that.
>
> +1
>
> BTW Tim, have you tested
Fujii Masao wrote:
> On Tue, Dec 15, 2009 at 4:11 AM, Tom Lane wrote:
>> Hm. Perhaps it should be a loadable plugin and not hard-linked into the
>> backend? Compare dblink.
>
> You mean that such plugin is supplied in shared_preload_libraries,
> a new process is forked and the shared-memory rel
Fujii Masao wrote:
> On Fri, Dec 18, 2009 at 11:42 AM, Fujii Masao wrote:
>> Okey. Design clarification again;
>>
>> 0. Begin by connecting to the master using PQconnectdb() with new conninfo
>> option specifying the request of replication. The startup packet with the
>> request is sent to the mas
Tom Lane wrote:
Perhaps invent pg_table_size() = base table + toast table + toast index
and pg_indexes_size() = all other indexes for table
giving us the property pg_table_size + pg_indexes_size =
pg_total_relation_size
Right; that's exactly the way I'm computing things now, I jus
Greg Smith writes:
> To answer Rafael's concerns directly: you're right that this is
> confusing. pg_relation_size is always going to do what it does right
> now just because of how that fits into the design of the database.
> However, the documentation should be updated to warn against the
Bernd Helmle wrote:
I've created a C-Function a while ago that extracts the TOAST size for
a given relation. This gave me the opportunity to do a
pg_relation_size(oid) + pg_relation_toast_size(oid) for a given table
oid to calculate on disk data size required by a table. Maybe we
should includ
On Monday 21 December 2009 16:38:07 Tom Lane wrote:
> Alvaro Herrera writes:
> > Andres Freund wrote:
> >> The logic behind this seems fine except in the case of dropping a
> >> database. There you very well might have a open connection without an
> >> open snapshot.
> > Perhaps the simplest fix i
On Dec 21, 2009, at 7:18 AM, Tim Bunce wrote:
>> Given the above three things it seems like we could define 5.8.1 as the
>> minimum required version.
>
> I'd be delighted with that.
+1
BTW Tim, have you tested with 5.11 yet?
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
> Rafael Martinez writes:
>> I am probably missing the point here, why is it not supposed to show the
>> size of the table(data) *without* indexes?
>
> Because pg_relation_size is defined at the "physical" level of showing
> one relat
On Mon, 2009-12-21 at 10:38 -0500, Tom Lane wrote:
> Alvaro Herrera writes:
> > Andres Freund wrote:
> >> The logic behind this seems fine except in the case of dropping a
> >> database.
> >> There you very well might have a open connection without an open snapshot.
>
> > Perhaps the simplest f
Alvaro Herrera writes:
> Andres Freund wrote:
>> The logic behind this seems fine except in the case of dropping a database.
>> There you very well might have a open connection without an open snapshot.
> Perhaps the simplest fix is to ensure that drop database gets a snapshot?
I confess to not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bernd Helmle wrote:
>
>
> --On 21. Dezember 2009 10:01:37 -0500 Tom Lane wrote:
>
>> It's not supposed to. Use pg_total_relation_size if you want a number
>> that includes index and toast space.
>
> I've created a C-Function a while ago that extr
Rafael Martinez writes:
> I am probably missing the point here, why is it not supposed to show the
> size of the table(data) *without* indexes?
Because pg_relation_size is defined at the "physical" level of showing
one relation, where relation means a pg_class entry. If you want
agglomerations o
Andres Freund wrote:
> The logic behind this seems fine except in the case of dropping a database.
> There you very well might have a open connection without an open snapshot.
Perhaps the simplest fix is to ensure that drop database gets a snapshot?
--
Alvaro Herrera
--On 21. Dezember 2009 10:01:37 -0500 Tom Lane wrote:
It's not supposed to. Use pg_total_relation_size if you want a number
that includes index and toast space.
I've created a C-Function a while ago that extracts the TOAST size for a
given relation. This gave me the opportunity to do a pg
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
> Rafael Martinez writes:
>> I wonder why the function pg_relation_size(text) does not take into
>> account the space used by toast data in a table when returning the space
>> used by the table.
>
> It's not supposed to. Use pg_total
Hiroyuki Yamada wrote:
> 4. Startup process tries to redo XLOG_HEAP2_CLEAN record, calls
> LockBufferForCleanup() and freezes until the Xact 1 ends.
I think they word you're searching for is "blocks". Blocking to
protect integrity doesn't sound like a bug to me; perhaps an
opportunity fo
On Mon, Dec 21, 2009 at 10:09:58AM -0500, Tom Lane wrote:
> Magnus Hagander writes:
> > 2009/12/21 Robert Haas :
> >> On Mon, Dec 21, 2009 at 5:45 AM, Tim Bunce wrote:
> >>> plperl requires Safe v2.09, released in Oct 2003 and included in 5.8.1.
> >>> That version, and later versions, have only b
Magnus Hagander writes:
> 2009/12/21 Robert Haas :
>> On Mon, Dec 21, 2009 at 5:45 AM, Tim Bunce wrote:
>>> plperl requires Safe v2.09, released in Oct 2003 and included in 5.8.1.
>>> That version, and later versions, have only been tested back to perl 5.6.
>>> I'd recommend Perl 5.8(.1) as a mi
Rafael Martinez writes:
> I wonder why the function pg_relation_size(text) does not take into
> account the space used by toast data in a table when returning the space
> used by the table.
It's not supposed to. Use pg_total_relation_size if you want a number
that includes index and toast space.
On Dec 21, 2009, at 7:46 AM, Magnus Hagander
wrote:
2009/12/21 Robert Haas :
On Mon, Dec 21, 2009 at 5:45 AM, Tim Bunce
wrote:
FYI Perl 5.6.0 was released in March 2000. 5.6.2 in November 2003.
Gosh, I feel old. I started on Perl 4.036.
What is worth a little bit of effort to establish
On sön, 2009-12-20 at 22:02 +0200, Marko Tiikkaja wrote:
> On 2009-12-20 18:20 +0200, Tom Lane wrote:
> > James William Pye writes:
> >> But it doesn't seem to want to stop configure'ing on my fbsd8/amd64 box:
> >
> > Usually that means timestamp skew, ie file timestamps are later than
> > your sy
On Mon, Dec 21, 2009 at 12:56 PM, Heikki Linnakangas
wrote:
> Simon Riggs wrote:
>> I notice that during copy_heap_data() we make no attempt to skip pages
>> that are all visible according to the visibilitymap. It seems like it
>> would be a substantial win to copy whole blocks if all the
>> pre-c
On Mon, Dec 21, 2009 at 11:43 AM, Pavel Stehule wrote:
>> If we don't find a way to optimize this for on-disk tuplestores though
>> then I wonder whether it's worth it. It would only help in the narrow
>> case that you had a large enough set to see the difference between
>> doing quickselect and q
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello
I wonder why the function pg_relation_size(text) does not take into
account the space used by toast data in a table when returning the space
used by the table.
As an administrator I would expect pg_total_relation_size() to return
data+toast+ind
Tom Lane wrote:
>> "The validator function must take two arguments: one of type text[], which
>> will contain the array of options as stored in the system catalogs, and one
>> of type oid, which will be the OID of the system catalog containing the
>> options, or zero if the context is not known."
>
Simon Riggs wrote:
> I notice that during copy_heap_data() we make no attempt to skip pages
> that are all visible according to the visibilitymap. It seems like it
> would be a substantial win to copy whole blocks if all the
> pre-conditions are met (I see what they are). I'm surprised to see that
On Fri, Dec 18, 2009 at 11:42 AM, Fujii Masao wrote:
> Okey. Design clarification again;
>
> 0. Begin by connecting to the master using PQconnectdb() with new conninfo
> option specifying the request of replication. The startup packet with the
> request is sent to the master, then the backend swit
2009/12/21 Robert Haas :
> On Mon, Dec 21, 2009 at 5:45 AM, Tim Bunce wrote:
>> FYI Perl 5.6.0 was released in March 2000. 5.6.2 in November 2003.
>
> Gosh, I feel old. I started on Perl 4.036.
>
>>> What is worth a little bit of effort to establish is exactly what
>>> version of Perl we're alrea
2009/12/21 Robert Haas :
> On Mon, Dec 21, 2009 at 1:03 AM, Pavel Stehule
> wrote:
>> 2009/12/21 Robert Haas :
>>> On Mon, Nov 16, 2009 at 5:01 PM, Pavel Stehule
>>> wrote:
Hello
now - complete patch
ToDo:
* enhance a documentation (any volunteer?)
* check nam
On Mon, Dec 21, 2009 at 5:45 AM, Tim Bunce wrote:
> FYI Perl 5.6.0 was released in March 2000. 5.6.2 in November 2003.
Gosh, I feel old. I started on Perl 4.036.
>> What is worth a little bit of effort to establish is exactly what
>> version of Perl we're already depending on, so that we can do
On Mon, Dec 21, 2009 at 1:03 AM, Pavel Stehule wrote:
> 2009/12/21 Robert Haas :
>> On Mon, Nov 16, 2009 at 5:01 PM, Pavel Stehule
>> wrote:
>>> Hello
>>>
>>> now - complete patch
>>>
>>> ToDo:
>>> * enhance a documentation (any volunteer?)
>>> * check name for backslash command
>>
>> I read thr
2009/12/21 Greg Stark :
> On Mon, Dec 21, 2009 at 5:48 AM, Pavel Stehule
> wrote:
>> Information about count of rows are not detected in planner time. This
>> have to by available in any executor's sort node. So this value will
>> be available every time - index scan is problem. Interesting is G
On Mon, 2009-12-21 at 18:42 +0900, Hiroyuki Yamada wrote:
> Do you think this problem is must-fix for the final release ?
We should be clear that this is a behaviour I told you about, not a
shock discovery by yourself. There is no permanent freeze, just a wait,
from which the Startup process wake
On Mon, 2009-12-07 at 16:55 +0900, Itagaki Takahiro wrote:
> Tom Lane wrote:
>
> > You should take those out again; if I am the committer I certainly will.
> > Such a test will guarantee complete instability of every other
> > regression test, and it's not worth it.
>
> I read the original comme
I've submitted this patch to the open CommitFest
https://commitfest.postgresql.org/action/patch_view?id=245
Tim.
On Wed, Nov 25, 2009 at 03:36:25PM +, Tim Bunce wrote:
> Following on from my earlier draft plperl.c refactoring patch, here's a
> new version that's complete (from my perspective
On Sun, Dec 20, 2009 at 10:55:55PM -0500, Robert Haas wrote:
> On Sun, Dec 20, 2009 at 10:23 PM, Tom Lane wrote:
> > Andres Freund writes:
> >> On Monday 21 December 2009 02:23:39 Robert Haas wrote:
> >>> A more important point is whether we really need to make this
> >>> dependent on Perl 5.6 or
On Mon, Dec 21, 2009 at 5:48 AM, Pavel Stehule wrote:
> Information about count of rows are not detected in planner time. This
> have to by available in any executor's sort node. So this value will
> be available every time - index scan is problem. Interesting is Greg's
> info about O(N) algorith
>The problem you mention here has been documented and very accessible for
>months and not a single person mentioned it up to now. What's more, the
>equivalent problem happens in the latest production version of Postgres
>- users can delay VACUUM endlessly in just the same way, yet I've not
>seen t
>Following question may be redundant. Just a confirmation.
>
>Deadlock example is catstrophic while it's rather a rare event.
>On the other hand, LockBufferForCleanup() can cause another
>problem.
>
> * One idle pin-holder backend can freeze startup process().
>
>This problem is not catstrophic,
Simon Riggs wrote:
> On Sat, 2009-12-19 at 20:59 +0200, Heikki Linnakangas wrote:
>> I put them on the TODO list at
>> https://wiki.postgresql.org/wiki/Hot_Standby_TODO, under the must-fix
>> category.
>
> I notice you also re-arranged other items on there, specifically the
> notion that starting
On Mon, 2009-12-21 at 04:02 +0100, Andres Freund wrote:
> The logic behind this seems fine except in the case of dropping a database.
> There you very well might have a open connection without an open snapshot.
Yes, you're right, thanks for the report.
I re-arranged the logic there recently to
66 matches
Mail list logo
