Tom,
> Another relevant question is why you are expecting to get this
> information through pgstats and not by looking in the postmaster log.
> I don't know about you, but I don't have any tools that are designed to
> cope nicely with looking at tables that have columns that might be many
> K wide
> > The switch statement could probably be done in a different way, but
> > there doesn't seem to be any good examples of how to return anyitem. If
> > anyone have a better way, please let me know.
>
> Why do you need the switch statement at all? array->elements is already
> an array of Datums.
On Fri, 5 Nov 2004, John Hansen wrote:
> Attached, array -> rows iterator.
>
> select * from unnest(array[1,2,3,4,5]);
>
> Unnest
> ---
> 1
> 2
> 3
> 4
> 5
> 5 rows
This mechanism is actually designed for the multiset data type in SQL.
AFAICT, our elementary one dimensional array
On Nov 5, 2004, at 7:09 AM, John Hansen wrote:
Attached, array -> rows iterator.
select * from unnest(array[1,2,3,4,5]);
This is really handy! But there is a problem...
The switch statement could probably be done in a different way, but
there doesn't seem to be any good examples of how to return a
Tom Lane wrote:
It's really a
performance issue: do you want to pay the penalty associated with
reassembling messages that exceed the loopback MTU [...]
BTW, the loopback MTU here is quite large:
[EMAIL PROTECTED]:~$ /sbin/ifconfig lo | grep MTU
UP LOOPBACK RUNNING MTU:16436 Metric:1
[E
Well, lets ask -hackers...
When COPYing data from a file, the file encoding is taken from the
client_encoding parameter. The JDBC driver always uses UNICODE as the
client_encoding and wants to prevent people from changing it by
monitoring ParameterStatus messages and erroring out if it's chan
Greg Stark <[EMAIL PROTECTED]> writes:
> That would have no downside and only benefits. The worst case is that a
> machine that didn't handle UDP fragment reassembly would drop the packets that
> postgres is currently dropping preemptively.
Huh? We're not dropping the query *entirely*, which is w
Greg Stark <[EMAIL PROTECTED]> writes:
> The only problem I see in raising the size of PGSTAT_MSG_PAYLOAD is that it
> also governs the size of PGSTAT_NUM_TABPURGE and PGSTAT_NUM_TABENTRIES.
> There's no need to grow those arrays and risk losing them. But these message
> sizes could just be left b
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > The pgstat messages are indeed fixed size.
>
> No, there's a fixed maximum size.
Hm. *rereads source*
It's true, pgstat_report_activity only sends the actual size of the query, not
the full payload size.
The only
Simon Riggs <[EMAIL PROTECTED]> writes:
> Recent runs of DBT-2 show very occasional ExclusiveLock (s) being held
> by transactions, sometimes waiting to be granted.
I think you are right that these reflect heap or btree-index extension
operations. Those do not actually take locks on the *table* h
Greg Stark <[EMAIL PROTECTED]> writes:
> The pgstat messages are indeed fixed size.
No, there's a fixed maximum size.
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> ISTM that what you have here is a bad substitute for using user locks
>> (see contrib/userlock/).
> Perhaps. I assume that the lock is automatically released when the
> holder closes its connection to the data
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> >>> What do you think is broken about fragmented UDP packets?
>
> > Fragmentation happens at the IP protocol level, the kernel is responsible
> > for
> > reassembly. There's nothing for the application level to handl
On Mon, 08 Nov 2004 13:07:34 -0500
Tom Lane <[EMAIL PROTECTED]> wrote:
> "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> > I checked the FAQ and docs but haven't found anything definitive.
> > This is my SQL test script:
>
> > SELECT pg_backend_pid();
> > SELECT * FROM pg_stat_activity order by
Recent runs of DBT-2 show very occasional ExclusiveLock (s) being held
by transactions, sometimes waiting to be granted.
On Sat, Nov 06, 2004 at 11:40:49AM +, Simon Riggs wrote:
> > The lockstats just show there's all those Exclusive Locks on
order_line, right?:
>
> http://www.osdl.org/pro
> Hi all,
>
> I need a help and an advice on playing around execution plans. I need a
> direct
> access to a 'plan structure' and change some fields. Even one step more, I
> need to create an execution plan directly w/o issuing an SQL statement (i.e.
>
> skipping parser and optimizer phases) a
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> I checked the FAQ and docs but haven't found anything definitive. This
> is my SQL test script:
> SELECT pg_backend_pid();
> SELECT * FROM pg_stat_activity order by procpid;
> When I run psql reading that I find that my backend procpid is not in
>
On Mon, 08 Nov 2004 12:56:57 -0500
Jan Wieck <[EMAIL PROTECTED]> wrote:
Hi Jan.
> On 11/8/2004 12:03 PM, D'Arcy J.M. Cain wrote:
>
> > I checked the FAQ and docs but haven't found anything definitive.
> > This is my SQL test script:
> >
> > SELECT pg_backend_pid();
> > SELECT * FROM pg_stat_ac
Jan Wieck <[EMAIL PROTECTED]> writes:
> On 11/4/2004 5:44 PM, Tom Lane wrote:
>> autovacuum would probably be a reasonable place to put it. We don't
>> currently have any good way for autovacuum to get at the information,
>> but I suppose that an integrated autovacuum daemon could do so.
> Don't
On 11/8/2004 12:03 PM, D'Arcy J.M. Cain wrote:
I checked the FAQ and docs but haven't found anything definitive. This
is my SQL test script:
SELECT pg_backend_pid();
SELECT * FROM pg_stat_activity order by procpid;
When I run psql reading that I find that my backend procpid is not in
the list. I
Andrew Dunstan schrieb:
with CVS tip in contrib/spi:
ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels
-fno-strict-aliasing -DREFINT_VERBOSE -I. -I../../src/include -c -o
timetravel.o timetravel.c
dlltool --export-all --output-def timetravel.def timetravel.o
dllwrap -o t
I checked the FAQ and docs but haven't found anything definitive. This
is my SQL test script:
SELECT pg_backend_pid();
SELECT * FROM pg_stat_activity order by procpid;
When I run psql reading that I find that my backend procpid is not in
the list. I know that I can see it if I can introduce a l
with CVS tip in contrib/spi:
ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels
-fno-strict-aliasing -DREFINT_VERBOSE -I. -I../../src/include -c -o
timetravel.o timetravel.c
dlltool --export-all --output-def timetravel.def timetravel.o
dllwrap -o timetravel.dll --def time
Marc G. Fournier wrote:
> On Mon, 8 Nov 2004, Bruce Momjian wrote:
>
> > Marc G. Fournier wrote:
> >>
> >> Just curious, but in what sort of circumstance could this happen?
> >> Permissions problems, that sort of thing?
> >
> > Restoring a dump to another system that doesn't have the same
> > dire
On Mon, 8 Nov 2004, Bruce Momjian wrote:
Marc G. Fournier wrote:
Just curious, but in what sort of circumstance could this happen?
Permissions problems, that sort of thing?
Restoring a dump to another system that doesn't have the same
directories to create the tablespaces.
'k, that's what I thought
On 11/4/2004 5:44 PM, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
Moved to -hackers where this belongs :)
On Fri, 5 Nov 2004, Justin Clift wrote:
Would making max_fsm_relations and max_fsm_pages dynamically update
themselves whilst PostgreSQL runs be useful?
Possibly, but it is
Marc G. Fournier wrote:
>
> Just curious, but in what sort of circumstance could this happen?
> Permissions problems, that sort of thing?
Restoring a dump to another system that doesn't have the same
directories to create the tablespaces.
Just curious, but in what sort of circumstance could this happen?
Permissions problems, that sort of thing?
On Sat, 6 Nov 2004, Bruce Momjian wrote:
Log Message:
---
Remove:
* Allow database recovery where tablespaces can't be created
When a pg_dump is restored, all tablespaces will atte
Hi,
Related to the definition of __DLL_IMPORT below, the cygwin port of
glib/gmodule just does the following:
#define G_MODULE_IMPORT extern
#ifdef G_PLATFORM_WIN32
# define G_MODULE_EXPORT __declspec(dllexport)
#else /* !G_PLATFORM_WIN32 */
# define G_MODULE_EXPORT
Tom Lane wrote:
Neil Conway <[EMAIL PROTECTED]> writes:
Ah, okay. I'll remove gistscancache() then, as this seems to be dead
code.
Is there someone out there that can instrument the code with Rational
Coverage in order to see how much dead code is still there ? Or at least
see how much code is use
Tom Lane wrote:
> Greg Stark <[EMAIL PROTECTED]> writes:
>
What do you think is broken about fragmented UDP packets?
>
>
>>Fragmentation happens at the IP protocol level, the kernel is responsible for
>>reassembly. There's nothing for the application level to handle.
>
>
> And, by the same toke
On Sun, 2004-11-07 at 21:31, Tom Lane wrote:
> "Katsaros Kwn/nos" <[EMAIL PROTECTED]> writes:
> > More precisely,when I call (my_)SPI_prepare the following message comes
> > exactly at the point where (my_)SPI_end_call(true) is called:
>
> > WARNING: problem in alloc set my_SPI Exec: detected wri
> > We have the following warning on Windows:
> > pgarch.c:349: warning: implicit declaration of function `sleep'
>
> > To fix it we could include the right header (which appears to be
> > in the Windows/Mingw case), or we could replace
> the call by
> > a call to pg_usleep().
>
> is include
Ameen - Etemady wrote:
> I want to create a data type that have tow arguments in the
> defenition, like the varchar type:
This is not possible.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 4: Don't 'ki
I want to create a data type that have tow arguments in the defenition,
like the varchar type:
create table mytmp(name varchar(10));
I like to do it like this:
create table mytmp(name myvarchar(10,"en_US"));
how can it be done by "CREATE TYPE"
I want to implement the internal functions (compare,
35 matches
Mail list logo
