Hi,
Seems like you can't use uint on windows, it fails trying to compile this:
typedef struct xl_xact_commit
{
TimestampTz xact_time; /* time of commit */
+ int slotId; /* slotId in procarray
*/
+ uintxinfo;
On Mon, Nov 10, 2008 at 09:38:58AM -0800, David E. Wheeler wrote:
I'd be happy to, but I haven't really been following this thread. What
does it do, and how do I make sure it continues to work as I refactor
it?
Just run parse.pl pgsql/src/backend/parser/gram.y preproc.y and compare the
There seems to be a lot of duplication in the libpq documentation
between the connection string parameters and the environment variables.
They are close to identical but not exactly (for example, there is a
and vs or change in PGSSLMODE/sslmode).
Any reason not to just have the environment
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Any reason not to just have the environment variable documentation refer
back to the connection option documentation?
Well, not all of 'em are connection options.
I could see documenting the connection options more like the
Gianni Ciolli wrote:
On Tue, Oct 28, 2008 at 08:59:53PM +0100, Magnus Hagander wrote:
The attached patch tries to implement regexp support in the usermaps
(pg_ident.conf).
Hi Magnus,
I am currently reviewing your patch.
Hi!
Thanks for the review!
I found out that the execution of
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
I just noticed that if you have libpq with SSL support, but psql
without, we don't print any SSL information at all. Would it be
worthwhile to have it print that SSL is in use, even if we can't print
the details about the connection?
Zdenek Kotala wrote:
Bruce Momjian napsal(a):
Zdenek Kotala wrote:
In the last week community made decision about pg_upgrade project and its
implementation. I would like to try summarize this conclusion and I add
other
topic which should be finished for 8.4.
Convert on read has
Bruce Momjian napsal(a):
Zdenek Kotala wrote:
Bruce Momjian napsal(a):
Zdenek Kotala wrote:
snip
1) Data does not fit on the new page. It will be solve by pre-upgrade check
which reserve space on each page, before upgrade.
Rather than specifying free space as an amount, I was thinking of
Do earlier versions work if built on this machine? Like 8.3-latest? My
guess is that it's something in mingw or the environment rather than
pg, but let's confirm that before trying to track down what..
/Magnus
On 11 nov 2008, at 06.56, Jaime Casanova
[EMAIL PROTECTED] wrote:
Hi,
I have an application where I am building a plan with SPI_plan and
then this plan is called multiple times. There is one free parameter
($1) to the plan. The issue is with the order of the values returned.
If $1 is identical during successive calls to SPI_execute_plan, is
there any guarantee that
On Mon, 2008-11-10 at 18:02 +0900, ITAGAKI Takahiro wrote:
That's because explain.log_analyze requires executor instruments,
and it's not free. I think we'd better to have an option to avoid
the overheads... Oops, I found my bug when force_instrument is
turned on. It should be enabled only
On Tue, Nov 11, 2008 at 11:33:41AM -0600, Tim Keitt wrote:
I have an application where I am building a plan with SPI_plan and
then this plan is called multiple times. There is one free parameter
($1) to the plan. The issue is with the order of the values returned.
If $1 is identical during
Alex Hunsaker wrote:
On Mon, Oct 20, 2008 at 05:50, Magnus Hagander [EMAIL PROTECTED] wrote:
$ SSLVERIFY=cn ./psql junk -h 192.168.0.2
psql: server common name 'bahdushka' does not match hostname
'192.168.0.2'FATAL: no pg_hba.conf entry for host 192.168.0.2, user
alex, database junk, SSL
Hi,
I am able to apply your patch successfully but I am still getting
compilation error
./configure --enable-depend --enable-cassert
make
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing
-fwrapv -I. -I../../../src/include
On Tue, Nov 11, 2008 at 11:33:41AM -0600, Tim Keitt wrote:
I have an application where I am building a plan with SPI_plan and
then this plan is called multiple times. There is one free parameter
($1) to the plan. The issue is with the order of the values returned.
If $1 is identical during
Sam Mason wrote:
On Tue, Nov 11, 2008 at 11:33:41AM -0600, Tim Keitt wrote:
I have an application where I am building a plan with SPI_plan and
then this plan is called multiple times. There is one free parameter
($1) to the plan. The issue is with the order of the values returned.
If $1 is
ITAGAKI Takahiro escreveu:
[Sorry for the delay. I'm preparing the final patch and in a day or so
I'll post it.]
I have a comment about reloptions of autovacuum parameters:
I'd like to have an easier way to extract individual parameters.
Alvaro Herrera [EMAIL PROTECTED] wrote:
Euler
Jaime Casanova [EMAIL PROTECTED] wrote:
i'm confused, original patch has this signature:
+ conv_strftime(char *src, size_t len, const char *format, const struct tm
*tm)
your's has:
+strftime_win32(char *dst, size_t dstlen, const char *format, const
you change all src for dst, just a
Brendan Jurd wrote:
On Sat, Nov 1, 2008 at 3:42 PM, Ron Mayer [EMAIL PROTECTED] wrote:
# Patch 3: cleanup.patch
Fix rounding inconsistencies and refactor interval input/output code
Compile, testing and regression tests all checked out.
I've picked up on a few code style issues, fixes
Alvaro Herrera wrote:
David Rowley escribió:
Or is sponsoring a feature paying money to people that already plan to
implement something?
Nobody on their mind would plan to implement the features being proposed
here ... I didn't look very far but it seems mainly nonsense.
Yeah, I would have
On Wed, Nov 12, 2008 at 5:32 AM, Ron Mayer
[EMAIL PROTECTED] wrote:
Brendan Jurd wrote:
* AdjustFractionalSeconds = AdjustFractSeconds
* AdjustFractionalDays = AdjustFractDays
Otherwise many lines were over 80 chars long.
And it happened often enough I thought the shorter name
was less
On Mon, Nov 10, 2008 at 01:41:23PM -0500, Tom Lane wrote:
I experimented with doing this and found that things seemed noticeably
uglier; for example in createdb_opt_item we have (ignoring the actions)
| TEMPLATE opt_equal name
| TEMPLATE opt_equal DEFAULT
Brendan Jurd wrote:
On Wed, Nov 12, 2008 at 5:32 AM, Ron Mayer
[EMAIL PROTECTED] wrote:
Brendan Jurd wrote:
* AdjustFractionalSeconds = AdjustFractSeconds
* AdjustFractionalDays = AdjustFractDays
Otherwise many lines were over 80 chars long.
And it happened often enough I thought the
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
Heikki, would it be reasonable to fix things so that a nonexistent FSM
fork is semantically the same as an empty one, and not create FSM until
there's actually something to put in it?
Possibly, but I'd like to understand what
Add in the tup_fetched column.
--
Greg Sabino Mullane
Index: doc/src/sgml/monitoring.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/monitoring.sgml,v
retrieving revision 1.62
diff -c -r1.62 monitoring.sgml
***
On Wed, Nov 12, 2008 at 6:13 AM, Ron Mayer
[EMAIL PROTECTED] wrote:
Brendan Jurd wrote:
I don't have any further gripes regarding this patch, apart from the
code style stuff I sent through in my previous post. Did you have any
response to those?
Yup - you were right again.
Applied them and
Hi,
While looking at the code base I have encountered a server crash in
to_timestamp function.
select TO_TIMESTAMP ( '2006 1', ' Q' );
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The
Heikki Linnakangas wrote:
I tried running this:
CREATE TEMPORARY TABLE footemp (id int4);
DROP TABLE footemp;
with pgbench -f, but can't see any meaningful difference between 8.3 and
CVS HEAD. Both can do about 300 tpm, or 700-800 with fsync=off. There
probably is a measurable difference
Ibrar Ahmed [EMAIL PROTECTED] writes:
While looking at the code base I have encountered a server crash in
to_timestamp function.
select TO_TIMESTAMP ( '2006 1', ' Q' );
server closed the connection unexpectedly
Looks like Heikki fixed this yesterday. It works here:
regression=# select
Brendan Jurd [EMAIL PROTECTED] writes:
On Wed, Nov 12, 2008 at 5:32 AM, Ron Mayer
[EMAIL PROTECTED] wrote:
Brendan Jurd wrote:
There are some very large-scale changes to the regression tests. ...
Previously, much (but IIRC not quite all) of the interval output stuff
rounded to the
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
Heikki, would it be reasonable to fix things so that a nonexistent FSM
fork is semantically the same as an empty one, and not create FSM until
there's actually something to put in it?
Possibly, but I'd like to
On Mon, Nov 10, 2008 at 11:03:37AM -0500, Tom Lane wrote:
* before committing we need to see the proposed diffs to the Makefiles
and the Windows build scripts.
Sure. I just committed the generated preproc.y file to see how it goes through
the buildfarm. I prefer to see the file is okay
[EMAIL PROTECTED] (Alvaro Herrera) writes:
David Rowley escribió:
Or is sponsoring a feature paying money to people that already plan to
implement something?
Nobody on their mind would plan to implement the features being proposed
here ... I didn't look very far but it seems mainly
Greg Sabino Mullane wrote:
Add in the tup_fetched column.
Applied, thanks.
//Magnus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Heikki Linnakangas wrote:
Tom Lane wrote:
Try several thousand temp tables within one transaction.
I ran into an interesting problem while doing that. I created a SQL
script with 1 CREATE TEMPORARY TABLE statements. After testing with
that a few times, I got this:
WARNING: out of
Heikki Linnakangas [EMAIL PROTECTED] writes:
What's happening is that there is simply so many temporary tables in
pg_class that when the new backend tries to clear them with
RemoveTempRelations, it runs out of lock space.
What happened to the original owner of the tables? It must have had
At a guess it's related to the float8-is-pass-by-value patch.
greg
On 11 Nov 2008, at 06:17 PM, Magnus Hagander [EMAIL PROTECTED]
wrote:
Do earlier versions work if built on this machine? Like 8.3-latest?
My guess is that it's something in mingw or the environment rather
than pg, but
Peter Eisentraut wrote:
Alvaro Herrera wrote:
David Rowley escribi?:
Or is sponsoring a feature paying money to people that already plan to
implement something?
Nobody on their mind would plan to implement the features being proposed
here ... I didn't look very far but it seems
On Mon, Oct 20, 2008 at 05:50, Magnus Hagander [EMAIL PROTECTED] wrote:
Attached patch cleans up the certificate verification in libpq, and adds
a configuration paraqmeter to control it. The new parameter is
sslverify, and can be set to:
* cn = default = will validate that the certificate
Greg Stark [EMAIL PROTECTED] writes:
At a guess it's related to the float8-is-pass-by-value patch.
I doubt it. It looks like underflow-to-zero behavior, which we expect
on some other platforms ... but not mingw.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Heikki Linnakangas wrote:
oprofile does suggest that more time is spent in the kernel in CVS HEAD.
CVS HEAD:
3738713.9383 no-vmlinux postgres (no
symbols)
8.3:
27264 9.3254 no-vmlinux postgres (no
symbols)
What
I just noticed that if you have libpq with SSL support, but psql
without, we don't print any SSL information at all. Would it be
worthwhile to have it print that SSL is in use, even if we can't print
the details about the connection?
It's not something that's very common outside development
Magnus Hagander [EMAIL PROTECTED] writes:
I just noticed that if you have libpq with SSL support, but psql
without, we don't print any SSL information at all. Would it be
worthwhile to have it print that SSL is in use, even if we can't print
the details about the connection?
I think the
Bruce Momjian napsal(a):
Zdenek Kotala wrote:
In the last week community made decision about pg_upgrade project and its
implementation. I would like to try summarize this conclusion and I add other
topic which should be finished for 8.4.
Convert on read has been selected as a good way,
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
What's happening is that there is simply so many temporary tables in
pg_class that when the new backend tries to clear them with
RemoveTempRelations, it runs out of lock space.
What happened to the original owner of the tables? It
Alvaro Herrera wrote:
Heikki Linnakangas wrote:
oprofile does suggest that more time is spent in the kernel in CVS HEAD.
CVS HEAD:
3738713.9383 no-vmlinux postgres (no
symbols)
8.3:
27264 9.3254 no-vmlinux postgres
On Tue, Nov 11, 2008 at 12:17 PM, Magnus Hagander [EMAIL PROTECTED] wrote:
Do earlier versions work if built on this machine? Like 8.3-latest? My guess
is that it's something in mingw or the environment rather than pg, but let's
confirm that before trying to track down what..
actually seems
Jaime Casanova wrote:
On Tue, Nov 11, 2008 at 12:17 PM, Magnus Hagander [EMAIL PROTECTED] wrote:
Do earlier versions work if built on this machine? Like 8.3-latest? My guess
is that it's something in mingw or the environment rather than pg, but let's
confirm that before trying to track down
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
Heikki, would it be reasonable to fix things so that a nonexistent FSM
fork is semantically the same as an empty one, and not create FSM until
there's actually something to put in it?
Possibly, but I'd like to
Magnus Hagander wrote:
I have developed the attached patch, which documents the inability to
use MD5 with db_user_namespace, and throws an error when it is used:
psql: FATAL: MD5 authentication is not supported when
db_user_namespace is enabled
IMHO it would be much nicer to
On Tue, Nov 11, 2008 at 4:32 PM, Magnus Hagander [EMAIL PROTECTED] wrote:
Jaime Casanova wrote:
On Tue, Nov 11, 2008 at 12:17 PM, Magnus Hagander [EMAIL PROTECTED] wrote:
Do earlier versions work if built on this machine? Like 8.3-latest? My guess
is that it's something in mingw or the
Tom Lane wrote:
...failure case ... interval 'P-1Y-2M3DT-4H-5M-6';
This isn't the result I'd expect, and AFAICS the ISO spec does *not*
allow any unit markers to be omitted in the format with designators.
Yes, this is true. I see you already made the change.
Tom Lane wrote:
Applied with
Hi ITAGAKI-san.
Sorry, very late reaction..
I lost time resources in an individual my machine trouble and busyness.:-(
Now, I appreciate your exact work. ! Then, I desire the best patch for PostgreSQL.
Probably, I think that it is finally helpful in not a problem of only Japan but many
2008/11/10 Hitoshi Harada [EMAIL PROTECTED]:
2008/11/9 David Rowley [EMAIL PROTECTED]:
I'm having a little trouble understanding the standard for NTH_VALUE(). I
would have assumed that NTH_VALUE(name,1) would return the first name in the
window. The current patch is using 0 for the first.
Have we made any progress on this, namely better documentation and
removing the Win32 delay code?
---
Andrew Dunstan wrote:
Simon Riggs wrote:
Well, this is a strange conclusion, leaving me slightly bemused.
The
Tom Lane wrote:
Kevin Grittner [EMAIL PROTECTED] writes:
That would make the file creation and unlink just under half the load.
Worst possible case :-( ... means that we wouldn't get much improvement
without addressing both aspects.
It strikes me however that this does put some urgency into
Euler Taveira de Oliveira wrote:
We will have an official function (getRelOptions()?) to extract the
reloption (autovacuum) parameters because we need to transform
pg_autovacuum catalog table in a view to maintain backward compatibility.
Why? I'd say don't waste your time. If anything, it
Magnus Hagander [EMAIL PROTECTED] writes:
Any reason not to just have the environment variable documentation refer
back to the connection option documentation?
Well, not all of 'em are connection options.
I could see documenting the connection options more like the
GUC-variable options, ie a
Magnus Hagander wrote:
Well, I was mostly thinking like:
PGSSLMODE
This corresponds to the linksslmode/link connection option.
Then for those that aren't connection options, we'd keep the full
description. I'm not advocating we remove the whole chapter, just the
duplicated stuff. (I
I have a fairly large TODO list, and Simon has thrown in the towel (and
I imagine he also has a large TODO list).
anyone else want to step in?
cheers
andrew
Bruce Momjian wrote:
Have we made any progress on this, namely better documentation and
removing the Win32 delay code?
Robert Haas wrote:
Heikki,
I was assigned as a round-robin reviewer for this patch, but it looks
to me like it is still WIP, so I'm not sure how much effort it's worth
putting in at this point. Do you plan to finish this for 8.4, and if
so, should I wait for the next version before reviewing
On Tue, Nov 11, 2008 at 4:48 PM, Jaime Casanova
[EMAIL PROTECTED] wrote:
On Tue, Nov 11, 2008 at 4:32 PM, Magnus Hagander [EMAIL PROTECTED] wrote:
Jaime Casanova wrote:
On Tue, Nov 11, 2008 at 12:17 PM, Magnus Hagander [EMAIL PROTECTED] wrote:
Do earlier versions work if built on this machine?
On Mon, 2008-11-10 at 19:15 -0500, Tom Lane wrote:
The reason I was thinking about heap_lock_tuple is that it might provide
a suitable defense against that case.
OK. Lock tuple works OK, but its the unlock that I'm worried about. How
would non-transactional un-lock tuple work?
--
Simon
What if the block of text is split in the middle of a multibyte character?
I don't think it is safe to assume raw blocks always end on a character
boundary.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Okay, so Bruce got in Perl hacking mode today and wrote a script to
munge the message-ids. If you look at our archives you'll notice that
on each message the Message-Id header is now a proper link to the
message itself using the message-id-style URL, and it is no longer
munged by the no spam
Ron Mayer [EMAIL PROTECTED] writes:
Brendan Jurd wrote:
I don't have any further gripes regarding this patch, apart from the
code style stuff I sent through in my previous post. Did you have any
response to those?
Yup - you were right again.
Applied them and updated the website and
The patch can be built and executed, and automatically insert/update/delete
action on the view based on single table is worked.
Tom Lane wrote:
The original INT64 coding here is exact (at least for the common case
where fval is zero) but I'm not convinced that your revision can't
suffer from roundoff error.
Good point. I'll study this tonight; and either try to make a patch
that'll be exact where fval's zero or try to
Ron Mayer [EMAIL PROTECTED] writes:
Once this settles I suppose I should post a ECPG patch that's based
off of these Decode/Encode interval functions too?
Yeah, if you want. I think you'll find that the datetime code has
drifted far enough since ecpg forked it that you'll be looking at a
Euler Taveira de Oliveira [EMAIL PROTECTED] wrote:
We will have an official function (getRelOptions()?) to extract the
reloption (autovacuum) parameters
Yeah, I want it, but...
because we need to transform
pg_autovacuum catalog table in a view to maintain backward compatibility.
I don't
Heikki Linnakangas [EMAIL PROTECTED] writes:
I'd really like to work on this to get it into 8.4, but being honest to
myself, I don't think I have the time to finish and benchmark it. I'm
swamped with reviewing other's patches, as well as with non-PG-related
work. I have some work to do on
Hi,
Can anyone explain the way to debug this kind of situation and/or
explain the meaning of these locks?
Partial output of select * from pg_locks:
| | 1192675195 | 62860 | ShareLock | f
| | 1192675195 | 62814 | ExclusiveLock | t
Sorry, should RTFM more closely:
If a transaction is waiting for a row-level lock, it will usually
appear in the view as waiting for the transaction ID
of the current holder of that row lock.
so I need to look at the row locks on the blocker.
Philip Warner wrote:
Hi,
Can anyone
Philip Warner [EMAIL PROTECTED] writes:
Partial output of select * from pg_locks:
| | 1192675195 | 62860 | ShareLock | f
| | 1192675195 | 62814 | ExclusiveLock | t
| | 1192675195 | 62838 | ShareLock |
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2008-11-10 at 19:15 -0500, Tom Lane wrote:
The reason I was thinking about heap_lock_tuple is that it might provide
a suitable defense against that case.
OK. Lock tuple works OK, but its the unlock that I'm worried about. How
would
Tom Lane wrote:
Neither are we, because you left out all the columns that might tell
that ...
The columns are actually blankit's the other rows I left out with
the row-level locks:
925282231 | 925280527 | | 62814 | RowExclusiveLock| t
925282208 | 925280527 |
I haven't done a full review of this patch, but here are some thoughts
based on a quick read-through:
- make check fails 16 of 118 tests for me with this patch applied.
- There are some unnecessary hunks in this diff. For example, some of
the gram.y changes appear to move curly braces around,
On Tue, Nov 11, 2008 at 06:16, Magnus Hagander [EMAIL PROTECTED] wrote:
Alex Hunsaker wrote:
On Mon, Oct 20, 2008 at 05:50, Magnus Hagander [EMAIL PROTECTED] wrote:
$ SSLVERIFY=cn ./psql junk -h 192.168.0.2
psql: server common name 'bahdushka' does not match hostname
'192.168.0.2'FATAL: no
It might be helpful to look at pg_stat_activity.
...Robert
On Tue, Nov 11, 2008 at 10:08 PM, Philip Warner [EMAIL PROTECTED] wrote:
Tom Lane wrote:
Neither are we, because you left out all the columns that might tell
that ...
The columns are actually blankit's the other rows I left out
On 12 nov 2008, at 05.28, Alex Hunsaker [EMAIL PROTECTED] wrote:
On Tue, Nov 11, 2008 at 06:16, Magnus Hagander [EMAIL PROTECTED]
wrote:
Alex Hunsaker wrote:
On Mon, Oct 20, 2008 at 05:50, Magnus Hagander
[EMAIL PROTECTED] wrote:
$ SSLVERIFY=cn ./psql junk -h 192.168.0.2
psql: server
Just wanted to close off this thread.
Previously I reported that building 8.3.4 with MingW on Windows resulted
in an initdb executable that couldn't create new databases due to
security restrictions in creating global file mappings in Vista.
I'm happy to say that the problem seems fixed in
On Mon, Nov 10, 2008 at 11:31:33PM +, Gregory Stark wrote:
No, I just meant that you could calculate the CRC by scanning the whole buffer
efficiently using one of the good word-wise CRC algorithms, then look at the
line pointers to find the hint bits and subtract them out of the CRC. The
82 matches
Mail list logo