Jim Nasby wrote:
I've also seen large shared buffer settings perform poorly outside of IO
issues, presumably due to some kind of internal lock contention. I tried
running 8.3 with 24G for a while, but dropped it back down to our default of 8G
after noticing some performance problems. Unfortuna
On Tue, 2010-04-20 at 21:03 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > Following patch writes a new WAL record that just says "copy foo to
> > newts" and during replay we flush buffers and then re-execute the copy
> > (but only when InArchiveRecovery). So the copy happens locally on the
> >
On Wed, 2010-04-21 at 15:09 +1200, Mark Kirkwood wrote:
> I did some testing of this patch (v2). Unfortunately I don't have access
> to hardware capable of doing tests at the same scale as Erik used.
> However I was still able to show a consistent difference (I think)
> between standby performa
On Tue, Apr 20, 2010 at 7:13 PM, Tom Lane wrote:
> Robert Haas writes:
>> I suppose the problem here is that pg_attribute and pg_class are not
>> shared catalogs, so we can't read them without selecting a database.
>
> Among other things.
>
>> What about making a fake version of these relations t
On Tue, Apr 20, 2010 at 11:09 PM, Mark Kirkwood
wrote:
> Robert Haas wrote:
>>
>> So, does anyone have a few cycles to test this out? We are down to
>> handful of remaining open items, so getting this tested and committed
>> sooner = beta sooner.
>>
>>
>>
>
> I did some testing of this patch (v2)
Fujii Masao writes:
> On Wed, Apr 21, 2010 at 8:49 AM, Robert Haas wrote:
>> On Apr 20, 2010, at 7:06 PM, Tom Lane wrote:
>>> Should we change this? It seems to me to be a good thing on security
>>> grounds if replication connections can't be made through a generic
>>> pg_hba entry.
>>
>> +1.
Robert Haas wrote:
So, does anyone have a few cycles to test this out? We are down to
handful of remaining open items, so getting this tested and committed
sooner = beta sooner.
I did some testing of this patch (v2). Unfortunately I don't have access
to hardware capable of doing tests a
On Wed, Apr 21, 2010 at 8:49 AM, Robert Haas wrote:
> On Apr 20, 2010, at 7:06 PM, Tom Lane wrote:
>> I spent a fair amount of time just now being confused about why
>> pg_hba.conf restrictions on replication connections didn't seem to be
>> getting enforced. After looking at the code, I realize
Hiroshi Inoue wrote:
> 1. How does it work when LC_MONETARY and LC_NUMERIC are different?
I think it is rarely used, but possible. Fixed.
> 2. Calling db_encoding_strdup() for lconv->grouping is appropriate?
Ah, we didn't need it. Removed.
Revised patch attached. Please test it.
Regards,
--
On Tue, Apr 20, 2010 at 11:01 PM, Robert Haas wrote:
>> 3. Your proposal
>> Treat superuser replication connection like non-superuser one
>
> Well, only for this one very specific purpose. I would adjust the
> docs like this:
>
> Determines the number of connection "slots" that are reserved fo
Josh Berkus writes:
> vacuum...ERROR: canceling autovacuum task
> CONTEXT: automatic analyze of table "bench.public.pgbench_accounts"
> ERROR: canceling autovacuum task
> CONTEXT: automatic analyze of table "bench.public.pgbench_accounts"
> done.
> What happened above is that the build of the
Simon Riggs writes:
> Following patch writes a new WAL record that just says "copy foo to
> newts" and during replay we flush buffers and then re-execute the copy
> (but only when InArchiveRecovery). So the copy happens locally on the
> standby, not copying from primary to standby. We do this just
Robert Haas writes:
> Current logic says we hit the connection limit if:
> if (!am_superuser &&
> ReservedBackends > 0 &&
> !HaveNFreeProcs(ReservedBackends))
> Couldn't we just change this to:
> if ((!am_superuser || am_walsender) &&
>
On Apr 20, 2010, at 7:06 PM, Tom Lane wrote:
> I spent a fair amount of time just now being confused about why
> pg_hba.conf restrictions on replication connections didn't seem to be
> getting enforced. After looking at the code, I realize that my entry
> with database = "replication" was indeed
Robert Haas writes:
> I suppose the problem here is that pg_attribute and pg_class are not
> shared catalogs, so we can't read them without selecting a database.
Among other things.
> What about making a fake version of these relations that includes only
> the shared catalogs?
Well, after you s
> That said, I'm not wedded to that message wording; feel free to propose
> something better.
Yeah, I'm looking to see if we can determine the difference between an
autovac which was cancelled by vacuum and one which was cancelled for
another reason.
--
-- Josh
I spent a fair amount of time just now being confused about why
pg_hba.conf restrictions on replication connections didn't seem to be
getting enforced. After looking at the code, I realize that my entry
with database = "replication" was indeed getting rejected as not
matching, but then the hba cod
Josh Berkus wrote:
>
> > Isn't this just because you ran the postmaster in the same terminal as
> > pgbench?
>
> Right, but those messages appear in the logs as well. I'm thinking of
> the reaction of anyone reading the logs ... since they wouldn't, at that
> time, know about a manual vacuum tha
Robert Haas escribió:
> I suppose the problem here is that pg_attribute and pg_class are not
> shared catalogs, so we can't read them without selecting a database.
> What about making a fake version of these relations that includes only
> the shared catalogs?
Hmm, interesting. I wonder if someth
On Tue, Apr 20, 2010 at 5:51 PM, Robert Haas wrote:
> On Tue, Apr 20, 2010 at 5:02 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Tue, Apr 20, 2010 at 2:24 PM, Tom Lane wrote:
3. We'd have to nail pg_authid, pg_auth_members, and their indexes into
relcache, because relcache.c isn't
On Tue, Apr 20, 2010 at 5:02 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Apr 20, 2010 at 2:24 PM, Tom Lane wrote:
>>> 3. We'd have to nail pg_authid, pg_auth_members, and their indexes into
>>> relcache, because relcache.c isn't prepared to cope otherwise. I doubt
>>> this would affect
Alvaro Herrera writes:
> Tom Lane escribió:
>> 2. We don't have infrastructure that would allow access to out-of-line
>> toasted fields during startup. Rather than try to add such, I propose
>> removing pg_authid's toast table, with the consequence that rolpassword
>> cannot be long enough to req
> Isn't this just because you ran the postmaster in the same terminal as
> pgbench?
Right, but those messages appear in the logs as well. I'm thinking of
the reaction of anyone reading the logs ... since they wouldn't, at that
time, know about a manual vacuum that happened.
--
Robert Haas writes:
> On Tue, Apr 20, 2010 at 2:24 PM, Tom Lane wrote:
>> 3. We'd have to nail pg_authid, pg_auth_members, and their indexes into
>> relcache, because relcache.c isn't prepared to cope otherwise. I doubt
>> this would affect performance in any material way, but it would eat a
>>
Josh Berkus wrote:
> vacuum...ERROR: canceling autovacuum task
> CONTEXT: automatic analyze of table "bench.public.pgbench_accounts"
> ERROR: canceling autovacuum task
> CONTEXT: automatic analyze of table "bench.public.pgbench_accounts"
> done.
>
> What happened above is that the build of th
On Tue, Apr 20, 2010 at 4:08 PM, Josh Berkus wrote:
>> Improve behavior of SUSET GUC variables added by loadable modules?
>> - Tom's looking at this, too.
>
> Is this an issue specific to 9.0?
http://archives.postgresql.org/pgsql-hackers/2010-04/msg00865.php
...Robert
--
Sent via pgsql-hackers
All:
NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index
"pgbench_branches_pkey" for table "pgbench_branches"
NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index
"pgbench_tellers_pkey" for table "pgbench_tellers"
NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implic
> - Fix to_char('L') (localization) on Win32 when the operating system
> character encoding does not match the database encoding
> Seems like we're close to a fix on this, but even if not, I don't see
> why this should be considered a blocker for beta.
If this isn't an issue specific to 9.0, I ag
On Tue, Apr 20, 2010 at 12:07 PM, Jim Nasby wrote:
> On Apr 16, 2010, at 4:56 PM, Robert Haas wrote:
>> From reading this and other threads, I think I generally understand
>> that the perils of setting shared_buffers too high: memory is needed
>> for other things, like work_mem, a problem which is
On Tue, Apr 20, 2010 at 2:24 PM, Tom Lane wrote:
> 1. We'd have to force an initdb because of a couple of small catalog
> changes. This doesn't seem like a showstopper at this phase of the
> release cycle, but it's slightly annoying. pg_migrator could be used
> if anyone's really in need of it.
Greg Smith wrote:
pavelbaros wrote:
I am also waiting for approval for my repository named
"materialized_view" on git.postgresql.org, so I could publish
completed parts.
Presuming that you're going to wander there and get assigned what
looks like an official repo name for this project is a
Tom Lane escribió:
> 1. We'd have to force an initdb because of a couple of small catalog
> changes. This doesn't seem like a showstopper at this phase of the
> release cycle, but it's slightly annoying. pg_migrator could be used
> if anyone's really in need of it.
check
> 2. We don't have inf
I just noticed that
ALTER TABLE foo SET TABLESPACE new_tablespace;
doesn't optimise writing WAL, so when streaming enabled it will copy the
whole table to WAL and across the wire. My understanding was that ALTER
TABLE had been optimised, though not as much as could be in this case.
Following pa
On Tue, Apr 20, 2010 at 6:37 PM, Joshua D. Drake wrote:
> On Tue, 2010-04-20 at 18:23 +0100, Dave Page wrote:
>> On Tue, Apr 20, 2010 at 6:09 PM, Robert Haas wrote:
>>
>> > /me pushes luck
>> >
>> > And how about a set of back-branch releases while we're at it?
>>
>> Yes, please don't push your l
I wrote:
> ... So we could solve both this and
> the original complaint in the thread if we can arrange for all
> authentication to be done on the basis of shared-catalog access under
> rules similar to what the AV launcher does with pg_database. At a
> minimum that will require marking the pg_aut
On Apr 16, 2010, at 4:56 PM, Robert Haas wrote:
> From reading this and other threads, I think I generally understand
> that the perils of setting shared_buffers too high: memory is needed
> for other things, like work_mem, a problem which is exacerbated by the
> fact that there is some double buff
On Tue, 20 Apr 2010, Robert Haas wrote:
/me pushes luck
And how about a set of back-branch releases while we're at it?
We tend to try and avoid overlapping a "release" with a "beta" to avoid
confusion ... but didn't we just do a fresh back branch release anyway?
Marc G. Fournier
Tom forwarded it to RPM list.
I'll take care of it soon.
On Tue, 2010-04-20 at 05:51 -0700, Jamie Strachan wrote:
> Hello,
>
> I posted Bug #5430,
> "initdb script fails due to permissions of /usr/share/pgsql/"
>
> I would be happy to fix this bug and submit a patch.
> However, I don't seem to
On Tue, 2010-04-20 at 18:23 +0100, Dave Page wrote:
> On Tue, Apr 20, 2010 at 6:09 PM, Robert Haas wrote:
>
> > /me pushes luck
> >
> > And how about a set of back-branch releases while we're at it?
>
> Yes, please don't push your luck :-p
/me gives Dave an "Easy" button.
>
>
>
> --
> Dave
On Tue, Apr 20, 2010 at 6:09 PM, Robert Haas wrote:
> /me pushes luck
>
> And how about a set of back-branch releases while we're at it?
Yes, please don't push your luck :-p
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-hackers
Bruce Momjian escribió:
> Magnus Hagander wrote:
> > Yeah, +1. I always go to one of the other sources (most of the time,
> > the gitweb or git server).
> >
> > It doesn't hurt to attach it if it happens to be around, but I
> > wouldn't suggest spending any extra effort on it...
>
> Well, many t
Korry Douglas writes:
>> That will break the ability to call trim() with ordinary function
>> syntax.
> Hmm... it seems counterintuitive to call TRIM() using ordinary
> function syntax anyway. What would the argument list look like?
"foo, bar, baz", just like any other function. This is impo
I think it might be time to think about shipping a beta release. I
guess this is a -core decision, but I can't argue for it there, so
I'll argue for it here. It seems like we're about ready, so maybe we
could plan for a beta, say, a week from now?
Here's a quick run-down of the remaining open it
Robert Haas wrote:
> is it helpful to attach the patch-as-committed to the -hackers
> email, or is it just duplicative of what's already available
> elsewhere?
I'm fine with using git.postgresql.org to see what was committed.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
Magnus Hagander wrote:
> On Tue, Apr 20, 2010 at 18:30, Tom Lane wrote:
> > Robert Haas writes:
> >> Bruce suggested to me off-list that when I commit a patch with
> >> revisions, I ought to attach the committed patch to the email in which
> >> I say that I have committed it. ?I know that Bruce h
On Tue, Apr 20, 2010 at 18:30, Tom Lane wrote:
> Robert Haas writes:
>> Bruce suggested to me off-list that when I commit a patch with
>> revisions, I ought to attach the committed patch to the email in which
>> I say that I have committed it. I know that Bruce habitually does
>> this, but I've
It seems to me that trim_list should defined as:
trim_list:a_expr FROM a_expr { $$ = list_make2($3, $1); }
| FROM a_expr { $$ = list_make1($2); }
| a_expr{ $$ =
list_make1($1);
On mån, 2010-04-19 at 21:25 -0400, Bruce Momjian wrote:
> > > Oh, that is an interesting example. What the code does is if there are
> > > several spaces and the next word is on a tab stop, the spaces are
> > > convered to tabs, except if we are in a string. This conversion is done
> > > by 'entab
On Tue, Apr 20, 2010 at 12:41 PM, Tom Lane wrote:
> It looks to me like you're not supposed to be able to omit FROM if
> you've written a . Should we tighten our
> syntax to reject that?
I would think not. If we were doing this from scratch we might choose
to set it up that way, but I don't thi
Korry Douglas writes:
> It seems to me that trim_list should defined as:
>trim_list: a_expr FROM a_expr { $$ = list_make2($3, $1); }
> | FROM a_expr { $$ = list_make1($2); }
> | a_expr{
On Tue, Apr 20, 2010 at 12:27 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Wed, Feb 24, 2010 at 2:11 PM, Bruce Momjian wrote:
>> > Oleg, Teodor, would you look at this? ?I see the same behavior in 9.0.
>>
>> As there has been no movement on this I think we should punt this from:
>>
>> http
Robert Haas writes:
> Bruce suggested to me off-list that when I commit a patch with
> revisions, I ought to attach the committed patch to the email in which
> I say that I have committed it. I know that Bruce habitually does
> this, but I've never found it very helpful, since I prefer to look at
Robert Haas wrote:
> On Wed, Feb 24, 2010 at 2:11 PM, Bruce Momjian wrote:
> > Oleg, Teodor, would you look at this? ?I see the same behavior in 9.0.
>
> As there has been no movement on this I think we should punt this from:
>
> http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items
>
> to
Magnus Hagander wrote:
> On Mon, Apr 19, 2010 at 18:24, Peter Eisentraut wrote:
> > On m?n, 2010-04-19 at 17:02 +0200, Magnus Hagander wrote:
> >> The MSVC scripts currently have a "perltidy coding style" so we run
> >> perltidy with a specific set of arguments to format the code. (This is
> >> in
In gram.y, the productions for the TRIM() expression expect an
argument of trim_list:
TRIM '(' trim_list ')'
TRIM '(' TRAILING trim_list ')'
TRIM '(' LEADING trim_list ')'
TRIM '(' BOTH trim_list ')'
And trim_list is defined as:
trim_list:a_expr FROM expr
On Sun, Apr 18, 2010 at 8:55 PM, Robert Haas wrote:
> Thanks for the review. Committed with revisions along the lines you suggest.
Bruce suggested to me off-list that when I commit a patch with
revisions, I ought to attach the committed patch to the email in which
I say that I have committed it.
Bruce Momjian writes:
> Tom Lane wrote:
>> Actually, SQL:2008 does say that if an output column of the SELECT is
>> known not nullable, then the created table should have the NOT NULL
>> property for that column. We don't implement anything about "known not
>> nullable", though, so I'd view this
Tom Lane wrote:
> Nikhil Sontakke writes:
> > I think the semantics should be pretty ok as is. But I saw another DB
> > honoring the NOT NULL modifiers and hence the wonder if there is
> > something about this in the standards.
>
> Actually, SQL:2008 does say that if an output column of the SELEC
On Tue, Apr 20, 2010 at 8:51 AM, Jamie Strachan wrote:
> I posted Bug #5430,
> "initdb script fails due to permissions of /usr/share/pgsql/"
>
> I would be happy to fix this bug and submit a patch.
> However, I don't seem to see the RPM scripts in the source tree!
> Do they live somewhere else?
>
Hello,
I posted Bug #5430,
"initdb script fails due to permissions of /usr/share/pgsql/"
I would be happy to fix this bug and submit a patch.
However, I don't seem to see the RPM scripts in the source tree!
Do they live somewhere else?
Please reply by email, as I haven't subscribed to this list
Andrew Dunstan escribió:
> I've actually found LinkedIn to be tolerably unobtrusive. And they
> actually advise people fairly prominently to be careful about
> selecting contacts, e.g.:
The actual problem here is that LinkedIn for some reason adds the
mailing list address to your profile as if it
Boszormenyi Zoltan writes:
> is there a danger in using SpinLockAcquire() in
> a signal handler?
Yes. Actually, pretty much anything beyond setting a "volatile" flag
variable is too dangerous.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
Takahiro Itagaki wrote:
Magnus Hagander wrote:
1. setlocale(LC_CTYPE, lc_monetary)
2. setlocale(LC_MONETARY, lc_monetary)
3. lc = localeconv()
4. pg_do_encoding_conversion(lc->xxx,
FROM pg_get_encoding_from_locale(lc_monetary),
TO GetDatabaseEncoding())
5. Revert LC_CTYPE and LC_MONE
Tom Lane wrote:
> Robert Haas writes:
>> Fujii Masao wrote:
>>> 3. Your proposal
>>>Treat superuser replication connection like non-superuser one
>
>> Well, only for this one very specific purpose. I would adjust
>> the docs like this:
>
>> Determines the number of connection "slots" that
I wrote:
> Actually, while I'm looking at that code, a more immediate TODO is
> "fix walsender". Somebody has inserted an absolutely flight-of-fantasy
> code path into InitPostgres. (Hint: template1 can be dropped.
> ESPECIALLY when you're deliberately not taking any lock on it.)
Now that I look
Robert Haas writes:
> On Tue, Apr 20, 2010 at 9:47 AM, Fujii Masao wrote:
>> 3. Your proposal
>> Treat superuser replication connection like non-superuser one
> Well, only for this one very specific purpose. I would adjust the
> docs like this:
> Determines the number of connection "slots"
Robert Haas writes:
> http://blog.metasploit.com/2010/02/postgres-fingerprinting.html
> Assuming the situation really is as described here, I am wondering if
> we should suppress the F, L, and R output in this and similar cases
> and back-patch it all the way back. This seems like it is entirely
On Tue, Apr 20, 2010 at 9:47 AM, Fujii Masao wrote:
> Yeah, I agree with you, but the difference is only how to achieve.
> ISTM that there are three choices:
>
> 1. Heikki's proposal
>> ReservedBackends = superuser_reserved_connections + max_wal_senders
>> MaxBackends = max_connections + autovacuu
Robert Haas writes:
> On Mon, Apr 19, 2010 at 10:29 PM, Tom Lane wrote:
>> The reason it seems of concern for 9.0 is that now we have a custom
>> SUSET variable in plpgsql. If we don't fix this then we need to think
>> hard about the alternative of forcing the variable into the core code
>> to a
On Tue, Apr 20, 2010 at 7:52 PM, Robert Haas wrote:
> Let's just stop for a second and think about why we have
> superuser_reserved_connections in the first place. As I understand
> it, the point is that we want to make sure that superusers don't get
> locked out of the database, because superuse
Hi,
is there a danger in using SpinLockAcquire() in
a signal handler? I mean if e.g. a spinlock is already
taken by the process and a signal comes that's handler
wants to execute SpinLockAcquire() again, does it
lock up or simply increases the lock counter?
Thanks in advance,
Zoltán Böszörményi
On Tue, Apr 20, 2010 at 9:40 AM, Tom Lane wrote:
> Robert Haas writes:
>> If replication connections can use up superuser_reserved_connections
>> slots, then it's very possible that this safety valve will fail
>> completely.
>
> Only if replication can use up *all* the superuser_reserved_connecti
Robert Haas writes:
> If replication connections can use up superuser_reserved_connections
> slots, then it's very possible that this safety valve will fail
> completely.
Only if replication can use up *all* the superuser_reserved_connections
slots.
regards, tom lane
--
Magnus Hagander wrote:
> > Another idea is to use GetLocaleInfoW() [1], that is win32 native locale
> > functions, instead of the libc one. It returns locale characters in wide
> > chars, so we can safely convert them as UTF16->UTF8->db. But it requires
> > an additional branch in our locale codes
Robert Haas wrote:
> I don't care whether or not the replication connection is or is
> not technically a superuser connection. What I think is important
> is trying to preserve the ability for a superuser to log in
> interactively and clean up the mess even when the regular supply
> of connect
Takahiro Itagaki wrote:
>
> Magnus Hagander wrote:
>
> > > 1. setlocale(LC_CTYPE, lc_monetary)
> > > 2. setlocale(LC_MONETARY, lc_monetary)
> > > 3. lc = localeconv()
> > > 4. pg_do_encoding_conversion(lc->xxx,
> > > FROM pg_get_encoding_from_locale(lc_monetary),
> > > TO GetDatabaseEn
Magnus Hagander wrote:
> > One new idea would be to set LC_CTYPE to UTF16/widechars unconditionally
> > on Win32 and then just convert that always to the server encoding with
> > win32_wchar_to_db_encoding(), instead of using the encoding from
> > LC_MONETARY to set LC_CTYPE and having to do double
On Sun, Apr 18, 2010 at 4:22 PM, Simon Riggs wrote:
> On Sun, 2010-04-18 at 13:16 -0700, David Fetter wrote:
>> On Sun, Apr 18, 2010 at 12:01:05PM +0100, Simon Riggs wrote:
>> > On Sun, 2010-04-18 at 08:24 +0100, Simon Riggs wrote:
>> > > On Sat, 2010-04-17 at 18:52 -0400, Tom Lane wrote:
>> > > >
On Tue, Apr 20, 2010 at 5:53 AM, Fujii Masao wrote:
> On Tue, Apr 20, 2010 at 9:55 AM, Robert Haas wrote:
>>> How about wal_keep_segments?
>
> +1
>
>> Here's the patch.
>
> Seems OK.
Thanks, committed.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make cha
On Tue, Apr 20, 2010 at 5:47 AM, Fujii Masao wrote:
> On Tue, Apr 20, 2010 at 11:04 AM, Robert Haas wrote:
>> Instead of doing this, could we just change the logic in InitPostgres?
>>
>> Current logic says we hit the connection limit if:
>>
>> if (!am_superuser &&
>> Reserve
On Tue, Apr 20, 2010 at 9:55 AM, Robert Haas wrote:
>> How about wal_keep_segments?
+1
> Here's the patch.
Seems OK.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
On Tue, Apr 20, 2010 at 11:04 AM, Robert Haas wrote:
> Instead of doing this, could we just change the logic in InitPostgres?
>
> Current logic says we hit the connection limit if:
>
> if (!am_superuser &&
> ReservedBackends > 0 &&
> !HaveNFreeProcs(ReservedBac
Magnus Hagander wrote:
> > 1. setlocale(LC_CTYPE, lc_monetary)
> > 2. setlocale(LC_MONETARY, lc_monetary)
> > 3. lc = localeconv()
> > 4. pg_do_encoding_conversion(lc->xxx,
> > FROM pg_get_encoding_from_locale(lc_monetary),
> > TO GetDatabaseEncoding())
> > 5. Revert LC_CTYPE and LC_MO
83 matches
Mail list logo
